How to avoid a messy transition to microservices

How to avoid a messy transition to microservices

By Paul Winters

The goals of using microservices to improve time to market, scalability and maintainability are noble. The results from Netflix, REA and other enterprises show that it can work. The transition phase from a monolithic environment to a microservices environment can get messy, whether the blame is the culture, technology or risk.

The cultural chaos comes from teams still clinging to their existing knowledge areas, methodologies and hierarchies. The includes moving from a project model to a product model and transforming the way that the business views customer interaction. This resistance could be due to motivation: of course there won’t be a shift if teams don't accept and understand the need for a paradigm shift.

Then there’s power and fear. The breaking and flattening of power structures need to happen and will shake things up. Being diplomatic while showing strong leadership will help as people are scared they won't have a role in the new model. Retraining staff and ensuring they have the skills to function in new roles is vital.

Technology changes are also required. It may not necessarily be wholesale replacements of languages, products or frameworks. For example, if you have significant Java EE skills, changing to NodeJS may not make sense. But the way you develop, test, integrate, deploy and monitor the technologies will change. It is essential to determine you have the correct tools, people, principles and procedures. Improving through continuous learning is also important. Other technology issues can include architectures that just add another layer and associated complexity rather than moving functionality.

IT risk and security and their biggest tool, change management, have been developed over years of monolithic application development. Changing to microservices does not inherently introduce more risk, but correct management is key. Reworking deployment procedures, risk assessments, coding exemplars, security controls, code reviews and penetration tests reduce the risk and enables developers to focus on their code. Having a security and risk person within the development team helps with questions and techniques.

Microservices are delivering value for enterprises. Deploying extra tools without wider change doesn't solve these underlying issues. Viewing the transition from a change management perspective is much better. Considering the broad aspects of change management is essential to avoiding making a mess. Transitioning to the new paradigm requires more than just using a new framework or tool.

Subscribe to the Syntegrity Solutions newsletter here.

Paul Winters is a Director at Syntegrity Solutions, a specialist IT consultancy that focuses on digital innovation enablement. He has over 10 years experience in the IT industry and has consulted on APIs, integration and security to enterprises including top-tier banks and insurers.

Have a question?