How DXC Helped a Customer Transform its Monolithic Application into Microservices on AWS

By Charles Christopher, Cloud Solution Architect – DXC Technology
By Dhiraj Thakur, Solutions Architect – AWS

DXC Technology

Outdated technology poses particular challenges to many businesses. Legacy systems or outdated applications can accumulate bugs and other issues over time, which cannot be fixed due to a lack of support and services, resulting in frustration of employees and customers alike.

In addition, aging or obsolete systems simply cannot align with current business goals, causing organizations to struggle to compete with “younger” enterprises and sustain themselves in today’s competitive market. Moreover, it isn’t easy to find viable solutions that can integrate with or are cost-effective for legacy applications because of their age. Modernizing legacy systems is the right solution for engaging with and attracting new customers.

This post will help you to understand how to migrate monolithic Java applications from on-premises to (Amazon Web Services) AWS. We’ll also help clarify the AWS-native services that can be used in terms of cloud-native application development.

DXC Technology is an AWS Premier Tier Services Partner and Managed Service Provider (MSP) with over 3,000 AWS Certifications that drives its ability to help customers who use Amazon Web Services (AWS) to harness the power of innovation and drive their business transformation.

Current Challenges

A few challenges organizations face with legacy systems include:

Security risks.
Inability to integrate with new technology.
Instability and inefficiency.
Lack of information.
Elevated management costs.
Incompatibility to customer needs.
Lack of user-friendliness.

One of DXC’s customers had a challenge using its legacy application due to the following reasons:

Monolithic application built in 2010 and legacy application is not sustainable in future.
Current application was not designed for cloud.
Legacy framework used in application is unable to migrate to latest Rest/SOAP versions.
Scaling is big drawback, as the application was originally designed for customer support (customer facing, partners) and then extended to 40+ client base.
80+ servers currently which are scaled horizontally, and there is no elastic scaling.
Initially, there was less volume. Now, it has gone to 2.5 million requests per day and will go up to 10 million in the future.
Oracle database is being used and the license is expensive.
Thread-based parallel processing is an old method of solving problems.
Integrating with non-client systems is challenge and costly; it’s also a pain point for integrating with backend systems.
Few backend systems are running on the AWS cloud.
90% of requests are synchronous and remaining are asynchronous (batch).

Functional View

The application modernization implemented for a customer is primarily an Obligation service system which supports the services provided to the customer. These support services are attached to products or contracts (care packs or annuity contracts) at the time the customer orders the product/service.

The Obligation gets stored in the customer’s multiple backend system—SAP Operations Program, SAP Orders & Contracts, Carepack Asset Management System—and activated at the time of delivery to the customer. It may be updated (upgraded, renewed, or expired) throughout the lifecycle of the product/service.

The customer requests their Obligation any time they access a product through a customer support channel with reference to their product/service. The support services are delivered to the customer based on the Obligation response provided, and the cost of delivering the service is accounted to the corresponding organization that owns the service.

As part of this application modernization, the monolithic application is migrated into microservices architecture with AWS as the hosting platform.

The application is used to fetch information about sold-out products. Information includes contract data for the product, guarantee information, and any extended guarantee or additional information.

The application is used by the different groups to fetch information and is expected to return the information with minimal response time. It needs to interact with multiple backend systems which are hosted on different platforms like SAP that are running both on-premises and on AWS.

Solution Architecture

The application is redesigned with microservices architecture, and there are five entry-level microservices invoked from the API gateway.

Figure 1 – Solution architecture.

The entry-level services invoke one orchestration service, and this service internally invokes individual orchestration services.

There are individual orchestration services developed that will invoke internal microservices and apply orchestration logic to prepare the final response. The low-level microservices are intended to invoke different backend systems and apply any merging logic, if required, and pass back the response to orchestration-level services.

DXC did the product comparison between Amazon ECS on AWS Fargate, Amazon EKS on AWS Fargate, and Amazon EKS on Amazon EC2. Based on the comparison, DXC’s recommendation was to go with Amazon ECS on AWS Fargate as this is based on serverless technology and supports features such as autoscaling. Deployment and configuration would be simpler as well, and this provides seamless integration with rest of the AWS services.

