Why did the container hype fizzle out – and how to reach container productivity?

https://blog.kontena.io/how-to-reach-container-productivity/

by xfiler • 8 years ago

33 47 8 years ago

blog.kontena.io

hguhghuff• 8 years ago

Complexity.

Containers feel wrong.

elsonrodriguez2• 8 years ago

Containers are as complex as your application's dependencies. If the container feels wrong, chances are the wrongness stems from the application.

chomp• 8 years ago

This is an advertisement masquerading as content.

All new technologies go through a hype phase, then the hype dies down. Containers aren't different.

aksss• 8 years ago

Gartner has a graph for this called the "Hype Cycle", identifying five stages a technology goes through: 1) Technology Trigger 2) Peak of Inflated Expectations 3) Trough of disillusionment 4) Slope of enlightenment 5) Plateau of productivity Maybe containers are somewhere between stages 2 & 4.

dredmorbius2• 8 years ago

The Gartner Hype Cycle ... is overhyped.

Few technologies follow it to any significant degree:

https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-...

organsnyder2• 8 years ago

Where does the Gartner Hype Cycle fall on the Magic Quadrant®?

dasil003• 8 years ago

Container hype fizzled?

samlevine• 8 years ago

Serverless is the new hotness.

Spivak• 8 years ago

Which is essentialy short lived JIT provisioned containers on the back end.

justbaker• 8 years ago

Weird, wasn't it "hot" a few years ago? Or is it still gaining momentum tracking compared to then?

dchuk• 8 years ago

Because they're so damn complicated.

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.

Zelphyr• 8 years ago

people lose sight of the Why's for doing something and instead gravitate to that cool new shiny thing

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.

Retric• 8 years ago

Scale is a missing component for most such fads. Overhead that can easily pay off when you do 100,000x, is a much larger burden at 100x.

Works great at Google / Netflix / Facebook is basically meaningless for 99% of everyone working in the field.

apple4ever2• 8 years ago

Exactly this.

knz3• 8 years ago

The guys at my work made the switch to containers months ago and we've yet to realize any gains from them,
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.

hinkley2• 8 years ago

To play devil’s advocate, if you already have a build process with repeatability and a close corellation to production, containers may seem like robbing Peter to pay Paul.

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.

blahyawnblah• 8 years ago

I use vagrant with the same os as the server for whatever project I'm working on. What's the advantage of docker over this?

Damogran6• 8 years ago

See "Object Oriented Programming" - approx 1994.

tomlagier• 8 years ago

Having done some development in containers on Mac, I totally agree that it's not worth it (at least for the front-end builds I was trying).

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.

eip• 8 years ago

Having done some development on Mac, I totally agree that it's not worth it.

FTFY

kochthesecond• 8 years ago

I won't advocate for setting up all development to happen inside containers, but delivering software with containers is an order of magnitude simpler than delivering to a running os.

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.

apple4ever2• 8 years ago

Its easier for the software developer to maintain. Its harder for the software user to maintain though.

I'll never understand the love for containers. Seems like a ton of work for little gain.

briandear• 8 years ago

There’s less hype because it has become commonplace. Containers are just another tool in the DevOps kit.

imsofuture• 8 years ago

Exactly. It's not a hype new thing anymore, it's just what people are using. For all the warts of specific implementations, the wins of using containers are pretty solid across a huge domain of problems.

CalRobert• 8 years ago

Seriously. Maybe other places are different but Docker is quickly becoming as important to know as git if you want to be taken seriously in a job interview, at least. Our whole infrastructure is containerized and it's really nice. But it was build that way from the get go.

dominotw• 8 years ago

what a bunch of crap. How does this guy know that it "fizzled out".

agentultra• 8 years ago

The author speaks for the mainstream and yet I've never heard a keynote, notable article, or mention of them in popular literature on the topic of containers, developer tooling, or operations...

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.

mbrumlow• 8 years ago

I am really getting tired of blogertizements. There are enough smart people here blogging with intent on sharing real information and spreading knowledge that I am surprised that I keep seeing these sorts of things pop up.

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.

existencebox• 8 years ago

While I agree in part, I'd hope we not throw out the baby with the bathwater. (and I say this despite grumbling to myself about how that Bloomberg article on dating apps was clearly a submarine piece that occurs whenever one of these platforms pops up every few years) The Backblaze blog, for instance, consistently delivers really quality writeups, and as I recall I was originally turned onto them via HN.

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.)

dhimes• 8 years ago

It may have something to do with how people perceive they are ranked by Google. See, for instance, this recent discussion on HN:

https://news.ycombinator.com/item?id=16858053

cm21872• 8 years ago

There is another thing I can't get my head around. I understand containers are meant to be read only, i.e. if any binaries needs to be updated, whether in the underlying image or the application, the container needs to be rebuilt from scratch.

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?

organsnyder2• 8 years ago

Ideally, the CICD pipeline that generates your container images should be considered part of the running infrastructure for as long as the system is in operation. Alternatively, it's fairly painless to build a new container image with the legacy container as the base image.

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.

snowwrestler• 8 years ago

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.

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.

Rantenki• 8 years ago

Containers involve a lot of complexity, sure. But a lot of that complexity is invoked in different ways with different deployment mechanisms. Using RPM to deploy your packages to servers? You need an update policy, curated hosts/VMs, build SPECs, etc. It's still complex as hell, just different (comfortable) complex.

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.

ahartmetz2• 8 years ago

Well. There used to be a virtual machines hype, too. I remember it. A plateau of productivity did happen (look at the market cap of VMWare), but VMs have not exactly become the standard way to run an application on a computer.

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.

cm21872• 8 years ago

The cloud is basically a cloud of VMs. And even on premise VMs have become pretty much the default for most servers unless you need to address very specific performance considerations. I think VM do qualify pretty much as a "standard" these days.

ahartmetz2• 8 years ago

Not all application run on servers, by far.

lacker• 8 years ago

The premise is false. Interest in containers has steadily grown over time. For example:

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.

olliej• 8 years ago

The article is inventing the claimed problem (usage is declining due to complexity of setup) because they are selling a tool that “solves” that complexity. The article is (and should be labeled as) hyperbolic sales pitch.

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.

elsonrodriguez2• 8 years ago

Don't forget to drink your Ovaltine.

core-questions• 8 years ago

Does anyone use Kontena? It does look great, but does it deliver?

cleanyourroom• 8 years ago

LXD 3.0 is pretty usable.

Why did the container hype fizzle out – and how to reach container productivity?

Related Stories