Forem: Nicolas El Khoury

Orchestrating Microservices on AWS and Docker Swarm - A Comprehensive Tutorial (2)

Nicolas El Khoury — Wed, 23 Aug 2023 05:58:49 +0000

Introduction

Monolithic architecture is a traditional model for designing applications where all components and functions are included in a single element. While monolithic applications are easy to develop and deploy, they become difficult to manage and maintain as the application grows. Microservices architecture, on the other hand, is a collection of smaller, independent, loosely coupled services that may communicate with each other via multiple protocols. Microservices are highly scalable, easy to maintain, and extremely suitable for container-based technologies. They complement cloud solutions and provide fault tolerance. Container orchestration tools are automation technologies that help manage the lifecycle of app containers and microservices architecture at scale. They automate container deployment, management, scaling, and networking, freeing teams from repetitive manual work. Container orchestration tools can be applied in any environment where containers are used. They help deploy the same application across different environments without needing to redesign it. Microservices in containers make it easier to orchestrate services, including storage, networking, and security. Enterprises that need to deploy and manage hundreds or thousands of Linux containers and hosts can benefit from container orchestration.

The first part of this tutorial dived deeper into the aforementioned concepts, and introduced Docker Swarm through an exercise of orchestrating containerized services on a Docker Swarm made of 2 Virtual Machines, on Amazon Web Services.

This article dives deeper into the orchestration of Microservices, and their deployment on Docker Swarm.

NK-Microservices Application

The NK-Microservices project is a basic, and open source application built using Microservices. It serves as a pilot project and/or a reference to be used by anyone who wishes to write software using the Microservices approach. Indeed, Microservices is a software development methodology that is being adopted widely nowadays, especially with the advancement of technology, and the adoption of cloud computing resources._
The project is made of the following components:

Gateway Microservice: A REST API Microservice built using SailsJS, and serves as a Gateway, and request router.
Backend Microservice: A REST API Microservice built using SailsJS, and serves as the first, out of many Microservices which can be incorporated and integrated with the aforementioned Gateway Service.
Redis Database: An open source, in-memory data store, used for caching purposes, and for storing other ephemeral pieces of information such as JWT tokens.
Arango Database: A multi-model database used for storing persistent information.

(Visit the documentation repository for the complete details of the project)

This tutorial concentrates on discussing the deployment of the backend microservices only (i.e., Backend, Gateway services). Enabling HA deployments for databases (i.e., Redis, ArangoDB) requires different strategies, and will be discussed in later articles.

To make the most value from this tutorial, you should be equipped with minimal technical and theoretical knowledge on Containers, Microservices, Cloud Computing, AWS. Readers who do not possess the knowledge above are encouraged to watch this Udemy crash course)

Tutorial 2 - NK-Microservices Application Deployment on Docker Swarm

Problem Statement

This tutorial provides a step-by-step to deploy the NK Microservices application with the following requirements:

Deployment Mode: High Availability - Docker Swarm.
- A Docker Swarm composed of 4 Virtual Machines, configured as such:
  - One Docker Swarm Master VM.
  - Two Docker Swarm Worker VMs, on which the Gateway and Backend Services are deployed.
  - One Docker Swarm Worker VM, on which the Arango and Redis Databases are deployed.
- Operating System: Ubuntu 20.04.
One Application Load Balancer to balance the load across all four VMs.

Expected Output

The application must be fully deployed and running on port 80 using the address: http://<load balancer>:80
The NK-gateway service and NK-backend service must be linked as a target group to the Application Load balancer.
The security group attached to the services machines must enable access on port 80 from the Application Load Balancer.
The security group attached to the load balancer must enable access to port 80 from the internet.
The NK-gateway service and NK-backend service must be deployed as 2 replicas, each on one of the two VMs labeled “Services” strictly.
The Arango and Redis databases must be deployed as one replica each, on the VM labeled “Databases” Strictly.
The Arango database must have a volume configured. Test the validity of the deployment by deleting the container (Not the service). A correct configuration should allow Docker Swarm to re-create a replica of the database, on the machine labeled “***************Databases***************”, and all the data should persist.
The Docker Swarm Master node must not have any container deployed on it.
Communication with the Backend service and the databases must be done internally from within the Docker Network only, and not through the VM IP and external port.

Solution

AWS Resources

SSH Keypair

An SSH Keypair is required to SSH to the Virtual Machines. To create a Keypair:

Navigate to the EC2 service, Key Pairs option from the left menu.
Create a Keypair.
The key will be automatically downloaded. Move it to a hidden directory.
Modify the permissions to read only: chmod 400 .pem

n SSH Key is required to SSH to the Virtual Machines. To create a Keypair:

Navigate to the EC2 service, Key Pairs option from the left menu.
Create a Keypair.
The key will be automatically downloaded. Move it to a hidden directory.
Modify the permissions to read only: chmod 400 <keyName>.pem

Security Group

A security Group is required to control access to the VMs. The ports below will be allowed access from anywhere:

TCP Port 80: To perform requests against the Httpd service.
TCP Port 22: To SSH to the machines.
All TCP and UDP Ports open from within the VPC: Several ports are required for Docker Swarm, which are out of the scope of this article.

In addition, Outbound rules must allow all ports to anywhere. This is essential to provide internet access to the machines.

EC2 Machines

Navigate to AWS EC2 —> Launch instances, with the following parameters:

Name: Docker Swarm Demo
Number of instances: 4
AMI: Ubuntu Server 22.04 LTS (HVM), SSD Volume Type
Instance Type: t3.medium (Or any type of your choice)
Key pair name: docker-swarm-demo
Network Settings:
- Select existing security group: Docker Swarm Demo
Configure storage: 1 x 25 GiB gp2 Root volume

Once the machines are created, rename one of them to Swarm Master, and the others to Swarm Worker - Backend - 1, Swarm Worker - Backend - 2, and Swarm Worker - Databases.

ECR Repositories

Two private ECR Repositories must be created, with the following configuration:

IAM Roles

The machines will be used to pull and push images from and to the private ECR registries. An IAM role with enough permissions must be attached to the created machines. To create a role, navigate to the IAM service --> Roles, and create a role, with the following parameters:

Trusted entity type: AWS Service.
Use case: EC2
Permission Policy: AmazonEC2ContainerRegistryPowerUser
Role Name: docker-swarm-demo

Create the role.

Navigate back to the EC2 instances dashboard. Click on every instance, one by one, then select Actions --> Security --> Modify IAM Role. Select the docker-swarm-demo role. Repeat this step for every VM.

Docker Installation

SSH to each of the four machines, and paste the code block below to install Docker on each of them:

# Update the package index and install the required packages
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# Add Docker’s official GPG key:
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
| sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Set up the repository
echo "deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list \
> /dev/null

# Update the package index again
sudo apt-get update

# Install the latest version of docker
sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
docker-compose-plugin

# Add the Docker user to the existing User's group 
#(to run Docker commands without sudo)
sudo usermod -aG docker $USER

To interact with Docker without sudo privileges, restart the SSH sessions of both machines. Validate the successful installation of Docker, by performing the following three commands on each machine:

docker ps -a
docker images
docker -v

Docker Swarm Configuration

As specified, the purpose is to create a Docker Swarm made of 1 Master node, and 1 Worker node:

SSH to the Master node, and initialize a swarm: docker swarm init --advertise-addr <Private IP>

advertise-addr specifies the address that will be advertised to other members of the swarm for API access and overlay networking. Therefore, it is always better to use the machines' private IPs.

SSH to every Worker node, and join the swarm using the command generated in the Master node: docker swarm join --token SWMTKN-1-210tp2olzm5z0766v71c6e6pmdzrjzz8pnkrw3z4mqj8ocjlbj-5758xx4x3dxib1249tceom6rr <Private IP>:2377
List all the nodes available: docker node ls

Node configuration

Part of the project requirements are as follows:

The Master Node must not host any container.
The databases (ArangoDB, and Redis) must be placed on the database machine only.
The backend services must be placed on the backend machines only.

To make this happen, first, the nodes have to be properly configured. SSH to the Master machine.

Draining the Master node will prevent it from hosting any container. Drain the node: docker node update --availability drain ip-172-31-46-120

Label the remaining machines. The services VMs must be labeled workload=service, and the database VM must be labeled workload=database

docker node update --label-add workload=database ip-172-31-41-113
docker node update --label-add workload=service ip-172-31-40-214
docker node update --label-add workload=service ip-172-31-36-173

Ensure that the labels have been applied correctly by listing the nodes by label:

docker node ls -f node.label=workload=database
docker node ls -f node.label=workload=service

The scenarios below further test the validity of the configuration:

Deploy 5 replicas of the HTTPD service with no constraints. The replicas must be deployed on all the worker VMs, and none on the Master node: docker service create --name myhttpd -p 80:80 --replicas 5 httpd:latest

The picture above clearly shows that all of the replicas have been divided among all the worker nodes and none of them was placed on the master node.

Update the HTTPD service to force the placement of the services on machines labeled workload=service only: docker service update --constraint-add node.labels.workload==service myhttpd

The image above clearly shows how the placement was modified. All the replicas that were on the database node were removed, and replaced by others placed on the service nodes.

Update the HTTPD service to force the placement of the services on machines labeled workload=database only: docker service update --constraint-rm node.labels.workload==service --constraint-add node.labels.workload==database myhttpd

The image above shows how all the replicas are now on the database.

Remove the service: docker service rm myhttpd

NK-Microservices Deployment

Internal Network

An overlay network is needed to allow services to communicate with each other within the swarm: docker network create --driver overlay nk-microservices

ArangoDB

The first component to add is the Arango database. The deployment must respect the following constraints:

The service can run only on the database node.
The service must be reachable from within the Swarm network only.
Data must persist and survive container failures.

Deploy the ArangoDB container: docker service create -d --name person-db --network nk-microservices --replicas 1 --constraint node.labels.workload==database --mount src=arango-volume,dst=/var/lib/arangodb3 -e ARANGO_STORAGE_ENGINE=rocksdb -e ARANGO_ROOT_PASSWORD=openSesame arangodb/arangodb:3.6.3

The command above instructs docker to create a service of 1 replica, attach it to the nk-microservices overlay network, attach the /var/lib/arangodb3 directory to a volume named arango-volume, use openSesame as root password, use the arangodb/arangodb:3.6.3 image, and place the container on the VM labeled workload=database.

The image above clearly shows that the container was created on the database node.

The image above is a screenshot from within the database node. Clearly the volumes and containers are created as they should be.

Redis

The deployment must respect the following constraints:

The service can run only on the database node.
The service must be reachable from within the Swarm network only.

docker service create -d --name redis --network nk-microservices --replicas 1 --constraint node.labels.workload==database redis:6.0.5

The command above instructs docker to create a service of 1 replica, attach it to the nk-microservices overlay network, use the redis:6.0.5 image, and place the container on the VM labeled workload=database.

The images above showcase the proper deployment of Redis

Connection testing

docker service create -d --name client --network nk-microservices --replicas 1 --constraint node.labels.workload==service alpine sleep 3600

The image above shows the correct placement of the client container on one of the service nodes.

SSH to the machine hosting the container, and then obtain a session into the container: docker exec -it client.1.vjhcn1zo86n1vqvr0iortjhe5 sh

Install the curl package: apk add curl

Test the connection to ArangoDB by sending an API request to the ArangoDB hostname (Which is the service name in this case): curl http://person-db:8529/_api/version.

The API request returns a 404 error response. Nonetheless, this indicates that the request from the clients container has successfully reached the ArangoDB container using the overlay network.

To test the connection to redis, install the redis package on the alpine container: apk --update add redis. Then connect to redis using its hostname (The service name in this case): redis-cli -h redis.

The image above shows the successful connection to the Redis service using the overlay network.

Remove the clients service, from the master node: docker service rm redis

Backend Service

As already described, the backend service is a NodeJS service hosted on a public Github Repository. The backend service must be deployed as 2 replicas, and hosted on the service nodes strictly.

Below are the steps that will be done to ensure the proper deployment of the service:

Use the Master node to build and push the container images (A separate machine could be used for this operation, but to avoid using additional resources, we will use the master node).
Create an Image for the backend service, using the existing dockerfile.
Push the image to the ECR.
Create the backend service.
Ensure its proper connectivity to the database.
Validation Tests

Create the Image

Clone the repository on the Master node: git clone https://github.com/devops-beyond-limits/nk-backend-service.git
Navigate into the downloaded repository. A Dockerfile containing all the build steps exist. No modifications are required for this Dockerfile.
Build the image locally: docker build -t backend-service:latest -f Dockerfile .

The image above shows the creation of the image locally.

Push the image to the ECR

To push the image to the ECR, perform the following steps:

Install the AWS CLI: sudo apt install awscli -y
Login to the ECR: aws ecr get-login-password --region eu-central-1 | docker login --username AWS --password-stdin 444208416329.dkr.ecr.eu-central-1.amazonaws.com
Tag the local image to reflect the repository name in the ECR: docker tag backend-service:latest 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-backend-service:latest
Push the Docker image to the ECR: docker push 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-backend-service:latest

(Make sure to modify the region and account name in the commands above)

Create the Backend Service

Create the backend service using this command:

docker service create -d --name nk-backend --network nk-microservices --replicas 2 --constraint node.labels.workload==service --with-registry-auth 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-backend-service:latest

The command above instructs Docker to create 2 replicas of the backend service image, located in the AWS ECR private registry, and hence use the --with-registry-auth flag (To allow the worker machines to authenticate to the ECR), attach the nk-microservices network, and place the replicas on the service machines only.

The picture above shows the correct placement of the containers on the machines.

Validation Tests
To validate the correct deployment of the backend service, perform the following:

Ensure the proper connection to the database, through the service logs: docker service logs nk-backend

The application logs shown in the picture above clearly show the successful connection of the application to the database

Ensure the backend service is reachable from within the overlay network.

To do so, re-create the clients service: docker service create -d --name client --network nk-microservices --replicas 1 --constraint node.labels.workload==service alpine sleep 3600

SSH into the machine hosting the created container, exec inside it, install the curl package, and perform a Health API against the backend service, using its hostname (service name): curl http://nk-backend:1337/health

A successful response indicates the proper configuration of the network.

Delete the client service: docker service rm client

Gateway Service

As already described, the gateway service is a NodeJS service hosted on a public Github Repository. The gateway service must be deployed as 2 replicas, and hosted on the service nodes strictly.

Below are the steps that will be done to ensure the proper deployment of the service:

Use the Master node to build and push the container images (A separate machine could be used for this operation, but to avoid using additional resources, we will use the master node).
Create an Image for the backend service, using the existing dockerfile.
Push the image to the ECR.
Create the backend service.
Validation Tests

