AWS Hands-On: Break a Monolith Application into Microservices (Module 4)

Module 4: Deploy Microservices
Approach.
1. Switch the Traffic: This is the starting configuration. The monolithic node.js app running in a container on Amazon ECS.
2. Start Microservices: Using the three container images you built and pushed to Amazon ECR in the previous module, you will start up three microservices on your existing Amazon ECS cluster.
3. Configure the Target Groups: Like in Module 2, you will add a target group for each service and update the ALB Rules to connect the new microservices.
4. Shut Down the Monolith: By changing one rule in the ALB, you will start routing traffic to the running microservices. After traffic reroute has been verified, shut down the monolith.

Steps.
Creation of Task Definitions for each of the service. Configure via JSON feature of ECS was used to create the three services.

Creation of Target Groups. This time, AWS CLI was used to create the three corresponding target groups.

Configuring the Listener rules 

Deploying the microservices

Traffic switching

Validating that services are working

Read More

AWS Hands-On: Break a Monolith Application into Microservices (Module 3)

Module 3: Break the Monolith
The purpose of Module 3 is to demonstrate how to break a monolith service into individual services that will run on different containers. The image creation and deployment are the same with what was done in the previous modules. We will explore new ways how to do it faster since there will be three services this time which will make this module as the shortest among all.

Step 1. Provision the ECR repositories.
We need to prepare container image repositories for the users, posts, and threads services.

Step 2. Authenticate Docker with AWS (only if needed).
Step 3. Build and Push Images for each Service

'docker build'

tagging and pushing

Read More

AWS Hands-On: Break a Monolith Application into Microservices (Module 2)

Module 2: Deploy the Monolith
After containerizing the monolith service application, we now deploy it in AWS. It will run in a cluster that will have 2 replicas with an Application Load Balancer in front for minimum high-availability. 

Key services that was used in this hands-on:Amazon Elastic Container Service, Amazon Elastic Container Registry, AWS CloudFormation, and Elastic Load Balancing. Most of the procedures were done in AWS console although the AWS CloudFormation part can also be done through the AWS CLI.

Step 1. Launch an ECS Cluster using AWS CloudFormation.
This is where we run the infrastructure code in the project that we cloned from Module 1.

The resulting infrastructure will have the following resources:

• A VPC with 2 Public subnets (1 for each container), and Internet Gateway and Route Tables for public access
• An ECS Cluster with a defined Security Group
• An Application Load Balancer
• An IAM Role for the ECS service

 Step 2. Verification steps to check that the cluster is running.

Step 3. Writing the Task Definition.
Task definitions specify how Amazon ECS deploys the application containers across the cluster. This is where referencing to the application image repository that was created in Module 1 happens.

Step 4. Configure the Application Load Balancer: Target Group
The Application Load Balancer will route network traffic to the container instances through a Target Group that refers to the VPC that was created in Step 1.

Step 5. Configure the Application Load Balancer: Listener
The ALB Listener checks for incoming connection requests to the ALB.

Step 6: Deploy the Monolith as a Service

Step 7: Test the Monolith

Read More

AWS Hands-On: Break a Monolith Application into Microservices (Module 1)

Module 1: Containerize the Monolith
In a real world application, the assumption is that we've already containerized our 'monolith' application and that a corresponding Dockerfile has already been created for it. Module 1 is a demonstration on how we can store a Docker image of that monolith application in Amazon EC2 Container Repository (ECR). This is just a summary of what goes, the steps and definitions are well documented in the AWS hands-on project link above.

Prerequisites:
1. AWS account, Git client, a text editor. These are pretty straightforward already.
2. Docker. I am currently at Fedora 32 but there is no Docker-ce official release yet for this version as of writing so I used this guide instead. Extra steps: I added my user to the 'docker' group so that I don't need to do 'sudo' for every docker command that I run.

After installing Docker, I proceeded with installing AWS CLI. I chose to install version 2 as recommended.

There will be a Git project that needs to be downloaded/cloned. It will contain infrastructure scripts and the Dockerfile of the test monolith application.

Next is the provisioning of a container repository in ECR. The resulting docker image of the monolith app will be stored here later.

Finally, the building and pushing of the Dockerized monolith app. 
Initially, I encountered an error while attempting to authenticate Docker to ECR so I proceeded on building and tagging the image first.

For the ECR docker login part, there is a new process described here. After successfully hooking up my Docker and ECR, I was then able to push the image.

Read More

Best Practices: Security Concerns with Microservices

Microservices architecture is more dispersed in nature hence, there will be a larger surface area for attacks and vulnerabilities. But because of this dispersion where services being independent at one another, this architecture allows for a more granular restrictions. 

• At the infrastructure, the concern is coming from multiple network entry-points, rate limits and traffic throttling configuration, need for multiple firewalls, defense in depth, network structures and keys and tokens management.
• Ensure regular updates taking note of the following:
• updates must not break the system
• updates should not interrupt the application
• updates must not require full deployments
  

• Keep control 
• never assume infinite scalability 
• rate limits protect from DDoS 
• always test your load
  

• Keep your guard up 
• multiple firewalls 
• minimum exposure (expose only what is needed)
• keep sensitive services private
  

• Keep/protect your keys 
• do not store in the servers 
• encrypt everything 
• use internal and changeable tokens like OAuth
  

• Application concerns
• repeatable deployments 
• encryption algorithms 
• protection methods depending on data types 
• security configuration 
• testing (white, black and penetration)

• Data concerns
• input validation 
• output encoding 
• not obvious ID's 
• end-to-end encryption 
• authentication and authorization even among services

• To mitigate both application and data concerns
• don't make the data structures obvious
• keep IDs out of API endpoints
• it is recommended to use OAuth for authentication and authorization
• usually done in API gateway which enables service discovery
• enables: role based access, access control and signed requests 
• helps with orchestration 
• provides caching layer
  

Reference: Packt's Hands-On Microservices with Python by Peter Fisher

Read More