It’s very complex with hyper visors and virtualization technology. I don’t fully understand it myself in terms of how resources are allocated across something like aws or azure, but take a look at openshift vs openstack maybe. Openshift is for deploying containers and openstack is virtual machines. Openshift is kubernetes with some customizations for enterprise. Openstack is same for vm’s.

Instances are virtual machines which tend to host an operating system, and a container is lighter and only hosts an application where the code and dependencies are isolated from the underlying operating system it runs on. k8 is kubernetes, which is container orchestration. I think of virtual machines for jobs that scale vertically, while containers are suited to jobs that scale horizontally. But this isn’t necessarily true as kubernetes is starting to get slurm functionality using tools like sunk.

For integrating these things it depends on the application. You can run services in either by exposing ports and interact through API end points that point at them, eg for frontend web app serving data from a database hosted on a server or a container via fastapi. But I’m no dev ops engineer and the field is very complicated. There are many discussions around building micro services (containers) vs monolith (vm). Many decisions depend on the project. Hopefully some actual dev ops engineers will chime in and correct all of the above! xD

I’m interested in the same question. There isn’t a definitive text because the problem is infinitely broad. My approach is to build crud apps around the tech stack I’m interested in, currently Python with fastapi, arangodb, with some next and typescript for the front end. But you could swap out Python for Go and swagger. For security there is Keycloak. For scalability you could look at building your system as pods in open shift but that adds cost. Personally, I think unless you’re Netflix kubernetes is probably overkill. But the biggest problem is that today’s tech stack is replaced tomorrow by the next new shiny, and all of them are complex and will be entirely different for every team and every problem. A book for dev ops is almost impossible.

deleted by creator

To flip this around, think of some projects you want to do. The languages are just tools and will be determined by what you want to do, and then each type of project has it’s best tool chain. Think of the problem(s) you want to solve first and the rest will follow.