
Was the containers hype an industry/tech media propaganda? - itsmefaz
&quot;It happened all of a sudden, and everyone now wants to be a part of it. Even the companies that have years of experience in the virtualization world failed to capitalize on this movement that doesn&#x27;t seem to have a clear starting point&quot;<p>I am becoming skeptical of the tech media and its role in driving the tech industry, especially the software aspect of it. Every technology or tool that we use, every meetup or conference that we go to is driven underneath with an agenda to sell the product, and not necessarily help engineers work.<p>I see no point in studying any technology, tooling than the toolings my organizations use because all these new tech is in someway linked to drive adoption of companies driving those technology and not necessarily improve the industry in general.<p>This is a cause of concern for me, because if the software that I&#x27;m using and promoting is low-key being used to drive someone&#x27;s agenda, that I&#x27;m becoming part of that hidden-agenda too. It feels these organization are using us engineers as a medium to promote and drive their idea and it is eating me alive.<p>What does the HN community this about this? And how should I articulate this problem?
======
ramtatatam
I worked for a startup roughly when docker started gaining proper momentum but
at the time I felt it's still not mature enough to use it in production. We
was using (I believe) less secure chroot jails to package our app and, well,
it was a bit of a nightmare. I was in need for containers technology and once
we decided to move to docker I never regreted this move. Now I use podman for
I'd prefer not to have to run containers as very privileged user and I don't
see better alternative.

There was good press around docker but I also heard lots of stories about
problems from my colleagues who decided to use it earlier than me, but I'd not
call this propaganda. Docker solves real problem and that's why it got so much
attention.

------
streetcat1
Everything starts as propaganda, simply because only companies (big ones) have
the PR budget to push new tech.

Also, tech companies need constant change to survive, since with every new
change, all the old systems become legacy, and we have a new wave of spending
(this is true for hardware as well as software).

However, this is not necessarily bad, you just need to play this game
correctly.

For example, if you are a startup, you can use this change as an entry point
when new markets get opened.

As an engineer you can also enjoy it if you ride this wave. For example,
become a Kubernetes consultant.

The holy grail, however, is the actually drive this change as a startup. I.e.
use the PR budget of the big tech in order to introduce a competing product.

~~~
itsmefaz
Thanks for the response. But the problem is it takes sometime to gain
expertise and consultant firms. And it is very difficult to foresee a tech
disruption as it is primarily driven by big-tech's agenda rather than of
introducing new tools and other firms just blindly accepting it as standard.

~~~
streetcat1
No problem. So it is actually become easier over time, as the IT field
concentrates around Google, Amazon, and Microsoft. Basically look for the new
announcements in each major conference, and specifically for new beta
services, or open-source projects.

Also, it takes around a year to become proficient in new tech, so you must
allocate some of your time (at work or free time) to such experimental bets.

------
NotZachari
The media's job is not to inform you at this point. Their job is to get eyes
on their product. That's no secret. However, the logic behind your approach is
flawed.

Why? Money is king in every industry. Sure, hype exists. I had one instance
where I felt exactly like you, and guess what hot new flavor of the month that
was? React. It didn't take long to realize who the idiot was in that situation
(me). It was hot because it was the next logical step, and no amount of being
frustrated because I had just gotten comfortable with Angular could change
that.

Containers aren't some snake oil racket. It's pretty easy to see why if you
take off the tinfoil. They are cost and resource efficient, and they provide a
large cushion for less than optimal situations. Containers are smaller than
VMs and less resource intensive so they allow you to do more with less
hardware. Sudden rush of people because Reddit or HN fell in love with you?
Provision a few more with almost zero effort knowing exactly what you'll be
getting. Working on bug fixes or improving shit? Cool. There's no difference
between the local instances and what hits production.

I mean, it's kind of like the folks who get real passionate about only using
basic code editors because all the extra tools are "cheating". Time is money,
and it's the only thing we can't get back. If containers significantly reduce
cost in terms of resources, man hours, or money for you or the company you
work for, it doesn't take a rocket scientist to understand why it'd be pushed
so hard.

I understand being cynical in this industry, but let's be realistic. Companies
are only pushing what they believe will be good for their bottom line. No
one's pushing containers because of some shitty agenda, just as they weren't
when Node.js was blowing up to the same screams of "this is all manufactured
hype".

