Legacy System to Microservices

Introduction

Several companies these days are trying to move from closed monolithic system to distributed services oriented architecture. Although SOA/SCA concepts have been in market for long time but arrival of Micro-services architecture has forced several companies to rethink their architecture to avail the benefits of Micro-services. Software industry is fast changing industry. Every year new frameworks are surfaced in market. Some fit really well in the problem domain other are adapted and thrown away after sometime. Companies are in constant battle to update its products to latest technology so that they can stay in race of offering tempting feature to it customer. Most legacy systems are not designed to work with new technologies, so it always challenges to convert these systems to Micro-services architecture.

Problem with existing system

Software can be broadly categorized in term of complexity as small, medium, large. Small software will always be ahead due to their simplicity. Medium software can stay in in the race by constantly updating itself or refactoring itself. It is the problem with large systems that makes it difficult if not impossible to extend or refactor. Large system also generates large revenue and reputation to the companies that restrict the chances of major architectural changes to software. Large systems can quickly become legacy systems if left unattended. Large Software matures over a long period of time. Generally, software quality is at its peak during the development or at the end of development. Problem starts to arise when new features are added to mature software which was not thought of during its original design. Developers start to ignore best practices and start applying patches due to timeline or lack of software knowledge. That results in a software which has highly coupled code and difficult to maintain or understand. Once software reaches this stage it becomes impossible to follow best practices without first doing a major refactoring of code.  Most companies don’t follow that path because of the high cost and risk involved in refactoring the running software.

Good software has two features, quality of code and good architecture. Micro-services, Rest services, SOA and SCA try to solve good architecture problem by providing decoupling in the form of services using underlying components.  When software are first design it has very good architecture and decoupling between it artifacts. It loses its beauty when cross cutting concern like security, transaction management, performance invades. Defect fixing and change requests implemented without proper design changes (“Because it is too late and too risky to change architecture for small change” attitude) act like last nail in the coffin. Once software loses its decoupling characteristic the only way forward is more spaghetti code.

Micro-services : the silver bullet

The evolution of Micro-services recently has enabled programmer to solve many of the problem faced while maintaining large software. Micro-services itself does not offer anything new in term of technology but it restructure the  software in a way that business capabilities are organized  in component that can be physically separated. This physical separation allows programmer to keep low coupling and help them to expedite infrastructure automation and decentralize governance. Following approach can be adapted if companies want to move to Micro-services architecture.

1. Refactor, decouple and create services business functionality that can be deployed separately.

In this approach you refactor your code bit by bit to create more cohesive component and try to arrange business functionality in decoupled components that can be exposed as services. As you arrange your code in component, you need to be careful to move common functionality in the components and refer those common components by specifying the version. In this approach you commit the code as frequently as possible to avoid any merge conflicts with other people who are adding values to code. Also by doing so you are also mitigating the risk by making small changes.

Once you code is arrange in services/components you are ready to go for micro-service architecture by deploying these services on different servers.

2. Write parallel software from the scratch.

It is a simple rewrite of project as per Micro-services architecture. If you have budget and business can take risk by launching new software, it is an ideal approach. But in real world software takes time to mature and some defect can only be detected in production and there is not always a quick fix for those problems. Also due to sheer size of software it is not always practical to rewrite it. Sometimes it is too risky to switch an old working system with a new system. This approach deliver will better software but the risk and cost  to business is very high.

Exceptions

If you have performance intensive application then Microservices might not be an ideal solution as it would introduce latency due to inter-services communication. It is better to go for monolithic application that follows good OO design principle. Microservices does not fit well when there is intensive inter-process communication.

Summary

Although Micro-services architecture is tempting idea but it cannot be implemented overnight, there are practical difficulties that stop large system to move Micro-services architecture. It is a long journey to move from Legacy System to Micro-services architecture and it is yet to be seen what happens to micro services application when they are left without maintenance and are infected by cowboy coding.