Dilemma on Utility module , making a jar or separate Microservice?

In my previous article, I talked about How you can come to a conclusion about what to choose for your new project Microservice or Monolith? 

As an architect may you follow the points what I mentioned in the previous article and come to a conclusion that you will be going to use Microservice Architecture, A big cheers for you, You promoted yourselves as a first-class citizens of the new era of  Digital world, but(when but is used it means the previous word is meaningless/no value until you solve the next part of but :)) what's next , you heard about Microservice Architecture demands Componentization of service but what is actually a component in Microservice world?

In this article, I briefly discuss What does it mean by Componentization, and when we need to do Componentization of a Utility module what problems we faced?

Componentization of service:: By the word "Microservice", we can understand it is a suite of small services, so the main objective is breaking a project into multiple services. But what does it mean by services, Which kind of services are those? Are we talking about a Service layer in a layered architecture, or a service wrap into the jar so-called "Library" or publish it through REST API, what is that?

To understand always remember "Microservices means an Independent thing(Component/Service whatever you call it) that can be deployed independently and update independently manage it lifecycle independently".

When you Create a Microservice very clear about that, There should not be any confusion, Maybe many tricky situations come but stick to basics "Microservice mean an independent deployable thing".

One of the best dilemmas is,  Suppose you have a utility module, now you are in a confusion what should you do,  wrap utility module into a jar and all other Miocroservice use the same as a jar , so that there should not be a code duplication or expose a utility service with API fiction(Separate Microservice)  so others can consume it.

One may think, making utility module as a jar   seems severely wrong in Microservice workspace as Microservice means several independent small services so Utility module  should be published as a service,  so Utility module must be a Microservice,

Why is the Utility module as a Jar a bad Idea?

when you import utility module as a jar you limit yourself, Now Your service is dependent on utility module which packaged as jar, If utility modules  java version upgrade you have to upgrade your service unless your program not able to use that jar, Now you both should stick in same language java(Although once service is written in one language, I saw rarely that is rewritten in another language), having said that,  you should not confined  your Microservice to a language(Java), Think your utility module is used by many microservices as a jar, so if you want to upgrade your version  it should be backward compatible, say you want to create functions which can easily be achieved by java9 but you can not upgrade your utility as other microservices not upgraded to java9.

Why Utility module as a Jar is a good Idea?

As a counter logic many can argue, To build a Microservice itself, we  import jars/Libraries like Sprint boot starter parent, or GSON, Jackson etc, so why we should not package our utility as jar why it is a bad idea , Even let me tell you, many architect think it is a brilliant idea as  it solves many purposes.

If we are not using utility module as a jar then we have two options

1. Duplicate the functionality of a utility module in all Microservices.

2. Create a Microservice called Utility service and publish an API to invoke utility methods.

These two options has there it's own demerits.

1.  Duplicate the functionality of utility module in all Microservices::Here the objective is duplicate the code to all Microservices who consumes Utility module, so that there is no utility module as such, all are the part of local codebase, but it is against the DRY principle and bad idea, If the utility module is holding some complex code which associates many classes, unnecessary that has been copied to all Microservices and any future changes in that, has to be copied over all Microservices. So there is a problem of maintainability, say we have a utility module which calls an External service and get a complex response then this module parsing the responses apply some business logic on it and create some analytical data which exposes as public methods (Java API), Now if you copied that complex algorithm written in Utility module in to multiple services certainly it is a very bad idea, think how many time duplication has been done, and if now a new analytical data is needed you have to add it in all Microservices , oops what a pain while I am writing this I am getting feared to imagine the scenario. So certainly it does not work unless you have a very small portion of utility code and which is not changeable say a generic code which deals with Date, TimeZone, and Format, ( A single class with multiple static methods), Copying that class in all Microservice is a onetime effort.

2. Create a Microservice called utility service and publish an API to invoke utility methods : 

