Reliability – Part of a Well-Architected AWS Framework

Every system is only as good as its ability to maintain a high level of reliability, even when experiencing stressful or unusual conditions. AWS (Amazon Web Services) certainly understands this core principle, which is why they include reliability as one of the key pillars in their description of building a well-architected framework. When a software system’s design incorporates reliability as an essential component of its foundation, it will operate consistently and correctly regardless of workload demand. It will also have both the ability to detect failure and initiate its own healing and recovery.

Design Principles for Reliability in the Cloud

When designing a cloud system, there are several objectives or principles that must be fulfilled to ensure that the requirements for reliability will be met. These principles include:

• Managing change through automation.
• Accurately measuring capacity.
• Testing and validating recovery procedures.
• Automatic recovery from failure.
• Increasing aggregate workload availability through horizontal scaling.

Best Practices

In practical terms, to address the principles that comprise the pillar of reliability, several best practices should be incorporated when building a solid framework. These best practices include addressing foundational requirements, workload architecture, change management, and failure management.

Foundational Requirements — While AWS is responsible for sufficient network and computing capacity, system creators still have some foundational responsibilities. For example, companies must still ensure they have sufficient network bandwidth for their data centers. In addition, it’s not uncommon for corporate workloads to exist in multiple environments, including private and publicly available cloud environments, along with a company’s current data center infrastructure. It is still within a company’s sphere to manage and monitor these environments.

Companies must also execute the groundwork for network foundational requirements such as domain name resolution, public and private IP address management, and intra and intersystem connectivity.

Workload Architecture — While AWS allows developers to choose their own languages and technologies, AWS does try to reduce some of the complexity by providing language-specific APIs. By providing these consistent interfaces, developers can easily connect with their services. Even so, developers should still consider how their own decisions, both in terms of design and the programming tools they use, will affect the overall reliability of the system they are creating. To give developers more insight on how AWS builds and operates their own software, Amazon provides a helpful resource in The Amazon’s Builder’s Library.

Change Management — A reliable system can adapt to changes in external demand and internal changes such as a security patch or deployment of a new feature. Managing changes means being automatically alerted to changes in resource requirements and having the ability to log both changes and responses (for later review). This comprehensive approach to managing change allows companies to note both their successes in delivering resources for increased demand and areas where they need to improve.

Managing Failure — While companies work very hard to avoid failure, as with any complex system, there is always the remote possibility of an unforeseen event that leads either to downtime or some other type of failure. Fortunately, software systems can be designed in such as way as to minimize failure. If a negative event should occur, the system can be prepared in advance to respond in a way that causes as little disruption as possible. Depending upon the issue, a system can be programmed to trigger an automated action to remedy a specific problem.

In other instances, a better resolution is to replace the system altogether. In these cases, the troubled system is immediately replaced with a new production system waiting on standby. Once the failed system is replaced with a working copy, teams can diagnose and repair the failure, then put the newly repaired system back in production at an appropriate time.