Microservices is the latest norm for enterprise development and many newly built applications are inherently adopting its core principles. Simultaneously, many existing enterprises are actively working towards migrating their existing monolithic applications to Microservices.
However, this is where the most interesting challenges lie. Monolithic applications are primarily mission-critical for the continued success of a business. Thus, the migration process must be as smooth as possible without any scope for obvious mistakes. Operational Pitfalls that can derail our migration process should be avoided consciously. This treatise covers the 7 Common Pitfalls that can hinder the migration process with recommendations to avoiding these pitfalls.
- Ambiguity in the targeted business goals and the set of operational constraints
- Non-compliance to Conway’s law of design
- An Inappropriate approach to migration
- Trying to reinvent the wheel for generic problems
- The improper harnessing of CI, CD, automation, and Monitoring
- Non-compliance with Agile principles
- Affinity towards Legacy Systems
To get technical support from our experts on Migration-related issues in Microservices, call us today.
WalkingTree Technologies provides the following services in Microservices.
Ambiguity in the targeted business objectives and the set of operational constraints
Scenario
Many times it may happen that teams might get tempted to start migrating the application without really pondering over the intended business objectives. Migration to microservices will not be considered useful unless it meets its business objectives. If the business objective is not very clear, there is a possibility that different stakeholders may have disagreements and will not concur in their decisions. This can bring migration to a standstill even after hours, weeks and months of valuable efforts have been invested. There are situations where business objectives are clear but there is no focus on the standard set of constraints for migration. If the constraints are not known upfront, the team will design something which will be an aberration to the context of a certain constraint. This will lead to rework and significant delays.
Recommended actions
It is important to document the following as the first step:
- Document the challenges that you face with the current application
- Document the technical/functional/operational inefficiencies and the corresponding workaround methods
- Document the scope of the application i.e. in terms of scalability, functionality, and agility
- Document the minimum set of functions that need to happen seamlessly during migration
These documents need to be presented to all the stakeholder/key participants. Put a process in place to ensure that all the architectural/design decisions will be validated against these objectives and that the idea that relates the most to the goals will be considered for actuation. This way better team cohesion and endeavour towards a common goal can be realized.
Non-compliance to Conway’s law of design
Scenario
There are certain situations when we start migrating the application from Monolithic to Microservices, but the team structure continues to be monolithic. The renowned Conway’s law of design states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” If the team structure is not realigned to meet the needs of Microservices, then there is a possibility of an inherent conflict between what the team wants to achieve and what it is trained to do.
Recommended actions
Do not hesitate to break the big team to smaller ones. You need to plan in such a way that as the application migrates from monolithic to microservices, the team structure will also migrate from a monolithic group to that of smaller teams. Whenever a certain module is getting migrated to Microservices, identify the relevant team and make them accountable for that module. This natural progression will make migration smooth.
An Inappropriate Approach to Migration
Scenario
While migrating the application, sometimes you end up taking the big bang approach, where you access multiple elements in a single iteration. In this case, you will face a high risk of failure. If you touch multiple modules of the monolithic application with its respective resources like a database/data storage/files system, you need to take care of not missing out on any module during the migration that could lead to challenges. The flip side is that, until you have completed the full circle migration process and used the system, you can’t confirm if the migration goal has been achieved or not.
Recommended actions
Following the multi-layered approach is recommended for this issue. Convert the overall migration goal to smaller and simpler goals in a sequence. As in the layered approach, you can convert goals into actionable items like modularization of the application, then making the services cohesive, and then systematizing the applications. By following this multi-layered approach, you can ensure that you achieve smaller objectives faster bu tracking each step diligently for the right direction. You can take a course correction based on most recent feedback as well.
Trying to Reinvent the Wheel for Generic Problems
Scenario
Migration to microservices involves the restructuring of the application with certain guidelines. During this process, you end up in a situation where you need to develop/create something new. Sometimes even when you identify the closest possible tool/framework or tool to work with, you still get tempted to develop your own tool by sighting some specific use case that is not covered by the tool. It may be the case that the specific use case appears to be the most needed feature at the time. We need to introspect if this is necessary. If we start reinventing the wheel for all the challenges, then you could be deterred from moving ahead.
Recommended actions
For any generic problem that you come across, choose an existing framework. Almost all the building blocks of Microservices have some good technology tools that you can leverage on. You could do this by using a public cloud infrastructure.
For example, If you want to analyze the logs of all microservices in one place, you do not need to create your own application, instead, you could use ELK to do so. You will need to manage the required configurations and provide the resources needed to run ELK and start analyzing the logs.
The Improper Harnessing of CI, CD, Automation, and Monitoring
Scenario
The speed and agility of Microservices cannot be achieved without the proper CI/CD in place. Microservices cannot compare in speed with a Monolithic application and, in fact, speed becomes a concern if CI/CD is not properly harnessed. Microservices will need shorter development & delivery cycles to obtain results quickly. Multiple teams can work on multiple microservices simultaneously and they need to coordinate with others for integrations. Without CI/CD this could be unmanageable. Monitoring plays a key role in Microservices’ architecture when you need to check issues at multiple places to find the root cause.
Recommended actions
You will need to ensure that a separate repository, CI Build, and the well-covered test suite is available for each service. Encourage the team to do as many trunk commits as possible since it identifies integration issues earlier. Ensure that the CD covers all the operational stages while following a layered approach. It is recommended that you build the foundation layer which ensures that all the services are inherently embedded in these important aspects. production with an artifact that is generated once. Bring in configuration to manage environment specific configurations. Ensure standardization of logs across along with correlation ids. This ensures aggregation of logging which will act as a single source of truth for all the problems, click here for more details on log management. Put a mechanism of Synthetic events which replicate real usage to perform semantic monitoring.
Non-compliance with Agile Principles
Scenario
Not following an agile approach can lead to worst results for Microservices. A waterfall model can push the team to BigBang deployments which automatically leads to larger release cycles, lowers turn around time. If you are following waterfall model, you will end up getting the results once you are done with the complete migration only and it may not guarantee that the migration is aligned with your business goal or not.
Recommended actions
Microservices architecture automatically fits into an Agile methodology. Devops, Agile Practices and Microservices will create a perfect combination which yields greater benefits. As I mentioned earlier in this discussion, microservices will have shorter development & delivery cycles with which we can get the early result and avoid last minute surprises in the goals achievement. Make sure that you stick to Agile and deliver it in shorter cycles.
Affinity Towards Legacy Systems
Scenario
Most of the monolithic applications deliver certain business value while they are on the path to Microservices Migration. As you reap certain benefits because of the current system, It is natural to have an inclination towards legacy systems. But this affinity has the potential to cause a serious challenge to migration.
Recommended actions
Choose any of the public clouds to host your microservices. Most cloud providers have the inherent tools for Containerization, Monitoring, Load Balancing, Service Discovery, and Auto Scaling. These are the building blocks for any Microservices ecosystem. Sometimes, you will face a situation where you have a good data centre with state-of-the-art hardware with the help of on-premise services.
In case you are building a solution that needs to work on multiple cloud platforms, then tools like Kubernetes, Eureka, Ribbon and ELK stack could be used. It is recommended that the code is scalable and evolves the Microservices way.
To get more insights into Migration in Microservices, call our technology experts today.
To read other informative blogs on Microservices, visit our blog page.
