Saturday 26 May 2018

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"


20 comments:

  1. Great Post,really it was very helpful for us.
    Thanks a lot for sharing!
    I found this blog to be very useful!!
    JAVA training in Bangalore

    ReplyDelete
  2. Iron Strike - Titanium Trimmer | TITAN-ART
    Iron ecosport titanium Strike is an titanium road bike Iron Strike for titanium dioxide the HTC Vive, HTC Vive, titanium dioxide sunscreen Playstation 1 and PlayStation 2. This item works perfectly on the titanium band rings HTC Vive.

    ReplyDelete
  3. Students are facing a lot of issues in completing the assignments and other academic tasks assigned to them on time.we open the networks of Assignment Help Canada for all students who have concerns for their project submission Our skillful Canada assignment writers are committed to providing students with top quality online solutions that help in their career advancement.We are providing top-quality online assignment help in Canada and helping students to score well in this competitive environment.
    For more info- Get Assignment Help Online

    ReplyDelete
  4. good article about diffusion of microservices
    Appointment Setting Lead Generation Companies

    ReplyDelete
  5. thank you for the information
    I concur that this is the most thorough description of the subject. I'm so glad I found your blog and am looking forward to reading your future posts. And I have referred to related content in the link below.

    At Login360, you may get the best training in android Training in Chennai
    . We provide a variety of software-related courses along with complete placement assistance.

    Excellent IT instruction has been given to our pupils in a number of methods by our teachers and subject-matter specialists.

    We offer top-notch instruction in Android technologies, and we frequently update our curricula to include the most recent IT trends.

    We provide placement help for recent grads (recent graduates). We will offer support to all eligible applicants.

    Contact Details:
    Name: Login360 Software Training Institute
    Address: No-06, Ground Floor, 5th Main Road, Vijaya Nagar Velachery, Chennai – 600042.
    Phone: 6385872810

    ReplyDelete
  6. Eimple Labs born to prepare an industry ready workforce. As a product based company Eimple Labs ensures to inculcate the end to end live product development and management skills. We work in a university-industry partnership and implement a holistic knowledge-imparting model to prepare students for new-collar jobs in emerging industries.

    ReplyDelete
  7. The best graphic design institute in Jaipur is Creative web pixel. Creative web pixel is having the best web designing courses in Jaipur. In a graphic design course, we provide classes from basics to advance level. We are providing the classes of the courses that come under graphic design. You can learn the course according to your interest.

    ReplyDelete
  8. Thanks you for sharing this. You can also check this: rpa online training

    ReplyDelete
  9. Thanks for sharing this amazing article. you can also check this: comptia a+ certification training

    ReplyDelete
  10. I appreciate you sharing this fantastic article.

    java course near me

    ReplyDelete
  11. A market research consultant is a professional who helps businesses gather, analyze, and interpret information about their target markets. They play a crucial role in helping businesses make informed decisions about their products, services, and marketing strategies.

    ReplyDelete
  12. This comment has been removed by the author.

    ReplyDelete
  13. Thank you for the article. it was awesome need more articles like this. i Have also posted articles like this : IB math tutor

    ReplyDelete