There are definitely cons to using containers. You're pushing a bunch of shit
with root access all sharing the kernel out there, and if a single one is
compromised, they're all compromised by definition. That's a legitimate
concern, but if I'm being honest, this sounds more like you haven't been in a
situation where containers were the proper solution more than a tech industry
scam to push an agenda.

------
Jonnax
What is eating you alive? You're likely working for an organisation trying to
push their software or services onto other people.

Open source adovocacy has the same kind of ideas from another perspective.

There isn't some magic ideal of an engineer. You solve problems. Those
problems are generally driven by the agenda of whoever is paying for it.
Unless you're running your own business then it's your agenda you're pushing.

If you don't want to use containers, then don't use them. VMs or bare metal
haven't disappeared. Any application that's container deployable should be
deployable outside of a container.

"I see no point in studying any technology, tooling than the toolings my
organization"

That's a fine perspective to have. Keeping up with technology can by very time
consuming, and we work to live rather than live to work.

However if you want to be involved in decision making processes. You should
have an understanding of the solutions that you don't want to recommend.

Saying "I don't like how the press have been pushing it everywhere and I think
there's an agenda" is not an acceptable argument if you're asked about the
possibility of contsinerising your company's application.

~~~
bfung
> "I see no point in studying any technology, tooling than the toolings my
> organization"

My personal take on this is that the opposite should be done -- study and
understand the fundamental problems tech orgs have and know the tools that
solve those problems. That's the way to cut through the media BS vs. valuable
news.

Containers became popular because they bring value to tech orgs/teams --
removing the need for a LOT of communication/coordination between infra teams
and dev teams where skills are generally different.

------
codegladiator
Following that throught process everything will look like a propoganda.

I suggest you to read and listen to everything (all propoganda) and make your
own choice.

For containers, I don't use containers because everyone thinks its great, but
because it makes my own life easier.

Similarly I could say functional programming is a propoganda, but I haven't
picked it up yet since I don't see that much of pros.

~~~
zzzcpan
_> Following that throught process everything will look like a propoganda._

Almost everything is. In tech industry and tech media in particular. PR is
essentially another name for propaganda, because propaganda got bad name at
one point and propaganda firms had to rename it to continue those practices.
Evangelist and advocate roles are essentially people employed to spread
propaganda. Even just the idea of startup growth is deeply tied to propaganda.

 _> For containers, I don't use containers because everyone thinks its great,
but because it makes my own life easier._

That's not really true. They help a bit with certain problems, introduce other
problems, and container-based technology implementations pile on so many
problems and look so incompetent, it's hard to even take any of it seriously.

~~~
codegladiator
> That's not really true.

Haha, are you telling me my perception of my life getting easier is not really
true?

~~~
aliswe
He means you're statement isn't objectively true.

(But I would say that containers used right, do objectively make our lives
easier.)

------
RantyDave
Yes, this is pretty much how it is. The best solution will be passed over time
and time again if there is a better marketed alternative. To make things worse
you have management adopting product X because they know engineers want to
work on it, and engineers adopting product X because they know there aren't
any nasty-arse legacy maintenance projects using it. This is but one of the
mechanisms that keeps our industry as the expensive, buggy, under performing
mess it is.

To articulate the problem: The tech industry is made of people, and people's
actions are based on all sorts of not-all-that-logical incentives. Principally
tribalism. We evolved this way and it's not going anywhere.

------
lazylizard
Maybe docker had a little bit of hype? But openvz n lxc have been around for a
long time..

~~~
itsmefaz
Was there a reason why they didn't take off like docker did?

~~~
rumanator
IIRC, the main problem was UI/UX. Docker containers in essence are a bit like
running isolated Linux processes in a chrooted and cgrouped environment.
Chroot exists for decades, and so does cgroups. Yet, Docker came up with a UI
and UX which, among other things, let you download and run isolated Linux
processes by simply running 'docker run <container name>', thus shoving
everything well under the rug and practically eliminating the need to pull any
arcane trick to get Linux processes to run in isolation.

~~~
kazen44
running processes in isolation has been happening for a long time. (jails for
instance, have existed for a very long time and freebsd has been used a lot
for hosting services in the past).

while i agree docker solved the UI/UX problem, it also introducted a massive
security risk, as running unverified binaries in production is very easy for
developers. Most shops don't have any private repository in use nor do they
have the people (anymore) to build proper processes and systems around running
code in production.

