There is no magic tech that makes problems go away. Just abstractions (sometimes they work, sometimes they don't).

Until of course, everything explodes.

The number of man hours invested (wasted imo) into pointless layers of container stacks is mind blowing and I'm yet to see the return on investment for any of it in real world scenarios. The cynic in me sometimes thinks you get some new abstraction to beta and the set up your own con and get some time off work to talk about it, and having been a primary speaker at a conference gets your CV gravitas. Theres a con for every goddam library any Big Name releases before you can even properly evaluate it in a prod stack.

As as side point that doesn't entirely fit with my argument the most important lesson I took away from dev conferences when I still went to them is that devs wax lyrical about all kinds of things in public, but often the things they talk about are their pet projects or sidelined to some small part of the business that doesn't really affect the main workflow, yet because they work at a Big Name we attach importance to it.

I dare say that all that microservice stuff only works with 300+ employees if you keep everything containerized.

It's no longer building some servers that run and putting somebody else's code on it. Instead, it's working closely with the team producing code and helping build a mature deployment and management capability. It's about being a responsible expert on the bits outside of the application process.

Containers help immensely here because they recognise that a product is composed of more than just an application and they have lowered the barrier of entry to making the system of parts as a whole cooperate.

As part of this change there will of course be quality issues. Classically trained developers will produce poor quality container images, just as classically trained sysadmins produce poor quality apps.

This initial hump will pass as new tools are introduced to assist with this and as people learn the skills they need to produce higher quality images.

If you have the skills, invest your time in helping this process along rather that raging at the fact you work in an industry where change is disruptive and constant.

You may find containers to be useful in this process. With rare exceptions, I don't, and the way you write this post with the implication that containerization is an unmitigated good grinds my gears. Disruptive and constant change leads plenty often down real bad roads, and unthinking embrace of every fad that comes down the pike has led to many more disasters than conservative thought has.

My experience is that using containers effectivelly requires a substantial rethink of the infrastructure and how the teams using it work. The payoff though is a step change in productivity.

Over time, I believe that companies which embrace the change will deliver more quickly than those who do not. They will get products to market in a shorter timespan and generally be nicer places to work.

Will that mean the death of other ways of doing infrastructure? No probably not. After all, there are still mainframes and cobol programmers out there.

Instead of doing OS updates, application updates, code updates, and configuration updates to 50 identical webservers that live behind load balancers, it might be faster to upgrade one. Then that one can be templated, cloned and deployed and replace the currently operating ones. There's still server name, IP address, and other configuration that has to be automated, and sometimes automating this is harder than automating all that patching, sometimes not.

This obviates server histories. True - you can't say "This VM has always performed better than the others" since you get a new farm of VMs every month. While many see that as a downside, it's actually a benefit that you don't need to think about that data.

Containerization is now letting individual teams manage app-specific configuration they actually understand and can test and iterate. A central org maintains the base image and can redeploy our containers with OS-level fixes as necessary. Our "self-service" deployment infrastructure was a behemoth that no one understood, documented by tribal knowledge. At less I can Google how to use the Docker API.

(And I say this as no fan of Puppet; I'm a Chef user. Where I've never seen anything remotely that deranged, even in dysfunctional environments.)

No, of course not. No single container should have a lifetime greater than a day or two. "Maintenance" is deploying the latest, integration- and end-to-end-tested version of the software, as part of a continuous build pipeline.

In this case the application containers themselves can perfectly live less than a day.

Build your own images, problem solved. (Albeit creating a whole host of other problems in place of it, but those are no worse than a world without containers.)

No one relying on third party images beyond an OS can claim that they _really_ care about security or vulnerabilities anyway.

Do you apply the same kind of reasoning to virtual machines, and reach the conclusion that a single massive mainframe is the optimal configuration?

Oh, right. I'm supposed to have no life as a tech worker and spend countless nights dealing with container runtime issues in production because "It's The Wave Of The Future".

If it turns out during evaluation that setting up a simple Debian VM with the requirements of the tool, the tool ends up on the "black list" for me.

No matter the possible productivity gains, I won't use anything needing more than two hours just to get started (i.e. running a Hello World).

well that certainly helps frame your posts. In this case docker has a webpage that you can play around with. Maybe 10 minutes to get the basic idea.

I'm struggling to find out where your hostility comes from. It doesn't make your job disposable, which it sounds like where your fear comes from. Just because people can't come to you to get the ideal Debian server setup doesn't mean you are less valued.

I like to be in absolute control over my environment - and my time. If a tool author cannot manage to provide a Debian package with reasonably current and extensive documentation, I won't waste my time.

Programming is young, but if you look at the history of more developed fields such as physics and mathematics, there is a very long history of extremely respected scientists out right rejecting new theories for being outlandish and ridiculous that we now accept as the bedrock of scientific theory.

The truth is, just as with physics and mathematics, in computer science new ideas do form, but older generations rarely adapt, and it's only with death of the old, and the growth of a new generation do ideas become accepted.

Then you patch it by redeploying it.

> Not to mention the likely possibility of breaking API changes in the container version. vagrant/puppet I'm looking at you, nothing is worse than having to figure out which ancient version of vagrant and puppet was used at creation in order to get the system running again

Is this a real issue that people run into? I've never had any issues with this.

> Or, well, look five years in the future, and hope today's hyped container solution will still be present then.

Good thing the real work essentially boils down to some scripts which can be easily translated into any new technology

> Fuck containers, get a properly managed ordinary Debian server and save yourself a lot of headaches.

Spotted the Debian sys admin!

The meaning and the life cycle of container are no different from having a big virtual machine image, but container technology such as docker has been made blazing quick to start and kill, and I think that's a step forward. Containers in general allows multiple applications live in its own "pretty good" sandbox environment (read about Docker security, as there are many security implications most people don't pay attention to). This is great for truly stateless applications, or ETL applications, for which there is no need for a pool of machines dedicated to just host one specific application. This is not something we can do with big virtual machine unless now you want to invest your time to manage creating different users on the server, carefully writing down UNIX permission, as opposed to understand the security control around using containers (and linking containers). And many people don't pay attention to the size of the base image. Most people probably just use the vanilla Linux (ubuntu/redhat/centos, etc) image, but that kind of Docker image is too big for scaling and testing.

An example of ETL or long running program would be downloading huge files from some on-premise, and upload files to S3 in chunks. If your files are large, you should chunks to your compute. To keep track of progress of thousands of chunks, you need queue and worker nodes. now you've got a fleet of computes, and you want to run everything (worker and primary web applications handling the requests) in parallels, as quickly as possible, as stateless as possible on the compute side, you can leverage containers, plus the use of queues, and a RMDBS for transaction logs. Here container technology such as Docker is useful.

You are right, don't blindly follow the "everything should be containerized" hype, I don't think most people would dare to containerized Cassandra database and fit a big box with Cassandra database and web applications running in production.

Regardless of approach, when it comes to self-healing, highly automated, reproducible, and secure infrastructure:

* service discovery

* access control

* monitoring and insight analysis

* credential management

* version control and management (containers, security patches, container and image life cycle)

are problems we cannot solve with containers without integrating with third-party softwares.

Guess, what, there is no one solution solves these. They are just buzz words and goals we haven't achieved well as a community... even OSS platforms like CloudFoundry and Kubernetes are only able to do the application-side of life cycle to the point of easing deployment, not so much everything else.

Version control properly lives outside the runtime environment, in my opinion; though these days CF has Gitlab integration points.