Ask HN: Why DevOps is still complicated in 2021? | Hacker News Reader

Ask HN: Why DevOps is still complicated in 2021?

12 pointsaristofun13 comments

Please point to my dark spot, because I really want to understand something.

Aren't like ~90% of all web infra deployment usecases eventually come down to just "run N instances of my M apps on these L nodes, and make X of them available for incoming traffic (+ optionally create me few overlay networks inside cluster)"?

With lower level details resolved on per container/app level.

Why then k8s and all those tools make even simplest cases look so complicated?

Why then tools following "simplify things" ideology (like Swarm) are barely surviving in the shadow of monsters like k8s and alike?

Why aren't there widely popular tools that compete for simplicity with heroku?

Do I miss some big point somewhere or people just really love to play with complicated solutions of "not so complicated" problems?

View on HN

I wouldn't say Swarm is much easier. You have to caveat 'easier' too. K8s is easier to do complicated things that were basically impossible before. It's the same with everything in software engineering. As we move up the ladder in abstractions, what's possible becomes more complicated, so it doesn't get any easier.

Graphics are good example. As people developed abstractions the ability to make more and more complicated graphics became possible. Now A+ games are more expensive and take longer to make then ever before, but they are also doing things that could of never happened before.

Our company is trying to make K8s much simpler to get into for the avg company, so another abstraction, but specifically done to make it simpler. This all feels very normal to me as someone that started back in the day managing 1000s of blade servers, now it's just containers. Was hard then and is hard now.

But now you can just run app in your desktop with one click, you dont have to build appstore app from sources right?

Im talking about dumb task of running software, not developing new software where I totally agree with your point.

There's generally always a trade off between customisability vs simplicity, and time efficiency vs price. If it was possible for something to be customisable, simple, time efficient and cheap with no vendor lock-in, everyone would be using it.

Heroku is great for example because it's simple and saves time, but it can be expensive, there's areas you cannot customise, and their hosting tools aren't open source.

What would you feel a simple solution be? Maybe you know something that others don't... or maybe it is just really hard to have a standard across millions of different ways of deploying and running software systems.

Heroku is a perfect example of simplicity in this area (devx/ux wise, putting aside proprietariness).

Why is it so hard to cover 90% of same ubuntus running same docker containers, communicating over same standard protocols?

I really like Heroku too and I think it does solve the problem particularly well for simple web apps. The world of devops isn't entirely simple web apps. Nor does it necessarily run (or can run) in the cloud.

There's an OSS heroku implementation, dokku I think? If it solves the problem well for what you need then you could just embrace it!

The challenge in some of the companies I've been is that the code base is 20~40 years old, there's a mix of languages, patterns, approaches and OSes generating value to the business.

Standardizing that across 100s of developers across 10s of departments isn't an easy task. Refactoring the deployment/code to whatever was the best practice of the last year isn't a good use of time either. People who wrote some of it left, there's no resources, etc.

The world of startups is quite straight forward, the world of enterprise software or companies that have a decent number of developers and have been around for a while, not so much...

Isnt all this legacy burden solved on container level?

Once you got a container - how complicated should it be to just run it?

It’s funny that your questions all imply that this should be a „solved“ problem while you can’t even grasp the complexity of reliably serving arbitrary software applications to arbitrary consumers. All that „legacy burden“ isn’t so legacy and for every layer of abstraction that makes all of this look less complicated, many highly skilled people put in a lot of effort.

Sure this thing can't be solved 100%, just as a problem of running consumer software.

But still we have good enough desktop apps, that even a kid can setup and run.

Nobody yet clarified what's the fundamental difference between those and apps running in the cloud.

> many highly skilled people put in a lot of effort

Without good "product" guys supervision they tend to get systems only other highly skilled people can comprehend, btw.

Doing one thing once is easy.

Do it ten times. That’s harder.

Do it ten times each for ten people at once. That’s a lot harder.

Do it ten times each for ten people each across ten different cities in ten different states in ten different countries. That’s much, much harder.

It’s the “Wheat and Chessboard” problem all over again (see https://en.wikipedia.org/wiki/Wheat_and_chessboard_problem ).

The fundamental problem here is one of scale.

It's because it's a complicated problem, and kubernetes is not good to simplify it.

To create more jobs. No really ..

It looks like it, unfortunately. Like a hidden unemployment thing )

Reply on news.ycombinator.com