~~~
rumanator
> also introducted a massive security risk, as running unverified binaries in
> production is very easy for developers.

Truth be told, that has nothing to do with Docker and everything to do with
how said teams operate.

------
darkhorn
Some news in media are published with money. You send your story and pay some
money, then they publish it as a news.

------
blahneverdies
Just sit and watch the trends roll in, and fizzle out. Choose your wave. (HN-
driven decision-making has existed since nearly the beginning as well.)

------
nailer
It was an industry propaganda from companies who knew containers had something
to offer over VMs (performance gains) but span those genuine advantages into
claims that containers were a revolution rather than an evolution.

People started doing silly things like run containers on top of their cloud
providers VMs (creating a second layer of isolation and massive amounts of
engineering burden) and hence Kubernetes became synonymous with wasted
engineering effort.

~~~
rumanator
> People started doing silly things like run containers on top of their cloud
> providers VMs

This assertion is simply wrong. Running containers in a VM is not silly at
all. It's a very basic and very important feature. I'm actually surprised how,
in HN of all places, this misconception is still mindlessly repeated in this
day and age.

By firing up a VM you're actually allocating in the cloud the computational
resources you need, and by running containers you are using those
computational resources as you need. When you need more instances of a service
running you replicate a container instance, and if a container instance is
idling then you shut it down. If you run close to exhaust the computational
resources of your VM instance then you just pick up your credit card and fire
up another one to make room to run more containers. You never have to worry
about anything because it just works.

And Kubernetes is the one responsible for monitoring resources and managing
how container and VM instances are initialized or shut down, and how
everything is kept up and running and communicating while you worry about
nothing.

~~~
nailer
The full quote is:

> People started doing silly things like run containers on top of their cloud
> providers VMs (creating a second layer of isolation and massive amounts of
> engineering burden)

Regarding your statement:

> When you need more instances of a service running you replicate a container
> instance, and if a container instance is idling then you shut it down.

> monitoring resources and managing how container and VM instances are
> initialized or shut down

You're confusing orchestration with isolation. Orchestration has existed far
before containers. You are already paying your cloud provider for isolation.

Containers are not needed for orchestration. I'm going to take a guess here
and say you have been in the tech industry for about five years.

And regarding your claim:

> You never have to worry about anything because it just works.

No. Running a Kubernetes or Docker cluster is a non trivial task.

Here's a more likely scenario for running your own container farm on top of
the platform your employer already pays for from your cloud provider: you just
want to learn Kubernetes and have someone else pay you to do it, despite the
lack of business benefit.

~~~
rumanator
> People started doing silly things like run containers on top of their cloud
> providers VMs (creating a second layer or isolation and massive amounts of
> engineering burden)

I've addressed the full quote, and it's entirely wrong and made by someone who
clearly has no practical experience running containerized apps. If you read my
comment you'll check the points that address that misconception.

> No. Running a Kubernetes or Docker cluster is a non trivial task.

Kubernetes is not containers. It's a container orchestration service. That's
an entirely different thing. It's like you are confounding application
installers with the OS that runs the application.

And it seems you also confused Docker Swarm, Docker's container orchestration
system, with Docker. Those are two entirely different things.

And container orchestration services are not a problem. If you ever get the
opportunity to learn about containers and container orchestration services,
you'll see that Docker Swarm is trivial to use even in bare VMs or even
directly in dedicated hardware, once you get the ingress controller thing
sorted out. In cloud providers it's even much simpler because ingress
controllers are already provided out of the box and you have nifty UIs to
configure everything.

And by the way, I appreciate if you stop rewriting your points midquote and
after you get replies addressing the points you rewrite, because you're
misrepresenting everything you and I am saying with each edit.

~~~
nailer
I wrote a comment then spent a minute editing it, because I am in bed on a
phone. _Shrug_

Here's a shorter version of the entire conversation, quoting you:

> By firing up a VM you're actually allocating in the cloud the computational
> resources you need, and by running containers you are using those
> computational resources as you need. When you need more instances of a
> service running you replicate a container instance, and if a container
> instance is idling then you shut it down.

You're confusing isolatation with orchestration. You haven't been in the tech
industry a long time. You do not need containers for orchestration. You do not
need containers for isolation if you are already paying for VMs.

