[ctrlc-root]

Not really. Let me prefix my reply with some context: I've used Puppet, Salt Stack, Ansible, and PowerShell DSC to manage infrastructure based on Windows, Linux, and macOS on top of bare metal servers, VMs, and containers. Any tool that promises to "make the complex simple" is really just hiding the complexity away from you behind default settings and their own implementation. Which is probably fine for simple use cases. If your application can be deployed to Heroku then deploying to a Kubernetes cluster you don't have to manage is probably analogous in terms of overhead and how much complexity you have to worry about. However this simply doesn't scale as your application increases in complexity.

In fact I recently completed a migration away from Docker/Kubernetes to an AWS stack that doesn't use anything higher level than autoscaling groups and it has been a positive experience. The same application is now faster (less layers necessary), easier to deploy (we own all the moving pieces), easier to debug in production (I can use strace and tcpdump without trying to install them in an already running Docker container), etc. All of the "complexity" that Docker and Kubernetes were handling for us has been replaced with a ~ 500 line Python script that's mostly comments (you can see an early prototype of this script in the repository below, named deploy_build.py, which omits some error handling but weighs in at ~ 150 LoC). Furthermore, now that we have to think about how to package and deploy our application to production, the incentives are there to follow proper Python best practices around packaging (i.e. use packages, don't make assumptions about paths, etc) which has been a nice bonus.

Containers (and Docker, Kubernetes, etc) are all tools that have their use cases and corresponding tradeoffs. Anyone who can't explain when or why you wouldn't want to use a tool is not prepared to explain when or why you should use it.

https://github.com/CtrlC-Root/proto-aws-django

[techntoke]

First, containers don't necessarily make complex simple. What they do is take an OS image, and allow you to run it on another OS (best performance is always going to be Linux on Linux, since containers were first built natively into the Linux kernel).

Obviously, Microsoft also saw your same vision of containers being so unnecessary that they also decided to build the concept into their OS as well.

This concept can't be done on bare metal. Additionally, because it is built into the kernel and they share the same kernel, they generally startup at over 10x performance of traditional VMs. There are solutions now of course to boot directly into the kernel from a hypervisor, but these are generally paired with container solutions as well due to the orchestration and ecosystem that exists to make container orchestration easy.

Most container solutions use a unified image solution that allows you to rapidly reiterate and test your changes in multiple environments. Doing this on bare-metal or VMs takes considerably more time and money for fixed infrastructure costs.

With container solutions such as Kind and Helm, you can rapidly deploy a local cluster to pre-test cloud rollouts on a single machine. The orchestration can also autoscale clusters horizontally and vertically, and is robust enough to directly compete with other bulkier VM orchestration solutions such as OpenStack.

With automatic certificate rotation, automated service discovery, etc there is no need to try to create tasks for every little thing you'd need to do with Ansible or another IaC component. It is all baked into the Kubernetes ecosystem.

Abstraction away from cloud-specific solutions can only be seen as a good thing. People that are invested in AWS generally can't be trusted to create holistic solutions.

[x86_64Ubuntu]

Never thought I would run into someone else that has used Powershell DSC...