DXC recommended AWS Fargate for the following reasons:

Serverless technology.
Supports automatic provisioning of workloads.
Offers flexibility for scenarios with variable utilization.
Lower maintenance overheads (as it’s an AWS managed service).

Amazon ElastiCache is used to store data with indicators to determine the necessity of a backend system call and stores the response back into cache. This is implemented to avoid multiple calls to backend systems when there are repeatable requests.

The legacy application was caching the frequent access data on JVM in memory cache. Existing implementation did not support distribution caching as it was a monolithic application. Introducing Amazon ElastiCache would provide common parameters across all the microservices.

DXC’s recommendation—based on inputs—was to keep multiple options for the cache strategy for the target state. The specifics would be defined in a fine-grained way during the implementation phase, and it would be distributed cache, as appropriate for the specific use case.

The application also uses event-driven architecture to gather data from external systems and store it in caches. Solace is used as a messaging system, and one microservice is developed to listen to the messaging system. When the message arrives, the service consumes the message, applies logic, and stores the response into cache and a database as appropriate. This helps events to trigger and communicate between decoupled services and is common in modern applications built with microservices.

Amazon OpenSearch Service is used for application monitoring which enables customers to easily ingest, secure, search, aggregate, view, and analyze data for a number of use cases such as log analytics, application search, and enterprise search.

The existing monolithic database was migrated to Amazon Elastic Compute Cloud (Amazon EC2) as-is using a decomposition approach, as it had many stored procedures. The existing license was applied for Oracle Database deployed on EC2.

On-Cloud, On-Premises Connectivity

DXC recommended and implemented the connectivity from the microservices deployed on Amazon EKS on AWS Fargate to the SAP system deployed on-premises using AWS Site-To-Site VPN and AWS Direct Connect in a secured manner.

AWS Direct Connect links an internal network to a Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to the router, and the other to a Direct Connect router. With this connection, it’s possible to create virtual interfaces directly to public AWS services (for example, to Amazon S3 or to Amazon VPC), therby bypassing internet service providers in a particular network path.

An AWS Direct Connect location provides access to AWS in the region with which it’s associated. Use a single connection or multiple connections for redundant purpose.

Following are key concepts for AWS Direct Connect:

Private connection.
Separate from the internet.
Consistent network experience.
Multiple AWS accounts can share a connection.
Uses Border Gateway Protocol (BGP) to exchange routing information over Virtual Local Area Network (VLAN).
Port speed from 1-Gbs, 10-Gbs, sub1-Gbs, and more.
AWS-provided or other vendor associated with AWS.
VPN over AWS Direct Connect.

Customer Benefits

Below are some of the benefits of this event-driven architecture:

Application is expected to respond in less than one second, and microservice architecture helps in achieving the target.
It’s divided into individual microservices so the complexity of the application can be divided; it will be easy to understand and maintain at the individual microservice level.
As the circuit breaker is implemented at the individual service level, it helps to avoid sending and incomplete response to the user. When any individual service is down, it returns a predefined static message instead of sending a complete exception message to the user.
As distribution caching is implemented, it helps to increase performance, scalability, and availability for microservices. The main purpose of using caching is to reduce latency, make applications faster, and reduce the number of hits to the database.
Use of the DevSecOps pipeline in the microservices brings benefits such as deployability and increased agility which leads to short build, test, and deploy cycles.
Amazon OpenSearch Service implementation is highly scalable and provides fast access and response to large volumes of data with an integrated visualization tool, OpenSearch Dashboards. This makes it easy to explore data for use cases such as real-time application monitoring and log analytics.

Conclusion

This reference architecture helps customers with:

Modernization of monolithic applications to microservice architecture.
Microservice deployment on AWS.
AWS cloud-native development.
Hybrid connectivity between on-cloud and on-premises.
Database migration to Amazon RDS in the decomposition manner.
Automated deployment using CI/CD pipelines.

.

.

DXC Technology – AWS Partner Spotlight

DXC Technology is an AWS Premier Tier Services Partner that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.

Contact DXC Technology | Partner Overview | AWS Marketplace | Case Studies