Microservices — Nothing Lasts

Nothing lasts forever

TLDR;

Build something simple and small, make sure it is replaceable.

Background

I was enlightened by this talk Microservices: How to Build Systems that Survive.

I used to encourage engineers to write a stable services (programs, apps). And usually, I would mention several services that we haven’t touched for some time just because it simply works. The angle I approached the engineers is:

Let’s build something stable. When you build something stable, you don’t need to be bugged by bugs. Hence you could focus on another upcoming exciting projects. When there are lots of bugs, you would keep coming back to fix the bugs, leaving you with little to no time doing other exciting projects.

This perspective is actually a fruit of my history in software engineering realm, where usually a “product owner” (or boss, or whoever gives you the tasks/jobs) have a lot more ideas (backlog) than the engineers could realized. Most often than not, the engineers would already have lots of bugs waiting to be fixed, and technical debts that haunt them.

Realization

The talk makes me realized that what I said (build something stable), although kind of makes sense, has a potential problems in it.

I realized that there are several services that I personally have rewritten times after times. They are small services, those that do one thing, as how a microservice should. Since they are so small, I could try out few architectures, new technologies and stuff. That’s how I learned as a software engineers.

Every time I look back to a code that I wrote months before, there are always things to be optimized, whether it is about performance, of readability.

Large Things

There are some projects that turns out to be big. The one that have a big impact. The one that you wouldn’t want to be offline as it would cost you a great deal. The one that you wanted to ensure a 100% up time.

Such projects are most likely to be handled by senior engineers. Usually, this kind of project is the type of project nobody would dare to touch. Everybody is so afraid that they would break the system.

The positive remains: if it works, it works, need not to touch. The drawback, however, when there are a slight change required, nobody would dare to do it. Leaving the original developers face it, alone. Then there comes a risk. What if that engineer were leaving? Who would take charge of that system?

Tiny Things

That’s why it’s preferable to have something small. When it’s small, you can always replace it.

As mentioned in the talk Microservices: How to Build Systems that Survive, imagine the cells in our body. It was never meant to last! It’s meant to be replaced by newer cells.

Even the great creator couldn’t make things last. How could us? For example, the constantly dying cells of our body, or the dying stars in the solar systems.

The Middle Ground

I would not take things to the extreme. At least I tried not to. I think it would be best to keep things simple and small, yet stable. So stable that it requires minimum maintenance. So simple that everybody could easily replace it, if necessary.