Create the Image

Clone the repository on the Master node: git clone https://github.com/devops-beyond-limits/nk-gateway-service.git
Navigate into the downloaded repository. A Dockerfile containing all the build steps exist. Modify the BACKEND_HOST environment variable, to reflect the correct service name of the backend service (nk-backend)
Build the image locally: docker build -t gateway-service:latest -f Dockerfile .

The image above shows the creation of the image locally.

Push the image to the ECR

To push the image to the ECR, perform the following steps:

Login to the ECR: aws ecr get-login-password --region eu-central-1 | docker login --username AWS --password-stdin 444208416329.dkr.ecr.eu-central-1.amazonaws.com
Tag the local image to reflect the repository name in the ECR: docker tag gateway-service:latest 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-gateway-service:latest
Push the Docker image to the ECR: docker push 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-gateway-service:latest

(Make sure to modify the region and account name in the commands above)

Create the Gateway Service

Create the gateway service using this command:

docker service create -d --name nk-gateway --network nk-microservices --replicas 2 --constraint node.labels.workload==service -p 80:1337 --with-registry-auth 444208416329.dkr.ecr.eu-central-1.amazonaws.com/nk-gateway-service:latest

The command above instructs Docker to create 2 replicas of the gateway service image, located in the AWS ECR private registry, and hence use the --with-registry-auth flag (To allow the worker machines to authenticate to the ECR), attach the nk-microservices network, and place the replicas on the service machines only.

The picture above shows the correct placement of the containers on the machines.

Validation Tests

Ensure that the gateway service is up and running, through checking the service logs: docker service logs nk-gateway.
Ensure that the gateway service can be reached from the internet, through any of the four VMs. Perform a health check using each public IP.

The remaining tests can be validated by performing different API tests against the gateway, and monitoring the behavior of the system. To do so, Download an API Client (i.e., Postman), and import the nk-microservices Postman collection

The first API to test is the Create Person API, which attempts to create a person in the database. Make sure to modify the GATEWAY_HOST and GATEWAY_PORT variables with the correct values (of any node).

A correct setup should allow the API to traverse the gateway and backend services, and create a person record in the database.

The image above shows the:

Request/Response of the API in Postman.
The logs in the gateway service.
The logs in the backend service.

The second API to test is the Get All Persons API. This API attempts to fetch all the person records, by performing the following logic:

Attempt to find the records in the Redis database.
If the records are found in Redis, return them to the client.
Else, dispatch the request to the backend service. The backend service will fetch the records, and return them to the gateway service. The gateway service will save the records in Redis, and return the result to the client.

Since this is the first time the API is requested, steps (1) and (3) will be performed.

Hit the API again and monitor the service logs. This time, the request will only reach the gateway service only, and fetch the records from redis.

Load Balancer

The final step is to create a load balancer, to divide the load across all VMs. To do so, Navigate to the EC2 Service --> Load Balancers, and create a load balancer with the following parameters:

Load balancer types: Application Load Balancer
Load balancer name: docker-swarm-demo
Scheme: Internet-facing
IP Address Type: IPv4
VPC: Default
Mappings: Select all Availability Zones (AZs) and subnets per AZ.
Security Group: docker-swarm-demo
Listener: Port 80
Default Action: Create a new Target Group with the following Paramters:
- Choose a target type: Instances
- Target group name: docker-swarm-demo
- Protocol: HTTP
- Port: 80
- VPC: default
- Health check protocol: HTTP
- Health check path: /health (The health check API of the gateway service)
- Include as Pending all the Swarm nodes

Create the target group. Navigate back to the Load Balancer page, and choose the created target group, as a value to the Default action option. Create the load balancer.

After a few minutes, the load balancer will be active, and the target groups will be healthy.

Replace the VM IP with the Load balancer DNS name in Postman, and perform the same API requests. Similar success responses must be returned, indicating the success of the setup.

Low Cost "Overkill" AWS Infrastructure for a Newborn Startup

Nicolas El Khoury — Tue, 28 Mar 2023 17:31:39 +0000

Introduction

On a cold and dark evening in December 2022, a good friend of mine calls me and says: "Nicolas, I am creating a product that is going to scale massively and revolutionize the market, and I need your help". Now, if I had a dollar for every time I heard this sentence, I would be financing trips to Mars by now.

Nevertheless, I met with the friend and his technical lead. After long hours of discussions (and daydreaming), the business model was summarized as follows: "The product is a maintenance management platform designed to help companies and vehicle owners to efficiently manage their vehicles. The product aims to automate the entire maintenance procedure and provide preventive and predictive solutions by connecting vehicles to IoT devices, which allows the monitoring of maintenance parameters in real-time."

I agreed to help them for many reasons, some of which include:

They actually know what they are doing.
The technical lead is absolutely intelligent.
I trust they will make it.

My job, evidently, was to architect and implement the infrastructure, deployment, and maintenance of the application.

Requirements and Challenges

At the time of discussion, they had just finished an MVP that was deployed poorly on AWS. In fact, both my friend and the technical lead have very minimal experience in everything related to infrastructure and DevOps. In addition, they had little money to pay my original fees and therefore did not want to be a big burden on me. So at first, they suggested that I perform a very basic infrastructure and deployment strategy, that they can use temporarily until they raise more money.

The first thought I had was: "Those noobs don't even know what they are talking about". From my experience in consulting with more than two dozen companies (from small startups to extremely large multinationals), once you start working with a bad infrastructure, chances are you will keep building on top of it until working on it becomes a living hell, and then possibly run out of business due to bad tech. I was definitely not going to be part of this scenario

Therefore, my answer was: "No, I will do it properly". So after countless back-and-forth discussions, below is the summary of the challenges to think about while architecting the solution:

There must be at least two environments: Develop and Production.
The developers must be able to operate the infrastructure without having to become DevOps Engineers.
Proper observability must be employed to quickly identify and solve issues when they happen (Because they will happen).
The cost must be as optimized as possible.
And finally, I set a requirement, for my sake primarily: The solution must be robust enough to minimize the number of headaches I have to suffer from in the future.

Understanding the Application

Before actually coming up with the solution, a good approach would be to first understand the different components of the application. Therefore, as a first step, the technical lead was kind enough to explain to me the different components of the application, and how to run it locally.

For simplicity purposes, both the backend (NodeJS) and frontend (ReactJS) applications are designed as a mono repository, managed through NX. The application stores its data in a PostgreSQL database. Surprisingly, the application was very well documented, a phenomenon I have rarely seen in my life. Therefore, understanding the behavior and the build steps of the application wasn't so difficult.

In about three hours, I was able to containerize, deploy, and run all the containerized application components on a single Linux machine. Amazing! First step complete.

Infrastructure Requirements

Now that the application is containerized, and all the steps documented, it is time to architect the infrastructure. Whenever I am architecting a solution, regardless of its complexity and cost, I always make sure to achieve the following characteristics:

Security: One of the most integral parts in any application is security. A robust software is one that prohibits cyber attacks, such as SQL Injection Attacks, Password Attacks, Cross Site Scripting Attacks, etc. Integrating security mechanisms in the code is a mandatory practice to ensure the safety of the system in general, especially the data layer.
Availability: Refers to the probability that a system is running as required, when required, during the time it is supposed to be running. A good practice to achieve availability would be to replicate the system and application as much as possible (e.g., containers, machines, databases, etc).
Scalability: The on-demand provisioning of resources offered by the cloud allows its users to quickly scale-in and scale-out resources based on the varying load. This is absolutely important, especially to optimize the cost, all while serving the traffic consistently.
System Observability: One of the most important mechanisms required to achieve a robust application is system visibility:
1. Logging: Aggregating the application logs and displaying them in an organized fashion allows the developers to test, debug, and enhance the application.
2. Tracing: Tracing the requests is another important practice, allowing to tail every request flowing in and out of the system and rapidly finding and fixing errors and bottlenecks.
3. Monitoring: It is essential to have accurate and reliable monitoring mechanisms in every aspect of the system. Key metrics that must be monitored include but are not limited to CPU utilization, Memory Utilization, Disk Read/Write Operations, Disk space, etc.

Infrastructure Solution

In light of all the above, and after twisting my imagination for a little bit, I came up with the architecture depicted in the diagram below (Does not display all the components used):

Networking

The infrastructure is created in the region of Ireland (eu-west-1). The following network components are created:

Virtual Private Cluster: To isolate the resources in a private network.
Internet Gateway: To provide internet connectivity to the resources in the public subnets.
NAT Gateway: To provide outbound connectivity to private resources.
Public Subnets: In each availability zone.
Private Subnets: In each availability zone.

VPN

A VPN instance with a free license is deployed to provide secure connectivity for the developers and system administrators to the private resources in the VPC.

AWS EKS

An AWS EKS cluster is created to orchestrate the backend service of each environment. The cluster is composed of one node pool made of 2 nodes, each in an Availability zone.

Application Load Balancer

An Application Load Balancer (Layer 7) is created to expose the endpoints and provide the routing rules required from the internet into the application. The load balancer is configured to serve traffic on ports 80 and 443.

AWS RDS PostgreSQL

An AWS RDS PostgreSQL database is created to hold and persist the application’s data. Both the develop and production environments are hosted on the same instance but are separated logically.

Clients VM

A private virtual machine on which client applications are installed, to interact with different parts of the infrastructure (e.g., kubectl, PostgreSQL client, etc).

AWS ECR

Two ECR repositories are created for the backend service, one for each environment.

S3 Bucket

An AWS S3 bucket is created to host the frontend application for each environment.

AWS Cloudfront

An AWS Cloudfront distribution is created to cache the frontend application hosted on AWS S3 of each environment.

ACM

ACM Public certificates are required for the domains. A public certificate must be created in the region of eu-west-1 to be used by the load balancer, and another one in the region of us-east-1, to be used by Cloudfront.

Cloudwatch

The infrastructure metrics and application logs are configured to be displayed on Cloudwatch.

Application Deployment

Now that the infrastructure was successfully architected and created, I proceeded to deploy the containerized backend services and ensured their proper connectivity to the databases. Afterward, the frontend application was built and deployed on S3.

Continuous Delivery Pipelines

The last step before signaling to the team the good news was to automate the build and delivery steps of all the services. Evidently, none of the developers should perform tedious and time-wasting tasks of building and deploying the application everytime there is a change. As a matter of fact, knowing the pace at which the developers are working, I expect they push code to develop 276 million times per day.

Therefore, I used AWS Codebuild and AWS CodePipeline to automate the steps of building and deploying the services. The diagram below depicts all the steps required to continuously deliver the frontend and backend applications:

Conclusion

Once everything is done, I met with the friend and with the technical lead for a handover. They were so pleased with the outcome, stating that the infrastructure is amazing, but is overkill and much more than they need right now.

But in reality, it is not an overkill. As a matter of fact, the product and the team are growing very rapidly. This solution is a skeleton that can be quickly and easily modified and scaled upon need:

Backend services replicas can be easily modified.
The EKS nodes can be easily scaled vertically and horizontally.
The frontend application is on S3, which is automatically scalable.
The database can be easily scaled vertically and horizontally.

After delivering the solution in mid December 2022:

The developers are happy because of the robustness and ease of use of the infrastructure.
My friend is happy because his application is live, and is costing him less than $500 per month.
I am happy because they never called me with a complaint.

Everybody is happy :)))) The end!!

AWS Certified DevOps Engineer Professional: Content Summary and Important Notes

Nicolas El Khoury — Fri, 24 Mar 2023 07:33:01 +0000

Introduction

The AWS DevOps Engineer Professional Certification is a certificate offered by Amazon Web Services (AWS), designed to test your proficiency in deploying, managing, and maintaining distributed applications on AWS using DevOps principles and practices.

In addition, it is a great way to verify your knowledge of industry best practices and enhance your profile and competencies in a competitive job market.

To increase your chances of passing AWS DevOps the exam, it is advised that you have a minimum of two years of experience in designing, setting up, managing, and running AWS environments. In addition, you should have hands-on experience with AWS services such as EC2, S3, RDS, Cloudwatch, CodePipeline, etc, and a good understanding of DevOps principles and practices.

Professional-level certificates are quite different from Associate-level ones. As a matter of fact, they are more difficult, require more professional experience in AWS, more maturity, and a higher level of thought process. In brief, obtaining the AWS DevOps Professional certificate is not a walk in the park.

In addition to that, chances are that you are employed, with a busy life. Therefore, preparing for the certificate is not going to be your full-time job.

In light of all the above, I am writing this article to serve the purposes below:

Summarize the requirements needed to pass the exam.
Summarize Stephane's amazing Udemy course content.
List additional preparation steps.

Definitely, this article does not constitute a single source of truth that will guide you to pass the exam. Nonetheless, it aims to be a summary, and a memory refresher.

Certification Requirements

The AWS DevOps Engineer Professional certification exam evaluates your skills and knowledge in essential areas related to deploying, managing, and operating distributed application systems on the AWS platform by implementing DevOps principles and practices. The exam will test your understanding of several key topics:

SDLC Automation

Continuous delivery and deployment is a process that automates the building, testing, and deployment of software in a smooth and continuous way. This leads to faster delivery of updates and better customer satisfaction. The exam may test your knowledge of AWS tools such as AWS CodePipeline, AWS CodeDeploy, and AWS Elastic Beanstalk.

Configuration Management and IaC

Infrastructure as code (IaC) is a practice that involves automating the deployment and management of infrastructure using code rather than manual processes. This approach enables teams to manage infrastructure more efficiently, reduce errors, and increase agility. The AWS DevOps Engineer Professional certification exam may test your understanding of IaC tools and services such as AWS CloudFormation

Resilient Cloud Solutions

The Resilient Cloud Solutions domain assesses your ability to build and manage systems that are able to cope with potential failures or disasters, including, creating backup and restore strategies, designing for disaster recovery, and managing scaling and elasticity on AWS.

Monitoring and Logging

The exam may assess your skills in designing and implementing effective logging and monitoring systems for AWS services and applications. You may be tested on your ability to identify and troubleshoot issues in these systems and set up alarms and notifications to ensure the efficient operation of the infrastructure.

Incident and Event Response

The exam evaluates your knowledge of incident management and response processes, such as identifying, categorizing, and resolving incidents and implementing and testing disaster recovery plans. You may also be tested on your ability to effectively communicate and collaborate with stakeholders during such incidents.

Security and Compliance

This domain evaluates your understanding of security and compliance best practices for AWS services and applications. This includes topics revolving around implementing security controls, managing access and authentication, and ensuring compliance with regulatory standards. You may also be tested on your knowledge of AWS security services such as AWS IAM and AWS KMS.

