AWS and AppDynamics APM

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. Next, you can learn 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.

Be aware of the way AWS terms map to AppDynamics terms, as shown in the table below.

Identify the Services you Want your Application to 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) is integrated with many platforms, including EC2

Storage

• Aurora is a relational database compatible with both MySQL and PostgreSQL
• Amazon RDS is simpler than Aurora, but not compatible with other databases
• other options include the Redshift data warehouse and

Load Balancing

The AWS Elastic Load Balancer products are

• Classic Load Balancer — basic,
• Application Load Balancer — advanced, and
• Network Load Balancer — maximally performant.

DNS and More

• Route 53 is the DNS service built into AWS. 
  • Whether to use Route 53 for domain registration, routing, resource health checking, or all three, is up to you.
• Other services available in the AWS ecosystem include messaging, storage, migration, and security.

Decide How Containers are Distributed within Hosts 

If you use containers, you must decide how to distribute each service's containers across the EC2 hosts. There are two possibilities:

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

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

In the case of an architecture build with Docker containers, EC2 hosts, and ECS orchestration, we would describe the results like this:

• Every Docker container is dedicated to one service,
• an EC2 host groups multiple Docker containers,
• every EC2 host is homogeneous, which means means the host has
  • containers that run code and AppDynamics agents for one particular service only
  • one container for the AppDynamics Machine Agent
• an ECS cluster groups one or more EC2 hosts.

The Machine Agent pulls metrics for

1. the EC2 host on which it resides, and
2. each Docker Container that resides on its ECS cluster.