Have you taken the Microservices journey falling on the promise of better stability, faster releases and better productivity and on the contrary found these factors falling on the downward trajectory? Are you wondering if you took a wrong decision of embracing Microservices? You are not alone. You are among many organizations jumping into Microservices without proper frameworks, processes and structures in place.
Microservices offers huge benefits, only if done right.
A poorly architected and executed microservices that does not follow such core principles and guidelines is times deferral than a monolithic application.
The following questions will help you analyze if you are doing Microservices the right way
Lack of standards:
Is every Microservices team re-doing the same mistake that the other teams did? Are they re-inventing the wheel so many times that it hurts productivity?
Lack of Automation:
Even now, Are there several manual steps necessary from provisioning infrastructure, deployment and operations? Does Testing in isolation using REST APIs really come in as a solution?
Example: Suppose there are three services X, Y and Z. When we test and debug Service X, how will it affect Y and Z? Will it affect the fluidity of the system? How do we know we have not broken something? How do we know the other people who are using these services are not impacted by such changes?
Have you broken down your Microservices with the right boundaries? Does it depend heavily on, and is chatty with other services? Can we opt for effective version upgrades while not compromising on the loosely coupled architecture? Will the loose coupling loosen the security?
Do you have to manually communicate version changes to a Microservice? Are you facing issues due to version upgrades of services?
Let’s try to understand what Dependency Hell is,
Let’s suppose there are three Microservices X, Y and Z. Microservice X has the API A and has upgraded to API B.
Case 1 :
When API A is upgraded to API B, Y still keeps sending messages to API A. This is called backward compatibility.
Now X reverts back to API A. Since API B is created, the other Microservice Z has already started to send messages to API B. Z still keep sending messages to API B even though X has reverted back to API A.
Thus, is the performance and stability of some Microservices affecting other Microservices too?
Are manual configurations becoming more and more complex and error prone and is more time consuming?
Are you unable to debug and find out the RCA of failure between dependencies? Does it take days instead of hours to find out the issue?
Are you encountering more issues on production even after spending a huge amount of time in manual testing?
If the answer to most of the above is yes then you need to re-evaluate your Microservices Architecture and process.
It is true that Microservices brings about a gamut of benefits to enterprises. Be it streamlining deployment at Best Buy or enabling a growth platform at Cloud Elements, Microservices ensures a ‘Winner Takes It All’ approach.
To traverse this winning route, businesses should transform business processes. You can begin by wrangling service to service intercommunication, advance testing implementations besides transcending organizational debates on the efficiency of Microservices Architecture. The former can be resolved by answering the above questions with generous time and efforts.
There are few accelerators available in the market to streamline the process of microservices architecture. These are different from the technology required for the microservices architecture development. The presence of the accelerators and the right culture adoption is mandatory to taste the success by making the life easier with the best of the breed.
Latest posts by Jothi Rengarajan (see all)
- Predicting ROIs to a Microservices Migration – Sowing Seeds to Success - May 22, 2019
- The 4 Pillars of Microservices: Process – The Fulcrum of Strength (Part 1) - May 22, 2019
- Saga – The key differentiator of Microservices - April 26, 2019