Course Summary and Important Notes

An important step in my preparation for the exam is Stephane Maarek's Udemy course. The course is highly interactive, well designed, and contains important information, explained in a simple and clear way.

Nonetheless, the course is (veeeeeery) long. Remembering, therefore, all the important information explained in the course may be quite difficult.

In light of the above, the next section of this article lists and explains most of these important concepts to remember. This article constitutes, in no way, a replacement for the course. Rather, it can be used to refresh your memory, only after having carefully studied the Udemy course.

Important Notes

CodeCommit

Using IAM, you can deny certain users from pushing to master by creating an explicit DENY policy
You can set up notification rules and triggers to either one of SNS or lambda. Examples include the creation or deletion of a repository, branch, Pull Request, etc. You can also configure such events using Cloudwatch Events.

CodeBuild

You can pass environment variables to Codebuild in many ways:
1. In the buildspec file as key-value pairs.
2. In Codebuild using plain-text key-value pairs.
3. In Codebuild or the buildspec file as a secret, using the Systems Manager Parameter Store.

CodeDeploy

There are multiple deployment strategies for EC2's using CodeDeploy:

In-place deployment: Deploy on the existing EC2 machines:
a. AllAtOnce: Deploys on all the existing EC2 machines at the same time.
b. HalfAtOnce: Deploys on half of the existing EC2 machines per batch.
c. OneAtOnce: Deploys on one EC2 machines at a time.
d. Custom Rules: You can specify your own custom rule.
Blue/Green deployment: Provision new instances to deploy the new application version. This deployment requires a new Load balancer. There are two ways to perform such type of deployment:
a. Manually provisioning instances
b. Automatically copy autoscaling groups.

appspec.yml:

The appspec.yml file contains all the necessary information to be processed by CodeDeploy to perform a certain deployment. Below is a sample appspec.yml file:

version: 0.0
os: linux  # The Operating system
files:
  source: /index.html # The location of the file(s) to be copied
  destination: /var/www/html # The location in which the file(s) must be copied to on the servers
hooks: # The list of hooks available for CodeDeploy
  ApplicationStop:
    location: scripts/stop_servers.sh # The location of the script to run when this hook is triggered
    timeout: 300 # The timeout for this hook (in seconds)
    runas: root # The user with which the script will be executed 
  BeforeInstall:
  AfterInstall:
  ApplicationStart:
  ValidateService:

Unlike Codebuild, in order to collect Codedeploy logs and display them in Cloudwatch, the Cloudwatch logs agent must be installed on the machines.
Rollbacks can be done in two ways:
1. Manually
2. Automatic: When a deployment fails, or when a threshold is crossed, using specifically set alarms.
Registering an On-premise instance to CodeDeploy can be done in multiple ways:
1. For a small number of instances: create an IAM user, install the CodeDeploy agent, register the instance using the register-on-premise-instance API
2. For a large number of instances: Use an IAM role and AWS STS to generate credentials
CodePipeline possesses different deployment strategies for lambda function:
1. Canary: Traffic shift in two increments. For example, pass 15% of traffic to the newly deployed version in the first 15 minutes post-deployment, then switch all the traffic to it afterward.
2. Linear: Traffic shifts in equal increments. For example, add 10% of traffic to the newly deployed version every 5 minutes.
3. AllAtOnce: Move all the traffic to the new version at once.

CodePipeline

There are two ways CodePipeline can detect source code changes:
1. Amazon Cloudwatch Events: A change triggers an AWS Cloudwatch Event. This is the preferred way.
2. AWS CodePipeline: Periodically check for changes.
Artifacts:
1. Each stage uploads its artifacts to S3 in order to be used by the later stage.
2. We can use the same S3 bucket for multiple pipelines.
3. Objects can be encrypted using AWS KMS or Customer Managed Keys.

Cloudformation

!Ref can be used to reference parameters or other resources.
Pseudo parameters are variables offered by AWS, for example ACCOUNT_ID, etc.
Mappings are a set of fixed variables

Mappings
  RegionMap:
    us-east-1:
      "32": "id-1"
      "64": "id-2"
    us-west-1:
      "32": "id-3"
      "64": "id-4"
Resources:
  MyEC2: 
    Type: "AWS::EC2::Instance"
    ImageId: !FindinMap [ RegionMap, !Ref "AWS::Region", 32 ] # Returns the ID based on the region in which the script is executed.

Outputs can be exported and used in other stacks
You cannot delete stacks which outputs are referenced by other stacks.
!ImportValue is used to import an output
Conditions: and, equals, if, not, or
!Ref:
1. When used against a parameter, it returns the value of the parameter.
2. When used against a resource, it returns the ID of the resource.
!GetAtt: Returns a specific attribute for any resource. For example:

Type: "AWS::EC2::Volume
Properties:
  AvailabilityZones:
    !GetAtt MyEC2.AvailabilityZone # Retrieves the Availability Zone attribute from the **MyEC2** resource

!FindInMap returns the value of a specific key in a map !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
!ImportValue retrieves the value of an output
!Join [ ":" , [ a, b, c ] ] --> "a🅱️c" joins an array of strings using a delimiter
!Sub substitutes values
UserData can be passed as a property using the Base64 function. The output of the UserData can be found under /var/log/cloud-init-output.log file in Linux
cfn-init is similar to userData, with some differences. cfn-signal and waitConditions are used after cfn-init to signal the status of a userData script.
Troubleshooting steps in case the wait condition did not receive the required signal:
1. Ensure the AWS Cloudformation helper scripts are installed.
2. Verify that cfn-signal and cfn-init commands ran by checking the /var/log/cloud-init.log and /var/log/cfn-init.log files.
3. Verify that the instance has internet connections
4. Note that such troubleshooting cannot be done if rollbacks are enabled.
By default, Cloudformation deletes all the resources after a failure. You can disable rollbacks, but you must make sure you delete all the resources.
Nested stacks are available. Always modify the parent stack, and the changes will propagate to the nested stacks.
Change sets allow you to understand the changes that will be done between two cloudformation stack versions, but it cannot show if it works or not.
Cloudformation has many deletion policies for resources:
1. Retain: does not delete the resource when deleting the stack
2. Snapshot: works on some resources, such as RDS.
3. Delete.
You can protect a stack from being deleted by enabling the deletion protection policy.
Cloudformation parameters can be fetched from SSM parameters. It is a good practice to store global parameters, such as AMI IDs. Cloudformation is able to detect changes to such parameters and perform necessary updates when needed.
DependsOn is used to create dependencies between resources.
Lambda functions can be deployed through Cloudformation in many ways:
1. Write the function inline in the Cloudformation script.
2. Upload the code in a zipped file to S3 and reference it in the Cloudformation script.
Lambda changes can be detected by Cloudformation in many ways:
1. Upload the code to a new bucket.
2. Upload the code to a new key in the same bucket.
3. Upload to a new versioned bucket and reference the version in the Cloudformation script.
Cloudformation cannot delete a bucket unless it is empty.
Use cases for Cloudformation custom resources:
1. Resource still not covered by Cloudformation
2. Adding an on-premise instance
3. Emptying an S3 bucket before deletion
4. Fetch AMI ID
Cloudformation drift detection is a tools that checks if the current resources that were created by Cloudformation were modified or not.
Cloudformation Status Codes:
1. CREATE_IN_PROGRESS
2. CREATE_COMPLETE
3. CREATE_FAILED
4. DELETE_IN_PROGRESS
5. DELETE_COMPLETE
6. DELETE_FAILED
7. ROLLBACK_COMPLETE
8. ROLLBACK_IN_PROGRESS
9. ROLLBACK_FAILED
10. UPDATE_COMPLETE
11. UPDATE_COMPLETE_CLEANUP_PROGRESS: when the update is complete but still cleaning up old resources
12. UPDATE_ROLLBACK_COMPLETE
13. UPDATE_ROLLBACK_IN_PROGRESS
14. UPDATE_ROLLBACK_FAILED
Potential causes for UPDATE_ROLLBACK_FAILED:
1. Insufficient permissions
2. Invalid credentials for Cloudformation
3. Limitation error
4. Changes done to the resources outside Cloudformation
5. Resources not in a stable state yet
INSUFFICIENT_CAPABILITIES_EXCEPTION: Cloudformation requires the CAPABILITY_IAM permission to create IAM resources.
Stack policies is a JSON object that specifies allow/deny rules for updates on resources in the Cloudformation script.

Elastic Beanstalk

Important CLI commands:

eb status: display information about the application.
eb logs: Display the application logs
eb deploy: Updates the application with a new version
eb terminate: Terminates the environment
There are two ways to modify elastic beanstalk configuration:

Saved Configurations:
a. eb config save <env name> --cfg <configuration name> --> saves a configuration of an environment locallly.
b. eb setenv KEY=VALUE --> Creates an environment variable in elastic beanstalk
c. eb config put <configuration file name> --> Uploads a configuration file to elastic beanstalk saved config
d. eb config <env name> --cfg <config name> applies a configuration to an elastic beanstalk environment
YML config files under .ebextensions. After the configuration is added, it can be applied using the eb deploy command

Configuration precedence is as follows:

Settings applied directly on an environment
Saved configurations
Configuration files (.ebextensions)
default values

Using the .ebextensions files, we can upload configuration files with additional resources added to the environment (e.g., RDS, DynamoDB, etc).
A database or resource that must outlive the ElasticBeanstalk environment must be created externally, and referenced in ElasticBeanstalk through environment variables for example.
Commands and Container Commands for .ebextensions:
1. Commands: Execute commands on EC2 machines. The commands run before the application and webserver are set up.
2. Conatainer commands: Execute commands that affect the application. Runs after the application and webserver are set up, but before the application is deployed. leader_only flag runs the command on a single machine only.
Important ElasticBeanstalk features:
1. When creating a webserver environment, there are two configuration presets: a. Low Cost: Creates a single instance with EIP. Good for testing. b. High Availability: Creates a ELB and autoscaling group. Good for production
Application versions are saved under the Application Versions section, limited to 1000 versions. We can create lifecycle policies to manage these versions.
Clone Environment is a quick way to create a new environment from an existing one.
Deployment Modes:
1. AllAtOnce: Fastest way, but brings all the instances down.
2. Rolling: Updates a subset of instances at a time.
3. Rolling with Additional Batches: Similar to Rolling but creates new instances for each batch.
4. Immutable: New instances created in a new Autoscaling Group, deploys the new version, and swaps environments when all is done
5. Blue/Green: can be achieved by having two environments, and then either swapping URLs, or creating weighted records using Route 53 records.
Worker Environment: is dedicated for long running background jobs (e.g., video processing, sending emails, etc). This environment creates SQS queues by default. Cron jobs can be specified in the cron.yml file.

Lambda

We can store environment variables in Lambda in 3 ways:
1. Stored as plaintext.
2. Stored as encrypted. Lambda needs enough permissions, and a KMS key to encrypt/decrypt the variable.
3. Stored as a parameters in SSM. Lambda needs to have enough permissions to fetch the secret.
By default, lambda uses the latest version, which is mutable. We can create versions, which are immutable. Each version will have its own ARN. Aliases can be created to point out to versions. In this way, we can preserve the same alias ARN, but change the underlying lambda version.
Serverless Application Model (SAM) allows us to create, manage, and test lambda functions locally, as well as uploading the functions to AWS.
Using SAM, we can create CodeDeploy projects to continuously deploy code.
Step function is a workflow management tool that coordinates the work between several lambda functions.

API Gateway

Two protocols available: REST and Websocket.
Endpoint type can be:
1. Regional: In one region
2. Edge Optimized: Across all regions
3. Private: Accessed within a VPC internally
API Gateway + Lambda proxy: The gateway can point to an alias for a lambda function, which allows us to do canary or blue/green deployments.
API Gateway Stages: Changes must be deployed in order to take effect. Stages are used to divide between environments (dev, test, prod). Stages can be rolled back, and possess a deployment history.
Stage variables are like environment variables but for the API gateway. Use cases include:
1. Configure HTTP endpoints with stages programmatically.
2. Pass parameters to lambda through mapping templates.
Canary deployment can be achieved in two ways across the API gateway:
1. From the canary deployment feature of the API gateway
2. Linking the stage to a lambda alias, and perform canary deployment on the lambda functions.
API gateway gas a limit of 10000 requests per second across all APIs in an AWS account.
You can add throttling or usage plans to limit API usage across many levels: lambda, stage, or API gateway levels.
You can also front a step function with API gateway. The response would be the ARN of the step function, since the API gateway does not wait for a response from the step function.

ECS

Task Definition: JSON document that contains information on how to run a container (e.g., container image, port, memory limit, etc).
Tasks need task roles to interact with other AWS resources.
If the host port is specified to be "0", a random port will be assigned.
ECR is the AWS container registry. If unable to interact with it, check the IAM permissions.
Fargate is the serverless ECS service. Using Fargate, we only need to deal with containers.
You can run Elastic Beanstalk environments in container mode:
1. Single Container Mode: One container per EC2.
2. Multi Container Mode: Multiple containers per EC2.
ecsInstanceRole: roles attached to the EC2 instances to pull images and other managerial stuff.
ecsTaskRole: roles for the container to interact with other AWS services.
Fargate does not have ecsInstanceRoles.
For ECS classic, autoscaling policies for the instances and autoscaling policies for the tasks are two different things.
The containers in ECS can be configured to send logs to Cloudwatch from their task definition.
The EC2 instances need the cloudwatch agent to be installed and configured on the VMs.
Cloudwatch metrics supports metrics for:
1. the ECS cluster
2. the ECS service (not per container).
3. ContainerInsights (per container). This option must be enabled and costs additional money.
CodeDeploy can be used to do Blue/Green deployment on ECS.

OpsWorks Stacks

It is the AWS alternative for Chef
There are 5 lifecycle events:
1. Setup: After the instance has finished booting
2. Configure: Instance enter or leave | Add/remove EIP | add/remove ALB
3. deploy: deploys an app
4. undeploy: undeploys an app
5. shutdown: right before the instance is terminated

Each event can have its own recipe.

Autohealing feature stops and restarts EC2 instances. An instance is considered down if the OpsWorks agent on it cannot reach the service for a period of 5 minutes.

Cloudtrail

Logs every API made to AWS
Logs can be sent to either S3 or Cloudwatch logs
Log files on S3 are by default encrypted using SSE-S3
Log files contain info: what is the call, who made it, to who, what is the response?
We can verify the integrity of cloudwatch files using the command: aws cloudtrail validate-logs.
We can aggregate cloutrail trails from multiple accounts:
1. Configure a trail in each account to send logs to a centralized S3 bucket in one account. Modify the S3 bucket permissions to allow objects to be pushed from all these accounts.

