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 articles of mine that discuss microservices.

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 one in another post.)

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, which they were initially reluctant to do, but 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, thus starting the whole microservices revolution; 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 made possible something which was impossible before.

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, but the truth of the matter is that most people do consider scalability to be a necessary characteristic of microservices, and I believe that if we re-examine all purported characteristics of microservices and discard all those that are not strictly speaking necessary, then the only one we are left with is, in fact, scalability.

There is one more characteristic of microservices which is practically a requirement, but it is not fundamental, because it is a direct consequence of the first, and this 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 are not anywhere near as performant as monolithic ones. In order to accommodate the same workload that you used to have with a single server running a monolith, you might need 10 servers running microservices. (I am just throwing a number here; what I mean is a ratio far worse than 1:1.) 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. And once you are capable of doing that, then you will of course add much more hardware, in order to accommodate more than the workload you originally had; afterall, that is precisely why you made the move to microservices in the first place. So, when we are talking about scalability we are usually talking about a lot 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 those pieces will fail at any given moment. Furthermore, as these pieces age, their individual chances of failure increase, and when we are speaking of hardware aging, we are not talking in terms of decades, we are talking in terms of years, which means that after one year of continuous use, a server may very well be nearing the middle of its expected lifetime. All this leads to hardware failure becoming such a frequently occurring phenomenon in server farms, that it must necessarily be addressed by the software architectures running on that hardware, or else the software is not simply running a high risk of failure; failure is with mathematical certainty inevitable.

A software system that manages to continue functioning despite parts of it ceasing to work is called a resilient software system. Once scalability is possible, resilience becomes necessary as a direct consequence of utilizing that scalability. So, if we really 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.

No comments:

Post a Comment