So, you create one Microservice where all utility methods are dumped, as this is a Utility module all Microservice or most of the Microservice Communicate with it, So Every Microservice has a link with this Microservice, So just imagine the picture every Microservice dependent(HAS-A) on it , So If that service is down due to some erroneous code or all instances down due to some major causes, All service will be down Total Microservice architecture is doomed then How it is different than a monolith?

As per Microservice, Partial failure may happen but total Microservice will not down ever, It has 100% uptime.

So certainly creating a Utility Microservice not looking very promising.

As an Architect What should you do now It is like a double-edged sword, whatever the option you choose, You have to deal with demerits.

Taking a decision :: As an architect, we always dealt with Demerits and try to choose in which case, which one to choose so it has least demerits, So, As an architect our favourite answer is "It depends on scenario", and we are hated for that answer, even Juniors are mocking us he does not have direct answer always said it depends.

Here I also giving answer in a same way, It depends :) How your utility method is written, in a one liner if your utilty functions are statless use Jar , If your utility functions are dealing with State use Microservice.

If you observe minutely, you can divide your utility methods into two categories.

One type of utility modules takes and input doing some operation on it and returns a result so there are no side effects and it is independent of any parameter state, every time you pass the same parameter you got the same result, In this case do not publish those as separate Microservice, as this is not dealing with state , so no need to publish as REST resource, because no create, Put ,delete operation done by this, So, you can package this as a jar and use in every microservices, Think about Utility jars like Jackson,Gson thy take request do some operation returns some data structure, But if your utility takes and request fetch some data from database, do some operation and return it or save that state in database, then it would be ideal to publish it as Microservice.

Here also think about the failure, if you make a synchronous operation then your utility module fail means all chain of Microservices is failed, so think can you make utility operation as async, is the utility module require in sync fashion? As an example Event store or store Audit information, Those are cross-cutting concerns and a utility operation so it is not a part of main business flow so we can make that async so that if audit information or even storing operation fails it does not block the business flow and your service should not down for it.

