AWS and AppDynamics APM new working copy

This page helps you map out your cloud application architecture by choosing particular AWS (or other) services for your cloud application architecture.

In so doing, you make tradeoffs: between convenience and flexibility, between resiliency and simplicity, and others. Be sure that these choices are solidly based on your project's needs. That way you avoid risky or costly situations, for example where the application needs to scale up or down but cannot.

Complete the process below to ensure that sound, well-informed choices go into your architecture. Then you can proceed to a page about monitoring applications deployed with Elastic Container Service (ECS). If you want to use a combination of AWS services not covered in these pages, contact your AppDynamics representative.

Identify the Services that your Application Must Provide

To begin creating your cloud application architecture, identify which tiers your application must provide.

One common architecture comprises these three services, each of which is a tier in AppDynamics terms:

• a web front end that runs on Node.js
• a back end MySQL database
• middleware written in Java

Decide whether your cloud application architecture requires one or more of these tiers, or different ones.

To these, add one more service which is not considered a tier: a Java server to run the AppDynamics Controller. 

Decide How your Application Needs to Scale, and Whether to Use Containers

In AWS, you can deploy applications

• directly onto EC2 instances
• within Docker containers which run within EC2 instances, or
• within Kubernetes containers which run within EC2 instances.

Another option, "serverless" cloud deployment, is mostly beyond the scope of this documentation.  

Consider how your application needs to scale. Docker or Kubernetes containers may provide faster, more reliable scaling than deploying directly onto EC2 instances—but the latter option is simpler. Blogs and conference presentations like this one from Amazon explain the tradeoffs.

Decide whether your architecture should use containers, and if so, what kind.

Identify the AWS Services that Best Support your Application

AWS offers more than choice for particular functions. For example, you can use either ECS or Elastic Beanstalk for orchestration—each offers a different balance between simplicity and flexibility.

Some basic choices are outlined below.

Orchestration

• Elastic Beanstalk offers fast and simple orchestration
• ECS provides finer-grained control and more flexibility, but requires more DevOps sophistication
• Fargate allows you to run containers (1) in a serverless manner, or (2) on servers managed with ECS or Elastic Container Service for Kubernetes (EKS)  
• Kubernetes (the only open source, non-AWS option described here) offer

Storage

• Aurora
• ???

Load Balancing

DNS and More

Decide How Containers are Distributed within Hosts 

This section explains principles for architecting the sample application according to best practices for the cloud. If you have your own application, adapt these principles to produce your version of the architecture diagram at the end of this section.

Note: Because the sample application uses ECS, this section describes an ECS-based architecture. If you are using an orchestration tool other than ECS, skip to the Elastic Beanstalk, Fargate, or Kubernetes versions of this section.

So far we've established that in the sample application,

• an ECS cluster groups one or more EC2 hosts
• an EC2 host groups multiple Docker containers
• every Docker container is dedicated to one service

Now we must decide how to distribute the Docker containers for each service across EC2 hosts. There are two possibilities:

1. EC2 hosts are heterogeneous: each host has Docker containers for all services
2. EC2 hosts are homogeneous: each host has Docker containers for one particular service only

Amazon recommends the second approach as a best practice. ECS scales applications much more efficiently with homogeneous EC2 hosts than with heterogeneous ones.

We'll start with the following allocation of Docker containers to EC2 hosts based on anticipated load on the system.

<insert table>

If a homogeneous EC2 host starts with one Docker container, ECS can spawn additional Docker within that host when etc etc (is this true?). 

Therefore, the architecture for the sample application, following AWS best practice, looks like this:

<insert graphic>

What to say about multiple ECS clusters?