16 ms·

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

33 points by xfiler 8y ago

hguhghuff 8y ago
Complexity. Containers feel wrong.
- elsonrodriguez 8y ago
  Containers are as complex as your application's dependencies. If the container feels wrong, chances are the wrongness stems from the application.
chomp 8y 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 8y 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.
- dredmorbius 8y 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-cycles-michael-mullany https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-...
  - organsnyder 8y ago
    Where does the Gartner Hype Cycle fall on the Magic Quadrant®?
    - dredmorbius 8y ago
      Visionary / Niche. Variously.
dasil003 8y ago
Container hype fizzled?
- samlevine 8y ago
  Serverless is the new hotness.
  - Spivak 8y ago
    Which is essentialy short lived JIT provisioned containers on the back end.
    - hinkley 8y ago
      Yeah and we called it process migration in the 80’s and Agents in the 90’s. Things don’t change as much as we like to think. The curtains change but the scenery doesn’t.
  - justbaker 8y ago
    Weird, wasn't it "hot" a few years ago? Or is it still gaining momentum tracking compared to then?
dchuk 8y 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 8y 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 8y 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.
  - apple4ever 8y ago
    Exactly this.
- knz 8y 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.
briandear 8y ago
There’s less hype because it has become commonplace. Containers are just another tool in the DevOps kit.
- imsofuture 8y 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 8y 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 8y ago
what a bunch of crap. How does this guy know that it "fizzled out".
agentultra 8y 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 8y 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 8y 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 8y ago
cm2187 8y 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?
- snowwrestler 8y 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.
- organsnyder 8y 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.
Rantenki 8y 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.
ahartmetz 8y 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.
- cm2187 8y 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.
  - ahartmetz 8y ago
    Not all application run on servers, by far.
lacker 8y 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=docker,kubernetes 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 8y 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.
elsonrodriguez 8y ago
Don't forget to drink your Ovaltine.
core-questions 8y ago
Does anyone use Kontena? It does look great, but does it deliver?
cleanyourroom 8y ago
LXD 3.0 is pretty usable.

33 points by xfiler 8y ago

hguhghuff 8y ago

Complexity. Containers feel wrong.

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

chomp 8y 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 8y 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.
dredmorbius 8y 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-cycles-michael-mullany https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-...
- organsnyder 8y ago
  Where does the Gartner Hype Cycle fall on the Magic Quadrant®?
  - dredmorbius 8y ago
    Visionary / Niche. Variously.

dasil003 8y ago

Container hype fizzled?

samlevine 8y ago
Serverless is the new hotness.
- Spivak 8y ago
  Which is essentialy short lived JIT provisioned containers on the back end.
  - hinkley 8y ago
    Yeah and we called it process migration in the 80’s and Agents in the 90’s. Things don’t change as much as we like to think. The curtains change but the scenery doesn’t.
- justbaker 8y ago
  Weird, wasn't it "hot" a few years ago? Or is it still gaining momentum tracking compared to then?

dchuk 8y 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 8y 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 8y 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.
- apple4ever 8y ago
  Exactly this.
knz 8y 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.

briandear 8y ago

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

imsofuture 8y 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 8y 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 8y ago

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

agentultra 8y 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 8y 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 8y 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 8y ago

cm2187 8y 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?

snowwrestler 8y 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.
organsnyder 8y 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.

Rantenki 8y 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.

ahartmetz 8y 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.

cm2187 8y 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.
- ahartmetz 8y ago
  Not all application run on servers, by far.

lacker 8y 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=docker,kubernetes 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 8y 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.

elsonrodriguez 8y ago

Don't forget to drink your Ovaltine.

core-questions 8y ago

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

cleanyourroom 8y ago

LXD 3.0 is pretty usable.