AWS Cloud Operations Blog

Mphasis rearchitects a legacy application to a serverless cloud-native architecture on AWS

Mphasis thrives on business agility and resilience. Its internal operations, especially the core development processes and supporting functions such as sales, client servicing, finance, and administration, are fueled by multiple in-house business applications. For a company to showcase its digital prowess, empower its workforce to innovate, and stay at the cutting edge of technology, these line of business (LoB) applications must be as digitized and friction-free as possible.

Mphasis wanted to upgrade its development infrastructure to deal with the following challenges:

  • The legacy architecture had issues with scalability, availability, resiliency, and security. Mphasis wanted to facilitate the effortless monitoring of microservices, with dashboards, analytics, alerts, and logs.
  • The maintenance of on-premises IT infrastructure was expensive, driving the need for cost optimization.
  • Procurement of servers and other hardware components was time-consuming and impacted delivery timelines.
  • Development of new applications was resource- and time-intensive. Portability on different platforms like smartphones, tablets, and computers increased the process complexity.
  • Latency in regional data centers increased when teams from other locations accessed the applications, making “anywhere, anytime” collaboration difficult.

As part of their next-gen enterprise IT strategy, the CIO team at Mphasis wanted to create a reference architecture for cloud-native applications that can be run on the AWS Cloud.  Although they initially considered deploying and hosting applications on virtual machines on the AWS Cloud, Mphasis decided to build their microservices on AWS Lambda.

Solution

Mphasis created a reference architecture for a legacy application that was written many years ago using an older version of the Microsoft .NET Framework. The application was for a document management system used worldwide by Mphasis employees and external users. To rearchitect the legacy application, Mphasis built their microservices on AWS Lambda. The Lambda function code was written in C# running the .NET Core runtime. The strategy used in the migration was to do a complete rearchitecture of the application as a cloud-native application.

The key technical challenges during the migration included:

  • Integration with Active Directory and providing access to external users.
  • Integration with other organization-specific services.

Mphasis was able to overcome these challenges by using a standards-based, loosely coupled integration between the microservices and other services.

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. When you use AWS Lambda, you are responsible only for your code. AWS Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources.

In addition to Lambda, Mphasis used these other AWS services:

Architecture

 

The document management system includes KMS, Amazon Cognito identity pool, and a document bucket. Internal and external users are authenticated through a process that uses API Gateway and the identity pool. The Lambda function runs inside the VPC.

Figure 1: Deployment architecture of the rearchitected application

 

The key technical modules of the serverless solution included the following:

Authentication

Amazon Cognito was used to authenticate external and internal users. Amazon Cognito provided authentication, authorization, and user management for the web application. The authentication module used Amazon Cognito user pools and application users federated through a third-party SAML identity provider (IdP). Users were able to sign in through the authentication module, which redirected them to the Angular front-end application with a grant code flow by which Amazon Cognito authenticated the user.

Business functions

The key application components were run on AWS Lambda, so there was no need to provision or manage servers. The components were run on the .NET Core 3.x runtime. The web API with an HTTP endpoint for the Lambda functions was exposed using Amazon API Gateway authorization controls. AWS Lambda functions also consumed external APIs by exchanging valid tokens and authorization credentials.

The Lambda functions also processed messages in an Amazon SQS queue, where Lambda polled the queue and invoked the Lambda function synchronously with an event that contained queue messages. The serverless functions used Amazon SNS to send approvals and messages in emails.

The key benefits of a serverless solution are continuous scaling (automatically scaling the application) and consistent performance.

API Gateway

For the API gateway requirement, Mphasis chose Amazon API Gateway so its developers can create, publish, maintain, monitor, ad secure APIs at scale. These APIs act as the front door for applications to access data, business logic, or functionality from back-end services running in AWS Lambda. API Gateway provided the tools to create and document web APIs that route HTTP requests to Lambda functions.

The COGNITO_USER_POOLS authorizer offered secure access to the API. It authenticates any request by validating a token sent from the front end before triggering the Lambda function.

Security

The serverless functions on AWS Lambda were run securely in Amazon VPC. Credentials were stored securely using AWS Secrets Manager and fine-grained AWS Identity and Access Management (IAM) policies and resource-based policies. AWS KMS was used to encrypt data at rest and in transit.

Hybrid connectivity

To provide a more consistent network experience than internet-based connections, AWS Direct Connect was used to establish private connectivity between AWS and the Mphasis data center. The SQL Server database on AWS used this Direct Connect connection to receive and send data from on-premises applications for extract, transform, and load (ETL) operations.

Benefits

A serverless solution on AWS provides Mphasis with the following benefits:

  • A serverless architecture based on AWS Lambda, Amazon API Gateway, Amazon Cognito, and Amazon SQS that does not require maintenance of back-end infrastructure.
  • End-to-end automation—from the creation of resources and infrastructure to deployment using AWS CloudFormation.
  • Virtual network integration with the company’s firewall for all services.
  • Stringent security enforcement across all components.
  • Integration of AWS Lambda across various technology stacks, such as Angular and Node.js, .NET Core, and earlier versions of .NET Standard.

In the words of Guruprasad BM, the Associate Vice President of Mphasis:

“Earlier, if we had to develop a new application and we did not have virtual machines available in our data centers, the procurement and setup process would take at least three months. Now, we can be up and running on AWS within minutes. That’s how agile our infrastructure and services are.”

Mphasis plans to use this architecture as a reference for rearchitecting other legacy applications to a serverless cloud-native architecture on AWS.

About the authors

Mani - Principal Solutions Architect, AWSMani Chandrasekaran is an Principal Solutions Architect specializing in Containers. He has over 25 years of experience in the IT industry and has worked with customers across the globe. He works with customers in India to help them adopt containers to achieve their business goals and is based in Bengaluru, India. When he is not dabbling in technology, you can find him watching crime thrillers, especially British crime series dramas. You can connect with him on LinkedIn or on twitter @cmani.

 

 

Guruprasad - AVP MphasisGuruprasad B M is an technology leader and an Associate Vice President at Mphasis, with over 23 years of experience in Program & Project Management, Product development & Production support. He has over 13 years of working experience in the CIO team for Enterprise Application’s operations, Cloud Migration, Could Architecture PaaS development and application security.