21–30 of 446 posts
Earlier quoted context omitted.
The commercial, licensed software I've dealt with in the past year has all been containerized.
I agree. I've seen containerization mentioned by many vendors in the last year. It adds another layer of questions to vet like "do they possibly know what they're doing?"
I've been at a company where they weren't (yet) using containers nor K8S. The build process would just create VM images with the required binaries in there and then deploy that to an autoscaling group. It worked well and if you only ever intend to run a single service per machine then is the right solution.
At my workplace we use Docker to run services, but there is no container orchestration like Kubernetes. An AMI bakes in some provisioning logic and the container image. Autoscaling does the rest. Even without orchestration, I argue containers are useful. They abstract the operating system from the application and allow you to manage each independently. Much more easily than you'd be able to otherwise, anyway. Plus yo…
At the time they would bake full machine images, which is really just a heavyweight way of making a container.
I've been at a company where they weren't (yet) using containers nor K8S. The build process would just create VM images with the required binaries in there and then deploy that to an autoscaling group. It worked well and if you only ever intend to run a single service per machine then is the right solution.
At my workplace we use Docker to run services, but there is no container orchestration like Kubernetes. An AMI bakes in some provisioning logic and the container image. Autoscaling does the rest. Even without orchestration, I argue containers are useful. They abstract the operating system from the application and allow you to manage each independently. Much more easily than you'd be able to otherwise, anyway. Plus yo…
That said, I'm using Docker for my current side project. Even if it never runs at scale, I just don't want to have to muck around with system administration, not to mention how nice it is to have dev and prod be identical.
The gist of their approach was radical uniformity. For the most part, all VMs ran identical images. Developers didn't get to pick dependencies willy-nilly; we had to coordinate closely with ops. (Tangentially, at subsequent employers I've been amazed to see how just a few hours of developers handling things for themselves can save many minutes of talking to ops.) All services and applications were developed and packaged to be xcopy deployable, and they all had to obey some company standards on how their CLI worked, what signals they would respond to and how, stuff like that. That standard interface allowed it all to be orchestrated with a surprisingly small volume - in terms of SLOC, not capability - of homegrown devops infrastructure.
I've been at a company where they weren't (yet) using containers nor K8S. The build process would just create VM images with the required binaries in there and then deploy that to an autoscaling group. It worked well and if you only ever intend to run a single service per machine then is the right solution.
I’m in the process of moving to exactly this approach. I’ve been trying to pick the right Linux distro to base my images on. Ubuntu Server is the low effort route but a bit big to redeploy constantly. I’ve also been looking at the possibility of using Alpine Linux which feels like a better fit but a bit more tweaking needed for compatibility across cloud providers. Unikernels are also interesting but I think that mig…