Hacker News Reader

Comment by ryandrake | Hacker News Reader

My background is in embedded, so I admittedly know extremely little about web development, but whenever I'm curious and sit down to read about microservices and containers and orchestration and all that stuff, my mind starts to numb and I can't help but conclude that 99% of companies that use it probably don't need to. And that they're just a complex way for engineers to keep themselves spinning their wheels and not actually working on an application. Like that guy who insists on doing nothing but refactoring and rearchitecting and moving things from one layer in the stack to the other, re-writing in different languages, integrating new third party libraries that do the same thing their existing third party libraries, but not actually adding anything that improves the product. How did the world get into this situation where you need all this complexity just to deploy and configure not even an application, but part of an application? Amazing!

View on HN

> And that they're just a complex way for engineers to keep themselves spinning their wheels and not actually working on an application...How did the world get into this situation where you need all this complexity

Isn't this just labeling the knowledge that you don't have (and could probably read up on) as potentially unnecessary complexity?

I mean, every time I hear about embedded, I keep hearing about byte boundaries, RTOSes, compiler chains, musl, JTAG, and a million other things that make my mind numb. But I assume embedded engineers need to know all those things, because of the constraints unique to their field. Some of them could be just "a complex way for engineers to keep themselves spinning their wheels and not actually working on an application", but a lot of them provide value in the real world and solve some specific problem.

Cloud infrastructure management frameworks are the same.

Fair enough--we perceive things we're ignorant about as complex. I buy that.

I guess I was comparing it to how things were (or more precisely, how I perceived things) 20 years ago. You'd rack a server or two, install Linux, stick the application in /usr/local/bin, make sure Apache was set up, and you were off and running. Simple enough. It probably didn't scale to 2020-sized Internet user counts, though.

> You'd rack a server or two, install Linux, stick the application in /usr/local/bin, make sure Apache was set up, and you were off and running. Simple enough.

That sounds incredibly complex! :) Where would you find a place to rack a server? Are there minimum rates for such a place, or can you rack a single server for one month? Would you be able to rack it yourself? What if there was some problem with the PSU, and the server lost power when the data center was fine? What if the network card failed? What about if a hard drive in the server blew out?

Cloud infra in 2021 infrastructure has pretty turnkey answers to all of those (Kubernetes is not one for any of the ones I mentioned, except maybe for “what happens when any node goes down“). So yes, the complexity might be high, but so are the capabilities.

I mean, maybe you are running a mom-and-pop shop with a server rack in the basement for some reason, and have pretty daytime-specific hours. That's fine, and I still think you can do the server rack thing. Or at least that's the way I see it.

Perhaps one piece of meta-commentary here is that server hardware has not become substantially cheaper, faster, smaller, and easier to set up since 20 years ago. I can't really set up a server in my small bedroom that's capable of serving 10k concurrent users, and doesn't deafen me with its noise. Maybe if I did, all this cloud stuff might be less ubiquitous?

Yeah, everyone feels that way until they ran into several issues that suddenly make containerization look like a great idea.

examples?

> How did the world get into this situation where you need all this complexity just to deploy and configure not even an application, but part of an application? Amazing!

Because everyone else is doing it.

Things have gotten so complex that we need complex solutions, but w're afraid to make and own the solution ourselves because of cost, focus on core business or recruitment/knowledge concerns. So we need to find the next best open source solution to leverage the collaborative effort to reduce time and cost and have a large community to fall back on for support. And because everyone jumps on board of the same train all use cases must/will be accounted for (else the solution will fade into a niche), meaning the solutions becomes a problem in and of itself.

Repeating the cycle once again.

There's an xkcd for that.

I do work in web app development, and what you say is spot on.

I used Docker for embedded.

Running a cluster across your IOT fleet (1k+ devices; 5-10 apps each) gives a nice interface for pushing out tasks, choosing applications for a device, configuring supervisor-device relationships, etc. It turns out from scratch Docker containers on ARM are very portable.

I think you’re being dramatic — embedded is notorious for crazy builds of weird config flags to even get “hello world” to compile, and you’re waving your arms pretending that concepts from Erlang abstracted away from the language are too much.

Docker is just cgroups and namespaces, with a zip file of code. More or less literally.

Orchestration is the same mess it’s always been — back to at least the telephone days, when Erlang used the same concepts.

That sounds fascinating. Would be very interesting to read more about your IoT fleet, tasks, and deployment with that stack.

Reply on news.ycombinator.com