Knoldus got an opportunity to work for a prominent enterprise client. They had a decade old legacy system (a set of monolithic applications) to address all of the IT requirements. Today, where the software and IT requirements are very dynamic in nature and to drive the best consumer experience; the client needs to do the rapid changes -- which wasn't possible with the existing system. One of the prime objectives was to be agile and move fast in the digital space where they can continuously roll out new applications and services to their customer and maintain the competitive edge. Knoldus proposed to adopt microservice based architecture to serve their need for rapid rollout of the new services as well as to remove the brittleness (harder and a long drawn cycle of introducing any new changes) of the existing system.

Microservice is all about doing one job and doing it well, they solve the challenges of monolithic systems by being as modular as possible. In the simplest form, they help build an application as a suite of small services, each running in its own process and are independently deployable.

The primary challenge was to migrate the current application to the new application while keeping everything alive and running as it is. So we decided to adopt an incremental approach for the migration and will implement one service at a time and replace the current functionality in the legacy system with that microservice.

However, there were some parts of the legacy application that can still be used as they were serving the business well. It's not necessary to migrate the complete system instead of finding a way to reuse the functionality of particular components in our newer architecture. One of such functionality was role-based authentication component, it was a complex functionality as multiple legacy components were involved to authenticate the user and its role. Migrating this service was a daunting task and since it was not adding any business value we decided to continue with legacy authentication.

In order to authenticate the user, all the microservices were calling the authentication feature of the legacy system. Later, we realized that it's not idle to call legacy service through a large number of microservices. It may activate security threat as well as we will have to duplicate the functionality in every service.

As Apigee edge was the part of new microservice based architecture, we decided to leverage the Apigee layer to invoke legacy authentication feature on the behalf of microservices. Using Apigee helped us to keep our microservices agnostic to the legacy application, as Apigee was the only layer which communicated with the legacy application for authenticating the user.

In the above figure, instead of invoking the Product, Order and Inventory microservices directly, the user makes an API call to Apigee. Apigee authenticates the API call using legacy authentication service and if the request gets authenticated then API delegate the API call to underlying microservices otherwise it sends an error response to the caller.

Results:

• By leveraging the Apigee Edge platform, our client was able to migrate legacy service into microservices incrementally while keeping the system live.

• User interaction to the system was limited to Apigee layer only, thus, keeping user agnostic to all the underlying mambo jumbo happening in the migration process.

• The new system is more secure since Apigee provides out of the box security policies for OAuth and LDAP.