[AWS and AppDynamics APM]

The root page @home could not be found in space AppDynamics AWS Monitoring.

[Monitoring Cloud Applications]

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

On this page:

AppDynamics customers are using AWS services to support a variety of cloud application architectures.

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

From here, you can proceed to pages that explain

  • Monitoring Applications Deployed with Elastic Beanstalk
  • Monitoring Applications Deployed with ECS

Plan How your Application Will Behave in the Cloud 

Any cloud application architecture embodies tradeoffs between convenience and flexibility, resiliency and simplicity, and so on. It's risky to make architectural decisions without thoroughly understanding those tradeoffs. For example, you might inadvertently create a situation where the application needs to scale up or down but cannot.

To avoiding such potentially costly problems, complete the process below, which is designed to promote well-informed architectural choices.

Identify the Services that your Application Must Provide

The sample application provides three services:

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

Identify which of these services your application must provide, and any additional services.

In AppDynamics terms, each of these services is one tier of your application.

For the cloud, your application needs to run one more service besides those you have identified thus far:

  • a Java server to run the AppDynamics Controller

The service supporting the AppDynamics Controller is not considered a tier.

 

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

Something about Gabriella's requirements for scaling and why Docker is better for her purposes

Do we prefer EC2 Host or Instance? anyway, state that they're equivalent somewhere

Identify the AWS Services that Best Support your Application

You have many options etc etc

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?

Get Started with AWS

If you don't have an account ...

Prepare your Application for the Cloud

If you have your own application, skip or modify the steps in this section as appropriate.

Download the Sample Application

Download the sample code from link TBD to your local system. 

Download agents separately?

Configuration Files and Templates

Docker Compose file creates etc etc

About Recycling Nodes

Preventing a "node explosion" is a concern that is unique to cloud applications etc etc

The AppDynamics Controller

Download?

AppDynamics Agents and Plugins

Sample application uses:

  • Java agent
  • Node.js agent
  • DB???
  • Machine agent

The Machine Agent Pulls Metrics in Two Ways

The Machine agent pulls metrics for

  1. the EC2 host on which it resides
  2. each Docker Container that resides on its host

etc etc

Deploy your Application to the Cloud

Log into the AWS console ...

The control panels for the AWS services you will use are

  • ECS
  • ...

Create an ECS Cluster

details TBD 

Create an EC2 Host for Each Service in your Application 

Create one EC2 host for each service that your application provides, and one more for the AppDynamics Controller.

details TBD 

Create Docker Containers within your EC2 Hosts

details TBD

Docker Compose file creates etc etc

Define an ECS Task to Bring Up your Docker Containers

JSON file creates etc etc

Verify that your Application is Running in the Cloud

Visit the following control panels and verify that metrics appear etc etc

Monitor your Cloud Application with AppDynamics

Here's more about what you can monitor etc etc


Supplement: Alternatives for Orchestration

If your preferred orchestration tool is not described by one of the sections below, we recommend adapting articles TBD


Decide on an Architecture (Kubernetes version)

steps TBD

skip back to section TBD

 

Decide on an Architecture (Elastic Beanstalk version)

steps TBD

skip back to section TBD

 

Decide on an Architecture (Fargate version)

steps TBD

skip back to section TBD


Supplement: Alternatives for Orchestration

If your preferred orchestration tool is not described by one of the sections below, we recommend adapting articles TBD


Decide on an Architecture (Kubernetes version)

steps TBD

skip back to section TBD

 

Supplement: Installing Additional Agents

If your preferred AppDynamics agents are not described by one of the sections below, we recommend adapting articles TBD


PHP Agent

steps TBD

skip back to section TBD


 

 

  • No labels