Amazon Kinesis

Amazon Kinesis Limits:
1. 1 MB/s or 1000 messages/s at write per shard or else we will receive a "ProvisionThrougputException"
2. 2 MB/s at read per shard across all consumers
3. Data retention of 1 day by default. Can be extended to 7 days
Producers can be: Kinesis SDK, Cloudwatch logs, 3rd party
Consumers can be: Kinesis SDK, Firehose, Lambda
Kinesis Data Streams vs FireHose:
1. Kinesis Data Streams: Requires custom code, realtime, users manage scaling using shards, data storage up to 7 days, used with lambda for realtime data
2. Firehose: fully managed, data transformation with lambda, Near realtime (±60 seconds), automated scaling, No data storage
Serverless realtime analytics can be done using queries on Kinesis data streams using SQL. New streams can be created using these queries.

Cloudwatch

Cloudwatch Metrics classic provides one data point per minute. Detailed monitoring can be enabled and provides one data point per second
To add custom metrics, use the put-metric-data API. A metric can be of:
1. Standard resolution: 1 minute granularity
2. High resolution: 1 second granularity
The get-metric-statistics API can be used to get the data of a metric. We can automate this to export the metrics to S3.
Cloudwatch alarms can accommodate for one metrics per alarm.
Alarm actions can be SNS notication, Autoscaling action, EC2 action
Billing alarms can be created in North Virginia only.
The unified Cloudwatch agent can be installed to collect logs and metrics from EC2 and on-premise instances.
You can create a metric from filtered logs and then create an alarm out of them.
You can export log data to S3, The bucket must have enough permissions. This can be automated using cloudwatch events and lambda.
Realtime processing of logs can be done using subscriptions, and having the logs delivered to Kinesis Streams, Data Firehose, or lambda.
S3 events can send notifications to SNS, SQS, and lambda (object level only).
Cloudwatch events has bucket and object level events.

Amazon X-Ray

An AWS service that allows API tracing, and service maps.

Amazin ElasticSearch (ES)

AWS managed Elastic Search, Logstash, and Kibana.

AWS Systems Manager (SSM)

Manages EC2 and on-premise instances, such as applying patch management, maintenance, automation, etc.
Either the AMI has the SSM agent installed or we have to install it manually before registering an instance to SSM.
If SSM is not working, it may be a problem with either the agent or the permissions.
The ID of EC2 instances registered with SSM start with "i-", while those of on-premise instances start with "mi-".
To register an on-premise instance:
1. Download the SSM agent on the instance.
2. Create an activation key
3. Register the instance using the CLI, activation ID and activation key.
SSM run command is used to configure something on a bunch of machines.
SSM Parameter store: Stores key value pairs. It is better to store the name of a variable as a path, since we can query one or more parameters using paths.
SSM patch manager: Creates patch rules for different operating systems
SSM Inventory: Collects applications running on our instances.
SSM automations: Allows the automation of a lot of steps. For instance: Create a VM, patch it, create a new AMI, delete old VM.

AWS Config

Tracks configuration changes for resources in our account.
Config rules allow to track the compliance of specific resources agains this rule.
Multi account and multi region can be aggregated into a single config account.

AWS Service catalog

Create and manage a suite of products.
Each product is a cloudformation template.
Each set of products is assigned to a portfolio.
Each user can be assigned to a portfolio.
Users can only manage products in their catalogs.

AWS Inspector

Continuously scans EC2 and ECR for vulnerabilities

AWS Service Health dashboard

Displays the health of every AWS service in every region

AWS Personal Health dashboard

Health of services related to you. Notifications can be set using cloudwatch events.

AWS Trusted Advisor

Provides recommendations related to cost optimization, performance, security, fault tolerance, and service limits. You can refresh the recommendations:

Using the refresh button in the console (Once every 5 minutes).
Using the refresh-trusted-advisor-check API

AWS Guardduty

An intelligent threat detection system to protect AWS accounts. No need to install anything.
Performs checks on: Cloudtrail logs, VPC flow logs, DNS queries. Can be integrated with Lambda and Cloudwatch events.

AWS Secrets Managers

Similar service to SSM parameter store. Specialized in managing and rotating secrets. The secrets can be integrated with Lambda and managed databases.

AWS Cost Allocation tags

Can be either AWS generated or user-defined. These tags are used for budget and reports by tags.

Autoscaling Groups - revisited

Launch Configuration: Specifies metadata to be used when creating Autoscaling Groups.
Launch Template: Specifies metadata to be used by Autoscaling groups, EC2, and other options. Supports a mix of on-demand and spot instances. Overall, it is a better option than Launch configurations.
Autoscaling Group Suspended Processes: Processes to suspend (for troubleshooting purposes)
1. Launch: Does not add new instances.
2. Terminate: Does not remove instances.
3. Healthchecks: No more healthchecks. The states of the machines are no longer changes.
4. replaceUnhealthy: Bad instances are no longer replaced.
5. AZRebalance: No longer rebalances instances across Availability Zones.
6. Alarm Notifications: No longer answers to alarms, including scaling alarms.
7. Scheduled Actions
8. Add to Load Balancer: Instances that are created are no longer added to the Target Group.
Scaling in can be disabled on specific instances of the Autoscaling group. This means the instance never gets terminated.
Autoscaling Groups Termination Policies: Determine which instances are terminated first:
1. Default: Check for the Availability Zone with the largest number of instances, and terminate one instance. Finally, terminate the instance with the oldest launch configuration.
2. Oldest Instance.
3. OldestLaunchConfiguration
4. NewestInstance
5. NewestLaunchConfiguration
6. ClosestToNextInstanceHour
7. OldestLaunchTemplate
8. AllocationStrategy
Integrating SQS with ASG: Autoscaling Groups can be integrated with SQS, by specifying the number of SQS messages per instance, and use it as a scaling policy for the ASG. To prevent VMs that are processing requests from being deleted, we can create a script that enables deletion protection on an instance, and then disables it when the VM is not processing any messages.
ASG Deployment Strategies:
1. in-place: Deployment on the same VM.
2. Rolling Update: Creates a new instance with the new version.
3. Replace: Creates a new autoscaling group.
4. Blue/Green: Creates a new ASG and ALB. We might need to shift traffic using route 53.

DynamoDB

When creating a table, it is mandatory to either create a unique partition key, or composite key(partition key and sort key).
Local Secondary Indexes can be created at table creation only. They are composite key formed of the same partition key as that of the table, but different sort key.
Global Secondary Indexes is when the primary key is different than that of the partition. It can be created and managed after table creation.
DAX clusters are a form of caching for DynamoDB.
DynamoDB Streams are used for realtime operations on the table.
To enable global tables, streams must be enabled, and the table must be empty. Global tables are replica tables in different regions.

Disaster Recovery

Recovery Point Objective (RPO): How much data is lost between a disaster and a successful backup.
Recovery Time Objective (RTO): How much time it takes to recover.
Disaster Recovery Strategies:
1. Backup and Restore: High RTO and RPO, but cost is low.
2. Pilot Light: Small version of the application is always running in the cloud. Lower RTO and RPO and managed cost.
3. Warm Standby: Full system is up and running but at minimum size. More costly, but even lower RTO and RPO.
4. Multisite / Hot Site: Full production scale on AWS and on-premise.

Additional Information

Below is a list of information gathered from different sources online, including, but not limited to, AWS tutorials and posts, AWS Documentation, forums, etc:

AWS Trusted Advisor is integrated with Cloudwatch Metrics and Events. You can use Cloudwatch to monitor the results generated by Trusted Advisor, create alarms, and react to status changes.
CodePipeline can be integrated with Cloudformation in order to create continuous delivery pipelines to create and update stacks. Input parameters, parameter overrides, and mappings can be used to ensure a generic template which inputs vary based on the environment.
The AWS Application Discovery Service helps plan a migration to the AWS Cloud from On-premise servers. Whenever we want to migrate application from on-premise servers to AWS, it is best to use this service. The discovery service can be installed on the on-premise servers in two ways:
1. Agentless discovery, works VMWare environments only, through deploying a connector to the VMware vCenter.
2. Agent-based discovery, through deploying the Application Discovery agent on the VM (Windows or Linux). The service collects static information, such as CPU, RAM, hostname, IP, etc. Finally, the service integrates with the AWS Migration Hub, which simplifies the migration tracking.
AWS Config allows you to Evaluate AWS resources against desired settings, retrieve (current and historical) configuration of resources in the account, and relationship between resources. AWS Config aggregators allow the collection of compliance data from multiple regions, multiple accounts, or accounts within an organization. Therefore, when you need to retrieve compliance information across regions, accounts or organizations, use AWS Config rules with aggregators.
Lambda functions can be used to validate part of the deployment on ECS. In this case, CodeDeploy can be configured to use a load balancer with two target groups, for test and production environments for example. Tests should be performed in either BeforeAllowTestTraffic or AfterAllowTestTraffic hooks.
While Canary Deployment is automatically supported in CodePipeline while deploying to lambda, it cannot be done for application in autoscaling groups. In order to do Canary deployments in autoscaling groups, we need to have two environments, and the traffic percentage is controlled by Route 53 for example.
AWS proactively monitors popular repository websites for exposed AWS credentials. Once found, AWS generates an AWS_RISK_CREDENTIALS_EXPOSED event in Cloudwatch events, with which an administrator can interact. aws.health can be used as an event source.
Cloudtrail can log management events, for example logging in, creating resources, etc, and data events, such as object level operarions.
When performing updates in an Autoscaling group, you can do a ReplacingUpdate by setting the AutoScalingReplacingUpdate and WillReplace flag to true, which will create a new autoscaling group, or a rolling update using the AutoScalingRollingUpdate property, which will only create new EC2 machines within the same ASG.
AWS Config is not capable of tracking any changes or maintenance initiated by AWS. AWS Health can do so.
Subscriptions can be used to access a real time feed of logs, and have it sent for other services for processing.
Amazon Macie is a security tool that uses ML to protect sensitive data in AWS (S3 in particular)
If you have a set of EC2 machines in an ASG, and some of the machines are terminating with no clear cause. You can add a lifecycle hook to the ASG, to move the instance in terminating state to Terminating:Wait state. Then you can configure Systems Manager Automation document to collect the logs of the machine.

Practice Exams

In addition to Stephane's course, a good approach would be to solve a few practice exams. This will familiarize you with the nature of questions to be expected on the exam.

As a matter of fact, studying the course alone is not a guarantee to pass the exam. The exam's questions are mostly use cases that require strong analytical skills, in addition to a good experience in providing DevOps solutions on AWS.

Jon Bonso's Practice tests are a great way to further apply the knowledge you learned, and better prepare for the exam. Two things make Jon's practice tests a must have:

They are close to the AWS exams, giving you a great overview on what to expect.
There is a great explanation to each use case. Jon explains in great detail each question, along with the correct choice of answers.

In addition, AWS posts sample questions with explanations.

Finally, AWS SkillBuilder posts a free set of sample exam questions for its users.

Conclusion

In conclusion, the AWS DevOps exam is a great way of testing your DevOps skills on AWS. However, achieving this certificate is not a walk in the park, and requires a lot experience, as well as preparation. Nonetheless, it is absolutely worth it!!

Best of luck!

Web Application Deployment on AWS

Nicolas El Khoury — Mon, 19 Dec 2022 07:09:30 +0000

Introduction

With the rapid evolution of the software industry in general, developing and deploying web applications is not as easy as writing the code and deploying it on remote servers. Today’s software development lifecycle necessitates the collaboration of different teams (e.g., developers, designers, managers, system administrators, etc), working on different tools and technologies to serve the challenging application requirements in an organized and optimized matter. Such collaboration may prove to be extremely complex and costly if not properly managed.

This tutorial provides an introduction to Web Applications and the different Infrastructure Types. To put the information provided into good use, a demo is applied on Amazon Web Services.

Moreover, multiple infrastructure types exist to deploy and serve these web applications. Each option possesses its advantages, disadvantages, and use cases.

This tutorial comprises a theoretical part, which aims to list and describe different concepts related to web applications and infrastructure types, followed by a practical part to apply and make sense of the information discussed.

What is Everything and Why

Websites vs Web Applications

By definition, websites are a set of interconnected documents, images, videos, or any other piece of information, developed usually using HTML, CSS, and Javascript. User interaction with websites is limited to the user fetching the website’s information only. Moreover, websites are usually stateless, and thus requests from different users yield the same results at all times. Examples of websites include but are not limited to company websites, blogs, news websites, etc.

Web applications on the other hand are more complex than websites and offer more functionalities to the user. Google, Facebook, Instagram, Online gaming, and e-commerce are all examples of web applications. Such applications allow the user to interact with them in different ways, such as creating accounts, playing games, buying and selling goods, etc. In order to provide such complex functionalities, the architecture of the web application can prove to be much more complex than that of a website.

A web application is divided into three layers. More layers can be added to the application design, but for simplicity purposes, this tutorial focuses on only three:

Presentation Layer: Also known as the client side. The client applications are designed for displaying the application information and for user interaction. Frontend applications are developed using many technologies: AngularJS, ReactJS, VueJS, etc.
Application (Business Logic) Layer: is part of the application’s server side. It accepts and processes user requests, and interacts with the databases for data modification. Such applications can be developed using NodeJS, Python, PHP, Java, etc.
Database Layer: This is where all the data resides and is persisted.

Example Deployment on AWS

The diagram above displays an example deployment of a web application on AWS, and how users can interact with it:

A database is deployed and served using AWS’ managed database service (e.g., AWS RDS). As a best practice, it is recommended not to expose the database to the Internet directly, and to properly secure the access.
The backend application is deployed on a server with a public IP.
The frontend application is deployed and served on AWS S3.
All the application components reside within an AWS VPC in a region.

A typical HTTP request/response cycle could be as follows:

The client sends an HTTP request to the front-end application.
The frontend application code is returned and loaded on the client’s browser.
The client sends an API call through the frontend application, to the backend application.
The backend application validates and processes the requests.
The backend application communicates with the database for managing the data related to the request.
The backend application sends an HTTP response containing the information requested by the client.

Web Application Components

As discussed, a website is composed of a simple application, developed entirely using HTML, CSS, and Javascript. On the other hand, web applications are more complex and are made of different components. In its simplest form, a web application is composed of:

Frontend Application.
Backend Application.
Database.

The components above are essential to creating web applications. However, the latter may require additional components to serve more complex functionalities:

