Was the containers hype an industry/tech media propaganda?
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.
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.
This is a cause of concern for me, because if the software that I'm using and promoting is low-key being used to drive someone's agenda, that I'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.
What does the HN community this about this? And how should I articulate this problem?
42 comments
[ 3.5 ms ] story [ 105 ms ] threadAlso, 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.
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.
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.
That eases adoption.
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.
Truth be told, that has nothing to do with Docker and everything to do with how said teams operate.
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.
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.
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.
> 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.
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.
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.
See HashiCorp’s Nomad....
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.
Perhaps more to the point of the other poster: autoscale groups existed pre-containers and microVMs exist after, orchestration being orthogonal to containment tech.
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).
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.
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.
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.
Haha, are you telling me my perception of my life getting easier is not really true?
(But I would say that containers used right, do objectively make our lives easier.)
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.
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.
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.
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.
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.