Skip to the content.

Background

If you are an engineer or an architect working in the field of enterprise IT, you may be hearing terms like “digital transformation”, “cloud-native”, “microservices”, “architecture modernization” several times a day. But your reality may be to make sure that

If you think just about the tasks and responsibilities you already have similar to above, you may think that this is enough trouble for you to spend your entire working career. This is true for anyone in the team from the engineer to CIO if they think only about these points. But there are people who think outside the box and look for proactive approaches to solve complex problems rather than act in a reactive manner. Instead of stuck with the existing set of challenges and finding solutions to those, they go one step further and look for ways to change the way things are handled and looking into the big picture.

Existing legacy platform (Step 0)

Let’s come back to the ground and try to understand the current legacy enterprise platform you are having in your enterprise along with the challenges it has.

Legacy platform

Figure: Legacy enterprise platform — challenges and expectations

As depicted in the above figure, the existing platform consists of a set of heterogeneous systems that interacts with each other through an ESB and exposed through a proxy or load balancer. In your enterprise, there can be 10s or 100s of different systems deployed. But the architecture would be similar to this. For this article, we’ll keep the proxy/load balancer component aside. This architecture works for the last 20 years and it still works with a few challenges. Users are mainly interacting with the system through SOAP/XML over HTTP/S and they handle the complexity of XML processing at the client-side applications.

Let’s try to figure out the challenges you have with this platform.

As I mentioned at the beginning of this post, addressing these challenges is necessary. But that does not solve the bigger problem of not designing the platform for future needs. That’s the responsibility of a good architect to think about the big picture and design the system which solves the existing problems, as well as any problem or challenge, occur in the future. Let’s try to understand the expectations of the modernized platform at the beginning of this migration effort.

Start the modernization (Step 1)

Once the existing challenges and the broader picture is identified and convinced to at least some of the stakeholders (sometimes you can’t convince everyone to get things started), you should start somewhere. One important aspect of doing any migration or modernization is to do that with minimum impact on existing users. This is the reason why we should bring in a layer at the highest point of interaction to the customer just below the load balancer or proxy.

Legacy modernization with APIs

Figure: Legacy modernization step 1

As depicted in the above figure, there are 2 main changes done to the platform architecture here.

Bringing in API management platform allows us to provide the same set of existing functionalities to the customers from multiple backend systems. Some functionalities of the legacy systems and in-house tools are migrated as microservices and deployed separately. This deployment can be on a physical/VM infrastructure or a container platform. Along with that, users can bring in new cloud services (SaaS) if required. But still, the integration is handled through the ESB layer.

In addition to migrating a set of capabilities to new microservices platform, now certain services can be exposed through modern interfaces like REST/JSON, GraphQL, or even Websocket. It allows the business functionalities to be exposed to a wider audience. It also allows the application developers to interact with the service developers through an interface like a developer portal. With this initial step, the platform has the following capabilities which were not there before.

But still, there are a lot of issues, and challenges still exist in the overall platform and you need to address those as well.

Establish the new platform (Step 2)

Even though the API management platform is capable of supporting certain aspects like automation, cloud-native, agile development, and improve monitoring aspects, the rest of the platform is still not ready to build that integrated experience. Because of that, we have to identify the next phase of the modernization effort carefully and execute without frustrating the stakeholders.

Legacy modernization establishing

Figure: Legacy platform modernization — establishing

The next phase is to move a considerable amount of legacy and in-house capabilities into the new microservices style deployment as well as migrating away from the existing legacy ESB which plays a major role in the overall platform. This might be one of the most challenging phases of the modernization effort since your existing developers find it difficult at the beginning to migrate these integration services to a new platform since the syntax of this new platform is vastly different. But in reality, most of these integrations are done according to a selected set of patterns (EIP patterns), and once you identify the pattern, you could find enough samples from the new vendor related to those patterns and migrating the logic won’t be that difficult. Depending on the number of integrations developed in the existing ESB, the time it takes to do the migration may vary.

One of the key improvements your developers can do during the migration is to think differently and write these new services in a much efficient manner since things have changed a lot since the original services are written. That will help you to reduce the number of integrations rather than blindly converting the services from one platform to the other. During this migration also, the API management layer plays the role of the anti-corruption layer where it serves the customers from backend services running in both ESBs for a certain period of time.

