Take

Popular modern technology is taken over by expats from a megacorp and made worse in the service of a hyper-specialized (and just plain over-hyped) orchestration platform. That's the world today. Anything that has a simple and elegant feature-set ends up coöpted by people who just want to build big ungainly architecture and ends up inheriting features from whatever megacorp the coöpters came from.

I have a tenuous relationship to containers, to orchestration, to automated infrastructure-as-a-service with Puppet, Ansible and so on. They make possible the dream of having a sea of computation, where your service isn't the individual wave or stream, but rather the sum of whatever needs to come into existence at the moment.

The problem for me is – at what cost do you get this? If you're Google or some other huge company, you need to have this anyway, the entire department company-wide (and/or one or two people in each related effort) are worth the expense and effort, and the complexity at least isn't added complexity as much as it is things you'd have to deal with one way or the other.

If you're not, well, you either have to spin up a layer of architectural and organizational complexity that Google can support or throw in with some sort of cloud solution that does it for you. Either is costly in one way or another, and handing someone else the keys never absolves you of all the new exciting ways in which something can break or fail to be tuned or proportioned correctly.

Which leaves the option of not doing it. I just received a message from my host that in August, the singular server that hosts this place will go down for a service window that "should be about an hour". Leaving aside the question of how on earth this isn't handled by live migrating these virtual machines to another server, this is a good opportunity to highlight the difference.

Right now, this site hosts everything on one server, with one application serving the pages and one SQLite database hosting them. To avoid the downtime, I would need to have at least two servers and a load balancer, and by necessity either a third server for the database, hoping it wouldn't need to go down at any point or a vendor-provided "database service" that I could use which could come with such guarantees, just like the load balancer.

The point isn't that these services are beyond me, or that it would be terribly expensive in real money, really, even if it would be a factor of 5-10x. The point is that the complexity needed to scale up comes in steep cliffs.

There's nothing wrong with understanding how to scale and decouple in the first place. The current lore and fascination with containers and orchestration invites you to entertain these investments, these aspects and these costs for everything you do. If what you do is a large scale system where every part is mission critical (either to a customer or to other infrastructure), they are justified. But what happens when our industry gets enthralled with this way of functioning, to the point when all technology works best like this?

What happens to the developer that only needed the simple solution, or to the many small shops that can scarcely afford the infrastructure or hosting costs, or the also many slightly larger shops where the resources are there, sure, but people end up spending much of their time monitoring and gardening the large complex system and less time doing actual development? And, to roguelazer's point, what happens to the simple solution, which could have been used by developers and solutions of all shapes and sizes to solve smaller or less complex problems in a meritorious way?

(This is effectively also a corollary on the related but not identical microservices debate which is essentially the same argument on another plane. Swap out Google for Yelp.)