In memory database: For caching.
Message bus: For asynchronous communication.
Content Delivery Network: For serving and caching static content.
Workflow Management Platform: For organizing processes.

As the application’s use case grows in size and complexity, so will the underlying web application. Therefore, a proper way to architect and organize the application is needed. Below is a diagram representing the architecture of a web application deployed on AWS.

Infrastructure Types

The diagram above lists different infrastructure options for deploying and managing applications.

Physical Servers

In this type of infrastructure, hardware resources would have to be purchased, configured, and managed in a physical location (e.g., a datacenter). Once configured, and an operating system is installed, applications can be deployed on them. The correct configuration and management of the servers and applications must be ensured throughout their lifecycle.

Advantages

Ownership and Customization: Full control over the server and application.
Performance: Full dedication of server resources to the applications.

Disadvantages

Large CAPEX and OPEX: Setting up the required infrastructure components may require a large upfront investment, in addition to another one for maintaining the resources.
Management overhead: to continuously support and manage the resources.
Lack of scalability: Modifying the compute resources is not intuitive, and requires time, and complicated labor work.
Resource Mismanagement: Due to the lack of scalability.
Improper isolation between applications: All the applications deployed on the same physical host share all the host’s resources together.
Performance Degradation over time: Hardware components will fail over time.

Virtual Machines

One of the best practices when deploying web applications is to isolate the application components on dedicated environments and resources. Consider an application composed of the following components:

A MySQL database.
A NodeJS backend API service.
A Dotnet backend consumer service.
A ReactJS frontend application.
RabbitMQ.

Typically, each of these components must be properly installed and configured on the server, with enough resources available. Deploying and managing such an application on physical servers becomes cumbersome, especially at scale:

Deploying all the components on one physical server may pose several risks:
- Improper isolation for each application component.
- Race conditions, deadlocks, and resource overconsumption by components.
- The server represents a single point of failure.
Deploying the components on multiple physical servers is not an intuitive approach due to the disadvantages listed above, especially those related to cost and lack of scalability.

Virtual Machines represent the digitized version of the physical servers. Hypervisors (e.g., Oracle VirtualBox, Hyper-v, and VMWare) are software solutions that allow the creation and management of one or more Virtual Machines on one Physical Server. Different VMs with different flavors can be created and configured on the same physical host. For instance, one physical server may host three different VMs with the following specs:

VM1 —> 1 vCPU —> 2 GB RAM —> 20 GB SSD —> Ubuntu 18.04.
VM2 —> 2 vCPU —> 4 GB RAM —> 50 GB SSD —> Windows 10.
VM3 —> 4 vCPU —> 3 GB RAM —> 30 GB SSD —> MAC OS.

Each virtual machine possesses its dedicated resources and can be managed separately from the other ones.

Advantages

Low Capital Expenditure: No need to buy and manage hardware components.
Flexibility: The ability to quickly create, destroy, and manage different VM sizes with different flavors.
Disaster Recovery: Most VM vendors are shipped with solid backup and recovery mechanisms for the virtual machines.
Reduced risk of resource misuse (over and under-provisioning).
Proper environment isolation: for application components.

Disadvantages

Performance issues: Virtual machines have an extra level of virtualization before accessing the computing resources, rendering them less performant than the physical machines.
Security issues: Multiple VMs share the compute resources of the underlying host. Without proper security mechanisms, this may pose a huge security risk for the data in each VM.
Increased overhead and resource consumption: Virtualization includes the Operating System. As the number of VMs placed on a host, more resources are wasted as overhead to manage each VM's requirements.

Containers

While Virtual Machines virtualize the underlying hardware, containerization is another form of virtualization, but for the Operating System only. The diagram above visualizes containers. Container Engines (e.g., Docker), are software applications that allow the creation of lightweight environments containing only the application, and the required binaries for it to run on the underlying server. All the containers on a single machine share the system resources and the operating system, making containers a much more lightweight solution than virtual machines in general. A container engine, deployed on the server (whether physical or virtual), takes care of the creation and management of Containers on the server (Similar function to hypervisors and VMs)

Advantages

Decreased Overhead: Containers require fewer resources than VMs, especially since virtualization does not include the Operating System.
Portability: Container Images are highly portable, and can be easily deployed on different platforms; a Docker image can be deployed on any Container Engine that supports it (e.g., Docker, Kubernetes, AWS ECS, AWS EKS, Microsoft AKS, Google Kubernetes Engine, etc).
Faster build and release cycles: Containers, due to their nature, enhance the Software development lifecycle, from development to continuous delivery of software changes.

Disadvantages

Data Persistence: Containers, although support data persistence, through different mechanisms, is still considered a bad solution for applications that require persistent data (e.g., stateful applications, databases, etc). Up until today, it is not advised to deploy such applications as containers.
Cross-Platform incompatibility: Containers designed to work on one platform, will not work on other platforms. For instance, Linux containers do not work on Windows Operating Systems and vice versa.

Serverless

Serverless solutions (e.g., AWS Lambda Functions, Microsoft Azure Functions, Google Functions), mainly designed by cloud providers not long ago, are also becoming greatly popular nowadays. Despite the name, serverless architectures are not really without servers. Rather, solution providers went deeper into the virtualization, removing the need the focus on anything but writing the application code. The code is packaged and deployed into specialized “functions” that take care of managing and running it. Serverless solutions paved the way for new concepts, especially Function as a service (FaaS), which promotes the creation and deployment of a single function per serverless application (e.g., one function to send verification emails, as soon as a new user is created).

The diagram showcases the architecture of serverless solutions. Application code is packaged and uploaded to a function, which represents a virtualized environment that is completely taken care of by the provider.

Serverless architecture, although alleviate a lot of challenges presented by the previous three infrastructure types, is still unable to replace any of them due to its many limitations. Serverless architectures do not meet the requirements of all use cases and therefore work best in conjunction with other infrastructure types.

Most serverless solutions are offered by providers, rather than being a solution that can be deployed and managed by anyone, thus making it a less favored solution.

Advantages

Cost: Users only pay for the resources consumed during the time of execution. Idle functions generally do not use any resources, and therefore the cost of operation is greatly reduced (as opposed to paying for a server that is barely used).
Scalability: Serverless models are highly scalable by design, and do not require the intervention of the user.
Faster build and release cycles: Developers only need to focus on writing code and uploading it to a readily available infrastructure.

Disadvantages

Security: The application code and data are handled by third-party providers. Therefore, security measures are all outsourced to the managing provider. The security concerns are some of the biggest for users of this serverless model, especially when it comes to sensitive applications that have strict security requirements.
Privacy: The application code and data are executed on shared environments with application codes, which poses huge privacy (and security) concerns.
Vendor Lock-in: Serverless solutions are generally offered by third-party providers (e.g., AWS, Microsoft, Google, etc). Each of these solutions is tailored to the providers’ interests. For instance, a function deployed on AWS Lambda functions may not necessarily work on Azure functions without code modifications. Excessive use and dependence on a provider may lead to serious issues of vendor lock-ins, especially as the application grows.
Complex Troubleshooting: In contrast with the ease of use and deployment of the code, troubleshooting and debugging the applications are not straightforward. Serverless models do not provide access whatsoever to the underlying infrastructure and provide their generic troubleshooting tools, which may not always be enough.

Docker

Docker is a containerization software that aids in simplifying the workflow, by enabling portable and consistent applications that can be deployed rapidly anywhere, thus allowing software development teams to operate the application in a more optimized way.

Container Images

A container image is nothing but a snapshot of the desired environment. For instance, a sample image may contain a MySQL database, NGINX, or a customized NodeJS RESTful service. A Docker image is a snapshot of an isolated environment, usually created by a maintainer, and can be stored in a Container Repository.

Containers

A container is the running version of an image. A container cannot exist without an image. A container uses an image as a starting point for that process.

Container Registries

A container registry is a service to store and maintain images. Container registries can be either public, allowing any user to download the public images, or private, requiring user authentication to manage the images. Examples of Container Registries include but are not limited to: Docker Hub, Amazon Elastic Container Registry (ECR), and Microsoft Azure Container Registry.

Dockerfiles

A Dockerfile is a text document, interpreted by Docker, and contains all the commands required to build a certain Docker image. A Dockerfile holds all the required commands and allows for the creation of the resulting image using one build command only.

Knowledge Application

To better understand the difference between the concepts above, this tutorial will perform the following:

Creation of the networking and compute resources on AWS
Deployment of a simple application on an AWS EC2 machine
Containerization of the application
Deployment of the containerized application on an AWS EC2 machine

AWS Infrastructure

The infrastructure resources will be deployed in the region of Ireland (eu-west-1), in the default VPC.

Security Group

A Security group allowing inbound connection from anywhere to ports 22, and 80 is needed. To create such a security group, navigate to AWS EC2 —> Security Groups —> Create security group, with the following parameters:

Security group name: aws-demo
Description: Allows inbound connections to ports 22 and 80 from anywhere
VPC: default VPC
Inbound rules:
- Rule1:
  - Type: SSH
  - Source: Anywhere-IPv4
- Rule2:
  - Type: HTTP
  - Source: Anywhere-IPv4

Key pair

An SSH key pair is required to SSH to Linux EC2 instances. To create a key-pair, navigate to AWS EC2 —> Key pairs —> Create key pair, with the following parameters:

Name: aws-demo
Private key file format: .pem

Once created, the private key is downloaded to your machine. For it to properly work, the key must be moved to a hidden directory, and its permissions modified (the commands below work on Mac OS. The commands may be different for other operating systems).



# Create a hidden directory
mkdir ~/.keypairs/aws-demo
# Move the key to the created directory
mv ~/Downloads/aws-demo.pem ~/.keypairs/aws-demo/
# Change the permissions of the key
sudo chmod 400 ~/.keypairs/aws-demo/aws-demo.pem

IAM Role

An IAM role contains policies and permissions granting access to actions and resources in AWS. The IAM role is assigned to an AWS resource (in this case the EC2 machine). To create an IAM role, navigate to IAM —> Roles —> Create Role, with the following paramters:

*Trusted entity type:* AWS Service
Common use cases: EC2
Permissions policies: AdministratorAccess
Role Name: aws-demo

Create Role. This role will be assigned to the EC2 machine during creation.

AWS EC2 Machine

An AWS EC2 machines, with Ubuntu 20.04 is required. To create the EC2 machine, navigate to AWS EC2 —> instances —> Launch instances, with the following parameters:

Name: aws-demo
AMI: Ubuntu Server 20.04 LTS (HVM), SSD Volume Type
Instance Type: t3.medium (t3.micro can be used for free tier, but may suffer from performance issues)
Key pair name: aws-demo
Network Settings:
- Select existing security group: aws-demo
Configure storage: 1 x 25 GiB gp2 Root volume
Advanced details:
- IAM instance profile: aws-demo

Leave the rest as defaults and launch the instance

An EC2 VM is created, and is assigned both a private and a public IPv4 addresses.

In addition, the security group created is attached correctly to the machine. Telnet is one way to ensure the machine is accessible on ports 22 and 80:



# Make sure to replace the machine's IP with the one attributed to your machine
telnet 3.250.206.251 22
telnet 3.250.206.251 80

Finally, SSH to the machine, using the key pair created: ssh ubuntu@3.250.206.251 -i aws-demo.pem

The last step would be to install the AWS CLI:



# Update the package repository
sudo apt-get update
# Install unzip on the machine
sudo apt-get install -y unzip
# Download the zipped package
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" \
-o "awscliv2.zip"
# unzip the package
unzip awscliv2.zip
# Run the installer
sudo ./aws/install

Ensure the AWS CLI is installed by checking the version: aws --version

Application Deployment on the EC2 machine

Application Code

The application to be deployed is a simple HTML document:



<!DOCTYPE html>
<html>
    <head>
        <title>My First Application</title>
    </head>
    <body>
        <p>I have no idea what I'm doing.</p>
    </body>
</html>

Apache2 Installation

A Webserver is needed to serve the web application. To install Apache2:

Update the local package index to reflect the latest upstream changes: sudo apt-get update
Install the Apache2 package: sudo apt-get install -y apache2
Check if the service is running: sudo service apache2 status
Verify that the deployment worked by hitting the public IP of the machine:

Application Deployment

To deploy the application, perform the following steps:



# Create a directory
sudo mkdir /var/www/myfirstapp
# Change the ownership to www-data
sudo chown -R www-data:www-data /var/www/myfirstapp
# Change the directory permissions
sudo chmod -R 755 /var/www/myfirstapp
# Create the index.html file and paste the code in it
sudo nano /var/www/myfirstapp/index.html
# Change the owership to www-data
sudo chown -R www-data:www-data /var/www/myfirstapp/index.html
# Create the log directory
sudo mkdir /var/log/myfirstapp
# Change the ownership of the directory
sudo chown -R www-data:www-data /var/log/myfirstapp/

Virtual Host

Create the virtual host file: sudo nano /etc/apache2/sites-available/myfirstapp.conf
Paste the following:



<VirtualHost *:80>
    DocumentRoot /var/www/myfirstapp
    ErrorLog /var/log/myfirstapp/error.log
    CustomLog /var/log/myfirstapp/requests.log combined
</VirtualHost>

Enable the configuration:



# Enable the site configuration
sudo a2ensite myfirstapp.conf
# Disable the default configuration
sudo a2dissite 000-default.conf
# Test the configuration
sudo apache2ctl configtest
# Restart apache
sudo systemctl restart apache2

Perform a request on the server. The response will now return the HTML document created:

In conclusion, to deploy the application on the EC2 machine, several tools had to be deployed and configured. While this is manageable for one simple application, things won’t be as easy and straightforward when the application grows in size. For instance, assume an application of 5 components must be deployed. Managing each component on the server will be cumbersome. The next part demonstrates how containerization can alleviate such problems.

Remove the apache webserver: sudo apt-get purge -y apache2

Application Deployment using containers

Docker Installation

Install Docker on the machine:



# Update the package index and install the required packages
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# Add Docker’s official GPG key:
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
| sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Set up the repository
echo "deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list \
> /dev/null

# Update the package index again
sudo apt-get update

# Install the latest version of docker
sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
docker-compose-plugin

# Add the Docker user to the existing User's group 
#(to run Docker commands without sudo)
sudo usermod -aG docker $USER

To validate that Docker is installed and the changes are all applied, restart the SSH session, and query the docker version: docker ps -a. A response similar to the below indicates the success of the installation.

Base Image

There exists several official Docker images curated and hosted on Docker Hub, aiming to serve as starting points for users attempting to build on top of them. There exists an official repository for the Apache server, containing all the information necessary to deploy and operate the image. Start by downloading the image to the server: docker pull httpd:2.4-alpine. 2.4-alpine is the image tag, an identifier to distinguish the different image versions available. After downloading the image successfully, list the available images docker images. The image below clearly shows the successful deployment of the image.