Once the Integration and the API management components are in place, the platform is capable of handling another set of challenges and supports the new capabilities mentioned below.

At this stage, the modernization effort is well established and most of the challenges faced in the legacy platform are gone and the new capabilities are providing the business level benefits across the board. There are a couple of things yet to be addressed.

Improve user experience (Step 3)

With the enterprise platform in better shape in terms of scalability, management, automation, and innovation, the next step would be to improve the overall user experience of the platform while applying the better security models for users and applications. Though it feels like we are considering security as a secondary matter since it appeared in step 4, it is not the right way to look at this approach. From the beginning, the security was handled by applications and they managed their own user stores and their own security protocols. Through the API management platform, certain aspects of security were modernized with the use of OAuth 2.0 tokens. But consolidating the various user bases which spanned across multiple applications needs to be done once the systems are properly implemented.

Legacy modernization user experience improvement

Figure: Legacy modernization — improve user experience

As depicted in the above figure, the Identity and Access Management layer is introduced to improve the user experience and consolidate the various user stores and manage them centrally. This allows both existing applications and modern microservices to provide a much better, unified user experience regardless of which application the user is accessing. With this component, users can be provided with more secure, yet easy to use applications with features like Single-Sign-On (SSO) to multiple applications, Strong Authentication (2FA, MFA), Social log-in (Facebook, Google) and many other. This will solve the distributed user identities problem and make life easier for users as well as system administrators to manage the users through a single component.

All is well up to this point and the system is providing more and more functionalities to the users and the overall maintenance, management, innovation aspects are vastly improved. Still, there is room for improvement.

Make it future proof (Step 4)

If you look at the figure in the previous section, there are 2 white boxes still we need to make green. Those are the resource under-utilization and cloud-native aspects. Based on research done in recent times, it is evident that more and more enterprises are moving their workloads to the cloud already or planning to migrate their workloads to the cloud in the future. As an enterprise architect who is planning a modernization effort, not thinking about cloud migration is a big mistake. Because of that, we should make the modernized platform cloud-friendly so that when the overall organization decides to go down the cloud direction, the platform is ready to move on to the cloud.

Legacy modernization future

Figure: Legacy modernization — future proof deployment

You will recognize several changes in the above diagram from the previous diagram. Since this section of the article discusses making the entire platform cloud-native and running on a container platform(docker), I have chosen an open-source technology platform that supports the functional capabilities of API management, Integration and Identity, and Access Management. In addition to that WSO2 platform comes with a set of runtimes that are cloud-native and supports container-based deployments from the core of the runtimes.

All the above-mentioned components along with the newly implemented microservices layer which replaced the legacy and on-premise tools can be deployed in a container platform like docker so that it can scale and manage independently. To make this platform fully automated and well managed, we need to use a set of supportive tools that are also available as open-source products.

One of the important aspects of driving this sort of a modernization effort is to handle the people aspect. That means you have to drive the people transformation as well as the platform modernization at the same time. Otherwise, it will not reap the full benefits of this effort. The other aspect is that you have to plan it properly and execute accordingly.

The reason why I choose open source technology for this modernization effort was that it allows you to do your early research, development without any cost involved or with the minimal cost. It also gives the flexibility to fix your mistakes (free from vendor-locking) if a certain component does not work as expected without burning additional dollars. Once the platform is designed and implemented as per the 5 step process described in this article, you will have a platform that addresses the existing challenges, that open up new business opportunities and that is ready to take on any future changes in the industry as per the current knowledge on the future.

Future

Once the platform is designed in the manner which was explained throughout this article, moving this platform into cloud infrastructure is not that hard. Many cloud providers support managed kubernetes environments that are capable of deploying container workloads with additional capabilities like auto-scaling, auto-healing, rolling updates, monitoring, and flexible pricing models. If your organization is looking to reduce your operational and maintenance overhead of the platform, this modernized state allows your organization to go through that transition smoothly and reduce the total cost of ownership (TCO) and improve the return on investment (ROI).