AWS: Architecting for the Cloud
AWS has a document that goes over the best practices for architecting the cloud and it’s a whopping 50 pages. It’s not much but for a new comer to the field, it may take a couple of read throughs to understand the information. We’ll break it down into pieces and make somewhat of a TLDR.
Traditional Computing V Cloud Computing
In the intro to AWS blog, we spoke about why cloud computing has become a norm and how companies are moving toward AWS Cloud Computing services. The main differences are that cloud computing offers flexibility, scalability, better security, and cost optimization.
Traditionally, companies would buy resources based on an estimate that results in expensive resources not being used or being insufficient.
With cloud computing, you can dynamically scale to meet demand while only paying for what you use. The main benefits of cloud computing are as follows:
- Provisioning services as needed.
- Deploying globally such that your application lives physically closer to your users.
- Manages services allots more time for you to focus on building your application and any complexities are taken care of by AWS.
- Architect for cost while also being able to track spending on all the services you are using.
Design Principles
The key design principles include scalability, disposable resources, automation, loos coupling managed services and flexible data storage option.
Scalability
Applications that grow need to build on top of scalable architecture so that there are no drop-in performance. You can scale vertically and horizontally.
- vertical scaling — upgrading a single resource like RAM or CPU.
- horizontal scaling — upgrading or scaling more than one resource.
Stateless Applications
These are applications that don’t have knowledge of a previous request and does not store any session information. A great example of this is Alexa services. Each request/response from the Alexa Service is a clean canvas with no knowledge of what was asked of her before hand. Without stored information, you can add more compute resources as needed. When the capacity is not required any longer, you can safely delete those individual resources. Horizontal scaling is best suited for these types of applications.
Distributed Load to Multiple Nodes
Push Model — uses an elastic load balance to distribute incoming traffic to multiple instances of you application. The aim of load balancing is to optimize the use of resources available to maximize throughput and minimize response times and to take the load off of a singular resource.
Pull Model — tasks are put in a queue using Amazon Simple Queue Service. Instances pull their own unit of work that need to get processed.
Statless Components
Web apps need to track whether a user is signed in so that personalized content can be presented. A portion of these architectures can be made stateless by not storing anything that needs to persist for more than a single request in the local file system. An example is HTTP cookies. The browser passes that information to the server at each request so the application does not need to store it. The drawbacks are that with every request the data must be validated and they are transmitted with every request which means their size should be small to avoid latency.
Another approach would be to store unique session identifiers in an HTTP cookie and storing more detailed user data on the server side. Storing data in a server creates a stateful architecture.
Stateful Components
These are applications that are specific to running out of a single machine like real-time multiplayer games. For these applications, you would not want to spread traffic to random horizontally scaled instances.
These components can make use of sticky session which attach a user to a specific EC2 instance. This ensures that as long as they are gaming, they won’t be moved to a different physical machine.
Disposable Resources Instead of Fixed Servers
AWS allows you to take advantage of dynamically provisioned services. Servers and other components can be a temporary resource that can be launched as many times as needed for how ever long you need them. Traditionally this would have been an incredibly expensive thing to do because you’d need to buy those physical servers.
Ways to instantiate a compute resource:
- Bootstrapping: When launching a resource like an EC2 instance, you can execute automated bootstrap actions (which are scripts that install software).
- Golden Images: some AWS resources can be launched with a snapshot of a resource. This is faster than bootstrapping and allows to quickly launch additional resources by ‘cloning’ an instance.
- Container: This refers to Docker, an open source tech that allows you to build and deploy apps inside of software containers. Docker allows you to package a piece of software in a Docker Image containing everything the software needs to run.
- Hybrid: A combination of the above mentioned resources. Some parts of configuration are captured in a golden image while others are dynamically set through bootstrap actions.
This information is definitely a bit thick. As I learn AWS, I find that my blogs definitely help me jog my memory on certain services because there are so many! If this information was a bit too much, I recommend taking a smaller bite here and reading Amazons document on this topic. By no means do I feel like an expert just yet with this material and that’s okay. Learning theories and basic fundamental on how to build out a scalable application isn’t an easy thing I assume. I’ll list some resource down below that I use to help me out and as always, happy coding !
Edit: I just realized that the document I was looking at has been archived by Amazon. The link below is their updated document on the same topic which seems to be refined! This blog should still hold some core fundamentals on Design Principles. Next week I’ll take a look at the new document! Cheers.