Next, it is time to run an container from this image. The goal is to run the apache server on port 80, and have it accept requests. Create a Docker container using the command:

docker run -d --name myfirstcontainer -p 80:80 httpd:2.4-alpine

The command above is explained as follows:

run: instructs docker to run a container.
-d: Flag to run the container in the background (Detached mode). Omitting this flag will cause the container to run in the foreground.
--name: A custom name can be given to the container. If no name is given, Docker will assign a random name for the container.
-p: Publish a container's port to the host. by default, if the ports are not exposed, containers cannot be accessible from outside the Docker network. To bypass this, the -p flag maps the container’s internal ports to those of hosts, allowing the containers to be reachable from outside the network. In the example above, The Apache server listens internally on port 80. The command above instructs Docker to map the container’s port 80, to the host’s port 81. Now, the container can be reached via the machine’s public IP, and on port 81, which will translate it to the container’s default port.

ensure that the container is successfully running: docker ps -a

Monitor the container logs: docker logs -f myfirstcontainer

Using any browser, attempt to make a request to the container, using the machine’s public IP and port 81: http:/3.250.206.251:80

Customize the Base Image

Now that the base image is successfully deployed and running, it is time to customize it. The official documentation presents clear instructions on the different ways the image can be customized, namely, creating custom Virtual Hosts, adding static content, adding custom certificates, etc.

In this example, the following simple HTML page representing a website will be added, thus creating a custom image.



<!DOCTYPE html>
<html>
    <head>
        <title>My First Dockerized Website</title>
    </head>
    <body>
        <p>I am inside a Docker Container.</p>
    </body>
</html>

The official documentation on Docker Hub clearly states that the default location for adding static content is in /usr/local/apache2/htdocs/. To do so, create an interactive sh shell on the container docker exec -it myfirstcontainer sh. Once inside the container, navigate to the designated directory cd /usr/local/apache2/htdocs/. The directory already has a file named index.html which contains the default Apache page loaded above. Modify it to include the custom HTML page above, and hit the container again: http:/3.250.206.251:80

Clearly, the image shows that the changes have been reflected.

Create a Custom Image

Unfortunately, The changes performed will not persist, especially when the container crashes. As a matter of fact, by default, containers are ephemeral, which means that custom data generated during runtime will disappear as soon as the container fails. To verify it, remove the container and start it again:



docker rm -f myfirstcontainer
docker ps -a
docker run -d --name myfirstcontainer -p 80:80 httpd:2.4-alpine

Now hit the server again http://3.250.206.251:80. The changes performed disappeared. To persist the changes, a custom image must be built. The custom image is a snapshot of the container after adding the custom website. Repeat the steps above to add the HTML page, and ensure the container is returning the new page again.

To create a new image from the customized running container, perform the following, create a local image from the running container docker commit myfirstcontainer.

Clearly, a new image with no name and no tag has been just created using the docker commit command. Name and tag the image: docker tag <image ID> custom-httpd:v2. The image should be that created by Docker, and the name and tag can be anything.

Remove the old container, and create a new one using the new image:



docker rm -f myfirstcontainer
docker run -d --name mysecondcontainer -p 80:80 custom-httpd:v2

A new docker container named mysecondcontainer is now running using the custom-built image. Hitting the machine on port 80 should return the new HTML page now no matter how many times the container is destroyed and created.

The custom image is now located on the Virtual Machine. However, storing the image on the VM alone is not a best practice:

Inability to efficiently share the image with other developers working on it.
Inability to efficiently download and run the image on different servers.
Risk of losing the image, especially if the VM is not well backed up.

A better solution would be to host the image in a Container Registry. In this tutorial, AWS ECR will be used to store the image. To create a Container repository on AWS ECR, navigate to Amazon ECR —> Repositories —> Private —> Create repository, with the following parameters:

Visibility Settings: Private
Repository name: custom-httpd

Leave the rest as defaults and create the repository.

Now that the repository is successfully created, perform the following to push the image from the local server to the remote repository:

First, login to the ECR from the machine:



aws ecr get-login-password --region eu-west-1 | docker login --username AWS \
--password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com

The repository created on AWS ECR possesses a different name than the one we created, therefore, we need to tag the image with the correct name, and then push it:



# Tag the image with the correct repository name
docker tag custom-httpd:v2 \
<AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v1
# Push the image
docker push <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v1

Clearly, we were able to push the image to AWS ECR. Now, to finally test that the new custom image is successfully built and pushed, attempt to create a container from the image located in the Container Registry.



# Delete all the containers from the server
docker rm -f $(docker ps -a)
# Delete all the images from the server
docker rmi -f $(docker images)
# List all the available images and containers (should return empty)
docker images
docker ps -a

create a third container, but this time, reference the image located in the ECR: docker run -d --name mythirdcontainer -p 80:80 <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v1

The image clearly shows that the image was not found locally (on the server), and therefore fetched from the ECR.

Finally, hit the server again http://3.250.206.251:80

The server returns the custom page created. Cleaning up the server from the applications is as simple as deleting all the containers and all the images:



# Delete all the containers from the server
docker rm -f $(docker ps -a -q)
# Delete all the images from the server
docker rmi -f $(docker images)
# List all the available images and containers (should return empty)
docker images
docker ps -a

Create a Docker image using Dockerfiles

Creating images from existing containers is one intuitive way. However, such an approach may prove to be inefficient, and inconsistent:

Docker images may require to be built several times a day.
A Docker image may require several complex commands to be built.
Difficult to maintain as the number of services and teams grows.

Dockerfiles are considered a better alternative, capable of providing more consistency and allowing for automating the build steps. To better understand Dockerfiles, the rest of this tutorial attempts to Containerize the application, using Dockerfiles.

To do so, The application code and the Dockerfile must be placed together:

Create a temporary directory: mkdir ~/tempDir
and place the application code inside the directory in a file called index.html



<!DOCTYPE html>
<html>
    <head>
        <title>My Final Dockerized Website</title>
    </head>
    <body>
        <p>I am Dockerized using a Dockerfile.</p>
    </body>
</html>

Create a Dockerfile next to the index.html file, with the following content:



FROM httpd:2.4-alpine
COPY index.html /usr/local/apache2/htdocs/

The Dockerfile above has two instructions:

Use httpd:2.4-alpine as base image
Copy index.html from the server to the /usr/local/apache2/htdocs/ inside the container

The resultant directory should look as follows:

To build the image using a Dockerfile, perform the following command: docker build -f Dockerfile -t <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v-Dockerfile .

Breaking down the command above:

docker build: Docker command to build a Docker image from a Dockerfile
-f Dockerfile: The path and filename of the Dockerfile (Can be named anything)
-t <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com:v-dockerfile: The name and tag of the resulting image
.: The path to the context, or the set of files to be built.

Push the image to the ECR: docker push <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v-Dockerfile

Finally, to simulate a fresh installation of the image, remove all the containers and images from the server, and create a final container from the newly pushed image:



# Remove existing containers
docker rm -f $(docker ps -a -q)
# Remove the images
docker rmi -f $(docker images)
# Create the final container 
docker run -d --name myfinalcontainer -p 80:80 <AWS_ACCOUNT_ID>.dkr.ecr.eu-west-1.amazonaws.com/custom-httpd:v-Dockerfile

Hit the machine via its IP:

DevOps: What it is, What it isn't.

Nicolas El Khoury — Wed, 16 Nov 2022 10:26:17 +0000

Introduction

DevOps, SysOps, DevSecOps, MLOps, CloudOps, PotatoOps, are all catchy and trendy buzzwords that are circulating all over LinkedIn and the tech realm in 2022. A simple search for such keywords on LinkedIn will return thousands of people and companies "applying" to them one way or the other.

Unfortunately, as with most trends, numerous definitions and variations arise, leaving the general public in confusion, creating irrelevant job positions and career paths, and leading to inefficient Software Development Lifecycles, further complicating everything!

In this article, I share my personal opinion on the matter, answering the following questions:

What is DevOps?
What are DevOps Engineers?
How to apply DevOps in organizations?

Background Information

Hi, my name is Nicolas, and I have been practicing DevOps since 2016. I was, and still am, heavily involved in applying DevOps for the companies I've worked with. In those 7 years, I worked with and advised for quite a few organizations ranging from small startups with a couple of services serving a small number of clients, to large enterprises developing and deploying absolutely complicated software solutions with even more complicated requirements.

Some of my most impactful achievements include:

Building a multi-disciplinary DevOps unit, capable of deploying - almost - any type of software on any kind of infrastructure.
Creating training materials and curriculums to transform junior and mid-level backend developers and system administrators into efficient DevOps Engineers.
Creating a University Course curriculum entitled "Introduction to Fullstack and DevOps Engineering", aiming to better prepare university students to the relevant technical and personal skills needed in the market today.

Evolution of DevOps Solutions

A lot of things changed in those 7 years, especially in DevOps related solutions:

Kubernetes is everywhere.
Cloud Providers have hundreds of managed services.
Continuous Delivery tools allow to easily automate everything.
Infrastructure can now be created and managed through code.
Multi-cloud solutions are a popular thing.
Everyone wants to become a DevOps Engineer, and all the companies want to apply DevOps.

One thing did not really change though: There is no clear definition of DevOps. This article sums up my years of experience in the field, showcases my personal point of view regarding DevOps, and presents opinions on how to successfully become a DevOps Engineer and how to apply DevOps in organizations.

Software Delivery Models.

DevOps is nothing more than a software delivery model, embracing today's available technologies and aiming to enhance the software development lifecycle. To better understand DevOps, it is important to understand the preceding models, namely the Waterfall and Agile models.

Waterfall Model

The waterfall model is one of the oldest software delivery models, introduced in the 70s. It divides the software development lifecycle into pre-defined sequential phases, each performing a specific activity, and must be fully complete before the next one can begin with no overlap between them.

With the current technological advancements and capabilities, this model becomes cumbersome and inefficient:

The model employs rigid process, discouraging changes.
Difficult to measure progress, due to the silo'ed mode of work.
Deployments are slow and complex.

Agile Model

The Agile model, formally launched in the early 2000s, provides a more flexible approach to deliver software. Unlike the Waterfall model, Agile promotes continuous iteration of design, development, and testing throughout the software development lifecycle of the project, bringing down silos between the different phases, and shortening releases cycles from months to weeks, in what is called "sprints". As the name states, the model increases the agility through continuous planning, improvement, team collaboration, development, and delivery, and responses to change.

Operations teams are left out given that infrastructure and operations did not require the same agility at that time.

DevOps Model

The birth of cloud computing, with its on-demand delivery of IT resources, revolutionized software delivery. Before, software development and delivery required an iterative approach, while the infrastructure remained rigid.

With the adoption of the cloud (2006 onwards), the need for owning and maintaining physical data centers was replaced by renting them out from cloud providers using different flexible payment models (e.g., Pay as you go).

Cloud computing came with several benefits, including but not limited to:

Agility: Ease of access to a wide range of compute resources, on demand, allowing for the creation of complex infrastructure in minutes.
Elasticity: Resource mis-utilization (over or under provisioning) are no longer a problem, especially with the ability to quickly modify the compute resources based on the varying needs.
Cost Saving: The pay as you go model, and the elasticity of the resources permit the users to continuously optimize the costs of the compute resources.

With the adoption of cloud computing in software delivery, Development and Operations teams can no longer be siloed, as it is the case with the Agile model. As a matter of fact, the development and management of the infrastructure must now align with that of the application itself.

DevOps is a bouquet of philosophies, set of tools & practices, that aim to decrease the cost, time, and complexity of delivering software applications, through unifying both the software development and infrastructure management processes.

DevOps aims to automate as many processes as possible to reliably and efficiently:

Create and manage infrastructure resources.
Release software changes.
Perform necessary tests (e.g., Unit, Integration, Stress tests, etc).
Automatically spin new environments seamlessly.
Enhance system security.
Ensure scalability.
Improve collaboration.

In light of the above, DevSecOps, SysOps, MLOps, CloudOps, PotatoOps, are catchy LinkedIn words that can be all replaced by the term DevOps.

DevOps: what it is, what it isn't!

Clearly, DevOps is nothing more than a set of philosophies and best practices to enhance the software delivery using today's existing technologies.

Having said this, DevOps is not:

Deployment of software on the cloud using the Agile approach (Most of today's understanding confuses this with DevOps).
Creating software using the Microservices approach.
Using Infrastructure as Code tools with no clear purpose.
The adoption of unneeded automation tools in general.

Many entities attempting to apply DevOps might fall for the misconceptions listed above, but rather still apply, unknowingly, the agile model, but on the cloud.

DevOps Engineers: What they are, and what they aren't!

The inability to truly define DevOps resulted in creating a lot of inefficient and weird job positions, that might not necessarily contribute to the Software Development Lifecycle. Worse, this can lead to further deteriorating the quality of the application and the lifecycle as a whole.

In light of the above, DevOps Engineers are not:

Engineers who create cloud infrastructure. Those are Site Reliability Engineers.
Kubernetes Gurus. Those are Kubernetes Gurus, not DevOps Engineers.
Cloud Enthusiasts.

In brief, a DevOps Engineer is someone with enough skillset to bridge the gap between the development and operations teams, through:

Creating the required infrastructure.
Deploying the application.
Providing Continuous Delivery Mechanisms.
Automating all the processes previously done manually by the different departments: development, testing, security, etc.

DevOps Engineers must have a strong background in System administration and/or software development. After all, whatever you need to automate, you must be able to do it manually at first!

How to apply DevOps in organizations

Applying DevOps in organizations is an easy concept, that is difficult to apply. As a matter of fact, DevOps entails the upskilling of all the stakeholders in a software company (Developers, QA, Designers, Technical Project Managers, System Administrators, UI/UX Designers, and business teams as well).

Conclusion

DevOps is still a confusing term for most of the tech industry. Several definitions have been created, without clear standards and straight-forward value.

DevOps is nothing more than a culture that further enhances the software delivery lifecycles.

Becoming a successful DevOps Engineer requires you to have a strong knowledge in both development and operations.

Applying DevOps successfully within an organization entails the upskilling of all the personnel in the organization, all-the-while applying the necessary set of tools and processes that promote collaboration, communication, and automation.

Redis Hackathon: NK-Microservices

Nicolas El Khoury — Sat, 06 Aug 2022 07:47:00 +0000

Overview of My Submission

This project started out as an initiative to better explain how microservices and deploying Microservices work. As a matter of fact, few years ago, DevOps and Microservices were still a blackbox. In this regards, I developed this microservices project, composed of a Gateway Service, Backend Service, ArangoDB (persistent storage), and Redis (Caching).

The main purpose of this project is to highlight the importance and complexities of distributed systems, and highlight how different components interact with one another.

In addition to that, the project contains multiple deployment modes, with the aim of showcasing different ways of deploying a Microservices project

Submission Category:

MEAN/MERN Mavericks.

Language Used

Node.JS

Link to Code

Documentation: https://github.com/automation-lb/nk-microservices-deployment

The repository above contains all the information needed to download and deploy the project.

How I obtained all AWS associate level certificates in two weeks.

Nicolas El Khoury — Thu, 04 Aug 2022 05:11:58 +0000

Introduction

Hi, my name is Nicolas, and I was able to pass all the AWS associate level exams in just two weeks (between 9/2/2021 and 25/2/2021), all while maintaining a full time job, and a hectic personal life. I tried to think of many catchy and trendy introductions about AWS Certificates, along with their advantages and whatnot. However, I noticed that the internet is filled with articles that contain excellent explanations. Therefore, in this article, I will omit this part, and cut straight to sharing my personal experience, along with some tips and tricks to better prepare for your associate level exams, and hopefully pass them with the right effort.

Background Information

The professional experience that I obtained in the past years played a major role in decreasing the complexity of understanding the exam material, and the time required to prepare for each exam. As a matter of fact, I have around 6 years of experience in providing DevOps Solutions, Cloud Infrastructure Solutions, and Software Architecture using the Microservices approach.

The exams

Over the course of 2 weeks, I managed to prepare and pass all three AWS Associate level Certificates:

AWS Certified SysOps Administrator - Associate (SOA)

This was the first exam I took. Needless to say, I was a little bit nervous, and did not know what to expect. I bought two courses from Udemy: AWS Certified SysOps Administrator Associate 2022 [SOA-C02] and the corresponding practice exams. Not knowing how to prepare, I started by watching every episode(On a speed of x1.75). Surprisingly, I enjoyed it very much. Even though I am quite experienced in most of the course's content (i.e., VPC, EC2, ASG, S3, RDS, etc), I learned a lot, due to its fun and interactive approach, which not only focuses on theories and information, but also on interesting hands on labs that further strengthen the topic being studied.

I finished the course in about 5 hours, and directly solved the practice test associated with the course. I was able to pass it easily, thus boosting my confidence. Afterwards, I solved two other test, which I also passed easily. That's when I decided that I was ready to take on the actual exam. I registered through the AWS Training Portal, and passed it with a score of 926 / 1000.

AWS Certified Solutions Architect - Associate (SAA)

After finishing the first exam, I became hesitant as to whether I should stop here or continue with the certificates. Before deciding, I went on and purchased another Udemy course along with its practice exams.

Honestly, I felt lazy, especially after learning that the course is much longer and contains a lot of information than the AWS SysOps exam. In addition, the content was quite similar to the previous one. However, the course contains a wonderful feature (I really appreciated it): The exam cram. At the end of every section, there exists one or two videos usually containing all the important information that must be kept in mind for the exam. Therefore, I skipped the whole content and only focused on the exam crams, which I finished in less than two hours. Finally, I solved 3 exams, which I was able to pass easily, before passing the actual exam on February 19th with a score of 825 / 1000.

Even though my score was relatively low, I can easily say that this exam was not more difficult than the AWS SysOps Associate exam.

AWS Certified Developer - Associate (DVA)

Having passed two exams in 10 days, I was determined to prepare and achieve the third and final associate level AWS certificate. Therefore, again, I purchased another Udemy course along with its practice exams.

Unfortunately, The AWS Certified Developer course content is quite different than the other two. As a matter of fact, this course focuses a lot on AWS Services related to development (i.e., Amazon DynamoDB, AWS SQS, AWS Cognito, etc). Evidently, I was not experienced with such services. I skimmed through the exam crams quickly, and directly jumped into solving the practice exams, which I successfully failed miserably :).

It was then when I noticed that unless I familiarize myself very well with these AWS services, I will never be able to pass the exam. Therefore, I researched and read a lot about every AWS service that I felt uncomfortable with, and I reviewed the explanation of every question that I failed to answer correctly. After around 12 hours of preparation, I felt ready for the exam, which I took and passed with a score of 987 / 1000.

Conclusion (and Tips)

In brief, the AWS exams are not easy, but also not impossible. It is important to understand very well the concepts and use cases of every service, since most of the exam questions are scenario based. Below is a set of tips to consider when preparing for AWS exams:

Have a thorough understanding, and preferably hands on experience on every AWS service covered.
Create an AWS account and play around with the AWS free tier. The AWS console is very amusing and easy to navigate.
Research the basic concepts behind the AWS services. For instance, if you're learning about AWS ELBs, a good approach would be to understand what load balancers are, how they operate, and why we need them. This will give you a great insight on why AWS services are built and are operated and used.
Preferably, make sure to have a few years of professional experience in using AWS.
There are plenty of tailored online courses (and cheap). I highly recommend purchasing such courses, in addition to doing your own research.
Solve practice exams as much as possible. Solving these exams will give you more insight on the type of questions asked, and will always teach you information that you might have missed from your exam preparations.

Best of luck!

Different Ways of Deploying a Microservices Application on AWS

Nicolas El Khoury — Wed, 12 Jan 2022 10:07:37 +0000

Introduction

Traditionally, applications were designed and implemented using a Monolithic architectural style, with which the application was developed and deployed as a single component, divided into multiple modules. Monolithic applications are very easy to develop and deploy.

However, such an architectural pattern becomes a burden once the application becomes too large:

Difficult to manage and maintain, due to the large code.
All of the application is built using one programming language, thus the system may suffer from bottlenecks when performing tasks not suitable for this specific language.
Difficult to scale the application.
Difficult to use container based technologies (Due to the large size of the application).

With the emergence of Cloud Computing, and the concept of the on-demand provisioning of resources, a more suitable architectural pattern was required. Microservices rapidly gained popularity, and became a widely used architectural pattern, especially for applications deployed on the cloud. Microservcies are an architectural pattern which divides an application into smaller, independent, loosely coupled services that may communicate with each other via multiple protocols (e.g., HTTP, sockets, events, etc). Microservices provide the following advantages:

Easy to maintain (smaller code in each service). Highly scalable.
Extremely suitable for container-based technologies. Complements cloud solutions.
Fault tolerance: If one microservice fails, the rest of the system remains functional.

Truly, the Microservices Architecture is a very powerful architectural pattern that goes hand in hand with the services provided by the cloud. However, a well designed system depends on two factors. A robust design of the software, and of the underlying infrastructure. There exists multiple articles, tutorials, courses, that explain and promote the design, and implementation of Microservices.

Microservices Example Project

The NK Microservices project is a sample project built using the Microservices approach. This project will be used in this article to better illustrate the differences between deployment modes.

This project is made of the following components:

Gateway Microservice: A REST API Microservice built using SailsJS, and serves as a Gateway, and request router.
Backend Microservice: A REST API Microservice built using SailsJS, and serves as the first, out of many Microservices which can be incorporated and integrated with the aforementioned Gateway Service.
Redis Database: An open source, in-memory data store, used for caching purposes, and for storing other ephemeral pieces of information such as JWT tokens.
Arango Database: A multi-model database used for storing persistent information.

The project requires all of the aforementioned components to be set up in order to function properly.

Deployment Modes

Deploying applications on robust infrastructure is a key operation to the success of the product. Evidently, each application serves a specific purpose, and is designed uniquely using distinct technologies. In this regard, the underlying infrastructure for each application may differ based on the application, business, regulatory, etc, needs.

Usually, when deploying software, several considerations must be taken into account, some of which include:

Security: The system must always be secure from all sorts of unwanted access.
Scalability: The ability to scale up/down resources based on demand.
Availability: The system must be able to sustain failure, and avoid single points of failure.
System Observability: Tools that increase the system visibility (monitoring, logging, tracing, etc).

However, in general, these different deployment modes can be categorized as follows:

Single Server Deployment.
Multi Server Deployment.
Deployment using Container Orchestration Tools.

The rest of this document explains the details of each deployment type, its advantages, and disadvantages.

Single Server Deployment

As the title states, in this mode, a single server is supposed to host all the different components. In this case, All the components of the NK Microservices project (Arango Database, Redis, Backend, and API Gateway) will be deployed on configured on the same server. A similar deployment can be found here. Typically, the inter-service communication between the components can be done using the local machine's IP. Despite this advantage, this mode of deployment is highly unadvised, except for local and temporary testing. Below is a list of disadvantages, explaining why it is advised to never proceed with Single Server Deployments, especially for production workloads:

Time consuming: Properly installing and configuring each component may prove to be time consuming, especially as the number of components grows in sizes. The NK microservices project is a relatively small project of 4 components, but imagine larger ones with 20+ components. In this case, such a deployment is definitely inefficient.
Non-Scalable: Each component can be installed and configured to run as a standalone process. Evidently, on a single server, clustering databases and spinning multiple replicas of the same process is not only worthless (The server represents a SOF), but also will contribute to the server's performance degradation through consuming more resources.
Huge Downtime: Any configuration, maintenance work, or the slightest error may put the whole server (and application) down, until the server and all of its components are restored.
Single Point of Failure: Being a single server, no matter what disaster recovery mechanisms, security policies, or auto-repair mechanisms, if the server goes down, the whole application goes down with it.
May mess up the host machine: The different application components are using the same servers, sharing the same resources, and outputting content on the same server. As the number of applications on the server grows, along with the demand of each one, the server is at risk of infection, where one component may consume the resources of the others, thus blocking them from operating safely.

In summary, single server deployments are only advised for personal use, and short term testing of small software applications.

Multi Server Deployment

A better approach would be to divide the project's components across multiple servers. Monolithic applications are usually developed using MVC, a three-tier architectural style (Frontend, Backend, and Database). A proper and intuitive deployment approach would be to deploy each layer on a separate server. In the case of microservices, a similar approach can be taken, by dedicated a small server to each component of the application. Such a deployment mode, while not the best, is definitely a more convenient approach:

Separation of concerns: Processes are no longer sharing resources and risking each other's proper operation.
Isolation: Each component may operate on its own, and use dedicated resources. A proper design of the application may allow partial system operation in case of partial downtimes. For instance, if the Redis database crashes, the rest of the system should be fully operational.
Scalability: Database clustering and service replication are now possible by replicating the servers of each application independently from the other.

Evidently, multi server deployments are definitely a better alternative to their single server counterparts. However, this approach tends to become cumbersome at scale, especially when it comes to scalability, and managing the lifecycle of each component, and each replica of that component properly. Handling a system of 4 components, and a couple replicas per service may be easy. However, consider a system of 30 components and 5 replicas per component. Properly handling such a system may become cumbersome.

Deployment using Container Orchestration Tools

Container Orchestration Tools provide a framework for managing microservices at scale. Such tools possess amazing capabilities and features to manage the lifecycle of distributed application components from a centralized command server, and can be used for:

Provisioning, configuration, resource allocation and deployment of services.
Container availability
Scale in/out of resources
Load balancing and traffic distribution and routing
Container health monitoring
Managing inter-process communication.

There exists several mature tools that are widely used in the market, namely Kubernetes, Docker Swarm, Apache Mesos, etc. Describing these tools is out of scope of this article.

The diagrams above clearly point how a simple Elastic Kubernetes Service (EKS) on AWS permits the provisioning of several servers, and deploying the NK microservices project in a production ready infrastructure composed of replicated servers and services. Such a deployment has several advantages:

Easy scalability mechanisms for servers and containers.
Improved governance and security controls.
Better visibility on the system.
Container health monitoring.
Optimal resource allocation.
Management of container lifecycle.
System Visibility.
Cost opimization.

Conclusion

In brief, this article summarized the different modes of deployment available for Microservices on AWS. Single server deployments are usually not advised, except for personal use and local temporary testing. Multi server deployments represent a better alternative, especially at small scale. However such a deployment may become cumbersome at scale, and must be replaced by a more convenient mode, such as using Container Orchestration Tools (At the expense of complexity).

Enforce MFA Access to the AWS Console

Nicolas El Khoury — Tue, 16 Nov 2021 12:26:17 +0000

Introduction

One of the most important security concerns for entities using AWS is securing their AWS accounts. Evidently, managing an AWS account with 5 users may be somewhat a walk in the park. However, as the usage of the account scales, and the number of users increases, managing account becomes trivial. Several policies must be put in place in order to organize access between different stakeholders.

One of the most common security features is to enable Multi-Factor Authentication on the AWS account users.

In this tutorial, we are going to setup a process that forbids any AWS user from using any service without:

Setting up an MFA device.
Signing in using MFA. Any user that signs in without MFA must not be allowed to manage any resource on AWS.

Steps

In this tutorial we will perform the following:

Create the required policy.
Create a test user.
Validate the setup.

Setup

Policy Creation

Navigate to Policies section, under the IAM service, and create the following policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowViewAccountInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:GetAccountSummary",       
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },       
        {
            "Sid": "AllowManageOwnPasswords",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnSigningCertificates",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteSigningCertificate",
                "iam:ListSigningCertificates",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnSSHPublicKeys",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteSSHPublicKey",
                "iam:GetSSHPublicKey",
                "iam:ListSSHPublicKeys",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnGitCredentials",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceSpecificCredential",
                "iam:DeleteServiceSpecificCredential",
                "iam:ListServiceSpecificCredentials",
                "iam:ResetServiceSpecificCredential",
                "iam:UpdateServiceSpecificCredential"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnVirtualMFADevice",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice"
            ],
            "Resource": "arn:aws:iam::*:mfa/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken",
                "iam:ChangePassword",
                "iam:GetUser"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

The policy above allows a user to only perform certain actions related to their account such as changing the password, or setting an MFA device. Moreover, the policy denies every other action for the user, if signed in without an MFA device. This policy allows any user to login for the first time, and set their own MFA device.

Give the policy a name and finalize its creation.

Test User Creation.

Navigate to Users section, under the IAM service, and add a new user with the following options:

Name: testuser
AWS Credential Type: autogenerated password that should be changed on first signed in for the AWS Management Console.
Under the permissions section, navigate to "Attach existing policies directly", search for the name of the policy created previously, and add it to the user.
Attach the AmazonEC2FullAccess policy as well, giving the user full access to the EC2 service.
Leave the remaining options as defaults, and create the user.
A password will be generated. Use this password to login to the console with the new user.

MFA setup and Validation

In order to validate the setup, perform the following:

