Saul Howard

Service politics

Microservice architectures are a solution to scaling systems. Startups who start with a micro service architecture before they have scaling problems, sometimes before they even launch, attract ridicule.

But microservices are also a solution to an engineering management problem. Startup codebases are usually a mess. Proof of concepts, abandoned features, quick hacks are what it takes to find the product.

Developers keep returning to service architectures because the separation of concerns enforced by the network makes it easier to maintain the codebase, onboard new developers and adopt and abandon features. Maybe your startup has a loyal team of focused developers, and you can do all of that within a monolith. But many don’t. In Yegge’s Platform Rant, he showed how service contracts are necessary for managing multiple engineering teams, but individual developers can benefit from them too.

Serverless functions, LLM-scaffolding, cloud IDEs and bounties for features are all on the rise. Increasingly, systems are built from loose federations of distributed functionality. Like all engineering solutions, it’s a tradeoff. Abstracting problems at the network layer gives you network problems. But it can solve for spaghetti-monoliths.