I am worried that the supreme arrogance of abstraction-builders and -apologists that this article's vernacular, too, emanates will be the cause of a final collapse of the tech and IT sector. Or maybe I even wish for it to happen, and fast.
Everything gets SO FRICKIN' COMPLEX these days, even the very simple things. On the flip side, interesting things that used to be engineering problems is relegated to being a "cloud cost optimization" problem. You can just tell your HorizontalPodAutoscaler via some ungodly YAML incantation to deploy your clumsy server a thousand time in parallel across the rent-seekers' vast data centers. People write blogs on how you can host your blog using Serverless Edge-Cloud-Worker-Nodes with a WASM-transpiled SQLite-over-HTTP and whatnot. This article's author fantasizes and fetishizes interconnected lanscapes of OpenID-Connected workloads that are, and I QUOTE, "stateful applications that are stateless". Because "This means data should be handled externally to the application using other abstractions than filesystems, e.g., in databases or object stores." - yeah, fine and dandy, but which platforms of the future should these services be hosted on? And who will develop and shepherd and maintain and fix them?
why not go further and call it "neo-feudalism"? The infrastructure providers are the territorial lords that control the arable land, the aristocracy of the digital world. Corporations that rent this infrastructure to build services on it are their vassals. They may claim to be freemen or nobility as they pay for their fief in money not in services and allegiance, but most of them are ministeriales that can't just move elsewhere without significant risk to business continuity (some can, like a oil mega-corp that just rents some IT infra). Lastly we have the cloud engineers, the serfs at the bottom of the pyramid, who work the land they don't own and have to give part of the profits of their work to the upper class in exchange for the opportunity to make a living on their infrastructure.
I've appreciated many of the modern tooling but as things have matured, I'm convinced the industry has lost the plot. As days wear on, I'm increasingly disliking the complexity these tools have bought and often times see them solving problems that never existed.
With that said, I'll echo your sentiment "Everything gets SO FRICKIN' COMPLEX these days, even the very simple things."
Nomad is now perhaps my only favored tool for container deployments/some orchestration. I also long for the days for the original container ... the folder! Put everything you need in and zip it up. instantly shareable and no spaghetti tooling needed to run it. The OS told you everything you needed to know about the process. I also oppose (my personal opinion) the trend to want to scale things crazy to numbers. I wholly believe on doing more with less. The company infrastructure stack I currently harbor admiration and put them on the pedestal is StackOverflow. Last I checked in 2021 it still ran on 4 MSSQL servers and 9 IIS servers with a few satellite services. Could easily be 4 MYSQL servers and 9 HTTPD servers.
I've been thinking a lot about this complexity problem too. Tech people are starting to get really arrogant and demand crazy salaries across the board. Right now this is OK because tech is now seen as a competitive advantage. I wonder if one day some C level is going to look at their IT budget and start to question if technology is really that much of an advantage. For example, at one point is it cheaper to put 10 humans in a call center rather than build online ordering systems and deal with data regulations, app changes, outages, etc?
That (in house tool builders) is not the kind of IT that demands high salaries, it’s the engineers building the call center replacement software (analogy) that demand the high salary. And they make it up in scale. All of these high paid engineers make it up in scale. And you can see it in companies financial statements. It’s not some hand wavy wizardry.
You need about three engineers to support a ~$500mm/year ecommerce site using managed kubernetes. Really you can do it with two, you need one that understands it, and another guy/apprentice in training who sort of understands it, in case the first guy gets hit by a bus. The third guy is just so the first and second guy don't trade off on-call and get burnt out immediately.
Ten or fifteen years ago you'd be looking at a team of at least five, probably 7-10 engineers, mininmum, to design, maintain and keep up to date a similar system. The company gets a tremendous value out of their three engineers at $150-250k/year, ea
Managed Kubernetes has really changed the economics of deployment. Kubernetes administration sucks about as much as vSphere or Open Stack. Which is to say: a lot. You can debate the details but you are talking highly trained people and potentially several of them to run a large installation. Plus your management chain now needs to worry about HA, security, upgrade being covered.
Managed Kubernetes services like EKS replace that with half a person or less + about $100/month overhead per cluster.
The complexity of the systems (mostly!) reflects the reality of the needs. Thousands of services working in orchestration in an environment that is, by definition, hostile; is non trivial.
Little parts of a system being over engineered may be the fault of an engineers ego somewhere, but the massive complexity of distributed systems isn’t some ego trip or frivolous fiddling with shiny new tech.
It’s just big and hard for mere mortals. It’s hard to say when k8s actually decreases complexity, but I think most will get there before ~100 software engineers do.
My current record is one week with 1 infrastructure person trying to run small containerized application on Azure. This is specific to Azure (I could get it running on GCP no problem, AWS would be a bit more complex), but it reflects, IMO, how k8s is simplifying operations because I could do it easily with k8s on all of those platforms (and that includes setting and managing the cluster).
I lost track on how many hours (more like man-months, mythical or not) k8s has saved so far in my work, whether it was in team of 2 or team of 15 supporting multiple other teams.
The portability and the widespread adoption is a force multiplier but I have yet to be on a (healthy) team where everyone levels everyone up as the k8s complexity grows for even "simple" things (where you end up adding custom controllers or similar). One engineer will add it based on a Google help article or stackoverflow post, HOPEFULLY the engineer reviewing the PRs tries to understand it and only later when it breaks does everyone find out it exists and only Sally knew all the potential issues, etc etc.
On a highly functioning team with strong communication skills and no major egos it should go a lot smoother where everyone is leveling up on the knowledge at the same time.
>will be the cause of a final collapse of the tech and IT sector
It has a name - it is the Anti-Singularity, and it is coming for us all. As we blindly make ever more aspects of our lives completely dependent on increasingly complex and fragile systems, those very systems are becoming unmaintainable, despite ever-increasing numbers of engineer hours. One day, we will go too far, and will make a change that will break things. It won't be possible to go back, as there will be nothing to go back to. As the breaks ripple out, faster and faster, the Anti-Singularity will occur, freezing development in place permanently, and bringing productivity to a halt.
Everything gets SO FRICKIN' COMPLEX these days, even the very simple things. On the flip side, interesting things that used to be engineering problems is relegated to being a "cloud cost optimization" problem. You can just tell your HorizontalPodAutoscaler via some ungodly YAML incantation to deploy your clumsy server a thousand time in parallel across the rent-seekers' vast data centers. People write blogs on how you can host your blog using Serverless Edge-Cloud-Worker-Nodes with a WASM-transpiled SQLite-over-HTTP and whatnot. This article's author fantasizes and fetishizes interconnected lanscapes of OpenID-Connected workloads that are, and I QUOTE, "stateful applications that are stateless". Because "This means data should be handled externally to the application using other abstractions than filesystems, e.g., in databases or object stores." - yeah, fine and dandy, but which platforms of the future should these services be hosted on? And who will develop and shepherd and maintain and fix them?