Login to the AWS management console using the new testuser. For the first time, you will be able to login using only the password. Moreover, you will be asked to change the password.
After successfully logging in, navigate to the EC2 instances console. You will be greeted with the following message "You are not authorized to perform this operation." forbidding you from listing any existing instances. Even though this user has full access to the EC2 service, managing EC2 resources is forbidden before signing in using MFA.
To setup MFA, navigate to the dashboard of the IAM section. The dashboard will be filled with permission error messages.
Click on Add MFA --> Assign MFA Device --> Virtual MFA device.
Download an MFA software (Google, Microsoft, etc) on your phone, and complete the setup on AWS by scanning the QR code, and then copying 2 consecutive MFA Codes.
Upon completion, you will receive the following message:

You have successfully assigned virtual MFA
This virtual MFA will be required during sign-in.

Sign out, and sign back in. This time, you will be prompted to enter the code from the authentication device.
After signing in, navigate again to the EC2 instances dashboard. The error message is now replaced by the list of EC2 instances present.

The end :)

Proposed Infrastructure Setup on AWS for a Microservices Architecture (4)

Nicolas El Khoury — Mon, 01 Nov 2021 10:36:02 +0000

Chapter 4: Deployment Strategies for Microservices.

Chapter 3 promotes one way of deploying microservices, along with some best practices, in order to achieve security, scalability, and availability. In fact, an improper deployment of microservices may lead to numerous problems, namely, bottlenecks, single point of failure, increased downtimes, and many more.

Now that the best practices and considerations have been discussion, what follows describes some of the different technologies that can be employed to manage and orchestrate Microservices.

Microservices come with numerous advantages. One of the rather important ones is the isolation (and independence) each Microservice provides from the rest of the system. Therefore, assume an application composed of three Microservices: Catalog service, Customer Service, and Payment Service. If well architected, the failure of one Microservice must only impact its own part of the system, and not the system as a whole. For example, if the Payment service fails, the system payments will fail. However, the users should still be able to use the other functionalities of the system, provided by the other two systems. Another advantage of Microservices is its scalability. Assume, in the same example above, the Catalog service is receiving traffic much more than the Payment service. In this case, it would make more sense to have more replicas of the Catalog service, than that of the Payment service.

To ensure the aforementioned scalability, and availability, proper orchestration tools must be employed. Before digging deeper in orchestration tools, below is a list of deployment modes to run microservices:

Physical Servers: Installing and configuring servers is one way of deploying and running Microservices. However, with today's technologies, and the incredible amount of resources offered by the machine, in addition to the wide adoption of cloud based solutions, managing your own phyiscal servers is not quite the best idea. In addition to the lack of scalability options, and misuse of the resources (be it under-utilization or over-utilization), managing physical servers on-premises comes with great Capital and Operational Expenditures. Moreover, each Microservice must run in its own isolated environment. Running multiple Microservices on the same physical server may hinder this isolation. Running each Microservice on an independent server, on the other hand is not an optimal solution.
Virtual Machines: Dividing a physical machine into multiple virtual machines is definitely a better approach. In fact, each virtual machine spun on a physical server acts as an independent, isolated environment, allowing to host multiple Microservices on the same machine, and therefore, better resource consumption. However, Virtual Machines come with their own disadvantages. In fact, each virtual runs its own full copy of an Operating System, in addition to a copy of the underlying hardware. Evidently, this consumes an excessive amount of RAM and CPU. Virtual Machines, despite being a better solutions than running actual servers, they are still not quite suitable for hosting Microservices. Examples of Virtual Machine providers include, but are not limited to: VirtualBox, Hyper-V, and KVM.
Containers: Similar to Virtual Machines, containers provide isolated environments that can run on a single host. However, containers share the physical server, and the host's operating system. Indeed, each container running on a machine shares the Operating System, its binaries, and its libraries. Therefore, containers do not have to own a copy of the operating system, thus heavily reducing the use of the host's CPU and RAM. Evidently, containers are lightweight isolated environments, that allow faster deployment, and the accommodation of a larger number of Microservices on the same host than Virtual Machines. Linux Containers, and Docker are examples of Container technologies.
Serverless: As the name states, Serverless is an approach that abstracts all kinds of server management for the users. Definitely, there exists servers on top of which the application runs. However, these servers are managed by the Cloud Providers (e.g., Amazon Web Services, Amazon Web Services, etc). Moreover, the functions hosted on the serverless technologies are only charged for the times they are being used. As opposed to the aforementioned three technologies, when the application is not being used (There exists no traffic), the application is not considered running. Serverless brings several advantages, namely, high scalability, reduces charges, and no servers to manage and maintain. Unfortunately, the Serverless technology comes with numerous disadvantages. In fact, since the functions are not running when idle, latencies may occur when first triggering a function. More importantly, each cloud provider provides its own set of libraries for writing applications using this technologies. Therefore, when changing cloud providers, or even technologies, one is at risk of performing major code modifications.

As a summary, this article discussed the several deployment modes for software application built using the Microservices approach. Evidently, the container and serverless technologies are newer and more suitable for Microservices than Virtual Machines and Physical Servers. The next chapter will discuss how Serverless and Containers can compliment each other, in addition to the benefits of incorporating them together.

List of articles

Proposed Infrastructure Setup on AWS for a Microservices Architecture (3)

Nicolas El Khoury — Sun, 31 Oct 2021 06:03:50 +0000

Chapter 3: Deployment Strategy for Microservices.

Chapter 2 provided an overview of the proposed infrastructure, and explained the different components used, along with its advantages. However, the aforementioned infrastructure is only as robust as the environment hosting the microservices. In fact, an improper deployment of microservices may lead to numerous problems, namely, bottlenecks, single point of failure, increased downtimes, and many more.

This chapter promotes one way of deploying microservices, along with some best practices, in order to achieve security, scalability, and availability.

To further illustrate the proposed solution, the diagram above represents a Virtual Private Cluster (VPC) located in the region Ireland (eu-west-1) (The details of creating a VPC and its underlying components are out of the scope of this artible). A VPC created in a region may support one or more Availability Zones (AZ). Each Availability Zone represents a distinct data center in the same region. While regions are isolated from one another, Availability Zones within a single region are connected to each other through low-latency links. For simplicity reasons, assume that this region is comprised of two availability zones (eu-west-1a, and eu-west-1b).

In each AZ, a public subnet and a private subnet are created. In chapter 2, we clearly stated that all of the microservices and other backend components are to be created in private subnets, and never in public ones, even components or services that require to be accessed by the internet (e.g., frontend applications, API gateways, etc). Even though resources in private subnets by default cannot be accessed by the internet, attaching them to an internet-facing load balancer is enough to alleviate this problem. Therefore, microservices that must be accessed from users outside the VPC must be attached to an internet-facing load balancer, and the other ones must be attached to an internal load balancer. Evidently, all microservices communicate with one another through the load balancers, and never through IPs. In fact, such a communication through load balancers not only ensures a balanced load across multiple replicas of one service, but also has multiple other advantages that will be discussed later in this article.

One must always take advantage of the existence of multiple AZs in a region. Thus, when deploying a microservice, it is always advisable to deploy multiple replicas of it, and span these replicas across multiple AZs. For instance, when deploying one microservice in the VPC above, a good approach would be to deploy two replicas of this service, one in each private subnet. In case of any failure, be it on the microservice, instance, or AZ level, the application still has another running instance ready to serve the requests, until the failing component is resolved.

Assume the following three deployment scenarios to illustrate the importance of what has been said.

Microservice A is deployed as 1 replica in private subnet (a). A failure on the microservice level is enough to create an unwanted downtime. In fact, should this microservice fail, there exists no other replica to serve the requests, until this microservice comes back to life. (Failed approach)
Microservice A is deployed as 2 replicas, in private subnet (b). While this deployment ensured more than one replica for the service, both replicas are located in the same subnet, and in the same availability zone. In this case, the application is protected from a failure on the microservice level, since another replica is ready to serve the requests. However, a failure on the AZ level is enough to bring the service down. (Failed approach)
Microservice A is deployed as 2 replicas, one in private subnet (a), and another one in private subnet (b). With such a deployment, the only way to suffer from downtime is to bring the whole VPC down, which is something very difficult to happen. In fact, each replica of the service is located in different datacenter. Thus, a failure on the microservice level, and even on the datacenter level is mitigated. (Successful approach)

The three scenarios above illustrate the importance of replicating and spreading microservices as much as possible in order to provide reliability, and fault tolerance. What follows explains the importance of attaching all the replicas of every microservice into a load balancer. Assume a service of two replicas. Attaching the replicas as a target group to a load balancer provides the following advantages:

Load balancing across all replicas.
Detecting and reporting failed replicas: The load balancer performs regular health check on each replica. In case of a failure in one of the replicas, the load balancer stops forwarding requests to it. Alarms could be set using Cloudwatch in order to report such incidents.
Ability to easily scale replicas: AWS provides multiple mechanisms to scale in and scale out a service, and easily integrates the added/removed instances from the target group.
Service Discovery: The load balancer alleviates the need for a service discovery tool, through attaching each distinct service to the load balancer as a target group. The load balancer, namely the Application Load Balancer (ALB) supports multiple routing rules such as host-based routing, and path-based routing.

In brief, this article explained the best practices when choosing a mode of deployment for microservices. The proposed solution maximizes security, availability, and reliability of the microservices. The next chapter will describe the different technologies that can be used on which microservices can be hosted.

List of articles

Proposed Infrastructure Setup on AWS for a Microservices Architecture (2)

Nicolas El Khoury — Tue, 26 Oct 2021 12:52:02 +0000

Chapter 2: Overview of the Infrastructure and Components.

Chapter 1 of this series explained the advantages and disadvantages of a Microservices architecture, in addition to the design considerations required to implement an infrastructure that is robust and adequate enough to host such types of architectures.

This chapter provides an overview of the proposed infrastructure, and explains the different components used, along with the advantages it provides.

Virtual Private cluster (VPC): is a private network, within the public cloud, that is logically isolated (hidden) from other virtual networks. Each VPC may contain one or more subnets (Logical divisions of the VPC) attached to it. There exists two types of subnets: public subnets, in which resources are exposed to the internet, and private subnets, which are completely isolated from the internet.
Amazon Application load Balancer (ALB): An Application load balancer serves as a point of contact for clients. The load balancer evaluates, based on a set of predefined rules, each request that it receives, and redirects it to the appropriate target group. Moreover, the load balancer balances the load among the targets registered with a target group. A load balancer canbe interet-facing (Can be accessed from the internet), or internal (cannot be accessed from the internet). AWS provides three types of load balancers: 1) Application Load Balancer, Network Load Balancer, and Classic Load Balancer.
Amazon Cloudwatch: AWS’ monitoring tool for all the resources and applications on AWS. Collects and displays different metrics of resources deployed on AWS (e.g.. CPU Utilization, Memory Consumption, Dis Read/Write, Throughput, 5XX, 4XX, 3XX, 2XX, etc). CloudWatch alarms can be set on metrics in order to generate notifications (e.g., Send an alarm email), or trigger actions automatically (e.g., Autoscaling). Consider the following alarm: When the CPU Utilization of instance A averages higher than 65% for three minutes (Metric Threshold) Send an email to a set of recipients (Notification) and create a new replica of instance A (Scaling Action).
Amazon S3: An AWS storage service to store and retrieve objects.
Amazon Cloudfront: A Content Delivery Network (CDN) service that enhances the performance of content delivery (e.g., data, video, images, etc) to the end user through a network of edge locations. AWS Cloudfront can be attached to an Amazon S3 bucket, or any server that hosts data, caches the objects stored on these servers, and serves them to the users upon requests.
Lambda Functions: A type of serverless compute functions, which allows users to upload their code without having to manage servers. AWS handles all the provisioning of underlying machines. Lambda functions are triggered by events configured, namely, An object put on S3, an object sent to the SQS, periodically, etc.

The diagram above depicts an infrastructure, in which multiple resources are deployed. Aside from S3, Cloudfront, and Cloudwatch, all the resources are created and deployed inside the VPC. More importantly, all of these resources are inside private subnets, as can be seen later in this article. Resources spawned in private subnets only possess private IPs, and therefore cannot be accessed directly from outside the VPC. Such a setup maximizes the security. In fact, a database launched in a public subnet, and protected by a password, no matter how strong it is, is at a high risk of being breached directly (Simple brute force attack). However, a database launched in the private subnet is practically nonexistent for anyone outside the VPC. Even if not secured with a password, the database is only accessible to users inside the private network.
The communication between the application components, such as microservices and databases passes through a load balancer. In more details, each microservice, database, or any other component is attached as a target group to a load balancer. The components that are given access to from the internet are attached to an internet-facing load balancer, whereas the backend system components are attached to an internal load balancer. This approach maximizes the availability, load balancing, and security of the system. To better explain the aforementioned, consider the following example:

Assume an application composed from a front-end microservice, an api gateway microservice, a backend-end microservice, and a database. Typically, the frontend, and api gateway services should be accessed from the internet. Therefore, they should be attached as two target groups to the public facing load balancer. On the other hand, the backend service, and the database must never be accessed from the outside world, thus attached to the internal load balancer. Consider a user accessing the application, and requesting a list of all the products available, below is the flow of requests that will traverse the network:

Request from the user to the internet-facing load balancer.
The load balancer routes the request to the frontend application to load the page in the user’s browser.
The front-end application returns a response to the load balancer with the page to be loaded.
The load balancer returns the response back to the user.

Now that the page is loaded on the user’s device, another request should be made by the page asking to fetch the available products.

Request from the user to the internet-facing load balancer.
The load balancer routes the request to the api gateway.
The api gateway routes the request, through the internal load balancer, to the backend service that is supposed to fetch the products from the database.
The backend service queries, through the internal load balancer, the products from the database.
The response returns back to the user following the same route taken by the request.

If the page loaded contains files available in an S3 bucket, that is synced with AWS Cloudfront, the following steps are performed:

Request from the user to the Cloudfront service requesting a file.
Cloudfront checks if it possesses the file in one of the edge locations. If found, the file is directly served back to the user.
If missing, Cloudfront fetches the file from S3, returns it back to the user, and caches it.

Attaching the services as target groups to the load balancers provide multiple advantages (Which will be explored in details in the following chapter), namely security, through only allowing requests that match certain criteria pass, and load balancing, by balancing the requests through all the replicas registered of the same service.

In summary, this article described a brief overview of the infrastructure proposed, how it operates, and the advantages it provides. The next chapter will describe in details how microservices should be deployed in a secure, available, and scalable fashion, in addition to setting autoscaling policies and alarms.