AWS and AppDynamics APM new working copy

This page details steps you must take regardless of which AWS services you want to use.

From here, you can proceed to a page about monitoring applications deployed with ECS. If you want to use a combination of AWS services not covered in these pages, contact your AppDynamics representative.

Map Out your Cloud Application Architecture

When you choose particular AWS services for your cloud application architecture, 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. 

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 Docker

Identify the AWS Services that Best Support your Application

AWS offers more than choice for particular functions. For example, both Elastic Container Service (ECS) and Elastic Beanstalk can be used for orchestration, though each offers a different balance between simplicity and flexibility.

Orchestration

• ECS, Elastic Beanstalk, Fargate, Kubernetes

Databases

• Aurora
• ???

If you are unfamiliar with the strengths and limitations of the many alternatives for orchestration and data storage on AWS, AppDynamics recommends that you review the following:

• article
• blog post
• blog post

Something about why ECS is better than Elastic Beanstalk for this app, but Elastic Beanstalk is a good choice when etc etc

Decide on an Architecture

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?