AWS Cloud Native Microservice Patterns – 2 common patterns

27th June 2018

AWS Cloud Native Microservice Patterns – 2 common patterns

https://aws.amazon.com/architecture/

2 common patterns on AWS for Cloud Native deployments are Java on EC2 and Continuous Deployment on ECS (Elastic Container Services).

1) Java on EC2 – using Containers

Containers are important in Cloud Native application development. Containers help us break down monolithic apps into components, and discrete pieces of functionality.  In general Containers:

  • Are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes
  • Allow us to easily package an application’s code, configurations, and dependencies into building blocks
  • Provide key building blocks for containers include: environmental consistency, operational efficiency, developer productivity, and version control
  • Help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment. Containers also give you more granular control over resources giving your infrastructure improved efficiency.

AWS provides ECS or Elastic Container Service.  ECS is a cluster management service that helps you manage a group of clusters through a graphical user interface or by accessing a command line.

With ECS we can install, operate, and scale our own cluster management infrastructure. With simple API calls, we can launch and stop Docker-enabled applications, query the complete state of the cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes, and IAM roles.

Amazon ECS also allows us to schedule the placement of containers across a cluster, based on resource needs and availability requirements. Integration with our a scheduler or third-party schedulers to meet business or application specific requirements is possible.

AWS Example:  The Spring Pet Clinic. A high-level architecture of PetClinic app is as follows,

GitHub resources:

  1. Part One: Moving existing Java Spring application to a container deployed using ECS
  2. Part Two: Breaking the monolith apart into microservices on ECS
  3. Part Three: Create a continuous integration and continuous delivery

Prerequisites

You will need to have the latest version of the AWS CLI and maven installed before running the deployment script.

  1. Installing the AWS CLI
  2. Installing Maven
  3. Installing Docker
  4. Installing Python
  5. Installing JQ

 

2) Continuous Deployment on ECS

In reality continuous deployment is usually implemented before continuous integration.  CD reference architecture on AWS is here – continuous deployment which shows the CD of an application to Amazon Elastic Container Service (Amazon ECS) using AWS CodePipeline and AWS CodeBuild.

With continuous deployment, software revisions are deployed to a production environment automatically without explicit approval from a developer, making the entire software release process automated.

To aid with CD we use AWS CloudFormation stack or templates, which provision a continuous deployment process that uses AWS CodePipeline to monitor a GitHub repository for new commits and AWS CodeBuild to create a new Docker container image and to push it into Amazon Elastic Container Registry (Amazon ECR).

When creating this stack, you can opt to deploy the service onto AWS Fargate or Amazon EC2. AWS Fargate allows you to run containers without managing clusters or services. If you choose Amazon EC2, an Auto Scaling group of t2.micro instances will be created to host your service.

Running the example

1. Fork the GitHub repository

Fork the Amazon ECS sample app GitHub repository into your GitHub account.

From your terminal application, execute the following command (make sure to replace <your_github_username> with your actual GitHub username):

git clone https://github.com/<your_github_username>/ecs-demo-php-simple-app

This creates a directory named ecs-demo-php-simple-app in your current directory, which contains the code for the Amazon ECS sample app.

2. Create the CloudFormation stack

This reference architecture can only be deployed to Regions which have all necessary services available.

The CloudFormation template requires the following parameters:

  • Cluster Configuration
    • Launch Type: Deploy the service using either AWS Fargate or Amazon EC2. Selecting EC2 will create an Auto Scaling group of t2.micro instances for your cluster.
  • GitHub Configuration
    • Repo: The repo name of the sample service.
    • Branch: The branch of the repo to deploy continuously.
    • User: Your username on GitHub.
    • Personal Access Token: Token for the user specified above. (https://github.com/settings/tokens)

The CloudFormation stack provides the following output:

  • ServiceUrl: The sample service that is being continuously deployed.
  • PipelineUrl: The continuous deployment pipeline in the AWS Management Console.

Testing the example

After the CloudFormation stack is created, the latest commit to the GitHub repository is run through the pipeline and deployed to ECS. Open the PipelineUrl to watch the first revision run through the CodePipeline pipeline. After the deploy step turns green, open the URL from ServiceUrl which loads a page similar to this:

To test continuous deployment, make a change to src/index.php in the ecs-demo-php-simple-app repository and push it to GitHub. CodePipeline detects the change, builds the new application, and deploys it to your cluster automatically. After the pipeline finishes deploying the revision, reload the page to see the changes made.

Cleaning up the example resources. To remove all resources created by this example, do the following:

  1. Delete the main CloudFormation stack which deletes the substacks and resources.
  2. Manually delete resources which may contain content:
    • S3 Bucket: ArtifactBucket
    • ECR Repository: Repository
CloudFormation template resources

The following sections explains all of the resources created by the CloudFormation template provided with this example.

Resources that compose the deployment pipeline include the CodeBuild project, the CodePipeline pipeline, an S3 bucket for deployment artifacts, and all necessary IAM roles used by those services.

An ECS task definition, service, IAM role, and ECR repository for the sample application. This template is used by the CodePipeline pipeline to deploy the sample service continuously.

An ECS cluster optionally backed by an Auto Scaling group of EC2 instances running the Amazon ECS-optimized AMI for the EC2 launch type.

An Application Load Balancer to be used for traffic to the sample application.

A VPC with two public subnets on two separate Availability Zones, an internet gateway, and a route table with a default route to the public internet.

==END