Semantic Diffusion of Microservices
Semantic Diffusion of Microservices
Are we calling too many applications ''microservices'' without thinking? Let's talk about the vocabulary of microservices and distributed systems.
Join the DZone community and get the full member experience.Join For Free
Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.
It has been a couple of years already that we've heard the "microservices" buzzword being mentioned in the IT world. "We have microservices doing this," or, "Oh, let's write a microservice doing that." If you are completely new to this term, you might even think that these guys are smart, experienced, and up-to-date with the latest architectural trends in software development. But if you really care about the words and their meaning, you will quickly get pissed off.
Right now, it is really annoying to hear that the word microservice has become a replacement for the name of almost every application that has been developed. At the same time, programmers often seem to treat microservices just as a set of relatively small applications, forgetting both that there are people behind that concept and that they are entering the distributed world, and committing so-called fallacies of distributed computing. I might seem to be overreacting because the definition of a microservice is still floating, but for all those years, numerous design patterns, good practices, and heuristics have been well-established, and clearly manifest what microservices are all about.
Do we really need to keep up with times by using buzzwords? Or maybe we are trying to find an excuse for not giving enough effort to think of what microservices really are? Or maybe we just want to feel that we are trendy? Regardless of the motivation, it is not the first time in history when we can observe such a phenomenon. Even in the late 80s when there was hype about Object Oriented Programming, developers called every piece of their software an object, although they were usually nowhere near the OOP principles. Martin Fowler, in one of his articles, came up with the term "semantic diffusion":
"Semantic diffusion occurs when you have a word that is coined a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely - and with it any usefulness to the term."
...and this is exactly what I'm talking about. The aim of this article is to shortly tell you what microservices are, how many different areas they cover, and how many things they require and imply. Then I hope you will revise your organization and software architecture and consider carefully if you are really doing microservices. I would like to encourage everyone to care for words and to defend their true meaning.
Does Size Matter?
The first thing that we should talk about is what "micro" means. How little is little enough and how little is too little? If you are waiting for a concrete line count range that would classify your application as microservices within a given technology stack (language, platform, framework, etc.), then sorry — there is none.
There are a couple of heuristics, though. The first one is that if you feel that you start losing the idea of how things in your code work, then it is probably too big (assuming you wrote it cleanly). Another rule of thumb was given by Jon Eaves, who said that if your application is a microservice, it should be rewritable in two weeks. We might also go in another direction — when the communication and maintenance costs of your application are much bigger than gains from its usability. This happens very often when we split our domain to separate services too eagerly, and we end up in having too many granulated applications doing almost nothing. This is what we call a nanoservice — yep, nano is not micro — and it is considered an anti-pattern. Of course, a very small application is nothing wrong as long as it really brings you enough value that you are ready to accept the costs of distributed computing which we already mentioned.
All these heuristics might make sense in some specific contexts; when we know our business domain well and have years of experience in the field of microservices, we learn what "micro" means for us. In general, however, DDD is what we should follow. If we implement an application for our Core Domain, we might not know how complex it is from the very beginning, and it is the complexity that may determine the service size. It is the business functionalities that we care for, not the size. Such applications must gather things related to exactly one bounded context so that we can provide high cohesion and decoupling/autonomy. However, if we implement applications from supporting or generic subdomains, should we care about the size? Not really, as this is not what we get money for.
Summing up, service size from any range won't make our application a microservice, so if you try to call you service a micro one and justify that with the number of your code lines, you are just doing it wrong. Similarly, if you mix business responsibilities among numerous applications, breaking your core domain's bounded contexts, you lose cohesion and autonomy, which means you are far away from real microservices.
Microservices are people. We are not developing software for fun — someone is paying us for bringing value. Now, how many times were you angry at the way applications in your company are communicating? It didn't happen just like that, and it didn't need to be developers' fault. According to Conway's Law, every organization that creates a system will eventually create one that will mirror the communication structure from within the company. Developers often tend to ignore business people — they seem to know what's best and how to solve all their problems. We know how to code, but we might not know the business. Let's talk with people who will use our systems, discover their processes, help them in locating bottlenecks, and...maybe go for DDD; if both developers and business are on the same page, our services will surely reflect that. Developers will be organized in teams corresponding to bounded contexts, and the business will know exactly of what's going on in the company.
If you underestimate the human factor and ignore the voice of the business, you will keep chaos in your services as well. If you don't discover the domain well enough, you won't be able to keep your applications cohesive, and thus you will lose their autonomy (yeah, it means there won't be any microservices anymore).
What You Give and What You Get
Microservices wouldn't be such a popular architecture style if not for the concrete benefits that they give us. What benefits am I talking about? Autonomy.
High cohesion, which is the main microservices characteristic, implies applications’ autonomy. Now the autonomy is multidimensional. It can refer to agile teams’ structure, independent deployments, technology stack, data management, and scalability. However, we don’t get it for free. Service discovery, load balancing, design for failure, monitoring, and continuous delivery are the things we must provide to deal with the problems of distributed computing, and fully utilize microservice architecture benefits. As this is out of the scope of this article, you will find details on this topic in a separate article.
Each vector of microservice autonomy space must be addressed within your infrastructure and on the organizational level. There are undeniable benefits, but they are hard to deliver if you don’t have the culture in your company or don’t solve issues of distributed systems first. Microservices give, but they take as well.
As it was already said, in our day-to-day work, we are supposed to bring value, not be rock stars. If microservices is what you find useful in your case, go for it, but be pragmatic and don't forget that the value is what you are paid for. Remember that microservices are about distributed computing, and before you go into development, think carefully about how you will manage all the problems of a distributed environment because they will occur for sure. Make small steps, providing solutions one by one, and you will quickly learn a lot, and at the same time, you will know if this is what you expected from microservices.
Don't worry if you start with a monolith — it is not a shame. We, the developers, are adults (mostly), and we are to make conscious decisions as software development is about tradeoffs. Don't pursue buzzwords; study them carefully instead, experiment, use well-defined patterns, choose solutions that fit you best, and believe me, you will finally feel confident with them and they won't be buzzwords for you anymore. If the definition isn't be crystal clear, the anti-definition will be. And for me, it is better to say, "I have a distributed system where I use microservice architecture patterns" than call everything a "microservice," as the second one is really hard to defend.
Summing up, microservice architecture has become a popular buzzword that every developer would like to use to keep up with the latest architectural trends, but microservices are not about nomenclature — these are concrete rules, tradeoffs, decisions, patterns, problems, and a specific philosophy. The semantic diffusion that we observe nowadays has devalued this term. In this article, you got a brief overview of what stands behind the definition of microservices, and what does not. I will end this article with one more Martin Fowler quote:
"...A good term is worth fighting for - particularly since the only bullets you need are words."
Published at DZone with permission of Bartłomiej Słota , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.