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"


14 comments:

  1. Replies
    1. The effectiveness of IEEE Project Domains depends very much on the situation in which they are applied. In order to further improve IEEE Final Year Project Domains practices we need to explicitly describe and utilise our knowledge about software domains of software engineering Final Year Project Domains for CSE technologies. This paper suggests a modelling formalism for supporting systematic reuse of software engineering technologies during planning of software projects and improvement programmes in Final Year Projects for CSE.

      Software management seeks for decision support to identify technologies like JavaScript that meet best the goals and characteristics of a software project or improvement programme. JavaScript Training in Chennai Accessible experiences and repositories that effectively guide that technology selection are still lacking.

      Aim of technology domain analysis is to describe the class of context situations (e.g., kinds of JavaScript software projects) in which a software engineering technology JavaScript Training in Chennai can be applied successfully

      The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training

      Delete
  2. I have read your blog its very attractive and impressive. I like your blog Java online training Hyderabad

    ReplyDelete
  3. 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
  4. Thanks For Sharing The Information The Information Shared Is Very Valuable Please Keep Updating Us Time Just Went On Reading The article Python Online Course Hadoop Online Course Aws Online Course Data Science Online Course

    ReplyDelete
  5. Thank you for sharing the article. The data that you provided in the blog is informative and effective. Best Devops Training Institute

    ReplyDelete
  6. This is such an informative blog, your opinion, observations and ideas are amazing and to the point. I would love to read more content like this, and I want to give one advice to you are looking for a builders in bhopal then Sagar Green Hills is the ideal township for you.

    ReplyDelete

  7. Thanks for Sharing This Article.It is very so much valuable content. I hope these Commenting lists will help to my website
    top microservices online training

    ReplyDelete
  8. Thanks for Sharing This Article.It is very so much valuable content. I hope these Commenting lists will help to my website
    top workday studio online training

    ReplyDelete

  9. I was scrolling the internet like every day, there I found this article which is related to my interest. The way you covered the knowledge about the subject and the Bungalows in chunabhatti bhopal was worth to read, it undoubtedly cleared my vision and thoughts towards B Commercial Shops on ayodhya bypass road. Your writing skills and the way you portrayed the examples are very impressive. The knowledge about flats in chunabhatti bhopal is well covered. Thank you for putting this highly informative article on the internet which is clearing the vision about top builders in Bhopal and who are making an impact in the real estate sector by building such amazing townships.

    ReplyDelete
  10. Thanks for sharing article. The way you have stated everything above is quite awesome. Keep blogging like this. Thanks.
    AWS training in chennai | AWS training in annanagar | AWS training in omr | AWS training in porur | AWS training in tambaram | AWS training in velachery

    ReplyDelete