
Why did the container hype fizzle out – and how to reach container productivity? - xfiler
https://blog.kontena.io/how-to-reach-container-productivity/
======
dchuk
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.

~~~
knz
> 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.

~~~
blahyawnblah
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?

~~~
thraxil
The first, obvious thing you would notice is performance. A docker container
typically starts up in a fraction of a second (whatever process is running
inside it might take a few seconds more) while a vagrant VM has to go through
a whole boot up process. Docker has a slight overhead on disk I/O, but it's
still far better than a typical vagrant setup. A docker container has very
little memory overhead beyond what the process is using vs vagrant requiring
you to allocate a fixed amount per VM. It's completely reasonable to run
dozens of containers simultaneously on a laptop all completely isolated. Doing
the same with vagrant would require an enormous amount of memory.

The bigger advantage is the switch in mindset that is much harder to explain
or quantify.

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

~~~
organsnyder
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
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.

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

------
chomp
This is an advertisement masquerading as content.

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

~~~
dredmorbius
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-...](https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-cycles-
michael-mullany)

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

~~~
dredmorbius
Visionary / Niche. Variously.

------
lacker
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=...](https://trends.google.com/trends/explore?date=today%205-y&q=docker,kubernetes)

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

------
dasil003
Container hype fizzled?

~~~
samlevine
Serverless is the new hotness.

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

~~~
hinkley
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.

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

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

------
elsonrodriguez
Don't forget to drink your Ovaltine.

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

~~~
CalRobert
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.

------
cleanyourroom
LXD 3.0 is pretty usable.

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

------
hguhghuff
Complexity.

Containers feel wrong.

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

