Was the containers hype an industry/tech media propaganda?

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.

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.

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.

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.

How does one become a k8s consultant? Certifications?

The clearest path is to become a Certified Kubernetes Administrator. There are a number of companies currently hiring CKAs.

https://www.cncf.io/certification/cka/ https://jobs.cncf.io/

Disclosure: CNCF, which I run, manages the CKA and the job board. But I really have seen many people get great jobs by becoming a CKA.

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.

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.

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

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.

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

This.

Containers solve a whole bunch of problems so well that they essentially eliminate them as problems.

- containers solve the problem of having to develop installers for applications because containers already come with the whole dependency graph resolved, deployed, and up-and-running.

- containers solve the problem of deploying applications because they run out of the box in isolated processes.

- containers solve the problem of configuring deployed applications to talk with each other safely because they enable developers to configure the network settings for the specific application that is supposed to be applied when the app is deployed, in a way that can be overwritten without any impact on deployment.

- containers enable you to download and run any application effortlessly, even tracking semver.

- etc etc.

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

> That's not really true.

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

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

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

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.

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

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

Usability/ergonomic. Docker was/is a lot simpler to grasp.

That eases adoption.

Docker came with the container metaphor.

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.

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.

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

> IIRC, the main problem was UI/UX

Best container UX I've had so far was with `lxd`, which is Ubuntu's `lxc` container manager (which is why the GP was asking about). I found it more pleasant to work with than Docker, particularly early Docker.

Actually lxc only appeared a few years before. It was based on original work in the kernel donated by IBM, who had originally intended it to be used to safely segregate the mega-resources on their mega-mainframes to individual non-mega workloads. (Source: I was using lxc a few years before, circa 2010, which is now 10 years ago. I had direct communications with the authors. I also submitted issues to docker outlining significant security issues early on, and made this summary of the space with skepticism around docker's already marketing-hype unreality: 'original post' and rest of page for context at http://stani.sh/walter/pfcts/ ... the amusing thing is, the core solution identified (virtualization/topology/OS/local-remote paradigm neutral orchestration with CI/CD integration friendliness as a first class feature) is still painfully relevant and unfulfilled today, even as https://microk8s.io/ and similar make local work and some deployment easier, and the money in cloud IaaS services reaches 'staggering')

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

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

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.

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

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.

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

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.

Containers are not needed for orchestration.

See HashiCorp’s Nomad....

Indeed. Or anything else on https://en.m.wikipedia.org/wiki/Orchestration_%28computing%2.... To write as if Kubernetes is required to orchestrate computing (particularly in an environment where other containment tech is already available) shows unfamiliarity with a huge body of work from the last two decades.

I wouldn’t call CloudFormation or Terraform “Orchestration” despite what Wikipedia says.

Neither adjust resources dynamically based on health checks, workload, a certain time or based on resources available on the underlying VM.

I don’t know the other tools but it makes me doubt the entire Wikipedia article based on what I know.

In cloud formation you'd make an autoscale group to handle dynamic adjustment of EC2 resources (ie, Xen VMs) or make Lambdas which are started and terminated as needed (is, Firecracker VMs).

CloudFormation isn’t doing the orchestration though. The orchestration is being done by the load balancer, APIGW, CloudWatch alarms, or whatever AWS uses to route events and trigger lambdas.

Yes, agreed. You're creating a resource to do the orchestration built with particular rules, rather than creating and applying those rules directly. I'm not sure the distinction is significant though - ultimately the rules in CF determine your scale-up/scale-down behaviour, directly or indirectly.

Perhaps more to the point of the other poster: autoscale groups existed pre-containers and microVMs exist after, orchestration being orthogonal to containment tech.

Sort of playing devils advocate. But lambdas are containers. Instead of a Docker container, you have a zip file. Now, you can even have up to 5 layers in your lambda and it works even more like a building a Docker container.

> But lambdas are containers.

Nope. Technically they're MicroVMs, based on KVM not LXC. They're an isolation tech but containers aren't the only isolation tech (which is really the whole point of this discussion).

https://firecracker-microvm.github.io/

Firecracker runs on Intel CPUs. 2 layers.

No probs with you playing devil's advocate, you're a lot more polite than the other guy (who seems to have quietened down since pre-and-post LXC orchestration was pointed out to him).