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 on what a microservice is, you will find many different descriptions, exhibiting considerable difference of opinion. Most claims about microservices are non-technical rather than technical, for example the allegedly "independent" software development style around microservices, or some alleged organization of microservices "around business capabilities". Even when the claims do stick within the technical realm, they are often unwarranted; for example, I have seen statements to the effect that a microservice is supposed to live in its very own source code repository, that microservices must communicate with each other via nothing but REST, etc. My favorite one is that they must necessarily be stateless. This paper is a first step in dispelling the statelessness myth.
(Useful pre-reading: About these papers)To clear up the confusion a little bit, I would like to propose a purely technical definition of a microservice which is brief and to the point:
From a purely technical standpoint, a microservice is a scalable module.
So, what I am proposing here is that the only fundamental technical requirement for a microservice is scalability, and that all other purported characteristics mentioned in the literature are either non-technical, or they are byproducts of this fundamental technical requirement.
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 appearing, and are commonplace today.
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 that their product has 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. (1)
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, and only for the purpose of these papers about statelessness.
There is one more characteristic of microservices which is not really fundamental, because it is a direct consequence of the first, but it is so important that it deserves mentioning as a requirement, 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 perform much worse than monolithic ones. In order to accommodate the same workload that you used to have with a single server running a monolithic application, 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. Thus, when we are talking about scalability, we are usually talking about a lot of hardware. And by this I mean an awful lot of hardware.
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. The result of all this is that hardware failure in server farms becomes 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:
From a purely technical standpoint, a microservice is a scalable and resilient module.
Further reading: michael.gr - On Stateless Microservices
(1) According to Neal Ford, this started with Pets.com; see Neal Ford: "Stories Every Developer Should Know" at YOW! 2018, starting at 35:56
No comments:
Post a Comment