Put That Microservice Down.

We need to have a no-shit moment, you and I.

Put that Microservice down.

Microservices aren’t for you, yet.

Let’s reach over to the well of software development conventional wisdom and draw out a slogan we all live by. Here, I’ll pick a random one:

Do the simplest thing that can possibly work.

Are Microservices really the simplest thing? Really?

Hell, I’ll pick another random slogan from the well:

You Ain’t Gonna Need It.

Maybe these aren’t random; but they are our best known slogans. In fact, going through all of the truisms I can think of in Software Development, none of them advocate for something remotely like Microservices.

I’ve tried, but I can’t find the “purposefully break up one piece of software into independent and autonomous collaborating systems that none of our tooling is really built to support and that the tooling that tries to support it tries to treat all of it like a monolith anyway (Hi to Dapr, Thrift, et. al.).” truism in our industry.

So why the hell are we creating microservices like our livelihood depends on it?

We don’t even know what the word “microservices” means. At least with its former name, Service Oriented Architecture, the name gave us an idea what direction to head in.

So putting aside for the moment that we don’t even know what that word means,

Have we gotten to the point where these slogans are necessary, but no longer sufficient?

Is there a point where YAGNI, TIMTOWDI, Worse Is Better, Don’t Repeat Yourself and the rest just fall flat on their face as truisms?

Have we reached that point where we have built so much complexity around software development that the old ways of building software are windows into a past we’ll never see again?

I remember starting out in Web Development in 2000 with Perl, and it was simple. It wasn’t easy, but the steps were simple. Looking back, we also didn’t know what we didn’t know, cross-site scripting, XSRF, click-jacking and the like were barely known industry wide. Whether it’s because of the fragile nature of the internet or because those living history don’t have time to write it down, it was hard for me to find the original online first mention of cross-site scripting. It’s hard even today finding what was representative of web development in the year 2000. You can still do it; but the flavor isn’t quite right.

Instead, today, we have lots of moving parts: Webpack, npm, nuget, MVC, API, caching, varnish, pubsub, the myriad of services you would use from a cloud provider: Elastic Beanstalk (is that still a thing?), Elastic Container Service, Elastic Kubernetes Service, API Gateway. Fargate, EC2. And that’s just Amazon’s. Microsoft’s Cloud is similarly situated, except they stick “Azure” before everything because how else can they meet their marketing KPIs? Azure DevOps, Azure Container Instances, Azure Kubernetes Service, Azure App Service, etc.

Once you’ve survived those sets of choices, you still have to decide what front-end you would like to use, if any: Angular, React, Vue, Vanilla JavaScript With Server Rendered Views. And that front end doesn’t even take into account the visual — Bootstrap, Tailwind, Bulma, and dozens more I don’t even know about.

I recognize it’s boomer-ish to pine for the good ol’ days; and in this case, the pining is for a simpler software development model, but I have to ask: Is it gone, never to be here again? Are we just stuck with all this complexity to make anything useful for our customers?

Put another way: Monoliths are a way for us to hold on to the last remaining vestige of our development stack in the year 2000: The code that does the work lives in one place, together. Of course it’s in one repo; but the entire thing is deployed together.

Monoliths may be the last simple thing we have in a world where a new developer needs to understand several disciplines to get a website to work. And now, unceremoniously, we’ve decided that new work should be done in small chunks, deployed separately, collaborating with other small chunks of functionality, and that somehow we’ll be able to make all of this work without going insane.

Microservices tear apart that last remaining bit of simplicity. We shouldn’t do that lightly. Gall’s Law comes to mind:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

John Gall, Gall’s Law.

Success comes from simplicity. You keep success by managing that complexity and keeping it as simple as possible.

And that’s what moving to microservices has to be about. To be successful, it has to be a transition from simplicity because of a small problem set to managing complexity as that system grows. It becomes a way to manage complexity using another dimension — with hopefully better outcomes than other discarded methods.

What discarded methods you ask? Well, how many teams do you know of that strive to put code under test before it’s written (TDD)? Or teams that relentlessly refactor code to reduce technical debt? Or teams that practice loose-coupling and high cohesion of code? Or teams that keep slack in their sprints so they can focus on ensuring they’re adding value without adding in accidental complexity?

How many teams do you know that practice one of those things more than 20% of the time, let alone all of those things?

And that’s just development team practices; ‘agile’ delivery methods like kanban or scrum seek to reduce complexity on another axis: making it easier to deliver value on a regular cadence.

Those are all methods to manage complexity, and microservices attack a combination of delivery and maintainability: breaking down parts of the system into its discrete pieces; allowing developers to reduce their cognitive load, to only think about the part of the system they’re changing without the rest of the system creeping in; but that has a cost.

Before you pick that Microservice back up, why do you want to move to microservices?

Is it because that’s what the cool kids are doing?

Is it because that’s where software development is going?

If so, don’t. Stay in the world of the monolith as long as possible. That’s the only way to escape the complexity you’re about to encounter.

But, if you’re pursuing microservices because:

You want to manage the complexity and cognitive overhead of your system, and other approaches haven’t worked.
You want to open up new lines of business without modifying existing parts of your system.
You want to scale your system and make it easier to adopt cloud native services.
You want to replace your aging monolith in a graceful fashion, without a big-bang rewrite.

Then you’re doing it for the right reasons, and you’ll get the most out of the move to microservices.

But let’s be real: It’s not an easy road, but it’s worth it if you are solving the right problem.

Leave a Reply