Why a developer should build a solution with microservices

Hi all!
Good day!

Today, I am continuing with our blog post series on microservices from the perspective of a developer. This is our second blog post of the series. I suggest you to read first blog post of the series Introduction to microservices.

This series is completely based in views of a developer and I will cover theory and practical from start to end. In this blog post I will discuss as developer why we should choose/adapt microservices.

Andreas Helland is running a separate series -Building Microservices with AKS and VSTS that you would like to read as well.

Before as an organization you can decide that you want to go ahead with microservices, you must know all its benefits and the flip side of the coin too. Let's see what are the benefits of microservices first. As we discussed some attributes of the microservices in the last article the most important ones are

1. Isolated/Single Functionality.
2. Isolated Data & State.

As you move ahead you will see how this is done. Meanwhile let's see what are the advantages you derive out of these. You will analyze the advantages from the perspective of the team involved in the actual development of the code and also for the sales team/strategy team as well.

Dev Team Advantages

Once Isolated/Single Functionality has been achieved - it means that now your code is available to you in a much more smaller unit to handle without any inter-dependency on other modules. This allows multiple teams to work on the existing code-base without having to rely upon each other for :

1. Knowledge Transfer
2. Code/Components
3. Deployment
4. Technology Choice
5. Scaling

This happens because with the code being independent of other modules/parts of the application - we don't have to worry about breaking/testing other parts of the code with whatever changes/additions we make to our code base. This is achieved not just with the code separation or isolation, but also combining it with Data Isolation for your part of the code [Microservice]. If the data that we are dealing with in our code is directly accessible to other applications or modules then you can never rely upon its state or availability.

We can work out the final setup of the Microservices based architecture such that we can make changes to our code, test and deploy it with worrying about breaking our existing services in action. This is achieved by releasing another version of your Microservice. So you can have different versions of your Microservice co-exist without any problem. The reason of having different versions could be other this also. There might be a need that the same functionality is delivered to other consumer with slight modifications based upon the business needs.

Business Advantages

When we design our product - aspects like stability, efficiency and features are the points that we design our product well around. Based upon the prevalent business needs at the time of designing of the software at points are considered. However there is always a chance that while we were still finishing our product another company might jump into the picture and provide more features in the same price. This would mean that effectively our product's business advantage might get reduced/completely lost altogether. After all this is business and no body is required to be nice to you with cut throat competition in the market.

So what is the strategy to not only minimize the losses but gain back the foothold. This is where business advantage of Microservices comes into picture. With this architecture it is easier for us to add new features without breaking existing functionality and with much lower cost. Here more from the cost the advantage of having the capability to swiftly respond to the business needs and minimum go to market time - business stands to gain.

In such scenarios for business it could be question of Do or Die situation. And the DEV team is the only savior they have at such times. This is one of the reasons that we mentioned in the last post that Microservices is a company wide culture that is adopted and not just another practice.

I am not sure how it was for you, but for me in the initial 15 years of IT industries, Sales and Dev Teams were usually never on the same page and always at logger heads. For sales team - the client opportunity was not be lost at any cost, where as for the Dev team committing to deadlines for code that can't be delivered was more important. This can be changed easily now.

Other Advantages

In my opinion simply speaking the advantages discussed above summarize it. However as the life cycle of a product progresses there are two areas where Microservices provide even more benefit. Let's take a look at them.

Scalability

Once an Enterprise level product has been deployed and made available to the online community then subject to few limiting factors, there is a good probability that user base might increase. If the increase is even modest and not substantial, then over the years it might be required to handle not just an increased concurrent user base but also increased data volumes.

Microservices allow you to easily identify and monitor areas that are under stress due to data handling or increased user base. And then with equal ease we could scale up just those Microservices where the stress is identified with out scaling up rest of the parts of the system/application. In Monolithic architecture this is not a luxury that we had. We would in those scenarios end up scaling the entire application - all modules.

This would mean - that you are effectively investing time and money in scaling up the modules/parts - that don't need it or won't benefit from it. Not only is this cost disadvantage but also time disadvantage.

The cost-benefit ratio would be very impressive in the case of a Microservice being scaled up vis-a-vis Monolithic application.

Technology Adoption

Even if you continue to work in the same language for your entire life-time, you always would have new compiler/language specifications/features being released. There would times that backward compatibility is broken. Or there would be times when there is absolutely new technology disrupting the market - that can make life easier for devs, faster goto market for business and better performance for the work at hand.

So in such scenarios you might consider evaluating the technology even if not adopting it eventually. However with Monolithic architecture even evaluation could be prohibitory. There is a probability that you want to take gradual steps in adopting the technology while the community around it is still building up. And as the technology is confirmed stable by the industry as a whole - you would take the plunge.

With Microservices we could very easily pick single out the part of the whole eco-system to be tested with the new technology and implement it without affecting rest of the system. The best part is that while we are still having the new version of the service in beta stage - the system could be made to support both versions of the service - effectively protecting the system from breaking down, in case our technology adoption experiment was to go wrong due to any scenario.

It cannot get easier than this when it comes to adopt a new technology and even go-to production testing with it. Because rest assured you know that the eco-system would not be affected even in the worst case scenario. And we could very well perform this with more than service at the same time.

Summary

In this blog post I tried to layout various advantages that microservices provide for the Developers and the Business sponsors alike. Also tried to showcase how technology adoption could be easily done with it.

In the coming posts I will start crafting how to actually pick up an existing monolithic application and convert it into microservice based architecture.

Comments

• Anonymous
  April 03, 2018
  Thanks Gaurav! Looking forward to the rest of the series.
  • Anonymous
    April 05, 2018
    Thanks, I will submit the next blog post sooner to maintain the rhythm.