So, what is a Microservice, anyway?

This article attempts to shed some light on what a microservice really is; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

What is a microservice?

If you go looking for information out there, you will find many different descriptions of what a microservice is; these descriptions exhibit considerable difference of opinion, and to the extent that they agree, it is largely the result of copy-paste. One common theme in these descriptions is that in trying to define this elusive concept, they tend to assign fictitious properties to it. Often, the claims have nothing to do with what a microservice technically is, but rather with impertinent concepts such as the allegedly "independent" software development style around microservices, or some alleged organization of microservices "around business capabilities". Even when the claims do manage to stick within the technical realm, they range from the unwarranted to the preposterous. I have seen statements to the effect that a microservice is supposed to live in its very own source code repository, that a microservice must be independently deployable, that microservices must communicate with each other via REST, etc. (My favorite one is that they must necessarily be stateless; more on that in another post of mine; see  michael.gr - On Stateless Microservices.)

(Useful pre-reading: About these papers)

To clear up the confusion a little bit, I would like to propose a definition of a microservice which is brief and to the point:

A microservice is a scalable module.

So, what I am proposing here is that the only fundamental requirement for a microservice is scalability, and that all other purported characteristics mentioned in the literature are in the best case byproducts of this fundamental requirement, or, more often, nothing but filler to make the text longer.

You see, there was a time back in the late 1990s to early 2000s when users were joining websites at exponential rates, and servers running monolithic web apps were reaching capacity and could not deliver service anymore; the business people were asking the technologists to fix this, because they were losing money, and the technologists were saying that they could not do anything, because they already had the biggest, most expensive server that money could buy. The business people would naïvely say "well, add more servers!" to which the technologists would (equally naïvely) reply "you don't understand, that's impossible!" Later on the technologists started realizing that it is in fact possible, it just requires a radical change in their way of thinking, and a radical redesign of all their systems. When the sums of money at stake were high enough to justify redoing everything from scratch, scalable systems started becoming mainstream. 

The new software development paradigm that was allowing web sites to achieve scalability received a name quite some time after it first started being put to use; the naming happened some time in the mid 2000s, and it was microservices.

Then of course came the evangelists. Unfortunately, when people become salespersons of a cause, for some reason they never seem to be satisfied with simply mentioning the one real, game-changing advantage of their product over the alternatives; instead, they feel compelled to throw as much as possible at the customer, inventing advantages if possible. That's how all the fictitious characteristics of microservices came to be. However, the truth remains that there was one and only one thing that business needed which could not be achieved otherwise, and therefore business was willing to pay for it limitlessly, and that one thing was scalability, nothing else.  

Business could not care less whether the software gets deployed in pieces or in a big bang; business could not care less whether development is done by autonomous teams or by all the programmers shouting at each other in one big room; business could not care less whether the software communicates via REST or via pheromone secretion. Things were getting done before, and things would continue getting done, regardless of those alleged "advantages" of microservices. Scalability was the only thing that was impossible before microservices and was made possible by microservices.

Of course, you might not agree with this definition; if not, then please take it as nothing but a working definition only for the purposes of my articles.

There is one more characteristic of microservices which is a direct consequence of the first, so it is not really fundamental, but it is so important that it practically becomes a requirement. That is resilience. 

You see, scalable architectures are not magically capable of performing better than monolithic ones; in fact, quite the opposite is true: in terms of raw throughput per unit of hardware, scalable architectures  perform much worse than monolithic ones. In order to accommodate the same workload that you used to have with a single server running a monolith, you might need several servers running microservices. The benefit of the scalable architecture is that you can in fact now throw more hardware at the problem, instead of being stuck with a single piece of hardware. So, given enough money to buy enough hardware you can end up with a higher sum of throughput despite the worse throughput per unit of hardware. 

Of course, once you have added enough hardware to accommodate the same workload that you used to have with the monolith, you are not likely to stop there; you will probably be adding even more hardware, in order to accommodate higher workloads. That is why you made the move to microservices in the first place. So, when we are talking about scalability, we are usually talking about lots and lots of hardware being involved.

Now, it just so happens that hardware, being necessarily bound to the constraints of the physical world™, has this inconvenient characteristic called "Mean Time Before Failure" (MTBF) which is of a somewhat statistical nature: the more pieces of hardware you have, the higher the chances are that any one of them will fail at any given moment. Furthermore, as these pieces age, their individual chances of failure at any given moment increase. All this leads to hardware failure in server farms becoming not just something that there is a high risk of; not even just something that is inevitable; it actually becomes a regularly occurring phenomenon. As such, hardware failure cannot be addressed on an as-needed basis via crisis management responses; it must be addressed systematically, as a normal part of the operation of the system. This means that the software that runs on that hardware must be capable of continuing to function as if nothing happened despite pieces of the hardware randomly failing and being replaced all the time.

A software system that manages to continue functioning despite parts of it ceasing to work is called a resilient software system. If we want to add the resilience concern into our definition, then this is what we are left with:

A microservice is a scalable and resilient module.

Further reading: michael.gr - On Stateless Microservices