Why did the container hype fizzle out – and how to reach container productivity?
blog.kontena.io
blog.kontena.io
The guys at my work made the switch to containers months ago and we've yet to realize any gains from them, whether that be productivity, efficiency, cost savings, scaling...the list goes on.
Development is more complicated and slower, everyone is on macs so docker runs like shit (I know I know there are syncing plugins but that's a workaround hack).
Even though I'm no longer an engineer and instead am in product, I still have strong opinions about a lot of things technical so I have to bite my tongue sometimes and trust team members.
It's just hard to watch people lose sight of the Why's for doing something and instead gravitate to that cool new shiny thing, even though it adds more layers of abstraction and complexity than most teams need.
> Development is more complicated and slower, everyone is on macs so docker runs like shit
That's probably related to the complexities of your specific architecture, applications, and infrastructure.
We are mostly a python shop and containers were a game changer (we've been using Docker since it was a beta product). The consistency between development/deployment and the ease of deployments made it possible to rapidly iterate in a way that wasn't possible in the past (deployments used to be a whole day affair and now we deploy multiple times a day).
Likewise with OSX development - the isolation of the container makes it far easier to manage dependencies and have a consistent experience with QA and production. I've also used it for horizontally scaling geospatial analysis - commands like "docker service scale gis=500" make it trivial to run complex analysis across multiple hosts compared to the alternatives.
Docker + Python API's + HTML/JS front ends has been nothing but smooth sailing for the past few years.
For one thing people almost always end up reworking their layers to go from least to most frequent changes for speed, but that often confuses the issue of logical units of work within the setup code.
And if you’re using npm or gem in a container, on Mac, You are going to experience some strong, negative feelings.
Use what works for your environment and team.
The bigger advantage is the switch in mindset that is much harder to explain or quantify.
To be honest, I don't know enough about vagrant to fully answer this.
I'm curious if there are any advantages with vagrant over Docker?
Works great at Google / Netflix / Facebook is basically meaningless for 99% of everyone working in the field.
You need packaging, update scripts, init scripts and strict policies for upgrades and do coordinated library updates (on the shared environment), or nearly roll your own os where you bundle your dependency with the app. That is incredibly time consuming.
With containers you don't need init scripts, the team can update any dependency when they want/need without breaking someone elses environment. And with containers every team deliver the same 'thing', a runnable image. Not a blob of php, some ruby and java ear and wars that have to run on a shared platform.
I'll never understand the love for containers. Seems like a ton of work for little gain.
I do think that they have a valuable role in deployment. They provide a simple contract that expresses a particular service's needs and side-effects cleanly.
I also think they are valuable when your stack has dependencies that you are not actively working on. Having a docker-compose to orchestrate those things has been a pretty solid productivity win at the one company I've been at that used that system.
100% agree that developing in containers just isn't worth it right now, at least for things with a somewhat complex build toolchain.
FTFY
This, to me, is a critical problem with our industry. I see so many times the same wheels being reinvented simply because the developers didn't take the time to learn from history.
That's all good as long as the application is actively developed. But the world is full of legacy software, actively used in production, but no longer maintained, where the source code has either been lost or no one knows how to rebuild it, or the tools to build it have become unavailable. But vulnerabilities will be found in the underlying libraries, whether it is the web server, the JVM, perhaps openssl again, or IIS for windows containers, or anything else.
How is that not going to end up as a windows server 2003-style disaster, with many many unsupported, unpatched servers all over the internet and intranets?
In fact for windows containers I understand the guest and host OS must run the very same version of the OS. How do you update or migrate your park of machines if you need the dev to re-issue all images at exactly the right time? How is that simplifying the life of ops in a large company?
Containerized infrastructure is not for the faint-of-heart. If you don't have a mature CICD pipeline and associated processes—and the staff and organizational awareness to maintain them—you're going to have a bad time. You need to anticipate rebuilding your containers on at least a monthly basis due to security updates in your upstream images. Though this isn't much different than non-containerized infrastructure—your system upgrades just happen at the build phase rather than the post-deploy operations phase.
The whole point of a container strategy is to better manage changes to the application; if the application is not changing, then containers are not needed. And it seems like a team that can't perform basic software maintenance is a team that would have trouble figuring out containers.
That said, for a lot of things, I think containers are premature optimization. People get so excited about deploying their little app that they deploy a 6 node K8S cluster with all the associated complexity, for an app that would happily run HA on two regular nodes with systemd starting it up.
Once you are plumbing together a dozen different microservices using a few different languages though, K8S starts to make a lot of sense. Service discovery, container-container routing, namespacing, and all that other good stuff make your life _easier_, but only past some level of scale.
Oh, and docker compose is amazing for local dev and integration testing of those more complex service compositions, just saying.
and look they're selling container solutions.
Honestly containers aren't that hard. Confusing if you haven't had to deal with how your software is actually deployed and managed in production operations. But you can read a book or follow a tutorial and get going in a few days. It doesn't require years of training.
I am probably a minority on this, but company ran blog post should be weighted and have to work harder to make it to the front page.
If I could down-vote this submission I would. For that I am going to up-vote the one below it.
Also, the discussion on this thread hasn't been terrible. As someone who uses containers day to day, it's interesting to hear other perspectives from people who fall into pro/anti container camps. Obviously an organic blog article spawning this discussion would be optimal, but in absence of that, I'll take this, and try to trust the HN community to be on point (as you and others in this thread are) to point out conflicting motives/incentives.
(To make this response actionable, though, personally I find I can have the most impact for surfacing the sort of content I want to see by skimming new as much as the front page, and keeping an eye out for grassroots work that might not gain much notoriety despite being worthy of a look.)
All new technologies go through a hype phase, then the hype dies down. Containers aren't different.
Few technologies follow it to any significant degree:
https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-...
https://trends.google.com/trends/explore?date=today%205-y&q=...
I don't have great data for it but I strongly suspect usage of containers is going up steadily over time as well, with Amazon, Google, and other cloud services all adding more container support to their product lines.
This isn’t to say containers are “easy” and we wouldn’t benefit from better tooling, just that this particular article is a sales pitch rather than an unbiased informative article.
Since containers existed, VMs and containers both added features from the other. For VMs, mostly lower resource overhead (admin tools were pretty nice even before containers). For containers, mostly better isolation. So if anybody mentions blah blah containers, just substitute "VMs" and check if it still sounds cool.
Containers feel wrong.