Semantic diffusion of microservices

It has been a couple of years already that we can hear microservices buzzword being mentioned in the IT world. "We have microservices doing this", "Oh, let's write a microservice doing that". If you are completely new to this term you might event think that these guys are smart, experienced, and they are up to date with the latest architectural trends in software development. But if you are really carrying about the words and their meaning, you will quickly get pissed. 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 only by using some 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 the motivation, it is not the first time in the history when we can observe such phenomenon. Even in the late 80s when there was a 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 of 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 think carefully if you are really doing microservices. I would like to encourage everyone to care for the 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 is a couple of heuristics, though. The first one is that if you feel that you start loosing 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 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 granulated applications doing almost nothing. This is what we call nanoservice - yep, nano is not micro - 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, we 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 application 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 loose cohesion and autonomy, which means you are far away from real microservices.

Conway's Law

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 this 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 business will know exactly of what's going on in the company.

If you underestimate 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 any more.

What you give and what you get

Microservices wouldn't have been such a popular architecture style if it hadn't been for the concrete benefits that they give us. What benefits I am talking about? Autonomy.

High cohesion, which is the main microservices characteristics, implies applications’ autonomy. Now the autonomy is multidimensional. It can refer to agile teams’ structure, independent deployments, technology stack, data management, scalability. However, we don’t get it for free. Service discovery, load balancing, design for failure, monitoring, continuous delivery - these are the things we need to 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, details on this topic you will find 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.

Be pragmatic

As it was already said, in our day to day work we are supposed to bring value, not to 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 how you will manage all the problems of distributed environment, because they will occur for sure. Make small steps, providing solutions one by another 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 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 won't be crystal clear, the anti-definition will. And for me it is better to tell "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.

Conclusions

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 specific philosophy. Semantic diffusion that we observe nowadays make this term devaluated. 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's quote:

"(...) a good term is worth fighting for - particularly since the only bullets you need are words"