Talk to an Expert

We're ready to help

Our cloud experts can answer your questions and provide a free assessment.

Schedule
a meeting
close
High Availability

DevOps and High Availability When Deploying with AWS

  • 0
  • 0

This is the fourth piece in our ongoing series on the Practice on DevOps.

Check out the other pieces in the series:

 

Winston Churchill once said said, “He who fails to plan is planning to fail.”  When it comes to the availability of systems and software in today’s computing ecosystem, this Mr. Churchill’s words could not be truer. Businesses utilizing cloud infrastructure have come to expect high availability (HA) with minimum human involvement, and are intolerant of any downtime.

HA, in particular, is where cloud DevOps intersects in very meaningful ways with Amazon Web Services (AWS) deployments.

Fortunately, many of the AWS offerings come with HA and fault-tolerant features built-in. Some of these include:

  • Amazon Simple Storage Service (S3), which assure HA as it claims to be inherently designed to be reliable to 11 nines (99.999999999%).
  • DynamoDB, which is a fully managed NoSQL database that is synchronized across multiple regions to provide HA.
  • Route53 is a Domain Name System resolution service that can be configured to point to elastic IP addresses that are provisioned dynamically when one instance fails.
  • Elastic Load Balancing (ELB), an automatic load balancing service that eliminates single points of failure and provides not only HA, but scalability benefits as well. (We will cover the topic of scalability, including Autoscaling groups, in more detail in another blog post.)
  • Relational Database Service (RDS), which allows an organization to establish a scalable relational database in the Cloud and assures HA when RDS replicas are set up in the application architecture, in Multiple Availability Zones (AZ) mode. Availability Zones make resources highly available because they are set up to fail independently and are physically distinct.
  • Elastic Block Storage (EBS) makes it possible to store data (application related, state data, etc.) separate from the EC2 instance itself. This makes it possible for HA of the data, since the EBS storage can be pointed at, by the new instance of EC2 that is spun up, in the event of a failure in the operating provisioned instances. EBS also has the feature to perform automatic health checks.

It is important to understand that if these inherent services are not intentionally designed to be able to recover from failure, the HA benefits they provide can be negated. It is, therefore, necessary to recognize that high availability architecture is a planned approach, rather than a feature of the tools that managed service providers specializing in Managed AWS use. The AWS DevOps solutions, such as CloudFormation, OpsWorks, and Elastic Beanstalk can be leveraged to abstract some of the design challenges that could adversely impact HA.

For businesses that require applications running continuously, CloudFormation can be used to make a template of the application configuration and resources that are modeled as a stack on the cloud. This template can then be held in a repository, from where it can be checked out as needed, by version (or branch), making it reproducible and easily deployable as new instances when needed – i.e., when existing applications fail or when they experience degraded performance.

OpsWorks automates almost all of the manual deployment processes like capacity estimation, provisioning servers, installation and configuration of required software and backend storage components across multiple AZs, security configuration, deployment, load balancing, bootstrapping, and health check monitoring. Both application functionality and data need to be highly available. For HA of the application, OpsWorks can be configured to set up ELB to balance traffic across multiple Availability Zones (AZs). One can also set up HAProxy that is offered within the OpsWorks product. HAProxy is a fast, stable and reliable load balancing and proxying solution that works by redirecting TCP and HTTP requests across multiple servers, eliminating single points of failure. For HA of data, OpsWorks can be set to provision RDS across two or more AZs with synchronous replication between the two zones. When there is a failure of either the application or the database in the master zone, which could be detected using Amazon CloudWatch service, OpsWorks can clone a replica and set the replica to take the place of the master instance that failed, continuing to assure the continuity of business operations.

In addition to CloudFormation and OpsWorks, another AWS DevOps service that can be leveraged to deploy code is Elastic Beanstalk. It is developed in .NET, Java, PHP, Python, Ruby, Node.js, on well-known servers, such as Apache, IIS, Nginx, etc. All one would need is to upload the correct version of the code into the source code repository and the Elastic Beanstalk service automatically handles the deployment. AWS Elastic Beanstalk is available in multiple AZs, and to make the application highly available, all one needs to do is to edit the environment configuration to include any two of the AZs with auto scaling configured to more two or more instances.

Defects and bugs in applications, network issues, infrastructure failures, etc., can impact the HA of computing resources. If one fails to plan for addressing HA requirements, they are indeed planning to fail. Taking a DevOps approach to deploying code in AWS environments with a high availability design ensures that customers don’t experience any downtime.

Most importantly, while AWS provides these tools and range of capabilities, the platform requires a great deal of expertise to fully unlock. A managed AWS hosting approach can greatly alleviate the lack of experience internal IT teams face when getting started on AWS. Managed AWS services can also bring HA tenets and applications faster to market, improved greatly by DevOps practices.

—-

By Mano Paul

October 23, 2014

No Comments

    Leave A Comment