Building Business Resiliency with Containers on AWS

As businesses embark on Digital Transformation, Applications and their round-the-clock availability take center-stage. More than ever, modern business establishments rely heavily on Applications to run and grow their business. It’s highly critical that these applications are deployed in a manner that ensures Business Resiliency in the times of a catastrophic event. Traditional Disaster Recovery (DR) strategies have primarily evolved around investing in an alternate site (DR site) and bringing up the applications in the DR site when a disaster occurs.

Containerized Applications provide several advantages in implementing a more flexible and cost-effective DR strategy. By nature, Containers are light-weight, portable, scalable, multi-platform capable and DevOps-friendly, making them an ideal choice for implementing a more robust DR strategy. AWS offers a gamut of services and tools to build a robust Container Platform and a suitable DR solution.

AWS Elastic Container Service (ECS), AWS Elastic Container Service for Kubernetes (EKS) and AWS Elastic Container Registry (ECR) provide the backbone needed to deploy Containers at scale. All these services can be integrated with third-party tools and solutions running on AWS or on-premise. This gives the much-needed flexibility and robustness in implementing the right DR solution. AWS ECS supports both EC2 based and Fargate based deployments, allowing users to choose the option that suits well for their DR needs. AWS EKS offers a completely managed Kubernetes service that offers many advanced features in implementing purpose-built DR solutions.

Let’s look at key advantages we gain when implementing DR for containerized applications.

1. Highly de-coupled DR implementation: In traditional applications, the code and data were highly coupled with one another from an infrastructure and tooling standpoint. This resulted in having multiple bespoke DR approaches within a business often relying on specific technologies and tools. Containers break this paradigm and hence having a uniform DR strategy becomes a reality. It is often possible to have a single DevOps pipeline for multiple applications that cater to the DR needs of the applications. However, this is not possible with traditional monolithic applications. DevOps and containers go hand-in-hand when it comes to DR. AWS offers a suite of DevOps services for code build, CI/CD, Infrastructure as Code etc. AWS CodePipeline, AWS Codebuild, AWS CodeDeploy, and AWS CodeStar provide CI/CD services. AWS CloudFormation and AWS OpsWorks provide Infrastructure as Code services. All these are essential tools in deriving the benefits containers offer.
2. Near-zero Recovery Time Objective (RTO): RTO is a measure of how quickly the application is up and running in the event of a disaster. Containers are light-weight and if planned upfront, can be spun near-instantly. In addition, containers provide the capability of rapid on-demand horizontal scaling, monitoring, and automation. These aspects can be leveraged to implement a DR strategy that can result in a near-zero RTO so that users can experience no downtime even in the event of a disaster. AWS provides a multitude of mechanisms for rapid on-demand scaling of containers. Both AWS ECS and AWS EKS support advanced scaling mechanisms for containers.
3. Cost-effective DR: Containers bode well to achieve cost-effective DR. For instance, it is possible to build a container-image that can run on multiple OS platforms and architecture. This means, in the event of a disaster, the same image can be run on an available VM and this avoids the need of provisioning an additional VM. Using a common infrastructure and tooling further brings down the cost. In addition, container orchestration engines like Kubernetes natively support multi-region clusters, removing the need for additional tooling. All these help in drastically reducing the cost.
4. Increased efficiency with container images: Unlike a VM image, the file system of a container image is built using a layered approach - each layer identified by a unique digest. Two different container images can have a common set of image layers. When these container images are pulled into a host, the common layers are pulled only once. This aspect of a container brings in more efficiency in a DR solution. For instance, image repositories can be replicated to the DR site very efficiently. It also allows for easy distribution of images. Images can be cached in local registry mirrors and for specific use cases, even directly on hosts. This makes the DR solution more efficient when compared to traditional applications. AWS ECR is a production-grade docker image registry that provides advanced features for implementing an appropriate DR solution.
5. Supporting runtime configuration and discovery: Containers are application constructs that can be configured and re-configured on the fly. For instance, a running container can be attached easily to a different network; new and updated configuration can be programmatically applied to containers; containers can discover other containers on the fly. There is no need to pre-configure discovery parameters. All these aspects make DR implementation very easy and uniform.

Here are some prominent patterns in implementing disaster recovery solutions for containerized applications on AWS:

1. Hot-Standby DR site: In this approach, there is a dedicated hot-standby DR site in a different AWS Region. The DevOps pipeline is built in such a manner that multiple instances of the containerized application are run, spread across the active and DR site. Traffic is handled by both the active and DR site. Container image registries and application state are constantly replicated between the active and DR site. When the active site becomes unreachable, the container monitoring solution like AWS CloudWatch identifies this and subsequently the DevOps pipeline brings up the lost container instances of the active site, in the DR site.
2. Warm-Standby DR site: In this approach, there is a dedicated DR site, however, the container instances are run only in the active site. Whereas, application state (database) and container images are constantly replicated to the standby Site. During a DR event, necessary infrastructure instances (e.g. EC2) are spun up in the standby site and the container instances are redeployed. The new container instances use the replicated application state and traffic is completely redirected to the DR site.
3. Cold-Standby DR site: This approach relies on frequently backing up the application state in a remote DR site while the application instances run only in the active site. During a DR event, necessary infrastructure instances (e.g. EC2) are spun up in the standby site and the application instances and database instances are redeployed. Data from the backup is restored into the database instances.

By nature, Containers provide unique advantages from a Disaster recovery perspective. And AWS provides the right Container services and tools necessary to build a robust and cost-effective DR solution for your Containerized applications. Containers and AWS together give your Businesses the resiliency needed in the Digital era.

Visit Cognizant booth 1001 at AWS re:Invent to learn more