Architecting for the Cloud: AWS Best Practices

Migrating applications to AWS, even without significant changes (an approach known as “lift and shift”).
Architect in a such a way to exploit the elasticity of cloud.

The Cloud Computing Difference:
1. IT Assets Become Programmable Resources
2. Global, Available, and Unlimited Capacity
3. Higher Level Managed Services : EC2, storage, database, analytics, application, and deployment services
4. Security Built In : The AWS cloud provides governance capabilities that enable continuous monitoring of configuration changes to your IT resources. Since AWS assets are programmable resources, your security policy can be formalized and embedded with the design of your infrastructure.
6. Design Principles
7. Scalability : Architecture can support growth in users, traffic, or data size with no drop in performance.
While cloud computing provides virtually unlimited on-demand capacity, your design needs to be able to take advantage of those resources seamlessly.
A. Scaling Vertically : On Amazon EC2, this can easily be achieved by stopping an instance and resizing it to an instance type that has more RAM, CPU, IO, or networking capabilities.
B. Scaling Horizontally: Increase in the number of resources.Not all architectures are designed to distribute their workload to multiple resources.
Stateless Applications: A stateless application is an application that needs no knowledge of previous interactions and stores no session.
How to distribute load to multiple nodes:
Push Model:
Elastic Load Balancer (ELB) routing requests to EC2.
Aletnerate approach DNS round robin (e.g., with Amazon Route 53): Round robin fashion. While easy to implement, this approach does not always work well with the elasticity of cloud computing. This is because even if you can set low time to live (TTL) values for your DNS records, caching DNS resolvers are outside the control of Amazon Route 53 and might not always respect your settings.
Pull Model:
Data that need to be processed could be stored as messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming data solution like Amazon Kinesis.

Stateless Components:Use HTTP cookies to store information about a session at the client’s browser (e.g., items in the shopping cart).
Two drawbacks
1.Content of the HTTP cookies can be tampered with
2. Second, HTTP cookies are transmitted with every request ( Keep their size to minimum)

A common solution to this problem is to store user session information in a database. Amazon DynamoDB is a great choice due to its scalability, high availability, and durability characteristics.
Amazon S3 for large file storage.
Amazon Simple Workflow Service (Amazon SWF) can be utilized to centrally store execution history and make these workloads stateless.

Stateful Components:
Databases are stateful
Many legacy applications were designed to run on a single server by relying on local compute resources.
Other use cases might require client devices to maintain a connection to a specific server for prolonged periods of time. e.g. Consistent view of the
game in real time multiplayer game. Session affinity.

How to implement session affinity:
For HTTP/S traffic, session affinity can be achieved through the “sticky sessions” feature of ELB4. Elastic Load Balancing will attempt to use the same server for that user for the duration of the session.
DNS
Clinet API to discover information (server)


Distributed Processing:
By dividing a task and its data into many small fragments of work, you can execute each of them in any of a larger set of available compute resources.
How to implement distributed processing.
Offline batch jobs can be horizontally scaled by using a distributed data processing engine like Apache Hadoop. On AWS, you can use the Amazon Elastic MapReduce (Amazon EMR) service to run Hadoop workloads on top of a fleet of EC2 instances without the operational complexity.
For real-time processing of streaming data, Amazon Kinesis partitions data in multiple shards that can then be consumed by multiple Amazon EC2 or AWS Lambda resources to achieve scalability.

Disposable Resources Instead of Fixed Servers:
Fixed resources:
Manual efforts and Cost
Configuration drift - Changes and software patches applied through time can result in untested and heterogeneous configurations across different environments.


Instantiating Compute Resources:
There are a few approaches on how to achieve an automated and repeatable process.
Bootstrapping -
Start with a default configuration. You can then execute automated bootstrapping actions.
Parameterize configuration details that vary between different environments (e.g., production, test, etc.)
Bootstrapping in practice
You can use user data scripts and cloud-init6 directives or AWS OpsWorks lifecycle events7 to automatically set up new EC2 instances.
You can use simple scripts, configuration management tools like Chef or Puppet.
AWS OpsWorks natively supports Chef recipes or Bash/PowerShell scripts.
In addition, through custom scripts and the AWS APIs, or
through the use of AWS CloudFormation support for AWS Lambda-backed custom resources, it is possible to write provisioning logic that acts on almost any AWS resource.

Golden Images
Amazon EC2 instances, Amazon RDS DB instances, Amazon Elastic Block Store (Amazon EBS) volumes, etc., can be launched from a golden image: a snapshot of a particular state of that resource.
Compared to bootstrapping faster.
Create AMI.
Versioning of AMI's.

Containers:
Docker - Docker Image, which is a standardized unit for software development, containing everything the software needs to run: code, runtime, system tools, system libraries, etc. AWS Elastic Beanstalk and the Amazon EC2 Container Service (Amazon ECS) support Docker and enable you to deploy and manage multiple Docker containers across a cluster of Amazon EC2 instances.

Hybrid:

Some part in Golden Image, some part in bootstrapping

The line between bootstrapping and golden image:

Items that do not change often or that introduce external dependencies will typically be part of your golden image.

For example, web server software

Items that change often or differ between your various environments can be set up dynamically through bootstrapping actions. 

For example, if you are deploying new versions of your application frequently

Database hostname configuration (different between the test and production environments)

User data or tags.

AWS Elastic Beanstalk follows the hybrid model.
 It provides preconfigured run time environments (each initiated from its own AMI10)
 but allows you to run bootstrap actions (through configuration files called .ebextensions11) and configure environmental variables to parameterize the environment differences.

Infrastructure as Code:
Apply techniques, practices, and tools from software development to make your whole infrastructure reusable, maintainable, extensible, and testable.

• Create and manage - AWS resources, and 
• provision and update them in an orderly and predictable fashion.
• Describe the AWS resources, and any associated dependencies or run time parameters, required to run your application. 
• Version control repository, allowing architectures to be reused and production environments to be reliably cloned for testing.

Automation:

AWS Elastic Beanstalk : Developers can simply upload their application code and the service automatically handles all the details

Amazon EC2 Auto recovery: Recovered instance is identical to the original instance, including the instance ID, private IP addresses, Elastic IP addresses, and all instance metadata ( Only certain EC2 Type). During instance recovery memory data is lost.

Auto Scaling:

Amazon CloudWatch Alarms: Sends an Amazon Simple Notification Service (Amazon SNS) message -  

SNS Message automatically trigger AWS Lambda function, 

enqueue message to SQS  or 

POST request to an HTTP/S endpoint.

Amazon CloudWatch Events:

AWS OpsWorks Lifecycle events:

AWS OpsWorks supports continuous configuration through lifecycle events that automatically update your instances’ configuration to adapt to environment changes. These events can be used to trigger Chef recipes on each instance to perform specific configuration tasks. For example, when a new instance is successfully added to a Database server layer, the configure event could trigger a Chef recipe that updates the Application server layer configuration to point to the new database instance.

AWS Lambda Scheduled events: