Hybrid Container Application Stack Using Microservices and Amazon ECS Anywhere
By Vikranth MohanRao, Containerization Capability Lead – DXC Technology
By Vaidehi Chirag Raval, Cloud Solution Architect – DXC Technology
By Dhiraj Thakur, Solutions Architect – AWS
DXC Technology is an AWS Premier Tier Services Partner and Managed Cloud Services Provider (MSP) that is helping organizations achieve excellence in operation of their public cloud hosted containerized workloads.
The Cloud Assessment Toolkit is used by application migration teams at DXC Technology and is typically installed alongside existing application workloads (or servers) on secured and hardened data center infrastructure managed by DXC or provided by the customer. These tools are also used for detailed analysis of DXC customer applications and their readiness to migrate to a cloud environment.
Local install of the toolkit is required due to stringent requirements for data residency since the source code and access to the server required for automated assessment is limited to the customer’s network on the data center.
Files being processed by the toolkit may contain personally identifiable information (PII) that needs to remain in the data center. There are also compliance requirements that data be hosted on IT systems that are fully controlled by either DXC or customer teams.
For application containerization as a service (aCaaS) teams, however, it can be a challenge to deploy and run different services of the toolkit for extended periods within the data center. This is due to limited compute and high latency issues associated with analytical processing that needs to be performed on data captured during discovery and assessment. Change management can be a challenge in scenarios where discovery and assessment run in waves for large transformation programs.
For the Cloud Assessment Toolkit, DXC decided to install services that only capture discovery and assessment metadata, without any PII or other sensitive information within the data center. These services would transfer data to the cloud where additional analytical services would process data based on artificial intelligence (AI) and machine learning (ML) algorithms that require high compute and minimal latency.
In this post, we will describe how DXC was able to leverage Amazon ECS Anywhere to fulfill regulatory and compute requirements and increase operational efficiency for a use case for an in-house proprietary tool where a part of the application stack must run on premises.
DXC’s aCaaS team has an in-house Cloud Assessment Toolkit comprising different microservices such as:
- Cloud Apps Compliance Tool (CACT) scans source code to validate and report cloud-native migration complexity with 12-factor methodology to run efficiently on cloud.
- Website Quality Checker Tool (WSQC) crawls through applications and identifies all broken web content URLs.
- Containerization Migration Assessment Tool (CMAT) provides a deep and detailed analysis of applications and their readiness to migrate to a cloud environment.
DXC’s aCaaS team needed a hybrid cloud solution to execute their toolkit data capture and analysis strategy without major changes in application design or architecture. This is where DXC’s collaboration with Amazon Web Services (AWS) helped, as partner solutions architects suggested Amazon ECS Anywhere could be used to meet this requirement.
Amazon ECS Anywhere is a feature of Amazon Elastic Container Services (Amazon ECS) that enables you to easily run and manage container workloads on customer-managed infrastructure. It helped DXC maintain architectural benefits while letting AWS manage the operations of running workloads on the cloud and in the data center, thus allowing the toolkit to be fully compliant with data residency and compliance requirements.
The high-level architecture of the toolkit topology and orchestration using Amazon ECS Anywhere is illustrated below.
Figure 1 – Hybrid container solution overview for DXC Cloud Assessment Toolkit.
Use Case Implementation
This section covers DXC’s use case implementation using Amazon ECS Anywhere and AWS IAM roles for ECS.
The following tools were downloaded and installed on data center machines:
- Vagrant in new vagrantbox directory.
- Virtual box in new virtualbox directory.
- AWS Command Line Interface (AWS CLI) was installed on the machine for all users.
Learn more about supported operating systems.
Creating IAM Role Using AWS CLI
Using an AWS subscription relevant for an Amazon ECS Anywhere solution, specific roles were created with the commands below by using one of the data center machines that will host the ECS Anywhere cluster and associated agents.
Placeholder tokens are specified within < > but were replaced with actual values relevant for the solution:
Cloud ECS Cluster and Activation Key
Using data center machines that were being used for the ECS Anywhere solution, a local cluster was created using AWS CLI. Relevant roles were extracted in specific formats required for registration of the local cluster with an ECS cluster, using commands as illustrated below.
Note that environment variables set up earlier are being used in these commands:
Once the ECS cluster is provisioned, DXC was able to check that cluster was “ACTIVE” by using the AWS subscription and logging into the AWS Management Console using the relevant accounts.
Figure 2 – On-cloud Amazon ECS cluster provisioned.
It was essential to ensure the cluster was in a healthy state from a resource utilization perspective before proceeding with the data center registration. Again, the AWS account associated with subscription (for the ECS Anywhere solution) was used to monitor the Amazon ECS on AWS Fargate metrics. See below for a sample illustration.
Figure 3 – On-cloud Amazon ECS cluster metrics.
Registration of ECS Anywhere Agents
Once the ECS cluster was provisioned in AWS, it was time to install and then register the on-premises machines with associated ECS cluster agents.
Note this was carried out as per the network proxy and firewall policies being applied to allow communication with only whitelisted ports and domains. For example, in this case it was *.amazonaws.com subdomains.
See below for a sample illustration of the steps that were used for installation and registration of agents. Note that it’s essential to modify vagrant files in order to communicate over a HHTP port of choice, which in this case was 8080:
To prepare the application to run on Amazon ECS, a task definition needed to be provisioned that can serve as a blueprint for the application microservices for Cloud Assessment Toolkit application services. Tasks and services also needed to be provisioned to enable DXC’s application bootstrap and execute the several microservices part of its application stack.
For each microservice used by the Cloud Assessment Toolkit, a definition of microservice was created by specifying the details as provided in the table below. Network mode is selected as a “bridge” to enable container-to-container communication with a default executioner role for containers.
In the last section, DXC specified the details of the container task itself that is used to pull the image from the registry and bootstrap the image for runtime execution.
|Task definition name||Name of task definition||Ext-<<service_name>>|
|Network mode||Select mode||Bridge|
|Task execution IAM role||IAM role is created automatically by AWS||ecsTaskExecutionRole|
|Add container||Give required details to create container||
In the illustration below, task definition is displayed. It should be noted that several versions of task definitions can be created, and the cloud assessment application used version 2 for this solution.
Figure 4 – Task definitions generated.
Services and Tasks
Amazon ECS services run and maintain a specified number of instances of a task definition simultaneously on clusters using task definitions. Containers are launched when services are instantiated.
The table below illustrates the several parameters that were used to define the service that provided an endpoint for communication, a key parameter task definition that specified the microservice and its version that was illustrated in previous steps.
|Task definition||Family: <select task definition>
Revision: <select version>
Revision: Ext-<<service_name>>-2 (latest)
|Cluster name||Name of external cluster||<CLUSTER_NAME>|
|Service name||Name of service||<<service_name>|
|Number of tasks||For replica services, set number of tasks according to business need||2|
The following graphic illustrates the entry point in the cluster configuration where services were created per definitions described in the previous section.
Figure 5 – Creation of services in ECS cluster.
Verify Cluster Health
Once services are instantiated, tasks are launched on the cluster with a RUNNING status which was verified by clicking on the “Tasks” tab.
Figure 6 – ECS cluster health.
Verify Tasks Health
The “Events” tab used to verify the cluster was healthy without any anomalous events that could provide a hint there was something amiss in microservices deployment. In this case, no events that signaled an erroneous behavior were observed.
Figure 7 – Tasks health.
- Leverage existing data center compute: DXC has already invested in third-party data center solutions to avail compute, data security, and customized solutions per DXC customer requirements. In this case, a containerized application was deployed on premises to leverage data center compute.
- Comply with customer regulatory and data residency requirements: DXC customers had reservations about the team migrating an entire application to the cloud. They were concerned about data breach and lack of control over their assets since it contained PII.
Amazon ECS Anywhere helped DXC provide privacy and security with its hybrid cloud model. The team had full control over backend services deployed in a secure network environment in a DXC data center, along with a default secure link provided by AWS between on-premises and cloud environments.
- Burst to AWS: With an increase in the number of customers accessing DXC’s application and limited compute on premises, the team was keen to migrate some microservices to cloud to provide centralized analytics capabilities for customers using a single service definition. Amazon ECS Anywhere gave DXC the ability to do this seamlessly, and the team was able to avail AWS compute to meet demands of customers in a cost-effective way.
Amazon ECS Anywhere helps customers orchestrate containerized application deployments across a wide range of compute environments. Hybrid container operations using ECS Anywhere provide consistent tooling, APIs, a single pane of glass for cluster management, workload scheduling, and monitoring across cloud and customer-managed (or DXC-managed) infrastructure.
DXC Technology is a launch partner for Amazon ECS Anywhere, complementing an in-house offering from DXC’s aCaaS team that enables organizations to transform into digital business using containerization as one of the critical constructs for modernization.
DXC follows a proven factory-based approach to assess application portfolio and identify migrate, build, run, test, and deploy distributed container applications to container platforms on the cloud.
Containerization is one of few niche technologies that fosters innovation by enabling organizations to mitigate challenges such as managing their legacy applications. Hence, containers help organizations deliver more software services at higher speed based on current market needs.
Collaboration between AWS and DXC is a key go-to-market strategy for DXC to support customers migrating applications to AWS.
DXC Technology – AWS Partner Spotlight
DXC Technology is an AWS Premier Tier Services Partner and MSP that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.
*Already worked with DXC Technology? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.