Why Go With Microservices?
Why Go With Microservices?
Learn how microservices architecture provides benefits to both the development team and the business with its isolated functionality and state.
Join the DZone community and get the full member experience.Join For Free
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 the benefits of microservices first. As we discussed some attributes of microservices in the last article, the most important ones are
- Isolated/Single Functionality
- Isolated Data & State
As we move ahead, we will see how this is done. Meanwhile, let’s see the advantages we derive out of these. We 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, 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
- Knowledge Transfer
- Technology Choice
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 for having different versions could be other this also. There might be a need that the same functionality is delivered to another consumer with slight modifications based on the business needs.
When we design our product – aspects like stability, efficiency and features are the points that we design our product well around. Based on 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 nobody 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 the business advantage of microservices comes into the 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 a 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 loggerheads. For sales team – the client opportunity was not be lost at any cost, whereas for the Dev team, committing to deadlines for code that can’t be delivered was more important. This can be changed easily now.
In my opinion, simply speaking of the above advantages summarize it. However, as the lifecycle of a product progresses, there are two areas where microservices provides even more benefits. Let’s take a look at them.
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 without 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 a cost disadvantage, but also a time disadvantage.
The cost-benefit ratio would be very impressive in the case of a microservice being scaled up vis-a-vis monolithic application.
Even if you continue to work in the same language for your entire lifetime, 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 time-to-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 adopting 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.
We learned about various advantages that microservices provide for the developers and business sponsors alike. Also, we saw how technology adoption could be easily done with it. In the next post, we will see how to actually pick up an existing monolithic application and convert it into microservice-based architecture.
Opinions expressed by DZone contributors are their own.