If you have to use utility operation in sync fashion, then implement a circuit breaker and return a default path, so that if the operation fails it does not block all Microservices, at least if show a default path and show the user a message. or users can perform other operations rather that this function (Say your transaction function calling a utility function to check Transaction amount and based on that bank giving you some credit points, now if that function fails we can show a default message "at this time we can't process transaction" but user can do other options like balance check. So any moment of time the service will not totally down.

Conclusion:: There are also different shades of Utility some are mostly read-only but has database operation, some may use in-memory caching so take decision wisely How you want to write your utility one,  jars or Microservice.

Read more

Microservice Vs Monolith:Which one to Choose?

"Microservice" is a Buzzword in the industry right? Apart from Microservice design rest of the design marked as "Monolith". But as an architect when you trying to create a new Software based on a specific Domain, What will you do , adopt Microservice without judging anything as this is the hit one,  every one runs behind it or just stop for a second and think about your company infrastructure, employee expertise and based on that choose Microservice.

As an Architect it is our duty to choose Microservice when it is required, Not going with the flow and use Microservice. This tutorial I will talk about few aspects, which I think most important before you adopt Microservice, and I am open to hearing any other proposal or aspects to cover which I missed, Even counter logic, This is my realization while working In Microservice and so-called Monolith, both the architectures.

Let's begin with the aspects to consider before choosing Microservice as default architecture.

1. Project associates Strength: While you are getting a project first parameter to consider is to How many associates are going to work in this project and what are their experiences. If your strength is low, like 10-12 don't go for Microservices , as Microiservices means independent services , and the motto is "You Build it you run it" so There should be one team have complete ownership on a Microservice, If you associate strength is small statistically each one or two persons will have ownership of two or three Microservices, and it creates a critical problem, Knowledge is confined to them and they will become a Pivot employee, On Another side If one/two persons take ownership of two or three microservices, the motto, Developers should only focus about a small portion but know everything about that service is going to break. So think about that.

2. Microservice and It's associate Knowledge: Microservice is a new architecture and there are various concepts inter-related with Microservice like Distributed Artechtures rules, like High availability, Resiliency, Service discovery, CAP theorem, , Domain-driven Design, Circuit Breaker pattern, Distributed cache mechanism, Route Tracing etc. Not only that DevOps culture is tightly coupled with Microservice in order to unleash the full power of Microservice, So you need to know CI/CD tools and it's culture(Automated deployment).The team should be efficient to drive all of these for a Microservice, If the Microservices deployed in cloud or container, Team should have an understanding of Cloud architecture(PCF, Amazon, Bluemix etc) or Container architecture.(Docker, Docker Swarm, Messos, Kubernetes etc). Think carefully about the Team knowledge, always think when you are dealing with Microservices it means multiple services and multiple teams, so each team member should have clear understanding all of the associated knowledge to run it's Microservices independently, If you don't have such leisure make sure for each team one or two persons, who know all the associated knowledge so they can educate their team. 

Organization Infrastructure: Another important dimension is Organization infrastructure, Before adapting Microservice always check in what mode you organizations work, As per Conway's law whatever your organization structure that is reflected in your code implementation, So check,  is your organization adopt the Agile technology? Is the team  built with cross-technology member (Like UI, Middle layer, Database), What are the deployment and QA test mode, is your organization follows manual deployment and manual testing, or they are already or going to adopt DevOps culture, Where the artifacts going to deploy, is Organization has few servers where you install Application servers and deploy your artifacts or Organization move to Cloud. Based on these parameter choose are you going to adopt Microservices or not , If Organization has its own servers(few) where application servers are installed, in that case, all the different Microservice artifacts going to deploy same server space, which does not fulfill the Horizontal scaling so Microservices adoption will be in danger, also in case of Manual testing and Manual deployment if you adopt Microservice it is a nightmare for Ops team and QA team, also for developer it is nightmare to integrate the changes and test in SIT. 

Domain Criticality: Check the nature of the domain you are working on, sit with Business analysist understand how critical is this, is there such a need where we need to break domain into subdomains, so that related function can be encapsulated under a context, based on that take decision if Domain is not very complex , It is better to stick with Monolith, no need to create Context map and encapsulate subdomains in a Bounded Context.

The budget of the Project: This is another important aspect to look on. Think about the budget of the project, the nature of the project is it fixed bid or TNM type. Microservice projects are expensive than monoliths as it needs more server or cloud infrastructure, Automated pipeline, Count of Resources, all team should be cross skills team, So in terms of  infrastructure and resources level it is much more costly than Monolith, so think about what the budget aligned with your project(Secretly I am giving one tip to you, Please do not publish to anyone, As a good Loyal Architect Always Think about Revenue margin, a modular monolith is better than Microservice in case of small budget it serves the purpose of  Revenue and In future if you want to move Microservice also that is possible.)

Conclusion : Nowadays, Microservices technology hit in such a way, Novice or mid-level developers think Monolith means bad it is a BBOM(Big ball of mud) all modules are strangled with each other, but If you maintain modular approach, It is good and many cases it is better than microservices when our resources are finite. So choose carefully not go with the flow. I always recommend to go with Monolith first but makes it Modular, If you use Java9 use Module else you can adopt SOA but start with modular one and when there's an actual need, like Module boundaries are going to leak, or you can't maintain Acyclic Graph (DAG) among modules, Then think for beaking Monolith basis on DDD and can lean towards Microservices. Not before that, what I am trying to say is Do not use Microservices as Others are adopting it, Adopt it when you need it. Many cases I saw some project try to adopt Microservice but just because of lack of knowledge they create such a project  which is neither a Microservice and nor a Monolith, They create many services, without a proper encapsulation and each service chained with other in such a way one Agile team can't take an independent decision on deploying one Microservice, multiple teams ,  multiple artifacts depends on each other , Teams are blaming each other as functionality span over many services , It is a horrible situation, I will discuss that  in my future articles, But for now think twice before adopt Microservice as Uncle Ben said  "Great power comes with Great Responsibility".

Read more