In the previous post of this series, we have seen an introduction to the topic of Cloud Design Patterns.
First things first: let’s see again the definition and description of AWS Cloud Design Patterns:
“AWS Cloud Design Patterns are a collection of solutions and design ideas aimed at using the AWS Cloud technology to solve common systems design problems”.
A complete description of a CDP comprises the following items:
- Pattern Name/Summary: Pattern name, summary and a brief description;
- Solving Issues: Description of typical issues that led to pattern creation, and what issues/challenges can be solved through its implementation;
- Explanation of pattern / Resolution in the cloud: Description of the solution to fix the problems in the cloud;
- Implementation: Details of how to implement the pattern using AWS;
- Benefits: Thorough description of the benefits from the pattern’s application;
- Notes: Tradeoffs, advantages, disadvantages, and points to note when applying this pattern;
- Other: Comparison with other patterns, use cases, and additional information.
These patterns may help the newbie AWS users, the systems engineers and developers who are looking out to Amazon cloud computing, nevertheless, they can be very useful even to the experts.
AWS Cloud Design Patterns: a practical example
Imagine we have our website hosted on an EC2 virtual server and our management asked us to get High Availability for our infrastructure. We must first take an image of our server and an image of our disk data, these operations are described by Stamp Pattern and Snapshot Pattern.
Now as the first approach to disaster recovery of our system, we must have the tools to rebuild everything in a short time. Here we are helped by these two patterns: Server Swapping and Floating IP Pattern
But our approach to high availability cannot end here, we must provide redundancies across multiple servers and across multiple data centers. Solutions described in these two other patterns: Multi-Server Pattern and Multi-Datacenter Pattern
The distribution of the workload over multiple front-end servers force us to separate the database service from our initial single-server installation. So now we need an approach to DB HA. In AWS this is easily achievable with the functionality Multi-Az of RDS. This is mentioned in the pattern DB Replication_Pattern.
Now, our Website is dynamic, not static. So there may be data to be updated or shared between front-end servers. In this case, we have only to choose whether to use a Network File System (NFS Sharing Pattern), maybe replicating shared data on local disks (NFS Replica Pattern) to increase performance. Or maybe it’s enough to share only the states between the front-end servers (State Sharing Pattern).
Nevertheless, I like a more cloud-aware solution, so instead of an NFS, we could use a highly available object storage system like AWS S3 with CloudFront synchronization (URL Rewriting Pattern).
Then, in case of intelligent use of the object storage S3, we must also provide a direct loading of content into S3, to take us the advantage of the scalability of the S3 system (Direct Upload Object Pattern). This pattern requires more about the direct authentication to the S3.
Now we are ready and we have a good High Available Solution. But we need to consider the security of our solution, so a look at the Functional Firewall Pattern maybe helpful.
After making our solution secure, we now must monitor it and allow for maintenance, so reading to Operational Firewall Pattern can surely be inspiring.
What we have seen so far is a good and thorough example of the patterns available on this website and dedicated to the Amazon Cloud. There are many others to evaluate and take as an example for our needs, so feel free to browse and read it thoroughly. Also, given that the website is a standard mediawiki installation, feel free to add suggestions and ideas there, in case you are an expert and something and willing to share your knowledge.
