In this tutorial, you’ll learn how to build and deploy a production-ready WhatsApp bot using:

• FastAPI

• Evolution API

• Docker

• EasyPanel

• Google Cloud Platform (GCP)

By the end of this guide, you will have a fully working WhatsApp bot connected to your own WhatsApp account and deployed on a cloud virtual machine.

Table of Contents

• How the Architecture Works

• How Your WhatsApp Bot Works

• Prerequisites

• Step 1: Create Firewall Rules on GCP

• Step 2: Create a Virtual Machine (Ubuntu 22.04)

• Step 3: SSH into the VM

• Step 4: Install Docker

• Step 5: Install EasyPanel

• Step 6: Open the EasyPanel Dashboard

• Step 7: Deploy Evolution API

• Step 8: Connect WhatsApp

• Step 9: Deploy the FastAPI Bot

• Step 10: Connect the Webhook - Telling Evolution API Where to Send Messages

• Step 11: Final Test

• Production Considerations

• Conclusion

How the Architecture Works

Before we start installing anything, let’s understand how the system works.

How Your WhatsApp Bot Works

Before we continue setting things up, let's make sure you understand what's actually happening behind the scenes. Don't worry – no technical experience needed here.

Imagine a postal service

Think of your WhatsApp bot like a very fast, automated postal service:

• Someone sends you a letter (a WhatsApp message)

• A postal worker (Evolution API) picks it up and brings it to your office

• Your office manager (FastAPI bot) reads it and writes a reply

• The postal worker takes the reply back and delivers it

That's it. That's the whole system.

The 7 steps

1. Someone sends a message to your WhatsApp number – just like texting a friend.

2. Evolution API notices the message – it's constantly watching your WhatsApp number for new messages, like a receptionist sitting by the phone.

3. Evolution API passes the message to your bot – it sends the message content to your app and says "hey, you've got a new message!"

4. Your bot reads the message and decides what to say – this is where your code does its job.

5. Your bot sends the reply back to Evolution API – "okay, send this response."

6. Evolution API delivers the reply through WhatsApp.

7. The user sees the reply on their phone – usually within seconds.

One line summary

User → WhatsApp → Evolution API → Your Bot → Evolution API → WhatsApp → User

Every step in this guide is just setting up one piece of that chain. Once they're all connected, the whole thing runs on its own automatically.

This architecture allows you to automate replies while keeping full control of your infrastructure.

Why These Tools?

Let’s briefly understand why we’re using each tool.

FastAPI

FastAPI is a modern Python framework for building APIs. It is fast, lightweight, and ideal for handling webhook requests from Evolution API.

Evolution API

Evolution API is a self-hosted WhatsApp automation server built on top of Baileys. It connects your personal WhatsApp account without requiring official WhatsApp Business API approval.

Docker

Docker allows us to run applications in containers. This makes deployments consistent, portable, and production-ready.

EasyPanel

EasyPanel is a graphical platform for managing Docker services. Instead of writing Docker Compose files manually, we use EasyPanel’s UI to deploy and manage our services easily.

Google Cloud Platform (GCP)

GCP provides the virtual machine that hosts our infrastructure. We will use an Ubuntu 22.04 server to run Docker, EasyPanel, Evolution API, and our FastAPI bot.

I chose these tools because they are practical, lightweight, and suitable for real-world production deployments.

Prerequisites

Before starting, make sure you have:

• A Google Cloud, AWS, or Azure account

• Billing enabled

• A project selected

• Access to Cloud Shell

• Basic Linux and Docker knowledge

Step 1: Create Firewall Rules on GCP

We need to allow traffic to specific ports on our VM. So, we run this command in GCP Cloud Shell:

gcloud compute firewall-rules create easypanel-whatsapp-fw \
 --network default \
 --direction INGRESS \
 --priority 1000 \
 --action ALLOW \
 --rules tcp:22,tcp:80,tcp:443,tcp:3000,tcp:8080,tcp:9000,tcp:5000-5999 \
 --source-ranges 0.0.0.0/0 \
 --description "SSH, EasyPanel, Evolution API, Bot"

This command:

• Creates a firewall rule named easypanel-whatsapp-fw

• On the default network

• Allows incoming internet traffic (INGRESS)

• Opens these ports:

  • 22 → SSH (server access)

  • 80 → HTTP

  • 443 → HTTPS

  • 3000, 8080, 9000 → App panels / APIs

  • 5000–5999 → Custom app range

• Allows access from any IP address (0.0.0.0/0)

Basically It opens your server so people (and you) can access your apps and services from the internet. This firewall rule allows external traffic to reach your VM.

Step 2: Create a Virtual Machine (Ubuntu 22.04)

Now we'll create the server that hosts everything. Run the following command in the GCP Cloud Shell to set up a virtual machine with Ubuntu 22.04.

gcloud compute instances create whatsapp-vm \
  --zone=asia-south1-a \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=30GB \
  --tags=easypanel

This command creates a new virtual machine (VM) on Google Cloud:

• Name: whatsapp-vm

• Location (zone): asia-south1-a (India region)

• Machine size: e2-medium (2 vCPU, 4GB RAM)

• Operating System: Ubuntu 22.04 LTS

• Disk size: 30GB

• Tag: easypanel (used to apply firewall rules)

This creates a Linux server in Google Cloud that you can use to host EasyPanel, WhatsApp bot, or your APIs.

Note: Wait about one minute for the instance to start.

Step 3: SSH into the VM

Connect to your server by using SSH to access the virtual machine you just created on Google Cloud.

gcloud compute ssh whatsapp-vm --zone=asia-south1-a

This command connects to your virtual machine named whatsapp-vm in the zone asia-south1-a using SSH (secure remote login).

It logs you into your Google Cloud server so you can start installing software and running commands. After running this, you will see a terminal prompt – that means you are now inside your Ubuntu server and ready to go.

Step 4: Install Docker

Docker is needed to run EasyPanel and the Evolution API.

First update the system:

sudo apt update -y
sudo apt install -y curl

This does two things:

1. sudo apt update -y→ Updates your server’s package list (refreshes available software info).

2. sudo apt install -y curl→ Installs curl, a tool used to download things from the internet using the terminal.

It prepares your server and installs a tool needed to download and install other software.

Then install Docker:

curl -fsSL https://get.docker.com | sudo sh

This command uses curl to download Docker’s official installation script. The | (pipe) sends it directly to sudo sh, which runs the script as administrator.

It automatically installs Docker on your server.

After this finishes, Docker should be installed.

Enable Docker:

sudo systemctl enable docker
sudo systemctl start docker

This command does two things:

1. enable docker→ Makes Docker start automatically every time the server reboots.

2. start docker→ Starts Docker right now.

It turns Docker ON now and makes sure it stays ON after restart.

Allow the Ubuntu user to run Docker:

sudo usermod -aG docker ubuntu

This command adds the user ubuntu to the Docker group.

This is important: By default, you must use sudo before every Docker command.After running this, the Ubuntu user can run Docker without needing sudo every time.

Note: This command assumes your username is ubuntu, which is the default on Google Cloud VMs. If your username is different, replace Ubuntu with your actual username.

Exit the session and reconnect:

exit
gcloud compute ssh whatsapp-vm --zone=asia-south1-a

1. exit→ Logs you out of your current server session.

2. gcloud compute ssh whatsapp-vm --zone=asia-south1-a→ Logs you back into your Google Cloud VM.

Why we do this: After adding the ubuntu user to the Docker group, you must log out and log back in for the permission changes to work.

Test Docker:

docker run hello-world

This command downloads a small test image called hello-world, runs it inside Docker, and prints a success message if Docker is working correctly.

It checks if Docker is installed and working properly. If you see “Hello from Docker!”, Docker is working correctly.

Step 5: Install EasyPanel

EasyPanel provides a user interface for deploying Docker services. Run this command in the VM:

curl -sSL https://get.easypanel.io | sudo bash

This command:

• Downloads the official EasyPanel installation script

• Runs it with administrator (sudo) permission

• Automatically installs and configures EasyPanel on your server

It installs EasyPanel on your VM so you can manage apps using a web dashboard instead of commands. Installation takes about one minute.

Step 6: Open the EasyPanel Dashboard

Once you have your IP address, open a new tab in your browser and type it in like this:

http://<YOUR_PUBLIC_IP>:3000

For example, if your IP was 34.123.45.67, you would type:

http://34.123.45.67:3000

EasyPanel runs on port 3000 by default – that's why we add :3000 at the end. Without it, your browser won't know which service to open on the server.

Create an admin account and log in; the EasyPanel login page will appear.

Click “Create Admin Account”.

Fill in:

• Username (choose something you’ll remember)

• Email

• Password (make it strong!)

• Submit the form.

You are now logged in as the admin and can start managing apps, APIs, and bots through the EasyPanel dashboard.

You will see a page like the one below:

Step 7: Deploy Evolution API

1. Create a new project (for example: whatsapp-1)

2. Go to Services → Templates

3. Select Evolution API

4. Deploy the latest version

Wait until all services turn green. You will see a page like the one below.

Next, open Environment Variables and locate:

AUTHENTICATION_API_KEY

Copy the AUTHENTICATION_API_KEY.

Open the Evolution API dashboard

Inside EasyPanel, find your Evolution API service. You will see a clickable domain link – it usually looks something like:

https://evolution-api.easypanel.host

Click that link to open it in your browser. You will see a JSON response confirming the service is running.

Once you open the link, you’ll see a JSON response confirming success. To proceed with login, copy the Manager link displayed in the response. This link opens the management dashboard where you can authenticate and begin using the Evolution API. The screenshot below highlights the manager URL along with version details for easy reference

Copy the manager link and open it in a new tab, then copy the AUTHENTICATION_API_KEY, which you did in the previous step. This is how it looks, as you can see below:

Create a new instance:

• Choose channel: Baileys

• Leave phone number blank

• Give your instance a name

Save the instance.

Step 8: Connect WhatsApp

Inside your instance dashboard:

1. Click Get QR

2. Scan it using WhatsApp on your phone

Once connected, your chats and contacts will sync automatically. If syncing fails, disconnect and reconnect the session.

Step 9: Deploy the FastAPI Bot

Now we’ll deploy the bot service.

1: Go to EasyPanel

You’re opening the EasyPanel dashboard you just installed. This is where you can manage apps, servers, and services using a graphical interface instead of terminal commands.

2: Create a new project

A “project” is like a container or folder for your bot service. It organizes all files, settings, and deployments for this app.

3: Add an App service

“App service” means a running instance of your application. In this case, it will be the WhatsApp bot.

4: Choose Git deployment

Git deployment lets you connect a code repository to EasyPanel.This will automatically download your code from GitHub and run it inside Docker.

5: Paste your repository URL

https://github.com/rajumanoj333/wabot

This is the GitHub repository containing the WhatsApp bot code. EasyPanel will clone this repo and prepare the app automatically.

6: Domains in EasyPanel

This section lets you assign a URL or domain name to your app service. Even if you don’t have a custom domain, you can use your server’s public IP. Your WhatsApp bot app runs on port 9000 inside the server.

7: Set the port to 9000

By setting the domain to use port 9000, EasyPanel knows where to send traffic.

Example URL after this step:

https://your-project.easypanel.host

This is the public address people (and other services) will use to reach your bot.

You’re telling EasyPanel:

“Whenever someone accesses this project, forward them to the bot service running on port 9000.”

Without this step, the bot service would run but you wouldn’t be able to access it from your browser or other apps.

Configure Environment Variables

Set the following variables:

EVOLUTION_API_URL=http://evolution-api:8080
EVOLUTION_API_KEY=YOUR_AUTHENTICATION_API_KEY
INSTANCE_NAME=your_instance_name

Note: You might notice two different names here – AUTHENTICATION_API_KEY (used in EasyPanel) and EVOLUTION_API_KEY (used in your bot code). They are the same key. Just copy the value from EasyPanel and paste it into both places.

Step 10: Connect the Webhook – Telling Evolution API Where to Send Messages

At this point, you have two separate things running:

1. Evolution API: the service that connects to WhatsApp and handles messages

2. Your app (fastapi bot): the chatbot brain you deployed in the previous steps

Right now, these two don't know each other exists. They're like two people in different rooms with no way to pass notes between them. A webhook fixes that.

So what exactly is a webhook?

A webhook is simply a URL (a web address) that you hand to one service so it can automatically notify another service when something happens.

You're going to tell Evolution API "whenever a WhatsApp message arrives, forward it to this address." Your app will be sitting at that address, waiting to receive it, read it, and send a reply.

Think of it like a forwarding address at the post office. When mail (a WhatsApp message) arrives, it gets automatically redirected to your app's door.

Let's set it up

1. Open your Evolution API dashboard.

You should already have this open from earlier steps. In the left sidebar, click on Events, then click on Webhook. This is where you control how Evolution API sends data to your app.

2. Turn the webhook on.

At the top of the page, you'll see a toggle next to the word "Enabled". Click it so it turns green. This tells Evolution API that you want to start using a webhook.

3. Enter your app's webhook URL.

In the URL field, type your app's address with /webhook added to the end, like this:

https://your-domain.easypanel.host/webhook

Replace your-domain with the actual domain name you set up when you deployed your app. The /webhook part at the end is important: it's a specific page your app has set up just for receiving these messages. Without it, Evolution API would be knocking on the wrong door.

4. Leave "Webhook by Events" and "Webhook Base64" turned off for now.

These are advanced options you won't need for a basic chatbot.

5. Scroll down to the Events section and enable these two events:

• MESSAGES_UPSERT: This triggers every time someone sends your WhatsApp number a message. Without this, your app would never know a message arrived.

• SEND_MESSAGE: This triggers when a message is sent out. It helps your app confirm that replies are going through correctly.

You can leave all the other events (like APPLICATION_STARTUP) turned off. They handle things like group chats and contact updates, which aren't needed for what we're building.

6. Click Save.

Quick recap of what you just did

You created a direct line between Evolution API and your app. Now, the moment someone messages your WhatsApp number, Evolution API will instantly pass that message along to your app. Your app reads it, figures out a response, and sends one back all automatically.

This is the step that brings your chatbot to life. Without it, nothing would happen when someone sent you a message. With it, the whole system clicks into place.

Step 11: Final Test

Send a message from a different WhatsApp number (not the connected one).

Send:

Hi

If everything is configured correctly, your bot should reply:

👋 Hello! Bot is working.

Congratulations! Your WhatsApp bot is now live.

Production Considerations

For real-world deployments, consider:

• Restricting firewall rules instead of allowing 0.0.0.0/0

• Using HTTPS with a custom domain

• Securing API keys with a secret manager

• Monitoring logs and container health

• Setting up automatic backups

This tutorial demonstrates the core working system, but these improvements will make your deployment more secure and scalable.

Conclusion

You now have a fully self-hosted WhatsApp bot running on a cloud VM using FastAPI, Evolution API, Docker, EasyPanel, and GCP.

This setup gives you:

• Full control over infrastructure

• No dependency on expensive SaaS platforms

• Production-ready container deployment

• Scalable architecture

From here, you can extend your bot with:

AI integrations : connect your bot to ChatGPT or Gemini or Claude so it can answer questions intelligently instead of just sending fixed replies.

Database storage: save incoming messages, user details, or conversation history to a database like PostgreSQL or MongoDB.

Custom automation workflows trigger actions based on keywords, like sending a PDF when someone types "menu" or booking an appointment when they type "schedule".

CRM integrations :connect your bot to tools like HubSpot or Notion to automatically log leads and customer conversations.Building your own infrastructure is one of the best ways to deeply understand how modern backend systems work together.

Happy building!

Among the many managed Kubernetes services AWS offers, Amazon EKS (Elastic Kubernetes Service) stands out for its seamless integration with the AWS ecosystem, strong reliability, and excellent support.

If you’re ready to move beyond local setups and want to deploy a real-world Kubernetes app on AWS EKS, this guide will walk you through the entire process. Whether you’re working on a microservice, a full-stack app, or just experimenting with Kubernetes in an environment that mimics production, you’ll find this walkthrough useful.

In this article, I’ll guide you through the process of creating your EKS cluster, deploying your application, and making it accessible over the internet, step by step.

What We’ll Cover:

• Prerequisites

• What is a Kubernetes Cluster?

• What is Amazon Elastic Kubernetes Service?

• Why Use Amazon EKS for Kubernetes?

• How to Create a Kubernetes Cluster Using AWS

• Conclusion

• Resources

Prerequisites

To get started, make sure you have the following installed on your local machine:

• Have a basic understanding of cloud services.

• Have a basic understanding of the Linux command line.

• Have an AWS account.

• Install eksctl, a simple CLI tool to create and manage EKS clusters.

• Install kubectl, the standard Kubernetes command-line tool.

• Install Docker to build and package your app into a container.

Before setting up a Kubernetes cluster for our application, it’s essential to understand a few basic concepts.

What is a Kubernetes Cluster?

A Kubernetes (also called K8S) cluster consists of machines (called nodes) that run containerized applications. It works alongside container engines like CRI-O or containerd to help you deploy and manage your apps more efficiently.

Kubernetes nodes come in two main types:

• Master nodes (control plane): These handle the brainwork, such as scheduling, scaling, and managing the cluster’s overall state.

• Worker nodes (data plane): They run the actual applications inside the containers.

If you're new to Kubernetes or want to brush up, check out the free course Introduction to Kubernetes (LFS158) from the Linux Foundation.

What is Amazon Elastic Kubernetes Service?

Amazon Elastic Kubernetes Service (EKS) is a managed service that enables easy Kubernetes deployment on AWS, eliminating the need to set up and maintain your own Kubernetes control plane node.

AWS EKS takes care of the heavy lifting by managing the control plane, handling upgrades, and installing core components, such as the container runtime and essential Kubernetes processes. It also offers built-in tools for scaling, high availability, and backup.

With EKS, you or your team can focus on building and running applications, while AWS handles the underlying infrastructure.

Why Use Amazon EKS for Kubernetes?

Here are some key benefits of using AWS EKS:

• EKS handles upgrades, patching, and high availability for you, giving you a fully managed control plane with minimal manual effort.

• You can easily scale your applications, and the infrastructure grows as your needs evolve.

• It has built-in support for IAM roles, private networking, and encryption.

• AWS EKS runs on highly available infrastructure across multiple AWS Availability Zones, making your application available globally.

• With Amazon EKS, you get the power of Kubernetes without managing the underlying setup. So you can stay focused on building and running your apps.

How to Create a Kubernetes Cluster Using AWS

Now let’s walk through the process of getting a Kubernetes cluster up and running.

Step 1: How to Install the Tools Needed to Create a Cluster

The easiest and most developer-friendly way to spin up an Elastic Kubernetes Service that you can use at the production level is by using eksctl. It takes care of the manual setup and automatically provisions the necessary AWS resources.

Before we begin, we need to install two essential tools:

• eksctl – This is used to create and manage your EKS cluster.

• kubectl – This allows you to interact with your cluster, deploy apps, and manage Kubernetes resources.

These tools will make it easy to set up your Kubernetes cluster and work with it directly from your terminal.

How to Install eksctl

Open your browser and go to the official eksctl documentation. Scroll down to the Installation section.

Scroll to the Unix instructions if you're using Ubuntu or a similar system. Then copy the installation command and paste it into your terminal.

Once it’s done, run eksctl version to confirm that the installation was successful.

How to Install kubectl

The next step is to install kubectl. You can find the installation instructions in the official Kubernetes documentation, which provides steps based on your operating system.

Step 2: How to Create the Elastic Kubernetes Service (EKS) Cluster

Now that you've installed the tools needed to create and interact with a Kubernetes cluster on AWS, it's time to launch the cluster.

To get started, open your terminal and run the following command:

# Create an EKS cluster named "k8s-example" in eu-west-2 (London)
eksctl create cluster --name k8s-example --region eu-west-2

One great thing about using AWS EKS is that once your Kubernetes cluster is created, it automatically updates your ~/.kube/config file. This means you can start interacting with your cluster right away, using kubectl – no extra setup needed.

After running the command (as shown in the GIF above), your Kubernetes cluster is successfully created.

Head over to the AWS console, and you’ll see your new cluster listed with a status of Active.

With your cluster up and running, it’s time to test the connection. You can do this by running a few kubectl commands in your terminal to list the nodes, pods and namespaces in your cluster.

To test the connection:

kubectl get nodes

This command lists all the nodes in your cluster.

kubectl get pods

This command lists all the pods currently running.

kubectl get namespaces

This command lists all the namespaces currently running.

If each command returns a list of resources, congratulations! Your connection to the Kubernetes cluster is successful.

Step 3: How to Create Kubernetes Manifests

Let’s define the application using a YAML file. In this file, you’ll create two key resources: a Deployment and a Service.

• The Deployment ensures your application runs reliably by specifying how many replicas to run, which container image to use, and how to manage updates.

• The Service makes your application accessible — both within the Kubernetes cluster and, if needed, from the internet, even if the underlying pods change or restart.

Together, these resources orchestrate your application so it can run consistently in different environments and be accessed by others.

#deployment-example.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amazon-deployment
  namespace: default
  labels:
    app: amazon-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: amazon-app
      tier: frontend
      version: 1.0.0
  template:
    metadata:
      labels:
        app: amazon-app
        tier: frontend
        version: 1.0.0
    spec:
      containers:
        - name: amazon-container
          image: ooghenekaro/amazon:2
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: amazon-service
  labels:
    app: amazon-app
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: amazon-app

The service uses a LoadBalancer type, which tells AWS to provision an Elastic Load Balancer (ELB) and route traffic to the pods.

Step 4: How to Deploy the App to EKS

Now that your YAML file is defined and the Kubernetes cluster on AWS EKS is ready, it’s time to deploy your application.

To do this, run the following command in your terminal to apply the configuration defined in your manifest file:

kubectl apply -f deployment-example.yaml

This command tells Kubernetes to create the necessary pods and services based on what’s specified in the manifest file.

Next, you can check the status of your pods and services:

kubectl get pods
kubectl get svc or service
kubectl get all

Step 5: How to Access Your Application

To view your application in the browser, run the following command to list your services:

kubectl get svc

Look for the EXTERNAL-IP of your service.

Copy the IP address and paste it into your browser. Your app should now be live!

Conclusion

Deploying a Kubernetes app on AWS EKS may seem complex at first, but with tools like eksctl and kubectl, the process is surprisingly approachable.

Whether you're a developer experimenting with Kubernetes or a team looking to scale production workloads, EKS provides a strong, scalable foundation that supports your applications as they grow.

Resources

• Play with Kubernetes

• Docker 101 Tutorial

• How to Create a CI/CD Pipeline Using AWS Elastic Beanstalk

Thanks for reading!

Why Learn Data Analytics with Google Cloud?

Turning raw numbers into actionable insights is a skill that sets you apart in the job market. As a Cloud Data Analyst, you’ll be able to unlock the stories hidden within massive datasets, helping organizations make smarter, faster decisions.

This course will help you enter that world. It offers a blend of expert instruction, hands-on labs, and real-world projects that will help you build a portfolio to impress employers.

What’s In the Course?

This course is a carefully curated program developed by Google Cloud, designed to take you from beginner to job-ready. You’ll learn technical skills like SQL, data visualization, and cloud storage. And you’ll also learn how to communicate your findings and drive business impact.

The course is structured to help you build a portfolio of industry-relevant projects, so you can showcase your expertise to potential employers.

Here’s what you’ll learn:

1. Introduction to Data Analytics in Google Cloud
Get a solid foundation in cloud data analysis. You’ll define the field, explore the roles and responsibilities of a cloud data analyst, and understand how data analytics drives business value. This module sets the stage for your journey, introducing you to the tools and concepts you’ll use throughout the program.

2. Data Management and Storage in the Cloud
Dive into how data is structured, organized, and stored in the cloud. You’ll get hands-on with data lakehouse architecture and tools like BigQuery, learning how to manage data efficiently and securely. This section is crucial for understanding how to handle large-scale datasets in a modern cloud environment.

3. Data Transformation in the Cloud
Follow the journey of data from collection to insight. You’ll learn to use SQL and other tools to clean, transform, and prepare data for analysis. By mastering data transformation, you’ll be able to turn messy, raw data into clean, usable information.

4. The Power of Storytelling: How to Visualize Data in the Cloud
Master the art of data visualization. This course teaches you how to turn complex data into clear, compelling stories using cloud-based visualization tools, making your insights accessible to any audience. You’ll learn the five key stages of visualizing data in the cloud, from planning to building impactful dashboards.

5. Put It All Together: Prepare for a Cloud Data Analyst Job
Apply everything you’ve learned in a capstone project that simulates real-world challenges. You’ll combine your skills in analysis, visualization, and communication to solve a comprehensive data problem, building a portfolio piece that demonstrates your ability to analyze, visualize, and communicate data insights.

Learn by Doing

The course is designed to be watched alongside the Google Cloud Skills Boost platform, where you’ll find interactive labs and practice environments. You get 35 free credits per month for labs, and if you want to move faster, you can pay for unlimited access. These labs give you the chance to practice your skills in real cloud environments, reinforcing your learning with practical experience. Complete the program and you’ll earn a Google Cloud Data Analytics Certificate.

Start Your Journey Today

Whether you’re just starting out or looking to advance your career, this course is for anyone who wants to harness the power of data. If you’re interested in technology, business, or problem-solving, this course will give you the tools you need to succeed in the fast-growing field of data analytics.

Watch the full course on the freeCodeCamp.org YouTube channel and begin your journey into cloud data analytics (10-hour watch).

It all sounds important...but also a little confusing. Like, why are there so many moving parts? And what do they actually do?

In this guide, we’re going to break it all down – step by step – using real examples and simple language.

You’ll learn:

• What load balancers are (and why apps even need them)

• How apps were deployed before load balancers existed (hint: everything lived on one lonely server)

• How Azure Virtual Machines work – and how they let you scale up your apps

• What Virtual Machine Scale Sets are, and how they help handle sudden traffic spikes

• The differences between Azure Load Balancer and Azure Application Gateway, and when to use each

By the end, you won’t just understand what these tools do – you’ll know when and why to use them in real-world scenarios.

Whether you’re a curious beginner, a hands-on builder, or someone just trying to wrap their head around Azure’s ecosystem, this guide is for you.

Ready to untangle the cloud spaghetti? Let’s go! 🍝🚀

📚 Table of Contents

1. 🧊 What Are Load Balancers?

2. 🖥️ How Applications Were Deployed Before Load Balancers

3. ⚙️ Azure Virtual Machines (VMs) – The Building Blocks

4. 📈 The Need for Scaling – Vertical vs Horizontal

5. 🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

6. 📦 Azure Load Balancer – Spreading the Traffic

7. 🍴 Azure Application Gateway – Smart Routing for Modern Apps

8. 🔍 Azure Load Balancer vs Azure Application Gateway

9. 🧭 Use Cases: When to Use Each One

10. ✅ Conclusion

11. Study Further 📚

12. About the Author 👨‍💻

🧊 What Are Load Balancers?

Imagine you're running a small restaurant with just one chef in the kitchen. Everything goes smoothly when you have a few customers – each order is prepared one after the other, and everyone leaves satisfied.

But what happens when 50 people walk in all at once?

🍽️ One chef can’t handle that many orders at the same time.
⏳ People start waiting longer.
😤 Some customers leave.
💥 The chef gets overwhelmed – and eventually burns out.

This is what can happen to a server (the computer running your app) when too many users try to access it at the same time.

So, What Does a Load Balancer Do?

A load balancer is like a smart restaurant manager. But instead of food orders, it handles user requests – the things people do when they open your app, click buttons, or load data.

Let’s say you now have three chefs (servers) instead of one. The load balancer’s job is to:

• 👀 Watch for incoming orders (user requests)

• 🧠 Decide which chef (server) is available or least busy

• 🍽️ Send that request to the right one

• 🔁 Repeat this over and over, making sure things stay fast and smooth

So in simple terms, a load balancer takes all the incoming traffic to your app and distributes it across multiple servers so no single server gets overloaded – cool, right? 🙂

Why Were Load Balancers Introduced?

Back in the early days, many applications were hosted on just one machine – called a Single Server Deployment.

That was okay when you had a small number of users. But once things started to grow – more users, more actions, more data – single servers became a bottleneck:

• They could only handle a limited number of requests.

• If they went down, your entire app would stop working.

• Scaling (adding more power) was expensive and manual.

💡 Enter load balancers – designed to solve this by making it possible to:

• Spread traffic across multiple servers (so no one server crashes under pressure),

• Replace or restart servers without downtime,

• Add or remove servers as needed, depending on how busy your app is (this is called scaling).

A Simple Use-Case Scenario

Let’s say you're building an online store — your own mini Amazon. At first, you host your app on one Azure Virtual Machine. Things are great. But one day, you run a huge promo and suddenly…thousands of people flood in to browse, shop, and check out.

Your single VM starts lagging.

Orders fail. People complain. Your dream app? Crashing fast. 💥

So what do you do?

You spin up two more VMs to help out – but now you’ve got another problem: How do you divide the traffic between the three?

This is where the load balancer steps in. It:

• Looks at every incoming user request

• Figures out which VM is available and least busy

• Sends the request there

• Keeps rotating requests in real-time

And the result?
✅ No single VM gets overwhelmed
✅ Your app stays fast and responsive
✅ Users are happy (and buying stuff again!)

🖥️ How Applications Were Deployed Before Load Balancers

Before cloud tools like load balancers came along, the typical way to run an application was pretty simple: You’d deploy the entire app on a single server, like running a small business from one tiny shop.

First Things First: What’s a Server?

Think of a server as a special computer that’s always connected to the internet. Its job is to “serve” your app to people when they visit your website, open your app, or use your service.

In cloud platforms like Azure, we usually call these Virtual Machines (VMs) – basically, software-powered servers you can spin up with a few clicks.

Monoliths vs Microservices

Now, applications come in different “shapes.” The two most common are:

• Monoliths: Everything is bundled together into one big app. All the code – from user login to shopping cart to checkout – lives in a single unit.

• Microservices: The app is broken into smaller, independent apps (services). Each service does one job – like login, payments, orders – and runs separately.

How Were These Apps Deployed?

Whether it was a monolith or a bunch of microservices, they were all usually deployed on a single server (VM).

For monoliths, you just ran the entire app directly on the server. For microservices: you'd run each service in a separate space on that same server, using containers.

Wait — What’s a Container?

A container is like a mini-computer inside a computer. It has everything an app needs to run – code, tools, settings – and it keeps each app isolated from the others.

Why use containers?

• You can run multiple services on the same server without their underlying software (software needed for each app to run) interfering with each other.

• It’s faster and more efficient than installing everything directly on the server.

• They make moving apps between environments (for example, test → production) super smooth (no more “But, it works on my machine…”).

Popular tools like Docker make working with containers easy.

Connecting It All Together: Domains, Subdomains, and Reverse Proxies

When your app lives on a server, you want people to be able to reach it. That’s where domain names come in.

• Your server has a public IP address – a set of numbers like 102.80.1.23, that gives it a unique identifier on the public internet

• But instead of asking users to type numbers, you link that IP to a domain name, like mycoolapp.com

If your app has microservices, you might even assign subdomains like:

• api.mycoolapp.com for the backend

• dashboard.mycoolapp.com for the user interface

• payments.mycoolapp.com for payments

To manage all this, you’d use a reverse proxy (like Nginx or Apache). It listens on the main domain and subdomains, and forwards traffic to the right app or service.

Example:

• Someone visits dashboard.mycoolapp.com

• The reverse proxy checks the domain and forwards the request to the correct container running the dashboard service

And to help with all of this setup – from deploying containers to configuring reverse proxies – there are developer-friendly tools like Coolify. Coolify is an open-source platform that makes it super easy for developers and DevOps teams to:

• Deploy apps in containers

• Set up domains and subdomains

• Configure reverse proxies – all from a clean dashboard, no complex terminal commands needed

All this was set up on ONE SERVER/VM. But here’s the catch: when that one server got overloaded or went down…💥 everything stopped.

That’s why we needed a better way. And that's where scaling and load balancing came in – to keep apps running smoothly, no matter the traffic.

⚙️ Azure Virtual Machines (VMs) – The Building Blocks

When it comes to running apps in the cloud, Virtual Machines (VMs) are the basic building blocks – kind of like renting an apartment in a giant digital skyscraper.

You don’t need to buy the whole building (aka physical servers), you just rent the space you need, when you need it.

What Exactly Is a Virtual Machine?

A Virtual Machine is a software-based computer that runs inside a real, physical computer (a server) – hosted in a data center, like those run by Microsoft Azure.

It looks and behaves like a normal computer:

• It has an operating system (Windows, Linux)

• You can install apps

• It has memory (RAM), storage (disks), and CPU

But the best part? You don’t need to worry about the hardware. Azure takes care of that behind the scenes – all you do is say:

“Hey Azure, give me a Linux VM with 4GB RAM and 2 CPUs.”

And boom 💥 — it spins up in minutes.

Why Use a VM?

Let’s say you’ve built a web app – it’s just a simple blog. You want to deploy it and make it accessible to the world.

Here's what you can do with a VM:

• Set it up with your favorite OS (for example, Ubuntu)

• Install web servers like Nginx or Apache

• Deploy your app

• Bind it to your domain name

• Let the world visit your blog at myawesomeblog.com

It’s your own personal environment – no sharing, full control.

📈 The Need for Scaling – Vertical vs Horizontal

Imagine your app is growing. At first, it’s just a few users. Then a few hundred. Then thousands are logging in, placing orders, chatting, uploading photos – all at once 😮

Suddenly, your server (VM) is under pressure. It’s like trying to pour a flood through a straw.

So, What Do You Do When One Server Isn’t Enough?

This is where scaling comes in – the art of upgrading your app’s infrastructure to keep up with traffic.

There are two main ways to scale:

🧱 Option 1: Vertical Scaling (aka Scaling Up)

You take your existing VM and give it more power:

• Add more CPUs 🧠

• Increase RAM 🧵

• Add faster disks ⚡

Think of it like upgrading from a regular car to a sports car. It’s the same vehicle, just faster and stronger.

Pros:

• Simple to do

• No major changes to your app setup

Cons:

• There’s a limit to how much you can upgrade

• Still a single point of failure: if the VM crashes, everything goes down 😬

🧩 Option 2: Horizontal Scaling (aka Scaling Out)

Instead of boosting one server, you add more servers – multiple VMs running copies of your app.

Now:

• Users can be distributed across all these VMs

• If one goes down, others keep serving traffic

• You can dynamically add or remove VMs based on traffic

It’s like opening more checkout counters in a busy supermarket 🛒

Pros:

• The load is evenly distributed. For example, if one server previously handled 100% of the traffic, adding two more servers would result in the traffic being split into approximately 33% to 34% for each server.

• Improves both performance and reliability

• You can scale based on real-time demand, that is traffic inflow

Cons:

• Needs something to split traffic between VMs – Load Balancers

• More expensive. You end up paying the original amount for 1 VM (for example $30) for the number of VMs you provide – if you provide 3 VMs at $30 each, you end up paying $90 at the end of the month

Quick Real-World Example

Let’s say you’ve launched an e-commerce site for sneakers 👟 Traffic spikes during a big sale? Your vertical scaling (bigger VM) might choke.

But with horizontal scaling:

• You spin up 5 VMs across different regions

• Traffic is shared between them

• If one VM slows down, others handle the load

So, remember 👇🏾

🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

Okay – so we’ve talked about horizontal scaling: adding multiple VMs to handle growing traffic. Sounds great, right?

But here’s the thing: manually spinning up and configuring 5, 10, or 100 VMs... every time your app gets busy? Yeah, that’s not fun 🙃

Enter: Virtual Machine Scale Sets (VMSS)

VMSS is Azure’s way of automating horizontal scaling. Instead of creating each VM one by one, you define a template, and Azure takes care of the rest:

• How many VMs to start with

• How to configure them (OS, apps, settings) ⚙️

• When to add or remove VMs based on traffic 📈📉

A Simple Analogy 🧃

Think of VMSS like a juice dispenser at a party:

• At first, it pours into 2 cups (VMs)

• If 10 guests show up? It starts filling 5 cups

• Party slows down? Back to 2 cups again

You never have to refill manually – the dispenser adjusts on its own. 🎉

How It Works (Without the Jargon 😌)

1. You set the rules: “If CPU usage goes above 70%, add 2 more VMs.”

2. Azure watches traffic and adjusts the number of VMs automatically.

3. All VMs are identical – like clones, all running the same app setup.

4. It works with Azure Load Balancer to spread traffic across all these VMs smoothly.

Real-Life Example: Food Delivery App 🍕📱

You’ve built an app where users order food. During lunch and dinner, traffic explodes.

💡 With VMSS:

• You start with 3 VMs in the morning

• At 12PM, Azure sees high CPU usage, so it spins up 5 more VMs

• At 3PM, traffic drops, so Azure removes the extra VMs

You only pay for what you use. And users get a smooth experience – no delays, no crashes 👌🏾

📦 Azure Load Balancer – Spreading the Traffic

By now, you know that your app can live on multiple Virtual Machines (VMs), and that you can scale them easily using Virtual Machine Scale Sets (VMSS).

But here's the big question: when users start accessing your app – hundreds, even thousands at once – how do you make sure that all that traffic is fairly and efficiently distributed across those VMs?

You don’t want one VM to be overwhelmed while others are just chilling. You need a middleman – something smart enough to balance the load.

That’s where Azure Load Balancer steps in. It’s Azure’s way of saying, “Don’t worry, I got this” when traffic starts rolling in.

🏢 So, What Is Azure Load Balancer?

Azure Load Balancer is a traffic director. It takes incoming traffic from the internet (or even internal sources within your network) and intelligently spreads it across multiple backend machines – usually VMs.

It's like having a well-trained receptionist who routes every customer to the next available agent, so no one waits too long and no one gets overwhelmed 😃.

And the best part? This entire process happens in the background – fast, silent, and seamless. Users visiting your app have no idea a traffic manager is working behind the scenes. They just see a fast, responsive experience.

🌐 The Frontend IP – Your App’s Public Face

Every Azure Load Balancer is tied to a Frontend IP, which is basically the public IP address of your application – the one users connect to when they open www.yourapp.com.

This IP acts as the entry point. All user traffic comes through it first. But the Load Balancer doesn’t actually run your app. Instead, it accepts the traffic and forwards it to one of the VMs in the backend pool (we’ll get to that shortly).

You can configure this Frontend IP to be either public (accessible over the internet) or private (used for internal traffic within your cloud network – say, between microservices or internal tools).

🗂️ Backend Pool – Where the Magic Happens

Behind every Azure Load Balancer is a backend pool – a group of VMs (or VM Scale Set instances) where your actual app is running. These are the real workers, doing all the heavy lifting.

When traffic hits the Frontend IP, the Load Balancer takes that request and hands it off to one of the VMs in the backend pool.

But it doesn’t just randomly pick one. It checks a few things first – like whether the VM is healthy, whether it's already busy, and what rules you’ve set.

Each VM in the pool typically runs the same app or service. This means any of them can handle any incoming request, which is what makes load balancing possible in the first place.

🩺 Health Probes – Keeping Tabs on the VMs

Now, how does the Load Balancer know which VM is healthy or not? This is where health probes come in. Think of them as regular check-ups.

You configure the Load Balancer to periodically "ping" each VM – maybe by hitting a specific URL (like /health) or a certain port (like 80 for HTTP). If a VM doesn’t respond correctly, Azure marks it as unhealthy and temporarily removes it from the rotation.

This ensures users never get routed to a broken or unresponsive instance of your app. And once the VM becomes healthy again, it's automatically added back to the pool.

⚖️ Load Balancing Rules – Who Gets What?

Next, we have Load Balancing Rules. These are the instructions that tell Azure Load Balancer exactly how to behave.

You can define rules like:

• “Forward all HTTP (port 80) traffic to backend pool VMs on port 80”

• “Forward HTTPS (port 443) traffic to VMs on port 443”

• “Only route traffic to healthy VMs”

These rules make Azure Load Balancer highly customizable. You get to decide how traffic flows, which protocols to support, and how to handle backend ports. It's like customizing the rules of a relay race – who gets the baton and when.

👟 Real-World Example: Sneaker Sale Rush

Imagine you're running an online sneaker store at www.sneakerblast.com. You’re launching a flash sale, and thousands of users are hitting your website all at once.

Thanks to your Azure Load Balancer, here’s what happens:

1. All those users land on your Frontend IP, the public face of your site.

2. The Load Balancer accepts the traffic and checks the health probes of all VMs in the backend pool.

3. Based on its rules, it forwards each user to a healthy, available VM.

4. One VM might serve a user in Lagos, another in Nairobi, another in Accra – all seamlessly.

If one VM crashes or lags? The Load Balancer detects it instantly and stops routing traffic to it until it’s back online.

That’s smooth traffic management without any manual effort.

🍴 Azure Application Gateway – Smart Routing for Modern Apps

So far, we’ve seen how Azure Load Balancer helps you split traffic across multiple VMs running a single service – like a monolithic app or a web frontend.

Let’s say you have a web application deployed on a VM. It listens on port 80, and you’ve scaled it into 3 instances. The Azure Load Balancer takes requests from the internet and spreads them across all 3 instances of the same service. Easy, right?

You can even link the Load Balancer’s public IP address to your domain – like mydomain.com – so users can visit your site normally.

🧠 But What If You Have Multiple Services?

Now imagine you’ve gone beyond just one app. You’re building something more modern, like a set of microservices.

You now have:

• A payment service listening on port 5000

• An authentication service on port 6000

• A purchase service on port 7000

All deployed across the same VMs (or Virtual Machine Scale Set), just on different ports.

Here’s the problem: an Azure Load Balancer is designed to route traffic to one backend pool – basically one service – on one port. If you tie it to mydomain.com, it can only send traffic to one of your microservices. 😬

So… what do you do?

You might think: “Let me just create a separate Load Balancer for each service!” 🤕

But that means:

• You’ll have to pay for multiple load balancers

• You’ll end up managing 3–5 public IP addresses

• You might even need to buy multiple domains like mypayment.com, myauth.com, and so on to route users properly

Yikes. That’s impractical, messy, and expensive 😖💸

🎉 Enter Azure Application Gateway

Azure Application Gateway solves this problem beautifully. It’s designed to route traffic intelligently – not just to one service, but to multiple services using just one gateway.

It works like this:

1. You create one public-facing frontend IP (like 52.160.100.5)

2. You link that IP address to your main domain, for example mydomain.com

3. Then, you define multiple backend pools – one for each service:

   • Payment service (port 5000)

   • Auth service (port 6000)

   • Purchase service (port 7000)

4. Next, you set up routing rules that decide how to forward each request.

✨ Two Ways to Route with Application Gateway

You can configure smart routing based on:

• URL paths:

  • mydomain.com/payment → Payment service

  • mydomain.com/auth → Auth service

• Subdomains (host headers):

  • payment.mydomain.com → Payment service

  • auth.mydomain.com → Auth service

This way, all your services share one public IP and one domain – super clean, super efficient 🙌🏾

🤓 Real-Life Scenario (Let’s Break It Down)

Let’s say you’re building a startup platform that has three key microservices:

• Payment service that handles transactions

• Authentication service that handles login and user identity

• Purchase service that manages product ordering

Each service is containerized and deployed on the same VM (or across several VMs using a VM Scale Set). But – and this is key – they all listen on different ports inside the VMs:

• Payment → port 3000

• Auth → port 6000

• Purchase → port 7000

Now, without a smart routing solution, you’d be stuck trying to expose just one of these services using a standard Azure Load Balancer. But you need all three to be accessible from the internet – and you don’t want to pay for or manage 3 different Load Balancers 😅

So, what do you do?

🧠 Using Azure Application Gateway to Route Traffic Intelligently

Here's how you can fix this using one Application Gateway:

1. Deploy your microservices inside each VM:

   • Each service runs on a specific port

   • All VMs in your scale set are identical (they contain all three services)

2. Create backend pools in Application Gateway:

   • A backend pool for the payment service (pointing to port 3000 on all VMs)

   • One for the auth service (port 6000)

   • Another for the purchase service (port 7000)

3. Create routing rules:

   • Option A (Path-based routing):

     • Requests to mydomain.com/payment → go to the payment backend pool

     • Requests to mydomain.com/auth → go to the auth backend pool

     • Requests to mydomain.com/purchase → go to the purchase backend pool

   • Option B (Subdomain-based routing):

     • payment.mydomain.com → payment service

     • auth.mydomain.com → auth service

     • purchase.mydomain.com → purchase service

You just tell the Application Gateway: “Hey, if a request comes in for this URL or subdomain, send it to this port on these VMs.” And it does just that – consistently and intelligently 🔁

📦 So, What’s Really Happening?

Imagine a user visits mydomain.com/auth. Here’s what goes on behind the scenes:

1. The DNS translates mydomain.com to your Application Gateway’s public IP

2. The Gateway receives the request

3. It checks your routing rules

4. It sees that /auth should go to the backend pool for port 6000

5. It forwards the request to one of the VMs running the auth service

6. The response goes back to the user – fast and seamless ✨

This happens in milliseconds, for every request. And because the Application Gateway is aware of multiple ports and services, it can handle routing logic that a regular Load Balancer just can’t do.

🔍 Azure Load Balancer vs Azure Application Gateway

By now, you've seen how both tools help route traffic in Azure – but they solve different problems.

Let’s break down how they compare, and when you should use one over the other 👇🏾

🛣️ 1. Routing Logic

Azure Load Balancer
It simply distributes incoming traffic evenly across a pool of VMs. It doesn’t care what the request is – it just balances the load.

Imagine a delivery guy who doesn't ask questions – he just drops each package at the next available house.

That’s what Azure Load Balancer does: it sends traffic to one of your servers without looking inside the request.

Azure Application Gateway
This is the smart one. It looks at what’s inside each request (like the URL path or domain) and makes intelligent decisions.

Just like a smarter delivery guy who looks at the address and decides where to go: "Oh! This one is for the payment office, not the main office."

That’s what Application Gateway does: it reads the request (like the URL or domain name) and sends it to the right place according to the routing rules.

🌐 2. Protocols Handled

Load Balancer
Works at the transport layer (Layer 4 in the OSI model). It deals with TCP/UDP traffic – raw network traffic, like HTTP, video streaming, games, and so on.

Application Gateway
Works at the application layer (Layer 7). It handles web traffic only – like websites and apps (HTTP/HTTPS) – and it can actually read what's being asked, like:

• “Go to /login”

• “Go to payment.mydomain.com”.

TL;DR: Load Balancer just pushes packets. App Gateway actually reads your web requests.

🔁 3. Use Case Scenarios

🔐 4. SSL Termination & Security Features

Load Balancer doesn’t handle security stuff. You’ll need to secure each server yourself (for example, set up HTTPS on each one).

Application Gateway can secure everything in one place – you upload your SSL certificate once and it takes care of HTTPS for all services.

It can also protect you from hackers and bad traffic with something called WAF (Web Application Firewall), which protects your app from threats like SQL injection, XSS, and so on (you need to set this up manually).

💰 5. Pricing and Complexity

Load Balancer is cheaper and easier to set up. Great when you don’t need anything fancy.

Application Gateway costs more, but gives you more control and less headache when working with complex apps and microservices.

Trying to use Load Balancer for multiple services? You’ll need to create one Load Balancer per service, which becomes costly and impractical.

🧠 Summary Table

🧭 Use Cases: When to Use Each One

There’s no one-size-fits-all when it comes to hosting apps in the cloud. The right setup depends on what you’re building, how much traffic you expect, and how complex your app is.

Let’s walk through 4 different use-case scenarios, starting from the most basic setup all the way to a fully auto-scaled and smartly routed architecture.

1️⃣ Single VM Instance – For Small Projects or Internal Tools

Use this when:
You're just getting started. You’ve built a small app – maybe a portfolio, a blog, or a side project – and you want to make it live, OR You’re a startup that just launched.

How it works:
You spin up one Azure VM, install your app on it, and open the port it listens on (for example, port 80 for a web server). You can then attach a public IP to the VM and bind it to a custom domain like myawesomeapp.com.

Real-life examples:

• A developer hosting a portfolio website or blog

• A startup testing a new product with only a few users

• An internal company tool for a small team

Pros:

• Super simple setup

• Low cost

• Full control of your environment

Cons:

• If the VM goes down, your app goes down

• No auto-scaling – performance may drop with traffic spikes (the only way to adapt to increased CPU/memory usage due to traffic inflow is via manually scaling the VM vertically)

• You manually maintain and monitor everything

2️⃣ Manual Horizontal Scaling – For Apps With Medium, Predictable Traffic

Use this when:
Your app is growing – maybe you have a few thousand users now, and performance matters. You want more than one server so your app doesn’t crash during busy hours.

How it works:
You manually create 2 or 3 Azure VMs with the same app setup. You then add a Load Balancer in front to split traffic evenly across them.

Real-life examples:

• A business with a customer portal

• A school website that handles regular logins, lecture video streaming, and so on during class hours

• An app that gets traffic mostly during the day (predictable load)

Pros:

• Better performance and availability

• Load is shared across multiple VMs

• You can scale manually when needed

Cons:

• You must manually add or remove VMs – which takes effort

• Still need to monitor performance manually

• No built-in automation or auto-healing

3️⃣ Auto-Scaling with VM Scale Sets + Azure Load Balancer – For Apps With Spiky or Unpredictable Traffic

Use this when:
You’re building something more serious – traffic comes in waves (for example, a fitness/coach booking app), and you don’t want to sit around scaling VMs all day. You want Azure to automatically scale your infrastructure for you.

How it works:
You set up a Virtual Machine Scale Set (VMSS) that can automatically create more VMs when needed (like during high traffic), and remove them when things are calm — saving money. A Load Balancer distributes traffic across all those VMs.

Real-life examples:

• A media platform where people upload videos or photos

• A shopping site that gets surges during promotions, for example Black Fridays

• A booking platform with peak traffic in evenings/weekends

Pros:

• Automatic scaling – saves time and money

• High availability: VMs can be replaced if one fails

• Easy to grow as your user base grows

Cons:

• Works best if your app is monolithic (one big service)

• No support for routing traffic to specific services – just spreads traffic across VMs

• Load Balancer can’t look at URL paths or subdomains

4️⃣ VM Scale Set + Azure Application Gateway – For Microservices or Complex Web Apps

Use this when:
You have a modern, multi-service app – maybe built with microservices. Each service (like payments, authentication, search, and so on) lives on a different port or even in a container.

You want to route traffic smartly – like /login goes to the auth service, /pay to payments, and /search to the search service – all on the same domain.

How it works:
You still use a VM Scale Set for auto-scaling, but instead of a basic Load Balancer, you add an Application Gateway. It can inspect each request and send it to the right service based on things like:

• URL path (for example, /payments, /orders)

• Subdomain (for example, payments.mydomain.com, auth.mydomain.com)

Real-life examples:

• A full-blown SaaS product with multiple services

• An e-commerce site with checkout, account, orders, and admin dashboards

• A business migrating from a monolith to a microservices setup

Pros:

• Smart routing based on path or subdomain

• Everything runs under one public IP and one domain

• Secure HTTPS handling + optional Web Application Firewall (WAF)

• Auto-scaling and high availability

Cons:

• More complex setup

• Slightly higher cost due to Application Gateway

• Needs planning around port numbers and backend pools

🧠 Quick Summary Table

✅ Conclusion

By now, you’ve gone from simply hearing the words “load balancer” or “scale set” to understanding exactly how they work, when to use them, and what problems they solve. Whether you’re just launching a small app or scaling up a high-traffic service, Azure gives you flexible, powerful tools to grow with confidence.

We started from the very beginning – a single virtual machine. It’s simple and great for small apps, but it quickly becomes a bottleneck as traffic grows.

That’s where scaling comes in. We explored:

• 🧱 Vertical scaling – Upgrading the same VM (quick fix, but limited)

• 🧩 Horizontal scaling – Adding more VMs to handle traffic better

Then we introduced Azure Virtual Machine Scale Sets (VMSS) – which bring auto-scaling to life. No more manual intervention – Azure can scale your servers up and down based on demand.

But where things really get smart is with load balancers:

• 📦 Azure Load Balancer helps spread traffic across your VMs — great for single-service apps

• 🍴 Azure Application Gateway takes it further by routing requests based on URL paths or subdomains — perfect for multi-service or microservice apps

🎯 TL;DR – What Should You Use?

• Single VM: For side projects, portfolios, or internal tools

• Manual scaling + Load Balancer: For medium apps with predictable load

• VMSS + Load Balancer: For monolithic apps with auto-scaling needs

• VMSS + Application Gateway: Also includes auto-scaling but for microservices or smart routing needs

💡 Final Thoughts

Cloud apps grow – fast. And with growth comes complexity. But with the right Azure setup, you can stay one step ahead of your traffic, serve users better, and keep costs under control.

Remember: you don’t need to start big. Start small, understand your app's traffic patterns, and scale only when you need to. Tools like Azure VM Scale Sets, Load Balancer, and Application Gateway give you the control and power to build scalable, modern applications without over-engineering.

Thanks for sticking with me through this deep dive. I hope this made things clearer, simpler, and maybe even a little fun 😊

Study Further 📚

If you would like to learn more about Azure Virtual Machines, Scale Sets, Load Balancer, and Application Gateway, you can check out the courses below:

• Microsoft Azure Fundamentals AZ-900 Exam Prep Specialization — Microsoft, Coursera

• Azure Virtual Machine Tutorial | Creating A Virtual Machine In Azure | Azure Training | Simplilearn — YouTube

• Virtual machine scale sets — YouTube

• Azure Load Balancer | Azure Load Balancer Tutorial | All About Load Balancer | Edureka — YouTube

• Azure Application Gateway Deep dive | Step by step explained — YouTube

About the Author 👨‍💻

Hi, I’m Prince! I’m a DevOps engineer and Cloud architect passionate about building, deploying, and managing scalable applications and sharing knowledge with the tech community.

If you enjoyed this article, you can learn more about me by exploring more of my blogs and projects on my LinkedIn profile. You can find my LinkedIn articles here. You can also visit my website to read more of my articles as well. Let’s connect and grow together! 😊

This is where MLOps (Machine Learning Operations) comes into play. It can help teams streamline these processes and elevate automation to the forefront of financial security and regulatory adherence.

In this article, we will investigate the potential of MLOps for automating compliance and fraud detection in the finance sector.

I’ll show you step by step how financial institutions can deploy a machine learning model for fraud detection and integrate it into their operations to ensure continuous monitoring and automated alerts for compliance. I’ll also demonstrate how to deploy this solution in a cloud-based environment using Google Colab, ensuring that it is both user-friendly and accessible, whether you are a beginner or more advanced.

Here’s what we’ll cover:

• What is MLOps?

• What You’ll Need

• Step 1: Set Up Google Colab and Prepare the Data

• Step 2: Data Preprocessing

• Step 4: Retrain the Model with New Data

• Step 5: Automated Alert System

• Step 6: Visualize Model Performance

• Conclusion

• Key Takeaways

What is MLOps?

Machine Learning Operations, or MLOps for short, is a methodology that integrates DevOps with Machine Learning (ML). The whole machine learning model lifecycle, including development, training, deployment, monitoring, and maintenance, can be automated with its help.

MLOps has several main goals: continuous optimization, scalability, and the delivery of operational value over time.

The financial industry provides great use cases for MLOps processes and techniques, as these can help businesses manage complicated data pipelines, deploy models in real-time, and evaluate their performance – all while making sure they're compliant with regulations.

Why is MLOps Important in Finance?

Financial institutions are subject to various rules including Anti-Money Laundering (AML), Know Your Customer (KYC), and Fraud Prevention Regulations – so they have to carefully manage private information. Ignoring these rules might result in severe fines and loss of reputation.

Detecting fraud in financial transactions also calls for advanced systems capable of real-time identification of suspicious activity.

MLOps can help to solve these issues in the following ways:

• MLOps lets financial institutions automatically track transactions for regulatory compliance, guaranteeing they follow changing legislation.

• MLOps helps to create and implement machine learning models that can identify fraudulent transactions in real-time.

• MLOps runs automated processes, enabling organizations to expand their fraud detection systems with as little human involvement as possible through automation.

What You’ll Need:

To follow along with this tutorial, ensure that you have the following:

1. Python installed, along with basic ML libraries such as scikit-learn, Pandas, and NumPy.

2. A sample dataset of financial transactions, which we will use to train a fraud detection model (You can use this sample dataset if you don’t have one on hand).

3. Google Colab (for cloud-based execution), which is free to use and doesn't require installation.

Step 1: Set Up Google Colab and Prepare the Data

Google Colab is an ideal choice for beginners and advanced users alike, because it’s cloud-based and doesn’t require installation. To start get started using it, follow these steps:

Access Google Colab:

Visit Google Colab and sign-in with your Google account.

Create a New Notebook:

In the Colab interface, go to File and then select New Notebook to create a fresh notebook.

Import Libraries and Load the Dataset

Now, let’s import the necessary libraries and load our fraud detection dataset. We'll assume the dataset is available as a CSV file, and we'll upload it to Colab.

Import libraries:

import pandas as pd
import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report, confusion_matrix
import matplotlib.pyplot as plt

Upload the Dataset:

from google.colab import files
uploaded = files.upload()

# Load dataset into pandas DataFrame
data = pd.read_csv('data.csv')
print(data.head())

Step 2: Data Preprocessing

Data preprocessing is essential to prepare the dataset for model training. This involves handling missing values, encoding categorical variables, and normalizing numerical features.

Why is Preprocessing Important?

Data preprocessing lets you take care of various data issues that could affect your results. During this process, you’ll:

• Handle missing values: Financial datasets often have missing values. Filling in these missing values (for example, with the median) ensures that the model doesn’t encounter errors during training.

• Convert categorical data: Machine learning algorithms require numerical input, so categorical features (like transaction type or location) need to be converted into numeric format using one-hot encoding.

• Normalize data: Some machine learning models, like Random Forest, are not sensitive to feature scaling, but normalization helps maintain consistency and allows us to compare the importance of different features. This step is especially critical for models that rely on gradient descent.

Here’s an example:

# Handle missing data by filling with the median value for each column
data.fillna(data.median(), inplace=True)

# Convert categorical columns to numeric using one-hot encoding
data = pd.get_dummies(data, drop_first=True)

# Normalize numerical columns for scaling
data['normalized_amount'] = (data['Amount'] - data['Amount'].mean()) / data['Amount'].std()

# Separate features and target variable
X = data.drop(columns=['Class'])
y = data['Class']

# Split data into training and testing sets (80% train, 20% test)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

print("Data preprocessing completed.")

Step 3: Train a Fraud Detection Model

We'll now train a RandomForestClassifier and evaluate its performance.

What is a Random Forest Classifier?

A Random Forest is an ensemble learning method that creates a collection (forest) of decision trees, typically trained with different parts of the data. It aggregates their predictions to improve accuracy and reduce overfitting.

This method is a popular choice for fraud detection because it can handle high-dimensional data. It’s also quite robust against overfitting.

Here’s how you can implement the Random Forest Classifier:

# Initialize the Random Forest Classifier
rf_model = RandomForestClassifier(n_estimators=150, random_state=42)

# Train the model on the training data
rf_model.fit(X_train, y_train)

# Predict on the test data
y_pred = rf_model.predict(X_test)

# Evaluate model performance
print("Model Evaluation:\n", classification_report(y_test, y_pred))
print("Confusion Matrix:\n", confusion_matrix(y_test, y_pred))

# Plot confusion matrix for visual understanding
cm = confusion_matrix(y_test, y_pred)
fig, ax = plt.subplots()
cax = ax.matshow(cm, cmap='Blues')
fig.colorbar(cax)
plt.title("Confusion Matrix")
plt.xlabel("Predicted")
plt.ylabel("Actual")
plt.show()

How the model is evaluated:

• Classification report: Shows metrics like precision, recall, and F1-score for the fraud and non-fraud classes.

• Confusion matrix: Helps visualize the performance of the model by showing the true positives, false positives, true negatives, and false negatives.

Step 4: Retrain the Model with New Data

Once you have trained your model, it’s important to retrain it periodically with new data to ensure that it continues to detect emerging fraud patterns.

What is Retraining?

Retraining the model ensures that it adapts to new, unseen data and improves over time. In the case of fraud detection, retraining is crucial because fraud tactics evolve over time, and your model needs to stay up-to-date to recognize new patterns.

Here’s how you can do this:

# Simulate loading new fraud data
new_data = pd.read_csv('new_fraud_data.csv')

# Apply preprocessing steps to new data (like filling missing values, encoding, normalization)
new_data.fillna(new_data.median(), inplace=True)
new_data = pd.get_dummies(new_data, drop_first=True)
new_data['normalized_amount'] = (new_data['transaction_amount'] - new_data['transaction_amount'].mean()) / new_data['transaction_amount'].std()

# Concatenate old and new data for retraining
X_new = new_data.drop(columns=['fraud_label'])
y_new = new_data['fraud_label']

# Retrain the model with the updated dataset
X_combined = pd.concat([X_train, X_new], axis=0)
y_combined = pd.concat([y_train, y_new], axis=0)

rf_model.fit(X_combined, y_combined)

# Re-evaluate the model
y_pred_new = rf_model.predict(X_test)
print("Updated Model Evaluation:\n", classification_report(y_test, y_pred_new))

Step 5: Automated Alert System

To automate fraud detection, we’ll send an email whenever a suspicious transaction is detected.

How the Alert System Works

The email alert system uses SMTP to send an email whenever fraud is detected. When the model identifies a suspicious transaction, it triggers an automated alert to notify the compliance team for further investigation.

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

# Function to send an email alert
def send_alert(email_subject, email_body):
    sender_email = "your_email@example.com"
    receiver_email = "compliance_team@example.com"
    password = "your_password"

    msg = MIMEMultipart()
    msg['From'] = sender_email
    msg['To'] = receiver_email
    msg['Subject'] = email_subject

    msg.attach(MIMEText(email_body, 'plain'))

    # Send email using SMTP
    try:
        server = smtplib.SMTP_SSL('smtp.example.com', 465)
        server.login(sender_email, password)
        text = msg.as_string()
        server.sendmail(sender_email, receiver_email, text)
        server.quit()
        print("Fraud alert email sent successfully.")
    except Exception as e:
        print(f"Failed to send email: {str(e)}")

# Example: Check for fraud and trigger an alert
suspicious_transaction_details = "Transaction ID: 12345, Amount: $5000, Suspicious Activity Detected."
send_alert("Fraud Detection Alert", f"A suspicious transaction has been detected: {suspicious_transaction_details}")

Step 6: Visualize Model Performance

Finally, we will visualize the performance of the model using an ROC curve (Receiver Operating Characteristic Curve), which helps evaluate the trade-off between the true positive rate and false positive rate.

Visualizing the performance of a machine learning model is an essential step in understanding how well the model is doing, especially when it comes to evaluating its ability to detect fraudulent transactions.

What is an ROC curve?

An ROC curve shows how well a model performs across all classification thresholds. It plots the True Positive Rate (TPR) versus the False Positive Rate (FPR). The area under the ROC curve (AUC) provides a summary measure of model performance.

from sklearn.metrics import roc_curve, auc

# Calculate ROC curve
fpr, tpr, thresholds = roc_curve(y_test, rf_model.predict_proba(X_test)[:,1])
roc_auc = auc(fpr, tpr)

# Plot ROC curve
plt.figure(figsize=(8,6))
plt.plot(fpr, tpr, color='blue', label=f'ROC curve (area = {roc_auc:.2f})')
plt.plot([0, 1], [0, 1], color='gray', linestyle='--')
plt.xlim([0.0, 1.0])
plt.ylim([0.0, 1.05])
plt.xlabel('False Positive Rate')
plt.ylabel('True Positive Rate')
plt.title('Receiver Operating Characteristic (ROC) Curve')
plt.legend(loc='lower right')
plt.show()

The ROC curve gives us a comprehensive picture of how well our model is distinguishing between the two classes across various thresholds. By evaluating this curve, we can make decisions on how to tune the model’s threshold to find the best balance between detecting fraud and minimizing false alarms (that is, minimizing false positives).

Conclusion

By following this guide, you’ve learned how to leverage MLOps to automate fraud detection and ensure compliance in the financial industry using Google Colab. This cloud-based environment makes it easy to work with machine learning models without the hassle of local setups or configurations.

From automating data preprocessing to deploying models in production, MLOps offers an end-to-end solution that improves efficiency, scalability, and accuracy in detecting fraudulent activities.

By integrating real-time monitoring and continuous updates, financial institutions can stay ahead of fraud threats while ensuring regulatory compliance with minimal manual effort.

Key Takeaways

• MLOps automates the whole machine learning model lifecycle by integrating machine learning with DevOps.

• Simplifies regulatory compliance and fraud detection, letting banks spot fraudulent transactions automatically.

• Maintains fraud detection systems current with fresh data through constant monitoring and model retraining.

• Machine learning model development and testing may be done on Google Colab, a free cloud-based platform that provides access to GPUs and TPUs. No local installation is required.

• Allows for automated workflows to detect suspicious behavior and send out alerts in real-time, allowing for fraud detection and alerting.

• Continuous integration/continuous delivery pipelines guarantee continuous system improvement by automating the testing and deployment of new fraud detection models.

• Financial organizations may save money using MLOps because cloud-based systems like Google Colab lower infrastructure expenses.

So what is Kubernetes, really? Why is it everywhere? And should you care?

In this handbook, we’ll unpack Kubernetes in a way that actually makes sense. No buzzwords. No overwhelming tech-speak. Just straight talk. You’ll learn what Kubernetes is, how it came about, and why it became such a big deal – especially for teams building and running huge apps with millions of users.

We’ll rewind a bit to see how things were done before Kubernetes showed up (spoiler: it wasn’t pretty), and walk through the real problems it was designed to solve.

By the end, you’ll not only understand the purpose of Kubernetes, but you’ll also know how to deploy a simple app on a Kubernetes cluster – even if you’re just getting started.

Yep, by the time we’re done, you’ll go from “I keep hearing about Kubernetes” to “Hey, I kinda get it now!” 😄

📚 Table of Contents

1. What is Kubernetes?

2. How Applications Were Deployed Before Kubernetes

3. The Problem Kubernetes Solves 🧠

4. How Kubernetes Works – Components of a Kubernetes Environment 🧑‍🔧

5. Kubernetes Workloads 🛠️ – Pods, Deployments, Services, & More

6. How to Create a Kubernetes Cluster in a Demo Environment with play-with-k8s

   • Sign in to Play with Kubernetes

   • Create Your Kubernetes Cluster

7. How to Deploy an Application on Your Kubernetes Cluster

8. ✅ Advantages of Using Kubernetes in Business

9. 😬 Disadvantages of Using Kubernetes

10. Use Cases: When (and When Not) to Use Kubernetes

11. Conclusion

12. Study Further 📚

13. About the Author 👨‍💻

What is Kubernetes?

Imagine you're building a huge software platform, like a banking app. This app needs many features, like user onboarding, depositing money, withdrawals, payments, and so on. These features are so big and complex that it’s easier to split them into separate applications. These individual applications are called microservices.

So what are Microservices? Think of them like little building blocks that work together to create a bigger platform. So, you might have:

• One microservice for user onboarding

• Another for processing deposits

• Another for handling payments

• And many, many more!

To the user, it still looks like they’re using one smooth, unified banking app. But behind the scenes, it’s like a bunch of little apps working together to make everything run.

But here’s where things get tricky...

When you have dozens (or even hundreds) of these microservices, managing them becomes a nightmare. You might need to:

• Deploy each one separately

• Monitor them individually (to ensure they don’t crash/become slow due to too much load)

• Scale them (make them bigger to handle more users) as traffic surges, one by one

So, if your banking app suddenly gets millions of users, you'd have to manually tweak and update each microservice to keep it running smoothly. 😖 It’s a lot of work, and if something goes wrong, you’re in deep trouble.

This is where Kubernetes comes to the rescue! 🚀

Kubernetes is like a super-efficient manager for all these microservices. It’s a platform that helps you:

• Automate the deployment (getting the apps up and running)

• Scale the microservices (making them bigger or smaller as needed based on the inflow of traffic – your customers)

• Monitor them (keeping an eye on their health)

• Ensure reliability (so if one microservice breaks/fails, k8s replaces it immediately)

In simple terms, Kubernetes takes all your little microservices and organizes them, ensuring they run smoothly together, no matter how much traffic your app gets. It handles everything behind the scenes, like a conductor leading an orchestra, so your microservices work together without chaos.

How Applications Were Deployed Before Kubernetes

Before Kubernetes came into the picture, software teams had quite the juggling act when it came to deploying applications – especially when they were made up of lots of microservices.

One popular method was using a distributed system setup. Here’s what that looked like:

Imagine each microservice (like your user onboarding, payments, deposits, and so on) being installed on separate servers (physical computers or virtual machines). Each of these servers had to be carefully prepared:

• The microservice itself needed to be installed.

• The software dependencies it needed (like programming languages, libraries, tools) also had to be installed.

• Everything had to be configured manually ON EACH server.

And all of these servers had to talk to each other – sometimes over the public internet, or via private networks like VPNs.

Sounds like a lot of work, right? 😮 It was! Managing updates, fixing bugs, scaling up during traffic spikes, and keeping things from crashing could turn into a full-time headache for developers and system admins. 😖

Then Came Containers 🚢

A more modern solution that eased the pain (a little) was using containers.

So, what are containers?

Think of a container like a lunchbox for your microservice. Instead of installing the microservice and its supporting tools directly on a server, you pack everything it needs – code, settings, software libraries – into this single, neat container. Wherever the container goes, the microservice runs exactly the same way. No surprises!

Tools like Docker made this super easy. Once your microservice was packed into a container, you could deploy it on:

• A single server

• Multiple servers

• Or cloud platforms like AWS Elastic Beanstalk, Azure App Service, or Google Cloud Run.

The Problem Kubernetes Solves 🧠

At first, when containers arrived on the scene, it felt like developers had struck gold.

You could package a microservice into a neat little container and run it anywhere – no more installing the same software on every server again and again. Tools like Docker and Docker Compose made this smooth for small projects.

But the real world? That’s where it got messy.

The Growing Headache of Managing Containers 💡

When you have just a few microservices, you can manually deploy and manage their containers without much stress. But when your app grows – and you suddenly have dozens or even hundreds of microservices – managing them becomes an uphill battle:

• You had to deploy each container manually.

• You had to restart them if one crashed.

• You had to scale them one by one when more users started flooding in.

Docker and Docker Compose were great for a small playground or startups, but not for an enterprise application with high traffic inflow.

Cloud-Managed Services Helped... But Only Up To a Point 🧑‍💻

Cloud services like AWS Elastic Beanstalk, Azure App Service, and Google Code Engine offered a shortcut. They let you deploy containers without worrying about setting up servers.

You could:

• Deploy each container on its own managed cloud instance.

• Scale them automatically based on traffic.

BUT there were still some big headaches:

📦 Grouping microservices was awkward and expensive

Sure, you could organize containers by environment (like “testing” or “production”) or even by team (like “Finance” or “HR”). But each new microservice usually needed its own cloud instance – for example, a separate Azure App Service or Elastic Beanstalk environment FOR EVERY SINGLE CONTAINER.

Imagine this:

• Each App Service instance costs ~$50 per month.

• You’ve got 10 microservices.

• That’s $500/month... even if they’re barely used. 💸 Yikes!

Kubernetes: Smarter, Leaner, and More Flexible 💪

With Kubernetes, you don’t need to spin up a separate server for each microservice. You can start with just one or two servers (VMs) – and Kubernetes will automatically decide which container goes where based on available space and resources.

No stress, no waste! 💡

🧑‍🍳 Kubernetes Lets You Customize Everything

1. You can assign resources to each microservice container.
   👉 Example: If you have a "Payment" microservice that’s lightweight, you might give it 0.5 vCPUs and 512MB of memory. If you have a "Data Analytics" microservice that’s resource-hungry, you could give it 2 vCPUs and 4GB of memory.

2. You can set a minimum number of instances for each microservice.
   👉 Example: If you want at least 2 copies of your "Login" service always running (so your app doesn’t break if one fails), Kubernetes makes sure you always have 2 live copies at all times.

3. You can group your containers however you like:
   👉 By teams (Finance, HR, DevOps) or by environments (Testing, Staging, Production). Kubernetes makes this grouping super clean and logical.

4. You can automatically scale individual containers.
   👉 When more users flood your app, Kubernetes can create extra copies (called “replicas”) of only the containers that are under pressure. No more wasting resources on containers that don’t need it.

5. You can even scale your servers!
   👉 Kubernetes can automatically increase the number of servers (VMs) in your environment – called a Cluster – when traffic grows. So you could start with 2 VMs at $30 each ($60/month) and let Kubernetes add more servers only when necessary, rather than locking yourself into high fixed costs like $500/month for cloud-managed services.

Also, Kubernetes works the same way everywhere. Whether you deploy your containers on AWS, Google Cloud, Azure, or even your own laptop – Kubernetes doesn’t care. Your setup stays the same.

Compare that to managed services like Elastic Beanstalk or Azure App Service – which tie you to their platform, making it super hard to switch later.

✅ In short: Kubernetes saves you money, time, and a whole lot of headaches. It lets you run, scale, and organize your microservices without being chained to a single cloud provider — and without drowning in manual work.

How Kubernetes Works — Components of a Kubernetes Environment 🧑‍🔧

So by now you’ve seen the problem: running dozens (or hundreds!) of microservices manually is like juggling too many balls – you’re bound to drop some.

That’s why Kubernetes was created. But... how does it actually do all this magic? Let’s first break it down with the technical definition (simple but sharp – perfect for interviews) and then the layperson’s analogy (so it sticks in your head!).

1️⃣ Cluster 🏰

A Kubernetes Cluster is the entire setup of machines (physical or cloud-based) where Kubernetes runs. It’s made of one or more Master Nodes and Worker Nodes, working together to deploy and manage containerized applications.

Think of a Kubernetes Cluster as your entire playground. This is the environment where all your microservices live, grow, and play together.

A cluster is made up of two types of computers (called nodes):

• Master Node (nowadays often called the Control Plane)

• Worker Nodes

2️⃣ Master Node (Control Plane) 👑

The Master Node is like the brain of Kubernetes. It manages and coordinates the whole cluster – deciding which applications run where, monitoring health, and scaling things up or down as needed.

It’s like the boss of the entire cluster. It doesn’t run your applications directly. Instead, it:

• Watches over the worker nodes

• Decides which microservice (container) goes where

• Makes sure everything runs smoothly and fairly

Think of it like a factory manager who tells machines what to do, when to start, when to stop, and where to send the next package.

Inside the Master Node are a few clever mini-components that handle the real work.

3️⃣ API Server 💌

The API Server is the front door to Kubernetes. It handles communication between users and the system, taking commands and feeding them into the cluster.

This is where you (or your team) give Kubernetes instructions. Whether you're deploying a new app or scaling an existing one, you "talk" to the API Server first. It's like submitting a request at the front desk – the API server passes it on to the right people (or machines).

4️⃣ Scheduler 📅

The Scheduler assigns Pods (applications) to Worker Nodes based on available resources and needs.

Imagine you’ve asked Kubernetes to launch a new microservice. The Scheduler checks:

• Which worker node has enough space?

• Which node has enough memory and CPU?

• Where would this service run best?

It makes the decision and assigns the microservice to the perfect spot. Smart, huh?

5️⃣ Controller Manager 🎛️

The Controller Manager runs controllers that watch over the cluster and ensures that the system’s actual state matches the desired state.

This component watches over the system like a hawk. Let’s say you told Kubernetes:
"Hey, I want 3 copies of my payment microservice running at all times."

If one of them crashes, the Controller Manager sees that and spins up a new one to replace it automatically. It makes sure the reality always matches the plan.

6️⃣ etcd 📚

etcd is Kubernetes' memory – a distributed key-value store where cluster data is saved: config files, state, and metadata.

Imagine a notebook where all rules, records, and plans are written down. Without etcd, Kubernetes would forget everything.

7️⃣ Worker Nodes 💪

Worker Nodes are the servers that run the actual application containers, doing the heavy lifting in the cluster.

These are the machines where your microservices actually live and run. The Master Node gives orders, but the Worker Nodes do the heavy lifting – they run your containers!

Each worker node has a few helpers to manage its microservices:

• The Kubelet

• The Kube Proxy

8️⃣ Kubelet 📢

The Kubelet is the agent which lives on each Worker Node that makes sure containers are healthy and running as expected.

It listens to the Master Node’s instructions. If the Master Node says:"Hey, run this container!", the Kubelet makes it happen and keeps it running. If something goes wrong, the Kubelet reports back to the Master Node

9️⃣ Kube Proxy 🚦

Kube Proxy handles network traffic, ensuring that Pods can talk to each other and to the outside world.

Imagine your banking app’s login service needs to talk to the payments service. The Kube Proxy handles the routing so the request reaches the right place. It also handles load balancing, so no single microservice gets overwhelmed.

So, to summarize:

• The Master Node is the boss – it plans, watches, and assigns tasks.

• The Worker Nodes do the actual work – running your microservices.

• Components like etcd, Kubelet, Scheduler, Controller Manager, and Kube Proxy all work together like parts of a well-oiled machine.

Kubernetes is designed to handle your microservices automatically – keeping them alive, scaling them up, moving them around, and restarting them if they crash – so you don’t have to babysit them yourself.

Kubernetes Workloads 🛠️ — Pods, Deployments, Services, & More

Kubernetes workloads are the objects you use to manage and run your applications. Think of them as blueprints 📐 that tell Kubernetes what to run and how to run it – whether it’s a single app container, a group of containers, a database, or a batch job. Here are some of the workloads in Kubernetes:

1️⃣ Pods

A Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in your cluster and can contain one or more containers that share storage and network resources. ​

Think of a Pod as a wrapper around one or more containers that need to work together. They share the same network IP and storage, allowing them to communicate easily and share data. Pods are ephemeral (live for a short time, they can be replaced very easily). If a Pod dies, Kubernetes can create a new one to replace it almost instantly.​

Say you have an application which is split into 2 distributed monoliths – a frontend and a backend. The frontend will run in a container in Pod A, while the backend app will run in a container in another Pod B.

2️⃣ Deployments

A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.

Deployments manage the lifecycle of your application Pods. They ensure that the specified number of Pods are running and can handle updates, rollbacks, and scaling. If a Pod fails, the Deployment automatically replaces it to maintain the desired state.​

Imagine you're managing a store. A Deployment is like the store manager – you tell it how many workers (Pods) you want, and it makes sure they’re always present. If one doesn't show up for work, the manager finds a replacement automatically. You can also tell it to hire more workers or fire some when needed.

3️⃣ Services

A Service in Kubernetes defines a way to access/communicate with Pods. Services enable communication between different Pods (for example, your frontend Pod A can communicate with your backend Pod B via a service) and can expose your application to external traffic (for example the public internet). ​

Services act as a stable endpoint to access a set of Pods. Even if the underlying Pods change, the Service's IP and DNS name remain constant, ensuring communication between the Pods within the cluster or with the internet.

A Service is like the front door to your app. No matter which worker (Pod) is behind it, people always use the same entrance to access it. It hides the messy stuff happening behind the scenes and gives users a simple way to connect to your app.

4️⃣ ReplicaSets

A ReplicaSet ensures that a specified number of identical Pods are running at any given time. It is often used to guarantee the availability of a specified number of Pods (horizontal scaling). ​

ReplicaSets maintain a stable set of running Pods. If a Pod crashes or is deleted, the ReplicaSet automatically creates a new one to replace it, ensuring your application remains available.​

Think of a ReplicaSet like a robot that counts how many copies of your app are running. If one goes missing, it automatically makes a new one. It keeps the number steady, just like you told it to.

5️⃣ DaemonSets

A DaemonSet ensures that all (or some) Nodes run an instance (a copy) of a specific Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are also removed. ​

DaemonSets are used to deploy a Pod on every node in the cluster. This is useful for running background tasks like log collection or monitoring agents on all nodes (for example to get the CPU, memory, and disk usage of each node).​

A DaemonSet is like saying, “I want this helper app to run on every single computer we have.” As mentioned earlier, it’s great for things like log collectors or security checkers – small helpers that every machine should have.

6️⃣ StatefulSets

A StatefulSet is the workload API object used to manage stateful applications (applications that store data, for example in their filesystem – databases). It manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods.

StatefulSets are designed for applications that require persistent storage and stable network identities, like databases.

Let’s say you’re running a database or anything that needs to save info. A StatefulSet is like giving each app a name tag and a personal drawer to store their stuff. Even if you restart them, they come back with the same name and same drawer.

7️⃣ Jobs

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As Pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the Job is complete. ​

A Job is like a one-time task. Imagine sending out a batch of emails or processing a report. You want the task to run, finish, and then stop. That’s exactly what a Job does.

8️⃣ CronJobs

A CronJob creates Jobs on a time-based schedule. It runs a Job periodically on a given schedule, written in Cron format.

A CronJob is like setting a reminder or alarm. It tells your app (in this case the Job) to do something every night at 2 AM, every Monday morning, or once a month – whatever schedule you give it.

🛠️ How to Create a Kubernetes Cluster in a Demo Environment with play-with-k8s

As we've discussed earlier, a Kubernetes cluster is a set of machines (called nodes) that run containerized applications.

Setting up a Kubernetes cluster locally or in the cloud can be complex and expensive. To simplify the learning process, Docker provides a free, browser-based platform called Play with Kubernetes. This environment allows you to create and interact with a Kubernetes cluster without installing anything on your local machine. It's an excellent tool for beginners to get hands-on experience with Kubernetes.​

🔐 Sign in to Play with Kubernetes

1. Visit the platform at https://labs.play-with-k8s.com/.​

2. Authenticate:

   • Click on the "Login" button.

   • You can sign in using your Docker Hub or GitHub account.

   • If you don't have an account, you can create one for free on Docker Hub or GitHub.​

🚀 Create Your Kubernetes Cluster

Once signed in, follow these steps to set up your cluster:

Step 1: Start a New Session:

Click on the "Start" button to initiate a new session.​ This will create a new session giving you about 4 hours of play time, after which the cluster and it’s resources will be automatically terminated.

Step 2: Add Instances:

Then click on "+ Add New Instance" to create a new node (Virtual Machine).

This will open a terminal window where you can run commands.​

Step 3: Initialize the Master Node:

In the terminal, run the following command to initialize the master node:​

kubeadm init --apiserver-advertise-address $(hostname -i) --pod-network-cidr <SPECIFIED_IP_ADDRESS>

You can find the command in the terminal. In my case, the IP address is 10.5.0.0/16. Replace the <SPECIFIED_IP_ADDRESS> placeholder with the IP address specified in your terminal.

This process will set up the control plane of your Kubernetes cluster.​

Step 4: Add Worker Nodes:

If you want to add worker nodes, in the master node terminal, you'll find a kubeadm join... command after running the kubeadm init --apiserver-advertise-address $(hostname -i) --pod-network-cidr <SPECIFIED_IP_ADDRESS> command.

Click on "+ Add New Instance" to create another node just as you did earlier.

Run this command in the new node's terminal to join it to the cluster:

Step 5: Configure the Cluster’s networking:

Navigate to the master node, and run the command below to configure the cluster’s networking.

kubectl apply -f https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml

Step 6: Verify the Cluster:

In the master node terminal (the first node with the highlighted user profile), run:​

kubectl get nodes

You should see a list of nodes in your cluster, including the master and any worker nodes you've added.​

Congratulations! You just created your very own Kubernetes cluster with 2 VMs: the master node (where the control plane resides), and the worker nodes (where the Kubernetes workloads, for example Pods, will be deployed).

🚀 How to Deploy an Application on Your Kubernetes Cluster

Now that we've set up our Kubernetes cluster using Play with Kubernetes, it's time to deploy the application and make it accessible over the internet.

🧠 Understanding Imperative vs. Declarative Approaches in Kubernetes

Before we proceed, it's essential to grasp the two primary methods for managing resources in Kubernetes: Imperative and Declarative.

🖋️ Imperative Approach

In the imperative approach, you directly issue commands to the Kubernetes API to create or modify resources. Each command specifies the desired action, and Kubernetes executes it immediately.​

Imagine telling someone, "Turn on the light." You're giving a direct command, and the action happens right away. Similarly, with imperative commands, you instruct Kubernetes step-by-step on what to do.

Example:
To create a pod running an NGINX container, run the below command in the terminal of the master node:​

kubectl run nginx-pod --image=nginx

Now wait a few seconds and run the command below to check the status of the pod:

kubectl get pods

You should get a response similar to this

Now let’s expose our Pod to the internet by creating a Service. Run the command below to expose the Pod:

kubectl expose pod nginx-pod --type=NodePort --port=80

To get the IP address of the Cluster so we can access our Pod, run the command below:

kubectl get svc

The command displays the IP address from which we can access our service. You should get an output similar to this:

Now, copy the IP address for the nginx-pod service and run the command below to make a request to your Pod:

curl <YOUR-SERVICE-IP-ADDRESS>

Replace the <YOUR-SERVICE-IP-ADDRESS> placeholder with the IP address of your nginx-pod service. In my case, it’s 10.98.108.173.

You should get a response from your nginx-pod Pod:

We couldn’t access the Pod from the internet, that is our browser, because our Cluster isn’t connected to a cloud service like AWS or Google Cloud which can provide us with an external load balancer.

Now let’s try doing the same thing but using the Declarative method.

🚀 Declarative Approach

So far, we used the imperative approach, where we typed commands like kubectl run or kubectl expose directly into the terminal to make Kubernetes do something immediately.

But Kubernetes has another (and often better) way to do things: the declarative approach.

🧾 What Is the Declarative Approach?

Instead of giving Kubernetes instructions step-by-step like a chef in a kitchen, you give it a full recipe – a file that describes exactly what you want (for example, what app to run, how many copies of it, how to expose it, and so on).

This recipe is written in a file called a manifest.

📘 What’s a Manifest?

A manifest is a file (usually written in YAML format) that describes a Kubernetes object – like a Pod, a Deployment, or a Service.

It’s like writing down what you want, handing it over to Kubernetes, and saying: “Hey, please make sure this exists exactly how I described it.”

We’ll use two manifests:

1. One to deploy our application

2. Another to expose it to the internet

Let’s walk through it!

📁 Step 1: Clone the GitHub Repo

We already have a GitHub repo that contains the two manifest files we need. Let’s clone it into our Kubernetes environment.

Run this in the terminal (on your master node):

git clone https://github.com/onukwilip/simple-kubernetes-app

Now, let’s go into the folder:

cd simple-kubernetes-app

You should see two files:

• deployment.yaml

• service.yaml

📦 Step 2: Understanding the Deployment Manifest (deployment.yaml)

This manifest will tell Kubernetes to deploy our app and ensure it’s always running.

Here’s what’s inside:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

Now, let’s break this down:

• apiVersion: apps/v1: This tells Kubernetes which version of the API we’re using to define this object.

• kind: Deployment: This means we’re creating a Deployment (a controller that manages Pods).

• metadata.name: We’re giving our Deployment a name: nginx-deployment.

• spec.replicas: 3: We’re telling Kubernetes: “Please run 3 copies (replicas) of this app.”

• selector.matchLabels: Kubernetes will use this label to find which Pods this Deployment is managing.

• template.metadata.labels & spec.containers: This section describes the Pods that the Deployment should create – each Pod will run a container using the official nginx image.

✅ In plain terms: We're asking Kubernetes to create and maintain 3 copies of an app that runs NGINX, and automatically restart them if any fails.

🌐 Step 3: Understanding the Service Manifest (service.yaml)

This file tells Kubernetes to expose our NGINX app to the outside world using a Service.

Here’s the file – let’s break this down, too:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

• apiVersion: v1: We’re using version 1 of the Kubernetes API.

• kind: Service: We’re creating a Service object.

• metadata.name: nginx-service: Giving it a name.

• spec.type: NodePort: We’re exposing it through a port on the node (so we can access it via the node's IP address).

• selector.app: nginx: This tells Kubernetes to connect this Service to Pods with the label app: nginx.

• ports.port and targetPort: The Service will listen on port 80 and forward traffic to port 80 on the Pod.

✅ In plain terms: This file says, “Expose our NGINX app through the cluster’s network so we can access it from the outside world.”

🧹 Step 4: Clean Up Previous Resources

If you’re still running the Pod and Service we created using the imperative approach, let’s delete them to avoid conflicts:

kubectl delete pod nginx-pod
kubectl delete service nginx-pod

📥 Step 5: Apply the Manifests

Now let’s deploy the NGINX app and expose it – this time using the declarative way.

From inside the simple-kubernetes-app folder, run:

kubectl apply -f deployment.yaml

Then:

kubectl apply -f service.yaml

This will create the Deployment and the Service described in the files. 🎉

🔍 Step 6: Check That It’s Running

Let’s see if the Pods were created:

kubectl get pods

You should see 3 Pods running!

And let’s check the service:

kubectl get svc

Look for the nginx-service. You’ll see something like:

Note the NodePort (for example, 30001) as we’ll use it to access the app.

🌍 Step 7: Access the App

You can now send a request to your app like this:

curl http://<YOUR-NODE-IP>:<NODE-PORT>

Replace <YOUR-NODE-IP> with the IP of your master node (you’ll usually find this in Play With Kubernetes at the top of your terminal), and <NODE-PORT> with the NodePort shown in the kubectl get svc command.

You should see the HTML content of the NGINX welcome page printed out.

Now terminate the cluster environment by clicking the CLOSE SESSION button:

🆚 Why Declarative Is Better (In Most Cases)

• 🔁 Reusable: You can use the same files again and again.

• 📦 Version-controlled: You can push these files to GitHub and track changes over time.

• 🛠️ Fixes mistakes easily: Want to change 3 replicas to 5? Just update the file and re-apply!

• 🧠 Easier to maintain: Especially when you have many resources to manage.

💼 Advantages of Using Kubernetes in Business

Kubernetes isn’t just a developer tool—it’s a business enabler as well. It helps companies deliver products faster, more reliably, and with reduced operational overhead.

Let’s break down how Kubernetes translates to real-world business benefits:

1️⃣ Better Use of Cloud Resources = Cost Savings

Before Kubernetes, deploying many microservices for a single application often meant creating separate cloud resources (like one Azure App Service per microservice), which could rack up huge costs quickly. Imagine $50/month per service × 10 services = $500/month 😬.

With Kubernetes:
You can run multiple microservices on fewer virtual machines (VMs) while Kubernetes automatically decides the most efficient way to use the available servers. That means you pay for fewer servers and get more out of them 💸.

2️⃣ High Availability and Uptime = Happy Customers

Kubernetes watches your apps like a hawk 👀. If one of them crashes or fails, Kubernetes restarts or replaces it immediately – automatically.

For your business:
This means less downtime, fewer support tickets, and happier customers who don’t even notice when things go wrong in the background.

3️⃣ Easy Scaling During High Demand

Manually scaling apps during high traffic (like Black Friday) can be a nightmare 😰. And if you don't act fast, customers experience slowness or crashes.

With Kubernetes:
You can configure each microservice to automatically scale — meaning it adds more instances of that service only when needed (too many users on your site trying to purchase different products) and scales back down when traffic drops. This ensures your app is always responsive and you only pay for what you use.

4️⃣ Faster Deployment = Faster Time to Market

Kubernetes supports automation and repeatability. Teams can deploy new features or microservices faster without worrying about infrastructure setup every time.

For business:
This means faster product updates, quicker response to market demands, and competitive advantage 🚀.

5️⃣ Consistent Environments = Fewer Bugs

Each microservice in Kubernetes is containerized, meaning it runs with all its dependencies in a self-contained package. You can run the exact same app setup in:

• Development

• Testing

• Production

This reduces bugs caused by "it works on my machine" issues 🤦‍♂️ and helps teams build with confidence.

6️⃣ Vendor Independence (Bye-bye to Vendor lock-in)

When you use cloud-managed services (like AWS Elastic Beanstalk or Azure App Service), it’s often hard to move to another provider because everything is tailored to that specific platform.

With Kubernetes:
It works the same way on AWS, Azure, GCP, or even your own data center. This means you can switch cloud providers easily and avoid being locked into one vendor – aka cloud freedom! ☁️🕊️

7️⃣ Organizational Clarity

Kubernetes lets you organize your apps clearly. You can group workloads by:

• Team (for example, Finance, HR)

• Environment (for example, testing, staging, production)

This structure helps large teams collaborate better, stay organized, and manage resources efficiently.

😬 Disadvantages of Using Kubernetes

Like everything in tech, Kubernetes isn’t all rainbows and rockets 🚀. Just like any other tool, it has its pros and its cons. And it's super important for startup founders, product managers, or even CEOs to know when Kubernetes is the right fit – and when it’s just overkill.

Let’s break down the main disadvantages in a simple, honest way:

👨‍🔧 1. You’ll Likely Need a DevOps Engineer or Team

Kubernetes is powerful, yes. But that power comes with great responsibility 😅.

In simple terms:

• You don't just "click a button" and your app is magically running.

• Kubernetes needs someone who understands how to set it up, keep it running, and fix issues when they pop up. This person (or team) is usually called a DevOps Engineer, SIte Relability Engineer or Cloud Engineer.

Here’s what they’ll typically handle:

• Creating the cluster (the environment where your apps will run)

• Defining how your app containers should behave (how many should run, how much memory they need, when they should restart, and so on)

• Monitoring the apps and making sure they’re healthy

• Ensuring security rules are followed

• Handling automated scaling, deployment rollouts, backups, and so on.

💡 In short: You’ll need someone skilled to manage this tool. If you’re a solo founder or a small team with no DevOps experience, Kubernetes might be too much upfront.

💰 2. Kubernetes Can Be Expensive (If Used Prematurely)

Kubernetes saves money at scale – but can cost more if you adopt it too early or for the wrong use case.

Here's why:

• Kubernetes is meant for managing multiple applications or microservices. If your business only has one small app, you’re using a rocket to deliver a pizza 🍕 – it’s just not necessary.

• Kubernetes is also best when you have high or unpredictable traffic. It can automatically scale up your services when traffic spikes...but if your traffic is steady and small, you won’t benefit much from that power.

Let’s say:

• You have one app with moderate traffic.

• You deploy it on Kubernetes (which requires at least 1–2 VMs + setup).

• You hire a DevOps engineer to manage it.

• You pay for cloud compute + storage + monitoring.

You could end up spending $300–$800/month or more... for something that could’ve been hosted on a simple service like Render, Heroku, or a basic VM for a fraction of the cost.

So when should you consider Kubernetes?

• When your platform is made up of multiple services (For example, separate services for user auth, payments, analytics, notifications, and so on)

• When you’re expecting traffic spikes (for example, launching in new countries, going viral, seasonal demand like black Friday)

• When you want flexibility in managing your infrastructure across cloud providers (AWS, GCP, Azure) or even on-premises

🧭 Use Cases: When (and When Not) to Use Kubernetes

Kubernetes is an incredibly powerful tool – but it’s not always the right solution from day one.

Let’s break down when it makes sense to use Kubernetes and when it might be overkill 👇

✅ When You Should Use Kubernetes

Kubernetes becomes essential in these scenarios:

1. Your Application Is Made of Many Microservices

If your app is broken down into multiple microservices – like user authentication, payments, orders, notifications, and more – it’s a good sign that Kubernetes might eventually help.

Kubernetes can:

• Help manage each microservice independently

• Automatically scale each one based on demand

• Restart failed services automatically

• Make it easier to roll out updates to specific parts of the application

2. You’re Getting Steady and High Traffic

It’s not just about complexity – it’s about demand.

If your app receives a consistent, high volume of users (like hundreds or thousands every day), and you start seeing signs that your servers are getting overloaded, Kubernetes shines here. It can:

• Automatically increase resources when traffic surges

• Balance the load across multiple servers

• Prevent downtime due to traffic spikes

3. You Want Portability and Cloud Independence

If your business doesn’t want to be locked into just one cloud provider (for example, only AWS), Kubernetes gives you flexibility. You can move your application between AWS, GCP, Azure – or even to your own data center – with fewer changes.

4. Your DevOps Team Is Growing

When you have multiple developers or teams working on different parts of the app, Kubernetes helps:

• Organize and isolate workloads per team

• Improve collaboration and consistency

• Provide easy access control and monitoring

❌ When You Should Not Use Kubernetes

Let’s be honest: Kubernetes is not for everyone, especially not at the beginning.

1. You Just Launched Your App

In the early days of your product, when you’ve just launched and traffic is still low, Kubernetes is overkill. You don’t need its complexity (yet).

👉 Instead, deploy your app or each microservice on a simple virtual machine (VM). It’s cheaper and faster to get started.

2. You Don’t Need Auto-scaling (Yet)

If traffic to your app is still small and manageable, a single server (or a few of them) can easily handle the load. In that case, it’s better to:

• Deploy your microservices manually or with Docker Compose

• Monitor and scale manually when needed

• Keep things simple until the need for automation becomes obvious

3. You Don’t Have a DevOps Team

Kubernetes is powerful – but it needs expertise to set up and maintain. If you don’t have a DevOps engineer or someone who understands Kubernetes, it may cause more problems than it solves.

Hiring a DevOps team can be expensive, and setting up Kubernetes incorrectly can lead to outages, security risks, or wasted resources 💸

📈 When to Move to Kubernetes

So, what’s the best path forward?

Here’s a simple roadmap:

1. Start small: Deploy your app (or microservices) on one or a few VMs

2. Watch traffic: As user demand grows, increase VM size or replicate the app manually

3. Track pain points: If scaling becomes too manual, or if services crash under load...

4. Then adopt Kubernetes 🧠

It’s not about how complex your app is – it’s about when the traffic and growth demand an upgrade in how you manage things.

🎯 TL;DR for Founders and DevOps Teams

• Don’t jump to Kubernetes just because it’s trendy

• Use it only when traffic grows steadily and auto-scaling becomes necessary

• Kubernetes is most valuable when you want to scale reliably and efficiently

• Before that point, stick to simple deployments – it’ll save you time, money, and stress

🎉 Conclusion

Wow! What a journey we’ve been on 😄

We started by answering the big question — What is Kubernetes? We discovered that it’s not some mythical beast, but a powerful orchestration tool that helps us manage, deploy, scale, and maintain containerized applications in a smarter way.

Then, we took a step back in time to see how applications were deployed before Kubernetes — the headaches of manually installing software on servers, spinning up separate cloud instances for every microservice, and racking up huge cloud bills just to stay afloat. We also saw how containers simplified things, but even they had their own limitations when managed at scale.

That’s where Kubernetes came to the rescue

We explored:

• The problems Kubernetes solves – like auto-scaling, efficient resource management, cost savings, and seamless container grouping.

• Kubernetes architecture and components – breaking down complex terms like the cluster, master node, worker nodes, Pods, Services, Kubelet, and more, into simple, easy-to-digest ideas.

• Kubernetes workloads like Deployments, Pods, Services, DaemonSets, and StatefulSets, and what they do behind the scenes to keep our apps running reliably.

From theory to practice, we even got our hands dirty:

• We created a free Kubernetes cluster using Play with Kubernetes 🧪

• Deployed a real application using both imperative (direct command) and declarative (manifest file) approaches

• Understood why the declarative method makes our infrastructure easier to manage, especially when our systems grow.

Then we took a business lens 🔍 and looked at:

• The advantages of Kubernetes – from auto-scaling during traffic surges, to cost efficiency, and cloud-agnostic deployment.

• And also the disadvantages – like needing experienced DevOps engineers and not being ideal for every stage of a product's lifecycle.

Finally, we wrapped up with real-life use cases, highlighting when Kubernetes is a must-have, and when it’s better to wait – especially for early-stage startups still trying to find their audience.

So, whether you're a DevOps newbie, a startup founder, or just someone curious about how modern tech keeps your favorite apps online – you now have a strong foundational understanding of Kubernetes 🙌

Kubernetes is powerful, but it doesn't have to be overwhelming. With a solid grasp of the basics (which you now have 💪), you're well on your way to managing scalable applications like a pro.

Start simple. Grow smart. And when the time is right – Kubernetes will be your best friend.

Study Further 📚

If you would like to learn more about Kubernetes, you can check out the courses below:

• Docker & Kubernetes: The Practical Guide (Academind - Udemy)

• Certified Kubernetes Application Developer (CKAD) Specialization (Coursera)

About the Author 👨‍💻

Hi, I’m Prince! I’m a DevOps engineer and Cloud architect passionate about building, deploying, and managing scalable applications and sharing knowledge with the tech community.

If you enjoyed this article, you can learn more about me by exploring more of my blogs and projects on my LinkedIn profile. You can find my LinkedIn articles here. You can also visit my website to read more of my articles as well. Let’s connect and grow together! 😊

I hope you're doing well. Whether you're a seasoned coder, a curious learner, or just someone browsing through, welcome to my little corner of the internet.

In this tutorial, we’ll dive into how you can deploy a web service on Microsoft Azure app service. It’s a topic I’ve been excited to explore, and I hope you’ll find it insightful and helpful. So grab a coffee, sit back, and let’s get started.

Prerequisites

• Basic understanding of RESTful web services

• Programming knowledge

• Docker basics

• Docker Hub account

• Command Line Interface (CLI) skills

What we’ll cover:

• Key Terminologies

• How to Install Docker and Docker Compose

• How to Create a Simple Get Client Info Web Service

• How to Build the App’s Docker Image

• How to Run the App in the Container

• How to Create an Azure Resource Group on Azure Portal.

• How to Deploy to Azure App Service

• Conclusion

Before we actually get started, I’d like to go over some key terminologies that I'll be using throughout this tutorial. Understanding these terms will make it easier to follow along and get the most out of what we're discussing. Let’s dive in!

Key Terminologies

1. Docker

Docker is an open-source platform that simplifies application development, shipping, and deployment by using containers. With Docker, there are three key things you can do:

• build once and run anywhere

• keep environment consistent, and

• easily scale your application with container orchestration tools like Kubernetes.

2. Docker Hub

Docker Hub is a cloud-based repository where developers can store, share, and manage Docker images. You can think of it as the GitHub for Docker images 😉.

3. Docker Image

A Docker image is a lightweight, standalone, and executable package that includes everything needed to run a piece of software. You can also think of it as a blueprint for creating and running a container.

Once built, an image is immutable, meaning it cannot change after creation. Instead, you create a new version when updates are needed. This means that you’ll need to rebuild if you update the code that’s being run in the container.

4. Container

A container is a running instance of a Docker image. It provides an isolated environment where an application runs with all its dependencies, without interfering with the host system or other containers.

Wait, what?! 😕 Well, simply put, a container is like a tiny virtual machine that runs the built Docker image. But unlike traditional VMs, it has no init process (PID 1), meaning it always runs on a host system rather than being fully independent. By now, you should be getting the idea: no image, no container. A container depends on an image to exist. You have to cook before you serve, right? 🍽️

5. Azure Resource Group

An Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. For example, if I want to deploy an eCommerce web app with MS Azure, I could create a resource group called EcommWebAppRG. I’d use this to create all the resources I needed for the web app to go live and be accessible – like VMs, DBs, caches, and other services.

Alrighty, now that all the terms are out of the way, lets get started with the tutorial so you can learn how to deploy a web service on Azure App Service.

Since we are deploying an app, let’s start by creating simple REST API app. I’ll be using Golang for the API development, but you can use any programming language/framework of your choice. If you’d like to follow along with the app for this tutorial, I’ve provided the source code here.

How to Install Docker and Docker Compose

To install Docker and Docker compose on your PC, for Mac and Windows you’ll need to download Docker desktop for your Operating System here.

For Linux, you can run the following command:

sudo apt update # update apt registry
sudo apt install docker.io # for docker engine
sudo apt install docker-compose-plugin

After downloading the Docker desktop for your application, open your terminal and enter the following command to verify that Docker and Docker Compose have been successfully installed on your machine:

docker-compose -v # this should show the version of docker compose cli you have on your PC

My Docker Compose version is:

Docker Compose version v2.31.0-desktop.2

docker -v

You should see something similar if Docker has successfully been installed on your machine:

Docker version 27.4.0, build bde2b89

How to Create a Simple Get Client Info Web Service

Alright, I’ll use this handy tool called sparky_generate to generate the app code template. sparky_generate is a command line tool used to generate boilerplate code for backend development using various backend languages and frameworks.

Use this command to install and setup the tool on your Mac or Linux machine. If you are on Windows, you can use WSL.

wget https://raw.githubusercontent.com/Ayobami6/sparky_generate/refs/heads/main/install.sh

chmod 711 install.sh
./install.sh # run the install command like so

sparky # run the sparky command like so

You should see something similar to the below. Select whatever framework you want to use for your backend service.

I will select Go, because I’m using Go for this tutorial. You should have your project template ready once you’ve selected your framework. I won’t go through how to code the web service since it’s out of scope for this tutorial. The goal here is to deploy on Azure using Azure App Service.

How to Build the App’s Docker Image

To build the Docker image for our app, we first need to create a Docker file that will include all the steps needed to build the image.

touch Dockerfile

We will be using a multistage Docker build to reduce the size of our Docker image. We need something as light as possible.

The multistage Docker build helps reduce size because we use different stages for different concerns. This helps ensure that only what’s needed runs the application in the final stage. For example, we might need certain artifacts to build the application, but we don’t need them to run the application. This is why we have the builder and runner stages in the Docker file below.

Our first stage (build) is concerned with building and bundling the application. The second stage (runner) is just used to run the executable we built in the first stage. So basically all files, modules, and so on used in the build process will be discarded in the runner since they’ve already served their purposes.

# using the first stage as build
FROM golang:1.23-alpine AS build # using alpine base image to reduce size

# install git on the machine
RUN apk add --no-cache git

# setting the current work directory on the vm to be /app
WORKDIR /app

# Copying all go dependency files to the working directory
COPY go.mod go.sum ./

# Install go dependencies
RUN go mod download

# copy all remaining files to the working directory
COPY . .
# build the execuatable

# build the go program
RUN go build -o api cmd/main.go

# stage 2 AKA the runner
FROM alpine:3.18

RUN  apk add --no-cache ca-certificates

# copy the go executable to the working directory
COPY --from=build /app/api .

# expose the service running port
EXPOSE 6080

This Dockerfile outlines all the steps for building a Docker image for our app. Lets go through all these steps line by line. Because we are using a multistage build here, our stages are build and runner.

• The first stage build starts from the first FROM golang:1.23-alpine AS build. It initializes a stage with all the steps in the stage. It states that the base image to be used for all the steps in this stage should use a pre-existing golang:1.23 image using an Alpine Linux distro to run all the steps in the stage.

• Next, we have RUN, which is used to run the command apk add git, followed by setting the working directory to the /app folder.

• Then we have the COPY command that copies all the Go dependencies that will run the Go program.

• Following that is RUN go mod download which is used to install all the dependencies.

• We then have the command COPY . . to copy all the files to the working directory /app of the image

• Then the last step in the build stage, RUN go build -o api cmd/main.go, builds the app code main.go to an executable API. The second stage “runner“ uses an alpine:3.18 base image, and also uses the RUN directive to add ca-certificates to the Alpine base image. The COPY is used here to copy just the built executable file from the builder image to the runner image.

• We then expose port 6080 so our built container can accept an HTTP connection from port 6080.

Now, let’s write our docker-compose.yml file to define and run our containerized service::

services:

  client_info_app:
    build: 
      context: .
      dockerfile: Dockerfile
    container_name: info_app

    ports:
      - "6080:6080"

    command: "./api"

Understanding the YAML Structure

YAML follows a key-value structure similar to a dictionary or hashmap. In our file, the top-level key is services, which acts as the parent key. Within services, we define individual service configurations.

In this case, we have a single service named client_info_app, which contains the necessary properties for Docker to build and run it.

• build: This specifies how to build the Docker image for the service. The context: . tells Docker to look for the Dockerfile in the same directory as the docker-compose.yml file.

• container_name: This assigns a custom name (info_app) to the running container, making it easier to reference.

• ports: Defines the port mappings between the host and the container. The - before "6080:6080" indicates that multiple mappings could be listed. Here, port 6080 on the host is mapped to port 6080 inside the container.

• command: Specifies the command to execute inside the container once it starts. In this case, it runs ./api.

This structure allows us to define and configure multiple services within the services key if needed, but for now, we are only defining client_info_app.

How to Run the App in the Container

You can use this command to start the container:

docker-compose up client_info_app

The above command will first build the image if it doesn’t exist. Then it runs it, because remember: no image, no container.

If all looks good, you should have something similar to this, depending on your application framework:

You should also verify that your Docker image has been built as well. To do that, run the following:

docker images

Voilà! You now have your Docker image built and ready for deployment on Azure App Service.

Let’s go on to the Azure Portal to deploy the app.

Note: if you don’t have an active Azure Subscription, that’s fine – you can still follow along. If you want to get a trial account, you can get one here.

How to Create an Azure Resource Group on Azure Portal.

As a reminder, an Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. Now let’s go about creating one.

When you login to the Azure portal, you should see some like this, the dashboard:

Search for Resource group using the search bar:

Click on Create to create a new resource group:

Give your resource group a name and select a region for it. Here I will use the default East US 2, but you can use any you want. Then click on Review + create.

You should see something like the above after creating the resource group.

How to Deploy to Azure App Service

Ok now that we’ve created the resource group, let’s go ahead and create the Azure App Service. To do this, navigate back to the dashboard and click on Create a resource.

You can search for Web App if you don’t see it in the list there. Then click on the Create Web App option:

Here, select the resource group you created earlier, give the app a name, then select Container for the Publish option.

Before you click on Create, go back to your dev workspace (VS Code or whatever IDE you are using) to push your Docker image to Docker Hub so you can add it there before proceeding to the next steps.

But why do you need to push to Docker Hub? Well, first of all, for accessibility – so we can easily share it with others or have other services access it (which is what we need here).

Remember how I compared Docker Hub with Github earlier? Docker Hub helps you host your Docker image on the internet and make it available for others or for various services on the internet to access if you make it public. Otherwise it’s limited to only authorized services.

To push the Docker image to Docker Hub, you first need to tag the Docker image with your Docker Hub username. Go to Docker Docker Hub to register and get your username if you don’t have one.

Run the following:

docker tag client_info_webservice-client_info_app:latest ayobami6/client_info_webservice-client_info_app:latest
# this adds the latest tag to your docker image

This shows that you successfully tagged your image with the latest tag.

Before you actually push the image to Docker Hub, go ahead and login to it with the Docker CLI.

docker login # this will prompt for browser authetication, for the prompt and login your account with your usernam and password

Push the image to Docker Hub like this:

docker push ayobami6/client_info_webservice-client_info_app:latest

You should see something like the below once you enter the push command on Docker Hub.

Alright, now that you have the Docker image on Docker Hub, you can go ahead and deploy it using Microsoft Azure App Service.

Click on the container on the top menu bar to configure the container settings.

Here, select Other container registries.

Select public, because your pushed image is public (meaning it’s publicly accessible over the internet).

Add your Docker image and tag. You can get this when you run the command docker images.

λ MACs-MacBook-Pro ~ → docker images
REPOSITORY                                        TAG         IMAGE ID       CREATED         SIZE
ayobami6/client_info_webservice-client_info_app   latest      a14f2a5b3bd4   2 weeks ago     30.8MB
postgres                                          13-alpine   236985828131   4 weeks ago     383MB
glint_pm_frontend-nextjs                          latest      424233ceaa4b   4 weeks ago     1.72GB
flask_app-flask_app                               latest      ff6ecfc4ba5a   5 weeks ago     203MB
nginx                                             latest      124b44bfc9cc   7 weeks ago     279MB
encoredotdev/postgres                             15          58b55b0e1fc7   10 months ago   878MB
λ MACs-MacBook-Pro ~ →

Copy the repository name and tag – in my case I have ayobami6/client_info_webservice-client_info_app and tag latest → ayobami6/client_info_webservice-client_info_app:latest.

Then add your startup command. If you are not using Go for the development like I am, your startup command will be different – so just use the command you added to your Docker compose command key, like so command: "./api". Copy just the value (mine is ./api) don’t add the double quotes, and add it to the startup command.

This start up command is the command that will start the application from the container and get the container running.

Click on review and create to create the service.

Once the deployment is complete you’ll be redirected here:

Congratulations! You’ve successfully deployed your web service to Azure App Service. You can visit your app using the default domain from the overview. Mine is here.

Conclusion

Deploying a RESTful web service on Microsoft Azure App Service is a powerful way to leverage cloud technology for scalable and efficient application hosting.

Understanding key terms like Docker, Docker Hub, and Azure Resource Groups will help you streamline the deployment process.

This guide walked you through creating a simple web service, building a Docker image, and deploying it on Azure. By following these steps, you can confidently deploy your applications, ensuring they are accessible and performant.

Thank you for following along, and I hope this tutorial has been insightful and helpful in your cloud deployment journey. If you found it useful, feel free to share it with others who might benefit from it. Happy coding and deploying!

Stay tuned for more insightful content, and let's continue learning and growing together. Cheers to building smarter, more efficient solutions with Azure.

The answer is Site Reliability Engineering (SRE). SRE is a discipline that ensures that your favorite online services keep running smoothly, even when things go wrong.

In this guide, you’ll learn about the core principles behind SRE, how automation can help you in this process, how to handle failure, and more.

Table of Contents

• SRE: More Than Just Fixing Problems

• Bridging the Gap Between Development and Operations

• The Core Principles of SRE

  • Focus on Availability and Reliability

  • Embrace Automation

  • Measure Everything

  • Work with Developers

  • Learn from Failure

• The SRE Role: A Balancing Act

• Why Automation Matters

• Key Takeaways for Anyone Involved in Digital Services

• Wrapping Up

SRE: More Than Just Fixing Problems

SRE goes beyond reacting to outages. It is a proactive approach to building and maintaining reliable systems. You can think of it as a blend of traditional IT operations, software engineering, and a relentless drive or pursuit for automation.

You might have heard of SRE being discussed alongside DevOps, so let’s differentiate them. DevOps is a broader set of principles that aims to improve collaboration and automation across the entire software development lifecycle. Site Reliability Engineering (SRE), on the other hand, is a specific implementation of these DevOps principles, with a strong focus on the operational aspects of running large-scale, highly reliable systems.

Let’s imagine a software company that wants to embrace DevOps. They might start the process by fostering better communication and shared goals between their development teams (who write the code) and their operations teams (who run the code in production). Also, they might implement continuous integration and continuous delivery (CI/CD) pipelines to automate the process of building, testing, and deploying software. This aligns with DevOps' focus on faster release cycles and improved collaboration.

Within this DevOps-oriented company, the SRE team might be specifically tasked with ensuring the reliability of their e-commerce platform. They would take the general DevOps principles and apply them to the operational challenges being experienced with a software engineering view.

For example, they would:

• define and measure Service Level Objectives (SLOs)

• develop and implement automated monitoring and alerting systems

• create self-healing infrastructure and automated incident response playbooks

• collaborate with development teams early in the software development lifecycle to ensure reliability

• conduct blameless post-incident reviews to learn from failures

• and track and automate away 'toil'.

Bridging the Gap Between Development and Operations

So as you can see, SRE is closely related to DevOps. One of the ways SRE implements DevOps principles is by bridging the gap between development and operations. SREs can do this in several ways.

First, SREs share responsibility with development teams for the reliability and performance of applications in production. This helps foster a collaborative environment and ensures that operational concerns are considered throughout the software development lifecycle.

SREs also provide valuable feedback to development teams based on their operational experience. They understand how software is designed and how it actually runs in production. This unique perspective allows them to identify potential issues early on and suggest improvements to the code, architecture, or deployment process.

And finally, SREs and development teams work together towards common goals, such as improving system reliability, increasing deployment frequency, and reducing time to recovery. This alignment ensures that everyone is working towards the same objectives.

The Core Principles of SRE:

Focus on Availability and Reliability

SREs aim to achieve specific service level objectives (SLOs), which are measurable targets for uptime and performance.

Scenario: A popular e-commerce website, used heavily during Nigerian business hours, sets an SLO of 99.9% uptime for its product catalog service. This high standard means the service is expected to be available almost all the time.

To understand just how little downtime this allows, let's break it down:

1. Downtime Percentage: An uptime of 99.9% means the allowed downtime is 100% - 99.9% = 0.1%.

   • Minutes in a day: There are 24 hours in a day, and each hour has 60 minutes, so there are 24 x 60 = 1440 minutes in a day.

   • Minutes in an average month*:* Assuming an average month of 30 days, there are approximately 30 x 1440 = 43,200 minutes in a month.

   • Allowed downtime in minutes: To find 0.1% of the minutes in a month, we calculate (0.1 / 100) x 43,200 minutes = 0.001 x 43,200 minutes = 43.2 minutes.

Therefore, a 99.9% uptime SLO for the product catalog service means it can be unavailable for a maximum of about 43 minutes per month. The SRE team constantly monitors the service's availability using tools that track request success rates and latency. If the availability drops below 99.95% (a leading indicator), the SRE team is alerted to investigate and remediate before the SLO is breached.

Example: An online banking platform in Nigeria has an SLO for transaction processing latency: 99% of transactions must be completed within 500 milliseconds. SRE dashboards track this metric in real time. If the latency starts to increase, indicating a potential performance issue, SREs investigate whether it's due to database bottlenecks, network congestion within Nigeria, or application code inefficiencies.

Embrace Automation

Automation is the heart of SRE. It reduces manual labor, improves consistency, and speeds up issue resolution.

Scenario: When a new server is provisioned for an application, an SRE has automated the entire process using infrastructure-as-code tools (like Terraform or Ansible). This includes configuring the operating system, installing necessary software, setting up monitoring agents, and deploying the application code.

Previously, this involved multiple manual steps taking hours and was prone to human error. Now, it's completed consistently in minutes.

Example: During peak traffic hours (for example, around lunchtime in Nigeria when many people are online), the load on a web server cluster increases. An SRE has implemented auto-scaling rules that automatically add more servers to the cluster when CPU utilization exceeds a certain threshold and remove them when the load decreases. This automated scaling ensures the service remains responsive without manual intervention.

Measure Everything

SREs rely on data and metrics to understand system behavior and identify various areas for improvement.

Scenario: For a ride-hailing app popular in Lagos, SREs track a wide range of metrics beyond just uptime. These metrics are often referred to as Service Level Indicators (SLIs), which are quantitative measures of a service's performance.

Examples include:

1. Request latency: How long it takes for a user to request a ride and get a confirmation.

2. Error rates: The percentage of ride requests or payment transactions that fail.

3. Resource utilization: CPU, memory, and disk usage of the servers.

4. Database query performance: The time it takes for database operations.

5. User engagement metrics: How often key features are used.

These SLIs are crucial for determining if the service is meeting its Service Level Objectives (SLOs) – the target values or ranges for these indicators (for example, 99% of ride requests should have a latency under 200ms). The metrics are visualized on dashboards, allowing SREs to understand the system's health and identify correlations between different indicators, ultimately helping them determine if the SLOs are being met or are at risk.

Example: After deploying a new version of their mobile app, SREs closely monitor key performance indicators (KPIs) like the number of active users in Lagos, the average time to complete a booking, and the frequency of crashes reported by users in Nigeria. This data helps them quickly identify if the new release has introduced any performance or stability regressions.

Work with Developers

SREs collaborate closely with development teams to ensure that applications are designed for reliability.

Scenario: When developers are designing a new feature for their Nigerian user base that involves significant data processing, SREs are involved early in the design phase.

They provide guidance on how to build the feature in a reliable and scalable way, suggesting patterns like circuit breakers, retries, and proper error handling.

This proactive collaboration helps prevent reliability issues from being baked into the application. SREs can also participate in design reviews, providing operational insights and raising concerns about potential failure points.

Example: Before a major marketing campaign is launched in Nigeria, which is expected to significantly increase traffic, SREs work with the development team to perform load testing on the application. This helps identify potential bottlenecks and areas for optimization before the actual surge in users occurs.

SREs provide insights into the system's capacity and suggest code changes or infrastructure adjustments to handle the anticipated load. SREs can analyze the load test results with developers, providing insights into the system's capacity and suggesting code changes, database optimizations, or infrastructure adjustments to handle the expected load. They can also jointly develop monitoring and alerting rules specific to the campaign's expected traffic.

Learn from Failure

Failure is inevitable. SREs use post-incident reviews to analyze failures, identify root causes, and implement preventative measures.

Scenario: A critical outage occurred on a payment gateway used by many Nigerian businesses. After the service is restored, the SRE team conducts a blameless post-incident review. They gather all relevant data (logs, metrics, timelines, communication records) and collaboratively analyze the sequence of events, the underlying causes (which might involve a combination of software bugs, configuration errors, and insufficient monitoring), and the impact on users.

The outcome of the review is a detailed document outlining the root causes and a list of actionable items with owners and deadlines to prevent similar incidents in the future (for example, improving monitoring for a specific metric, implementing a new rollback strategy, fixing a configuration management issue).

Example: A minor incident occurred where a specific API endpoint became slow for a short period during peak hours in Lagos. Even though the impact was minimal, the SRE team still conducts a lightweight post-incident review.

They analyze the logs and metrics to understand why the slowdown happened (perhaps a temporary spike in database load) and identify potential preventative measures, such as optimizing the database query or adjusting resource limits.

The actionable item might be to create a new dashboard specifically for this API endpoint's performance, with a target completion date and assigned to a specific SRE (owner). Afterward, the team will follow up and ensure the dashboard is serving its purpose.

SREs acknowledge that systems will fail, and the goal is not to prevent all failures but to minimize their impact. SREs can achieve this through:

1. Monitoring: SREs implement real-time tracking of system health and performance, which allows them to detect issues early on.

2. Logging: They use detailed records of system events for analysis, investigation, debugging, and troubleshooting, which is essential for understanding the root cause of failures.

3. Alerting: SREs set up automated notifications when system metrics deviate from expected thresholds, enabling them to respond quickly to potential problems.

4. Incident response: They establish structured and documented procedures for responding to and resolving incidents, ensuring a coordinated and efficient approach.

5. Post-incident reviews: SREs conduct in-depth analysis of incidents to identify root causes and prevent recurrence, treating every incident as a learning opportunity. This is a crucial aspect of continuous improvement.

The SRE Role: A Balancing Act

SREs face the challenge of balancing day-to-day operational needs with longer-term engineering initiatives. This "balancing act" is crucial for maintaining a system's stability and its ability to evolve and improve.

SREs typically spend their time in two key areas, each requiring a different skillset and focus:

Operational Responsibilities (50%):

An SRE’s operational responsibilities are pretty wide-ranging. They typically involve responding to incidents and outages, which is a core part of any operations role. SREs are often on-call, meaning they are available to address urgent issues outside of regular work hours.

They also handle escalations, which means taking over complex or critical issues that other teams can't resolve.

SREs also provide support to internal and external customers, which can involve troubleshooting problems, answering questions, and providing guidance.

These responsibilities require strong problem-solving skills, quick thinking, and the ability to remain calm under pressure.

Engineering Responsibilities (50%):

Engineering responsibilities are what truly distinguish SREs. SREs are responsible for automating manual tasks, which is crucial for increasing efficiency and reducing errors.

They also develop monitoring and alerting systems, which involve designing and implementing tools to track system health and notify teams of potential problems.

SREs contribute to improving system reliability and performance by identifying and addressing bottlenecks, optimizing code, and implementing best practices.

They contribute to software development with a focus on operational concerns, which means they work with developers to ensure that applications are designed for scalability, maintainability, and resilience.

These responsibilities require strong programming skills, a deep understanding of system architecture, and a proactive approach to problem-solving.

Why Automation Matters

Automation is an important tool that SREs use to achieve both their operational and engineering goals. It's not about replacing human engineers, but about empowering them to work more effectively.

There are several key areas where automation is really important:

1. Reducing toil: SREs use automation to eliminate repetitive, manual tasks, often referred to as "toil." This frees up their time to focus on more strategic work, such as improving system design and implementing new features.

2. Improving efficiency: Automation can significantly speed up processes like deployments, rollbacks, and incident response, which leads to faster recovery times and reduced downtime.

3. Enhancing reliability: By automating critical processes, SREs can reduce the risk of human error, which is a common cause of outages and other issues.

4. Gaining deeper understanding: Every time an SRE automates a process, they gain a deeper understanding of the system, leading to further improvements or enhancements. This iterative process of automation and learning is central to the SRE approach.

Key Takeaways for Anyone Involved in Digital Services:

1. Reliability is a feature: Treat reliability as a major requirement, not an option.

2. Automation is essential: Embrace automation to reduce toil and improve efficiency.

3. Make data-driven decisions: Use metrics to understand system behavior and in turn guide improvements.

4. Collaboration is key: Foster close collaboration between development and operations teams.

5. Focus on continuous improvement: Adopt a culture of continuous learning and improvement.

Wrapping Up

You've now gained a foundational understanding of Site Reliability Engineering and its core principles centered around availability, automation, measurement, collaboration, and learning from failure. You’ve also learned how it plays a crucial role in ensuring the smooth operation of the digital services we rely on every day.

If you found this tutorial helpful and want to stay connected for more insights on Site Reliability Engineering, you can follow me on Twitter, connect on LinkedIn, or reach out via email at omolade.ekp@gmail.com.

If you need a basic introduction to cloud computing, here’s a beginner-friendly tutorial for you: What is Cloud Computing? A Guide for Beginners.

In this guide, I’ll show you how to create an AWS EC2 instance. This is one of AWS’s top services for building applications. By the end of this guide, you'll know how to launch an AWS EC2 instance and connect it to VS Code.

Table of Contents

• Prerequisites

• What is an AWS EC2 Instance?

• Why Connect Your AWS EC2 Instance to VS Code?

• How to Launch and Connect Your AWS EC2 Instance to VS Code

  • Step 1: Create an AWS EC2 Instance

  • Step 2: Connect the AWS EC2 Instance to Your Code Editor

  • Step 3: Install the Programming Language

  • Step 4: Open a Remote Window

  • Step 5: Access Your Project Folder

• Conclusion

Prerequisites

Before you start, make sure you have:

• An AWS account. If you do not have one, sign up here.

• A GitHub repository with your source code. If you don’t have a GitHub account, sign up here.

• Basic knowledge of web development and version control.

• A code editor. For this tutorial, I’m using VS Code.

Let’s jump right in!

What is an AWS EC2 Instance?

AWS EC2 (Elastic Compute Cloud) allows you to run virtual machines in the cloud. These computers allow you to run your applications without needing physical hardware.

There are a number of things you can you do with AWS EC2, such as hosting websites or apps, running big data or machine-learning tasks, creating testing environments, and handling tasks that need flexible, scalable computing power.

Why Connect Your AWS EC2 Instance to VS Code?

Connecting your AWS EC2 instance to VS Code is helpful for several reasons. Before we start the setup process, it’s important to learn why it’s beneficial.

1. Using VS Code provides a familiar and efficient development space. It feels like coding on your own machine.

2. You don’t have to log into your AWS EC2 instance each time. You can edit files, run commands, and debug code from a distance.

3. You can streamline your workflow with built-in terminal access and extensions. This way, you won't have to switch between SSH clients all the time.

4. You can push changes to GitHub. This makes working together and deploying much smoother.

5. VS Code works well with Java, Node.js, and Python. It supports many languages and frameworks, so it's great for cloud development.

Now that you understand the benefits, let’s move on to setting up the connection.

How to Launch and Connect Your AWS EC2 Instance to VS Code

To launch an EC2 instance on AWS, just follow these steps:

Step 1: Create an AWS EC2 Instance

First, log into your AWS account. Then, use the search bar to find EC2 and select it.

Click EC2 and follow the on-screen instructions to create a new instance.

1. Choose an AMI (Amazon Machine Image): This is a pre-configured template that includes an operating system and may come with additional software.

2. Select an instance type: Pick the right size for your needs. For example, t2.micro is a good option for beginners and small workloads.

3. Configure Your EC2 Instance: Set up networking, storage, security groups, and other options based on your requirements.

4. Launch Your Instance: Start your virtual server and access it remotely to begin using it.

Launched instance running:

So what’s happening in Step 1?

By launching an AWS EC2 instance, you are setting up a remote server in the cloud. AWS offers different AMIs that serve as pre-configured environments.

Step 2: Connect the AWS EC2 Instance to Your Code Editor

To connect your EC2 instance created in AWS to your VS Code, you need SSH.

What is SSH?

SSH (Secure Shell) is a secure way to connect and communicate with other devices. It keeps your connection safe. This is important when you access servers or repositories. In Git, you can use SSH instead of HTTPS to clone repositories with a secure connection.

Why is SSH important here?

With SSH, you can link your local code editor (like VS Code) to your AWS EC2 instance. This allows you to work on files stored on the EC2 instance directly from your editor as if on your local computer.

To connect your AWS EC2 instance to your local editor using SSH, follow these steps:

• Open your terminal.

• Go to the folder where your .pem key file is. The key file (.pem) downloads automatically when you create your EC2 instance (usually in the Downloads folder).

• Update the file permissions to keep your key secure and ensure proper authentication.

For Linux users, use this command to update the file permissions:

chmod 400 codebuild-keypair.pem

For Windows users, first you’ll need to find the username of your laptop, as you’ll need it to update the file permissions.

To do this, open your terminal and type:

whoami

This will display your current username.

Once you have your username, use the following command to update the file permissions:

icacls "codebuild-keypair.pem" /reset
icacls "codbuild-keypair.pem" /grant:r "%USERNAME%:R"
icacls "codebuld-keypair.pem" /inheritance:r

Here's what I mean: My username is ijeon, so you should replace it with your laptop's username and own key, which ends with .pem extension.

Running this command above updates the file permissions. So with this, you can work with your remote server.

Now that you have set the correct file permissions, you can use the SSH command along with the IPv4 address to connect to our EC2 instance. Type the following command:

ssh -i [PATH TO YOUR .PEM FILE] ec2-user@[YOUR PUBLIC IPV4 DNS]

Example:

ssh -i "C:\Users\ijeon\OneDrive\Desktop\devops-series-nextwork\codebuild-keypair.pem" ec2-user@ec2-35-178-142-201.eu-west-2.compute.amazonaws.

Breaking it down:

1. ssh: This starts a secure remote connection.

2. -i "C:\Users\ijeon\...\codebuild-keypair.pem": This tells SSH to use the .pem key file for secure access.

3. ec2-user@ec2-35-178-142-201.eu-west-2.compute.amazonaws.com:

   • ec2-user is the default username for EC2 instances.

   • @ec2-35-178-142-201... is the public address of your EC2 instance.

This command logs you into your EC2 instance remotely from your computer. It then uses the key (.pem file) instead of a password for security. It also lets you control the EC2 instance from your terminal as if you were using it directly.

If everything is set up correctly, a “success message” will appear. This confirms that you've logged in and can access the remote server.

Step 3: Install the Programming Language

Now that you’ve linked your instance to the editor, you can install the packages needed to build your web app. You can use any programming language you're comfortable with, but we’ll use Java for this tutorial. This will be a simple web application – we don’t need to go into advanced details.

1. Install Java

In your terminal, run the following commands to install Java:

sudo dnf install -y java-1.8.0-amazon-corretto-devel

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64

export PATH=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64/jre/bin/:$PATH

This installs Java on your system. You also need Maven. It helps manage Java projects and create templates for web applications.

2. Install Maven

Maven helps you organize Java projects. It also lets you create templates for web applications. Run these commands to install Maven:

wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz

sudo tar -xzf apache-maven-3.5.2-bin.tar.gz -C /opt

echo "export PATH=/opt/apache-maven-3.5.2/bin:$PATH" >> ~/.bashrc

source ~/.bashrc

To confirm Maven's correct installation, run this command:

mvn -v

Also, run the following command to check whether you have Java installed:

java -version

Now that you have installed Maven, you can use it to create a Java web app with the following command:

mvn archetype:generate \
  -DgroupId=com.nextwork.app \
  -DartifactId=nextwork-web-project \
  -Dpackage=com.nextwork.app \
  -DarchetypeArtifactId=maven-archetype-webapp \
  -DarchetypeVersion=1.4 \
  -DinteractiveMode=false

Running the command above generates a template for your application. In the terminal, it should show a "Build Success" message. This means the setup worked.

Step 4: Open a Remote Window

Now that you’ve installed the necessary packages and set up your app template, you need to open your IDE or code editor. This will let you access the folders on your remote server.

In your terminal, click the double arrow icon at the bottom left.

When you click on it, it opens a modal window for you.

A window will appear. Click "Connect to Host," which will open another window.

Then choose "Add New SSH Host" to open the SSH connection terminal.

Input your SSH command to configure the host.

After pressing "Enter," a configuration file will open. In this file, ensure that the .pem file and the IP4v DNS addresses from your EC2 instance are correct.

Here’s a GIF view of the image above:

Here’s the configuration file:

Go back to your editor and click on that double arrow again. This will automatically open a new window.

If your editor displays the IPv4 DNS address, your VS Code is successfully connected to the EC2 instance.

Now that you’re connected and a new window has opened, let’s access the folder stored in the cloud.

Step 5: Access Your Project Folder

In step 3, remember when you installed Maven? It created a template for your web app. Now, you’ll access the folder where you created this.

1. Go to the Explorer panel in the window.

2. Click the “Open Folder” button.

Clicking on this button opens a modal box for you to select your folder, which was created by the Maven template:

To access the template file, click the “src” folder. This takes you to the index.jsp file.

With this template created, you can decide to tweak it and send it to your Git repository for storage.

Conclusion

Great job! You’ve set up an AWS EC2 instance, linked it to your code editor, and installed the tools needed for your web app. In this tutorial, we used Java, but you can also choose other languages like Node.js or Python.

If you found this article helpful, please share it with others who may find it interesting.

Stay updated with my projects by following me on Twitter, LinkedIn and GitHub.

Thank you for reading.

This article compares three leading CDEs: Harness CDE, Gitpod, and Coder. My goal here is to offer an objective analysis to help you make informed decisions based on your specific needs.

What is a Cloud Development Environment (CDE)?

A Cloud Development Environment (CDE) is a cloud-hosted workspace where developers can write, test, and deploy code without relying on local machines. Unlike traditional setups, CDEs provide pre-configured environments accessible via a browser or IDE, eliminating the "it works on my machine" problem.

How CDEs differ from traditional development environments

• CDEs are more consistent and help standardize tools, dependencies, and configurations across teams.

• They’re also accessible from anywhere, enabling remote collaboration.

• They’re more scalable, as resources (CPU, memory) scale dynamically based on workload.

• And they’re secure, with centralized security controls and compliance adherence (for example, SOC 2, GDPR).

Common CDE Features

Most CDEs come with a variety of helpful features. They typically have pre-built environment templates (for example, Python, Node.js) and integrate easily with Git repositories and CI/CD pipelines. They also have various real-time collaboration tools, as well as the ability to automate backups and recovery.

You’ll learn more about specific features when we discuss each of our CDE options below.

The Case for Cloud-Based Development

CDEs can help you and your team solve some critical pain points:

CDEs make setup easier

When using a CDE, you don’t have the hassle of setting up local machines. Instead, you have a pre-configured development environment that’s ready to go in minutes. With a traditional setup, you have to install dependencies, configure environments, and resolve compatibility issues – and this can take hours or even days. CDEs make this process much easier.

Let’s say a new developer joins your project that requires a complex stack – it needs a specific Python version, multiple frameworks, and environment variables. Instead of spending hours configuring their local machine, they can just launch a cloud-based workspace (like one of the tools we’ll discuss here), which comes pre-loaded with everything they need.

CDEs help reduce costs

CDEs can reduce your costs by making sure that development resources are allocated only when they’re needed. Unlike local machines, which require upfront investment in high-performance hardware, cloud environments help you scale resources dynamically and pay only for the compute power you and your team use.

Perhaps your team is developing a resource-intensive AI application. If you’re using a CDE, you’ll no longer need to provide every developer with an expensive workstation. Instead, you can just provision high-performance cloud instances when needed and shut them down when idle. This cuts down on unnecessary spending.

CDEs enhance security

With cloud-based environments, code and sensitive data remain on secure, centralized servers rather than being stored on individual developer machines. This helps reduce the risk of data loss or theft. CDEs also provide audit logs, identity management, and automated backups, all of which help make things more security.

Let’s say a financial services company requires strict security controls over customer data. By using a CDE, the developers on the team can access code via secure connections without storing sensitive files locally. This helps ensure compliance with industry regulations like SOC 2 or GDPR.

CDEs enable global collaboration

CDEs make collaboration among distributed teams much easier by allowing multiple developers to work in the same environment with shared configurations. Remote developers can contribute from anywhere without worrying about compatibility issues or inconsistent setups.

For example, perhaps your global development team is working on a SaaS product. They can use a CDE to collaborate in real time. A member of your dev team in India can start debugging an issue, and then a teammate in the US can pick up where they left off hours later without needing to set up the same environment locally.

Methodology

This analysis is based on official documentation, user reviews, and independent testing. All information is current as of the last update date. The article is focused on key aspects such as features, deployment options, security, pricing, and use cases.

Overview of Each Tool

Harness CDE

Harness CDE is part of the broader Harness platform, designed to streamline software delivery with integrated CI/CD pipelines, feature flags, and cloud cost management. It provides enterprise-grade security, a user-friendly interface, and robust integration capabilities, making it ideal for large-scale applications.

With its comprehensive suite of tools and advanced cost management, Harness CDE helps enterprises efficiently manage their entire development lifecycle. Harness CDE's intuitive interface and detailed documentation further enhance its suitability for large-scale applications.

Drawbacks

Despite its many strengths, Harness CDE is relatively new to the market, meaning its features and capabilities are still evolving. Deep integration with the Harness platform could make switching challenging.

Gitpod

Gitpod is a SaaS solution that provides automated, ready-to-code development environments. It integrates seamlessly with popular version control systems like GitHub, GitLab, and Bitbucket, offering fast and consistent setups.

Gitpod is known for its user-friendly web interface and quick onboarding process, which significantly reduces setup times and lets devs focus on coding rather than environment configuration. This makes it ideal for agile development teams and startups.

Drawbacks

Gitpod's SaaS model offers limited control over infrastructure, which can be a disadvantage for teams needing more customization and control. Also, dedicated instances can be more costly, potentially offsetting some of the benefits of its free plan.

Coder

Coder is an open-source platform offering both free and self-managed (paid) options. It provides highly customizable, secure, and scalable development environments that you can host on your infrastructure. This makes it suitable for organizations needing tailored solutions.

Coder excels in environments where stringent security and compliance requirements are paramount, offering extensive control and customization.

Drawbacks

Coder requires more setup time and maintenance compared to Gitpod and Harness CDE. Its reliance on self-managed infrastructure can also increase complexity and cost, particularly for smaller teams or startups without dedicated DevOps resources.

Detailed Feature Comparison

Now let’s compare some basic features to see how these three tools stack up against each other.

Deployment and Scalability

• Harness CDE: Integrated with the Harness & Gitness platforms, offering high scalability within the Harness ecosystem.

• Gitpod: SaaS model with easy scalability and options for managed dedicated instances.

• Coder: Self-managed deployment with full control over infrastructure, providing high scalability for tailored environments.

Integration and User Experience

• Harness CDE: Comprehensive suite of development tools, intuitive interface, and detailed documentation.

• Gitpod: Seamless integration with GitHub, GitLab, and Bitbucket, featuring automated setups and excellent documentation.

• Coder: Integrates with existing infrastructure and various tech stacks, providing detailed documentation and customizable configurations.

Security and Compliance

• Harness CDE: Enterprise-grade security features, including SOC 2 compliance, role-based access control, and advanced secrets management. Offers comprehensive audit logging and governance with policy-as-code support.

• Gitpod: Secure environments with data encryption, SOC 2 compliant.

• Coder: Focuses on security and compliance, supporting various standards like HIPAA and GDPR.

Cost/Pricing

• Harness CDE: Competitive pricing with integrated platform features. A lot of features are free to use. Pricing varies based on scale and needs – contact Harness for details.

• Gitpod: Varies with free and paid plans, limited customization based on SaaS offerings. The free plan includes 50 hours/month, while paid plans offer unlimited hours.

• Coder: Costs depend on self-managed infrastructure, offering high customization and control over environment setup. The tool is free for open-source use, and paid for self-managed deployments.

Setup Time and User Interface

• Harness CDE: Fast setup with integrated CI/CD pipeline and modern, intuitive interface.

• Gitpod: Quick setup in minutes with a user-friendly, web-based interface.

• Coder: Setup time varies based on custom configurations, offering a flexible and customizable interface.

Availability

• Harness CDE: Part of the Harness platform, typically targeted at enterprise users.

• Gitpod: SaaS model with both free and paid plans.

• Coder: Open-source with both free and self-managed (paid) options.

Specs

• Harness CDE: Integrated CI/CD, feature flags, cloud cost management, enterprise-grade security, and so on.

• Gitpod: Automated setups, seamless integration with VCS, user-friendly interface.

• Coder: Highly customizable, secure, scalable, extensive control.

Additional Features

Here’s a detailed table that includes info on a bunch of other features that might help you make your decision as to which tool is best for you.

How to Choose the Right Tool

As you can see, each of these cloud development environments has its strengths. It’s up to you to analyze them and decide which tool is right for you. Here’s a quick summary:

• Harness CDE offers the fastest startup times and a straightforward, performance-focused approach.

• Gitpod provides the widest language support and a large community, with competitive pricing.

• Coder excels in security, compliance, and customization.

When choosing a CDE, consider the following factors:

• Team size and structure

• Existing technology stack

• Security and compliance requirements

• Budget constraints

• Customization needs

• Scalability requirements

• Integration with existing tools and workflows

Conclusion

In this guide, you learned about three CDE tools and their main features. Which of these tools you choose will largely depend on your specific needs.

Ultimately, I recommend that you take advantage of any free trials or demos offered by these platforms to get hands-on experience before making a decision. Consider your team's specific workflows, the technologies you use, and your scalability needs when choosing a cloud development environment.

References

• Harness Docs

• Gitpod Docs

• Coder Docs

Note: This article is for informational purposes only. Everyone should conduct their own thorough evaluation based on their specific requirements before making a decision.

I hope you’ve enjoyed it and have learned something new. I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.

If you’ve enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorsing me for relevant skills on LinkedIn.

Till the next one, happy coding!

In this tutorial, I’ll show you how to use AWS Lambda with three other services:

• Amazon S3 for storing files, images, and videos

• Amazon Simple Notification Service (SNS) for sending notifications

• Amazon EventBridge for scheduling messages

We’ll go through everything step by step.

By the end, with the integration of the other services, you will have built a Goal Manifestation Quote App that sends random inspirational messages to keep you motivated and focused on your goals.

Prerequisites

• An AWS account: If you don’t have one, sign up here.

• A GitHub repository: This is for storing your source code. If you don’t have a GitHub account, you can create one here.

• An Integrated Development Environment (IDE) such as Visual Studio Code or Sublime Text.

• A basic knowledge of web development and any programming language of your choice. I used Python for this tutorial.

• Zenquote Random API

What You'll Learn

• How to create an Amazon S3 bucket

• How to use Amazon Simple Notification Service (SNS)

• How to use Amazon Lambda

• How to use Amazon EventBridge

Table of Contents

1. Step 1: Set Up Your Development Environment

2. Step 2: Create an Amazon Simple Storage Service (S3)

3. Step 3: Create an Amazon Simple Notification Service (SNS)

4. Step 4: Create an IAM Policy

5. Step 5: Create an Amazon Lambda function

6. Step 6: Create an EventBridge

7. Step 7. Upload Your Code

8. Conclusion

Step 1: Set Up Your Development Environment

In this step, you'll get everything set up. Start by signing in to your AWS account, then install Python if you don't have it on your IDE.

Step 2: Create an Amazon Simple Storage Service (S3)

Before we begin creating an S3 bucket, let's first understand what Amazon S3 is:

Amazon S3 (Simple Storage Service) is a service from Amazon that allows you to store and access any amount or type of data, such as photos, videos, documents, and backups, whenever you need it.

Now that you know the basics of what Amazon S3 is, let's return to the tutorial.

Create an S3 Bucket

There are several ways to create an S3 bucket, but for this tutorial, we'll use the Ubuntu command line (CMD), your terminal, or Amazon CloudShell, depending on what you're most comfortable with.

• Type boto3 s3 in the web search bar to view a list of related documentation.

• Click on the first result.

• Once the documentation is open, copy the first command you see.

• Paste it on your CMD OR terminal of your choice – but before then remember to "cd" into the right directory.

• In the documentation, scroll down and click on "create_bucket.

• Once it's open, scroll down to "Request Syntax." Copy the bucket name and the bucket configuration.

• Other variables listed in the request syntax are optional.

• Once this is done, make sure you save.

• Go back and call the script:

#python3 your file name

• Running the script automatically creates an S3 bucket in your Amazon S3.

• Now you can go to the console to check if it has been created:

Upload Files

With the bucket created, we can now upload files through the console. I believe there's also a programmatic way to upload files and test, but I haven't explored all the methods in the documentation yet.

Click on the bucket name to be redirected to the object page. This is where you will upload your files for storage.

Click on the Upload button to upload a file. Remember, we're creating a Goal Manifestation Quote Application.

Now that we've set up a storage bucket:

• Open a tool like Google Drive, MS Word, WPS, or any other document editor.

• Write down the goals you want to achieve.

• Save the file in either PDF or DOCX format.

• Take the document and upload it to your Amazon S3.o

To verify if it's the correct file:

• Navigate to the Permissions tab.

• Scroll down to Block public access.

• Click on Edit and uncheck the box.

As shown above, it is currently set to "on." Uncheck it to turn it "off."

• On the same bucket settings page, modify the policy.

• Scroll down, and you'll see that a bucket policy has been auto-generated.

• Go ahead and copy the policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

• Go back to the bucket policy editor and paste the policy.

Once you've completed these steps, your object will have public access.

Return to the Objects tab and click on the Object URL provided below:

With this URL, your upload is now visible.

Step 3: Create an Amazon Simple Notification Service (SNS)

SNS is a fully managed messaging service provided by AWS. It enables communication between applications or directly with users by sending notifications.

To create an SNS, follow these steps:

1. Log in to the AWS management console

Then go to Amazon SNS. Navigate to the SNS Dashboard and select Topics from the left-hand menu.

To create a topic:

• Click Create topic.

• Choose a Topic type: Standard (default) or FIFO (for ordered messages).

• Enter a Name for your topic. (for example, MyFirstSNSTopic).

  

• Configure optional settings like encryption, delivery retry policies, or tags.

• Click Create topic.

2. Add Subscriptions:

Once the topic is created, click on it to open the details page. Select the Subscriptions tab.

Click Create Subscription and choose:

• Protocol can be Email, SMS, HTTP/S, Lambda, or SQS.

• Endpoints such as email address, phone number, or URL.

Click Create Subscription.

3. Confirm the Subscription:

If you selected email or SMS, a confirmation link or code will be sent to the provided endpoint. Follow the instructions to confirm the subscription.

Now that we’ve done this, let's create an Amazon Lambda function that will trigger the SNS so that the message will be sent to your mail.

Step 4: Create an IAM Policy

This policy is created to authorize Amazon Lambda to trigger the event and to ensure that CloudWatch is automatically triggered to monitor the application's events.

To create a policy, follow these steps:

1. Log in to the AWS Management console.

In the left-hand menu, select Policies. Then:

• Click Create policy.

• Choose the Visual tab, then select the SNS service.

• Next, click the Choose tab to create a custom policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sns:Publish",
            "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:goal_topic"
        }
    ]
}

Then, replace the following placeholders with your info:

• region: Your AWS region (for example, us-east-1).

• account-id: Your AWS account ID.

• topic-name: Your SNS topic name.

2. View and create the policy:

You can do this by following these steps:

• Click on the Review button.

• Give your policy a Name (for example, LambdaSNSPolicy), and optionally, a Description.

• Click Create policy.

3. Attach policy to the Lambda Execution Role

Now, you need to attach the policy to your Lambda Execution Role. To do that, follow these steps:

• Go to the Roles section in the IAM Console.

• Search for and select the execution role.

• Next, search for the policy you just created and select it.

• Click Attach policy.

Both policies will be automatically attached.

Step 5: Create an Amazon Lambda function

Amazon Lambda is a service from AWS that lets you run code without managing servers. You upload your code, and Lambda automatically runs and scales it when needed.

Follow these steps to create an Amazon Lambda function:

1. Log in to AWS Management Console:

Navigate to AWS Lambda.

2. Create a Function:

Click on the Create function and choose the option Author from scratch.

Fill in the details:

• Function name: Enter a unique name (for example, SNSLambdaFunction).

• Runtime: Select the runtime (for example, Python, Node.js, Java, and so on).

• Role: Choose or create a role. If you already have a role, select Use an existing role. Otherwise, select Create a new role with basic Lambda permissions.

• Click the Create function button.

3. Paste in the code:

On the Lambda function’s page, go to the Configuration tab:

Remember, we are trying to fetch a quote. I'll add the ARN of the topic we created here and include my API keys. But for this tutorial, I will use the API directly to fetch the data.

4. Write the Lambda Code:

Go to the Code tab in your Lambda function. Then write or paste the code from your IDE to process the incoming SNS messages.

Example:

Here’s the code:

import os
import json
import urllib.request
import boto3

def fetch_random_quote():
    """
    Fetches a random quote from the ZenQuotes API.
    """
    api_url = "https://zenquotes.io/api/random"
    try:
        with urllib.request.urlopen(api_url) as response:
            data = json.loads(response.read().decode())
            if data and isinstance(data, list):
                # Format the quote and author
                quote = data[0].get("q", "No quote available")
                author = data[0].get("a", "Unknown author")
                return f'"{quote}" - {author}'
            else:
                return "No quote available."
    except Exception as e:
        print(f"Error fetching random quote: {e}")
        return "Failed to fetch quote."

def lambda_handler(event, context):
    """
    AWS Lambda handler function to fetch a random quote and publish it to an SNS topic.
    """
    # Get the SNS topic ARN from environment variables
    sns_topic_arn = os.getenv("SNS_TOPIC_ARN")
    sns_client = boto3.client("sns")

    # Fetch a random quote
    quote = fetch_random_quote()
    print(f"Fetched Quote: {quote}")

    # Publish the quote to SNS
    try:
        sns_client.publish(
            TopicArn=sns_topic_arn,
            Message=quote,
            Subject="Daily Random Quote to help you stay motivated and inspired to achieve your goals",
        )
        print("Quote published to SNS successfully.")
    except Exception as e:
        print(f"Error publishing to SNS: {e}")
        return {"statusCode": 500, "body": "Error publishing to SNS"}

    return {"statusCode": 200, "body": "Quote sent to SNS"}

5. Save:

Click on the deploy button to save.

6. Test Your Lambda Function:

Go to the Test tab and create a new test event.

Then save and run the test. If it’s successful, a message will be sent:

This means the message has been created for you

Finally, check your email or SMS, depending on the endpoint you used for this tutorial. In my case, I used email.

Step 6: Create an EventBridge

Amazon EventBridge is a service that helps you connect applications and AWS services such as the Amazon SNS and Amazon Lambda.

To create an Amazon EventBridge rule, follow these steps:

1. Navigate to EventBridge:

In the search bar, type EventBridge and select it from the services list.

2. Create a Rule:

In the EventBridge console, click Rules on the left panel. Then click the Create rule button.

3. Set Up the Rule Details:

• Name: Enter a unique name for your rule.

• Description (optional): Add a description to explain what this rule does.

4. Choose the Event Bus:

Select Default event bus (or another event bus if you've created one).

5. Define the Event Pattern or Schedule:

For Event Pattern:

• Choose an AWS Service as the event source.

• Select the specific event type (for example, an S3 file upload or an EC2 instance state change).

For Schedule:

• Choose the Schedule option to run the rule on a fixed interval (for example, every 5 minutes).

• Click on continue. This takes you to the specific details page where:

• Scroll down and click on the cron scheduler. The cron scheduler specifies what time the message will be sent.

• Select "Off" for the flexible time window option.

• Review the rule details to confirm everything is correct.

• Click the "Next" button to proceed to the Target page.

  

  The picture above shows when the time the messages will be sent.

  • On the Target page, select AWS Lambda to invoke your function.

• Scroll down to invoke and choose the function you created.

• Click the "Next" button to proceed. This will take you to the settings page. Under the permissions section, select "Use existing rule."

• Lastly, go to the review and create a schedule:

• The next page shows you all the details:

Using the EventBrige creates a scheduler for the users.

Step 7: Upload Your Code

Finally, upload your code to GitHub and include proper documentation to help explain how the code works.

Check this documentation out if you don’t know how: Uploading a project to GitHub.

Conclusion

If you’ve followed all these steps, you will have created a Goal Manifestation Quote App using AWS Lambda, Amazon S3, Amazon SNS, and Amazon EventBridge. This app fetches motivational quotes and sends them to subscribers on a schedule.

You can find the repository link here.

Feel free to share your progress or ask questions if you have any issues.

If you found this article helpful, share it with others.

Stay updated with my projects by following me on Twitter, LinkedIn and GitHub

Thank you for reading 💖.

Disclaimer:
The resources shown in this article, including the S3 bucket and its ARN, have been deleted and no longer exist. The details visible in the screenshots are used solely for demonstration purposes.

In Kubernetes environments, the complexity of managing distributed microservices can be challenging. For instance, an application usually spans multiple pods, nodes, and clusters. Because of Kubernetes’s dynamic nature, where pods are frequently created and terminated, proper monitoring and observability are ideal for capturing its fleeting behavior.

Imagine building a microservices application with several connected services handling critical components such as authentication, payments, and databases without proper monitoring. A sudden traffic spike could affect a single service, cascading to other services, causing the system to crash and resulting in downtime.

Without proper visibility, you may struggle to find the root cause of the issue. You may spend hours manually going through logs – and meanwhile, users are frustrated, and businesses are losing revenue and customer trust.

Before we begin the project, you’ll learn key monitoring and observability concepts, as well as why tools like Prometheus and Grafana are crucial for setting up a robust monitoring stack on your Kubernetes infrastructure.

Here’s what we’ll cover:

• Understanding Monitoring and Observability

• Tools for Monitoring and Observability

• How to Deploy Prometheus and Grafana on AWS EKS using Helm

• Conclusion

Understanding Monitoring and Observability

Implementing a proper monitoring and observability approach is important in fast-paced production Kubernetes environments. This helps in situations where downtime can lead to serious business loss and damage to customer trust. It’ll hopefully help you avoid the dreaded 2 am calls that are usually triggered by alert noise so you can focus on adding more innovative features to your software (rather than spending so much energy firefighting).

Monitoring and observability are often referred to as the same thing. But they serve two different purposes, especially for development and engineering teams.

Monitoring

In the software development lifecycle, monitoring is the practice of analyzing data in real time or reviewing data trends to ensure the health and performance of systems, infrastructure, and applications. Monitoring acts as the eyes and ears of your IT operations, collecting insightful data and presenting it in a way that is actionable.

If you have visited the IT department of a well-established organization, you have most likely seen large screens displaying colorful dashboards with charts and real-time statistics. This offers a centralized view of the key metrics, such as the server uptime, application response times, and resource usage.

Observability

Observability helps to address issues that haven’t been anticipated. These are usually called “unknown unknowns." Unlike monitoring, which deals with predefined parameters and data, observability goes deeper into the application to give a broader view.

This not only helps to answer what is happening within your system and why it is happening. It also uses patterns within the system and application operations to detect and resolve issues efficiently.

Observability revolves around the three pillars of data: metrics, logs, and traces.

1. Metrics

Metrics consist of time-series measurements such as CPU usage and memory consumption. These data points help teams to manage, optimize, and predict system performance and deviations from expected behavior.

2. Logs

Logs serve as a history of what happened within the system. It is a trail for engineers, especially during troubleshooting. Logs are important in diagnosing root causes and discovering malicious activities.

3. Traces

Traces provide insights into application workflows by tracking requests as they move through various components. They are good for highlighting latency issues and potential points of failure.

Tools for Monitoring and Observability

Now that you understand the theory behind monitoring and observability, you may be wondering what platforms and tools are available to developers to collect data and get insights about their services.

In the world of cloud-native infrastructure and Kubernetes, many users gravitate towards the popular stack of Prometheus and Grafana.

Prometheus

Prometheus is an open-source tool that specializes in collecting metrics as time-series data. The information is stored with the timestamp when it was recorded.
The Prometheus ecosystem includes the main Prometheus server, which scrapes and stores time-series data, an alert manager for managing alerts, a push gateway for handling metrics from short-lived jobs, and exporters for collecting metrics from various services connected to the cluster.

It fits both in machine-centric and application-centric monitoring, especially for microservices in a Kubernetes cluster. It’s designed to be the system you go to if there is a system outage and you need to quickly diagnose problems.

The Prometheus ecosystem includes the main Prometheus server, which scrapes and stores time-series data, an alert manager for managing alerts, a push gateway for handling metrics from short-lived jobs, and exporters for collecting metrics from various services connected to the cluster.

Prometheus fits both in machine-centric and application-centric monitoring, especially for microservices in a Kubernetes cluster. It’s designed to be the system you go to if there is a system outage and you need to quickly diagnose problems.

Grafana

Grafana is a visualization tool that transforms, queries, visualizes, and sets alerts on raw metrics stored in Prometheus. With Grafana, you can explore metrics and logs wherever they are stored and display the data on live dashboards. This allows teams to monitor system performance, identify trends, and act quickly on anomalies.

Prometheus and Grafana are compatible with containerized applications, especially in Kubernetes environments. It can also manage workloads outside Kubernetes for flexibility. They are both open-source tools that give developers control over the implementation. There is no licensing cost, which helps teams that cannot afford expensive, powerful solutions.

By combining Prometheus and Grafana, your team gets helpful insights into the system to optimize performance, track errors, and aid troubleshooting processes.

How to Deploy Prometheus and Grafana on AWS EKS using Helm

Prerequisites

For this project, we will use an EC2 instance with the Ubuntu 22.04 operating system. If you are using Windows or a Mac, log into AWS to create your virtual machine.

Here’s what else you’ll need:

1. AWS account setup with access keys and secret keys

• AWS Sign Up

• AWS Access ID and Secret Keys

2. Knowledge of Kubernetes

• Kubernetes Official Documentation

3. AWS CLI installation for the virtual server

• AWS CLI Installation Guide

Getting Started

Let’s start by setting up an EKS cluster on a virtual server and installing the required tools on the server. Then, we’ll deploy our monitoring tools, Prometheus and Grafana, using Helm charts. In the end, we’ll deploy an NGINX web application on Kubernetes and use Grafana to visualize the pod performance and cluster resource usage on the cluster.

Step 1: Install AWS CLI, eksctl, kubectl, and Helm

AWS CLI is a tool that allows users to interact with AWS services using the command-line interface. It makes the management of cloud resources simpler and enables admins to configure AWS services.

Here, we will install AWS CLI on our server to be able to create Kubernetes resources.

On your server, run the following commands:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

sudo apt install unzip

unzip awscliv2.zip

sudo ./aws/install

Verify the installation by running this:

aws --version

After installation, configure the AWS CLI with your credentials using the following command:

aws configure

You will be prompted to enter your AWS Access Key ID, Secret Access Key, Default region name, and default output format.

Next, we need to install eksctl. eksctl is a command-line tool that simplifies the creation and management of Kubernetes clusters on AWS. It helps you configure, set, and maintain clusters and allows you to manage clusters more effectively.

This tool removes the complexities of setting up a production-grade cluster, helping you and your admins focus only on application development and deployment.

To set up eksctl on your machine, download the latest release using the following command:

# for ARM systems, set ARCH to: arm64, armv6 or armv7
ARCH=amd64

PLATFORM=$(uname -s)_$ARCH

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

# (Optional) Verify checksum

curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check

tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz

sudo mv /tmp/eksctl /usr/local/bin

Run eksctl version to confirm its successful installation and the version downloaded.

eksctl version # 0.198.0

Next, we’ll run Kubectl which is a command line interface for managing and interacting with Kubernetes clusters. It enables users to deploy and manage applications within a Kubernetes environment.

With Kubectl, you can perform various crucial operations such as scaling, deployments, inspecting cluster status, and managing networking.

To install kubectl, run the following commands:

curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin

Run kubectl on your command line to confirm it has been installed successfully:

kubectl version 
# client version: 0.198.0
# Kustomize Versionv: 5.4.2
# Server Version: v1.30.7-eks-56e63d8

Finally, we’ll install Helm which is a Kubernetes Package manager that simplifies the deployments and management of applications in Kubernetes. It uses charts to define Kubernetes resources into a collection of files, handles templating and versioning, and makes application deployment easier.

Here, we will install the Helm package manager on our virtual machine for our cluster deployments. This downloads the installation script and saves it in the get_helm.sh file.

Next, the file is set to executable, which allows only the user to run it. Finally, the script is executed using the ./get_helm.sh command.

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

chmod 700 get_helm.sh

./get_helm.sh

Step 2: Create a Kubernetes Cluster

Next, we need to create our Kubernetes cluster in AWS with the eksctl command line. We can do this with the following command:

eksctl create cluster --name my-prac-cluster-1 --version 1.30 --region us-east-1 --nodegroup-name worker-nodes --node-type t2.medium --nodes 2 --nodes-min 2 --nodes-max 3

Let’s break down the command:

• –name my-prac-cluster-1: This specifies the name of the EKS cluster that will be created. In this case, the cluster will be named my-prac-cluster-1.

• –version 1.30: This sets the Kubernetes version for the cluster. Here, the version will be version 1.30.

• --region us-east-1: This specifies the AWS region where the cluster will be provisioned on AWS. Here, it is set to us-east-1.

• --nodegroup-name worker-nodes: This defines the name of the node groups that will be created. In this case, it’s named worker-nodes.

• --node-type t2.large: This sets the instance type for the worker nodes in the node-group.

• --nodes 2: This sets the desired number of worker nodes in the node group.

• --nodes-min 2: This sets the minimum number of worker nodes that should be maintained in the node group to 2.

• --nodes-max 3: This defines the maximum number of worker nodes allowed in the node group and sets it to 3.

Once the cluster comes up, run the command kubectl get nodes to ensure that the cluster is set up properly.

Step 3: Install the Metrics Server

The metrics server is a component that collects resource data from the Kubelets on each node in the cluster. This includes metrics such as CPU, memory, and network usage, which Prometheus can access. The server provides a single source of truth for resource data and is easy to deploy and use.

Run the following script to install the metrics server:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

To verify the installation, run the following command:

kubectl get deployment metrics-server -n kube-system

Step 4: Install the IAM OIDC Identity Provider and Amazon EBS CSI Driver

The IAM OpenID connect provider allows Kubernetes access to AWS resources within the cluster. Here, we need EBS volumes to create persistent storage for Prometheus pods.

Run the following commands to create the IAM OIDC provider:

eksctl utils associate-iam-oidc-provider --cluster my-prac-cluster-1 --approve

Next, we will create the Amazon EBS CSI Driver that will provide permissions for the cluster to access the EBS volumes. Replace the placeholder “my-cluster” with your cluster name.

eksctl create iamserviceaccount \

--name ebs-csi-controller-sa \

--namespace kube-system \

--cluster my-prac-cluster-1 \

--role-name AmazonEKS_EBS_CSI_DriverRole \

--role-only \

--attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \

--approve

Now, we need to add the AWS EBS Driver Addon to the cluster using the following commands:

eksctl create addon --name aws-ebs-csi-driver --cluster <cluster_name> --service-account-role-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/AmazonEKS_EBS_CSI_DriverRole --force

Adding the AWS EBS CSI Driver to your Kubernetes cluster enables the cluster to dynamically create and manage EBS volumes for persistent storage within the cluster. Since our Prometheus installation needs persistent volumes, this add-on will enable the cluster to create EBS volumes to persist data.

Now, our future Prometheus installation will create EBS volumes for persistent storage.

Step 5: Install Prometheus and Grafana.

To install Prometheus and Grafana, we need to add the Helm Stable Charts for the local client.

Run the command below:

helm repo add stable https://charts.helm.sh/stable

Next, we will add the Prometheus Helm repo:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

We’ll use the Prometheus community version because it is well-maintained by the Prometheus community. It offers faster updates and continuous improvements for different Kubernetes environments.

Next, create the Prometheus namespace:

kubectl create namespace prometheus

Install Prometheus and Grafana through the kube-prometheus-stack Helm Chart:

helm install stable prometheus-community/kube-prometheus-stack -n prometheus

When that’s done, verify that the Prometheus deployment and service are installed by using the command below:

kubectl get all -n prometheus

At this stage, you should change the service type from a ClusterIP to a LoadBalancer in the manifest file. We can update the file by running the command below:

kubectl edit svc stable-kube-prometheus-sta-prometheus -n prometheus

After the update, a LoadBalancer URL will be generated for you to access your Prometheus Dashboard.

Next, we’ll move over to Grafana. Change the SVC file of Grafana to create a LoadBalancer and expose it to the public using the command below:

kubectl edit svc stable-grafana -n prometheus

Next, we will update the Grafana SVC file by changing the service type from ClusterIP to LoadBalancer to expose it to the public using the command below:

kubectl edit svc stable-grafana -n prometheus

Once the settings are saved, you can use the LoadBalancer link to access your Grafana Dashboard from the browser. The username is admin. To get the login password printed in the terminal, run the following command:

kubectl get secret --namespace prometheus stable-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

After successfully logging into the Grafana dashboard, the first step is to create a datasource that will provide the metrics for the Grafana visualization.

Go to Add your first data source and choose Prometheus as the Data Source.

Insert the Prometheus URL, and click on “Save and Test”. It should show success if Grafana queries the Prometheus URL successfully.

The next step is to create a Dashboard that our Grafana visualization will use to view the metrics of our pods. To do so, click on “Dashboards” and then on “Add Visualization.”

You’d be taken to an environment where you’d be required to import a dashboard. Select the data source as “Prometheus-1” and use the code “15760” to import the Node Exporter dashboard to view our pods.

Click on Load after importing the dashboard, and you will see your newly created dashboard.

Here, we can see the entire data of the cluster, the CPU and RAM use, and data regarding pods in a specified namespace.

Step 6: Deploying an Application on Kubernetes to Monitor on Grafana.

Finally, we will deploy an NGINX container in our EKS Cluster to monitor using Grafana. We need to create a Yaml deployment and service file.

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-app

spec:

replicas: 2

selector:

matchLabels:

app: nginx-app

template:

metadata:

labels:

app: nginx-app

spec:

containers:

- name: nginx-app

image: nginx:latest

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

name: nginx-app

spec:

type: LoadBalancer

ports:

- port: 80

targetPort: 80

selector:

app: nginx-app

To deploy the Node.js application on the Kubernetes cluster, use the following kubectl command. Verify the deployment by running the following kubectl command:

kubectl apply -f deployment.yml

kubectl get deployment

kubectl get pods

Click the load balancer URL to see your application on your browser:

Let’s refresh our Grafana dashboard to see our NGINX web application in Grafana.

Step 7: Deleting the Cluster

Now that everything is set up, we can delete our Kubernetes Cluster to avoid extra costs. Run the following commands to do so:

eksctl delete cluster my-prac-cluster-1 –region us-east-1

Conclusion

This article teaches the theory behind monitoring and observability and highlights the roles of Prometheus and Grafana in these processes.

We went through a hands-on deployment of Prometheus and Grafana on an EKS cluster and a web application to illustrate how they can be effectively monitored using Grafana.

By leveraging these tools, administrators can enjoy real-time visibility into their Kubernetes infrastructure, easily spot performance bottlenecks, and confidently make decisions that enhance application performance and reliability.

You may want to move your Fly application to a new region if you experience performance issues, high latency, or data residency compliance problems. Placing your application closer to your users can reduce latency and improve response time.

Additionally, aligning your data storage with regional compliance requirements can prevent legal issues. Overall, these changes enhance the user experience with your application.

This article will cover how to smoothly move a Fly application that includes a single Fly Machine and an attached Fly Volume, from one Fly region to another using flyctl commands.

Prerequisites

• Fly.io account
• flyctl installed
• Command line Interface (CLI)

Getting Started

To get started, you will have to verify if you already have flyctl installed and also get it authenticated.

How to Verify flyctl Installation

You can verify that you have flyctl installed using the command below. If not, use this guide to install it.

fly version

Output of fly version

This shows the version you have installed.

How to Authenticate flyctl

Connect the terminal to your account via the CLI using:

fly auth login

When the browser opens up, login if you aren't already logged in and proceed to authenticate your CLI.

After authenticating your account, return to the CLI.

How to Confirm the Region of the Application

Navigate to the root folder of your project and run the following to determine the current region of your application:

fly status

Output of fly status

The application's current region is lhr, the command shows additional information about the application, including the app name, owner, hostname, image, and machine details.

How to Verify the Number of Volumes Available

Run the following command to list all volumes:

fly volumes list

Output of fly volumes list

There should be only one volume that exists and it should be already attached to a machine. You can use this guide to create an application with a single machine with an attached volume.

How to Verify that the Volume is Attached to a Machine

To ensure the volume is attached to a machine, run:

fly machine list

Output of fly machine list

From the output, you can determine if there is a volume attached to the machine.

List of Fly Regions

To determine the new region you want to move the Machine and volume to, use the following command to view the list of available regions:

fly platform regions

Output of fly platform regions

For this article, the machine and volume will be moved to the syd region.

Fork the Available Volume to a New Region

You can create a copy of an existing volume and place it into a new region by forking it using the current volume ID to create a fork:

fly volumes fork vol_4yj0k93z118j9x14 --region syd

Result:

Output of fly volumes fork

This shows information about the newly created volume.

fly volumes list

Output of fly volumes list

The current state of the new forked volume in a new region will be in a hydrating state for a couple of minutes before it is changed to created.

fly volumes list

Output of fly volumes list

The image above shows current state after hydrating is complete.

You have successfully created a new volume in another region containing data from the volume existing in the old region.

How to Clone the Existing Machine

Fly possesses the clone feature to replicate a machine and you can make use of this by getting the ID of the existing machine.

fly machine list

Output of fly machine list

After retrieving the ID of the machine, use the command below to clone the machine and attach the new volume using the same region as the newly created volume:

For example:

fly machine clone <machine id> --region <region code> --attach-volume <volume id>:<destination_mount_path>

It's important to note that the destination_mount_path has to be a different path other than / which is the root directory of the application. It should be a unique path /zata.

fly machine clone 5683977a624218 --region syd --attach-volume vol_vzkd2l6yxnk72p9v:/zata

Output of fly machine clone

You have successfully created a clone of the existing machine and attached the forked volume.

How to Verify the Volume Attachment

To check if the volume has been successfully attached:

fly volumes list

Output of fly volumes list

The volume is now attached to a machine.

To check if the machine has been successfully attached:

fly machine list

Output of fly machine list

The machine now has a volume attached.

You have successfully moved the machine and volume to a new region.

How to View the Application Available Regions

Currently, the application exists in two different regions and you can view this using the following command:

fly scale show

Output of fly scale show

The application is now running in lhr and syd.

How to Update the Remote fly.toml

Add the new region to the fly.toml file primary_region = 'syd', update the volume destination to destination = '/zata', and deploy the changes.

fly deploy

Output of fly deploy

Once this is successful, the changes to the fly.toml file will be on the remote configuration.

How to Destroy the Old Machine

You have successfully moved your machine and attached volume to a new region and since we no longer need the machine in the old region lhr, you will have to clean it up. The first approach is to stop the machine using the ID.

Stop the Old Machine

fly machine stop <old_machine_id>

Output of fly machine stop

To confirm if it was successful, use:

fly machine list

Output of fly machine list

The state of the machine has been updated to stopped

Destroy the Old Machine

fly machine destroy <old_machine_id>

Output of fly machine destroy

Run the below command to verify if the machine still exists.

fly machine list

Output of fly machine list

The machine in the old region has been successfully deleted.

How to Destroy the Unattached Volume

After successfully destroying the Machine, the volume attached to it is now unattached and can also be destroyed.

fly volumes list

Output of fly volumes list

Use the ID of the unattached volume and run the below command:

fly volumes destroy <old_volume_id>

Output of fly volumes destroy

The unattached volume has now been destroyed.

Output of fly volumes list

Only one volume exists and is attached to a machine in the new region.

How to Check the State of the Instance

Check the logs to see the state of the instance:

fly logs

The logs show the application is running without any issues.

Conclusion

Moving a Fly.io application to a new region involves forking the existing volume, cloning the existing machine with the forked volume to a new region, updating fly.toml, deploying the changes, and removing the old machine and volume.

Following these guidelines ensures a smooth and successful transition with minimal disruption.

If you have any questions you can always find me on X (formerly Twitter)

Resources:

• Fly Docs
• Flyctl
• Fly Machines
• Fly Volumes
• Fly regions

So far, web development has become much more advanced, and data migration and backup is an essential skill every web developer should have to help ensure continuity of data and preserve user information regardless of any circumstances.

For developers like me who prefer to test all their code features locally in a development environment before final deployment to the cloud, this tutorial would come in handy for you when faced with the challenge of migrating your locally stored MongoDB data to a cloud platform or any other platform.

The inspiration for this article is a result of the need for me to migrate the total JSON data on my local MongoDB Compass server to the cloud (MongoDB Atlas) for an ongoing project. I waded through the endless internet resources and documentation but couldn’t get a suitable, straightforward fix. With multiple trials and errors, I was able to succeed with the migration. This article should serve as the definitive guide you need to save you time and achieve fast results.

In this article, we'll delve into data management in MongoDB, data backup, and efficient data migration tools that ease up the entire process. This article is suited for people with intermediate to advanced knowledge of MongoDB and backend development.

If you have any difficulty with the terminologies used in this article, I would suggest studying the MongoDB documentation here.

Let’s begin.

Introduction to MongoDB

MongoDB is a non-relational NoSQL-based database that stores data via the document model in a JSON format. It’s quite popular, and ranks top among the most used databases worldwide.

It's also more code-friendly as it's currently the default database used by many JavaScript-based full stack and backend developers.

It has various database options, comprising both local database servers and a cloud-based Database-As-A-Platform.

A good example of this is the MongoDB Atlas. MongoDB Atlas is a flexible and scalable MongoDB implementation with strong cloud security.

It provides indexing, load balancing, and sharding, among other features. More information regarding it can be found here.

How to Initialize the MongoDB Server

You should have the MongoDB local server already installed. However, if you haven’t installed it, it can be downloaded here.

The MongoDB server can then be easily executable by adding its path to the environmental variables on Windows.

To initialize the MongoDB application, activate the command prompt and type in
Mongod

MongoDb server running

To explore the databases on the MongoDB server, open the MongoDB command shell and type show dbs

The databses on the MongoDB server

This displays all the databases on the MongoDB server.

With this, let's go on to migrate one of these databases to the cloud.

How to Back Up Data

To efficiently upload the database collections to the cloud, they must first be backed up.

To back up your database, you'll have to install an additional tool. Navigate back to the MongoDB downloads site and download the MongoDB database administration tools.

This package contains a lot of database tools, such as MongoExport, MongoImport, MongoDump, and MongoRestore.

The above settings are applicable for users who have a version of MongoDB above version 4.4. MongoDB decided to release it as a stand-alone tool. For users whose version is less than version 4.4, these tools can be pre-installed in the MongoDB package.

Now, let's go on to the two major tools that would help facilitate the migration process: MongoDump and MongoRestore.

When MongoDump is executed on a database, it helps to create a backup database file in a binary-encoded JSON format (BSON). While the MongoRestore helps to return the backed-up database to MongoDB for usage.

Moving on, ensure that their package path is included in the environmental variables so as to guarantee efficient execution.

In order to back up a local database, open the MongoDB shell and then enter this command:

Mongodump --db={TheNameOFYourDB} --collection={TheNameOfYourCollection} –out={The name of the folder the backed up JSON files would be located}

With this execution, you have successfully backed up your local MongoDB database.

How to Set Up a MongoDB Atlas

MongoDB Atlas is MongoDB cloud Database-As-A-Service cloud option accessible to its users at all times with little to no disruption.

Also, for most production apps that utilize the power of MongoDB on the server as a database tool, the easiest and most convenient provider of this solution is the MongoDB Atlas.

Hence, it is our choice to back up our MongoDB data to the cloud. I would assume you already have a MongoDB Atlas account, but you can still create one and then create a database that would serve as the recipient of the local database.

To set the account up, kindly navigate to the Atlas home page here. Create an account and you'll be directed to a dashboard where you can create new databases.

MongoDb Atlas home page

You can, however, name it with any name you want. To complete the upload of the local MongoDB data to the cloud, navigate to the settings tab on the MongoDB Atlas database and click on the migrate data option. With this successfully done, let's now go on to complete the migration process.

How to Migrate Your Data to the Cloud

To migrate your backed-up database to the cloud, MongoImport and MongoExport will be invoked.

In the command prompt, paste the migration code copied from the Atlas, and then execute it on the command prompt. With that, you should see a success text.

You can then check and refresh your cloud database to see the new files that have been uploaded there. Thereafter, you can connect the new cloud database to your backend application and run it successfully to get the same results on your local computer.

Conclusion

With this, we have come to the end of the tutorial. We hope you’ve learned about data management and migration in MongoDB, tools involved and all its intricacies.

Feel free to drop comments and questions, and also check out my other articles here. Till next time, keep on coding!

AWS is currently the most popular cloud service provider, as it owns around 33% of the cloud market.

Companies and organizations are looking for candidates with AWS skills. A way to showcase your AWS knowledge is by obtaining an AWS certification.

In this article, I will list the current AWS certifications and go into more detail about the Cloud Practitioner certification.

Let's get into it!

What Is AWS? Amazon Web Services Explained

Amazon Web Services (or AWS for short) is a cloud computing platform offered by Amazon.

The platform provides on-demand cloud computing services such as hosting for servers, storage, database management, networking, and security, to name just a few of them.

Many businesses use AWS, including big companies such as Airbnb, Netflix, LinkedIn, and Twitter. With that said, it is also used for personal projects.

What Is an AWS Certification?

An AWS certification is a credible way to demonstrate to an employer that you have the specific technical skills and competence to design, build, deploy, migrate, operate, and maintain well-architected AWS systems.

Obtaining an AWS certification and gaining cloud architecture expertise is a great way to kickstart a new career in tech and open doors in a fast-growing industry.

An Overview of the Different AWS Certification Types – Levels of AWS Certifications

Currently, there are four types of AWS certifications.

There is one foundational level certification – the Cloud Practitioner certification.

There are three associate level certifications – the Solutions Architect, the Developer and the SysOps Administrator certifications.

There are also two professional level certifications – the Solutions Architect and DevOps Engineer certifications.

And lastly, there are six specialty level certifications – the Advanced Networking, Data Analytics, Database, Machine Learning, Security and SAP on AWS certifications.

Choosing an AWS certification will depend on your experience level, professional goals, and interests.

Now, let's go into more detail on the fundamental AWS certification – the Cloud Practitioner certification.

What Does an AWS Cloud Practitioner Do?

An AWS cloud practitioner is responsible for the organization's cloud computing architecture. They resolve scalability challenges and handle high-risk issues.

The practitioner understands AWS's core design principles and best practices for architecture.

They know how to design, build, deploy, and monitor applications on the cloud within AWS platforms.

They gather insights into end-users' problems and pain points, leverage software and hardware systems to address those problems, and come up with solutions.

What Is the Average Salary for an AWS Cloud Practitioner?

According to data from Glassdoor, the estimated total pay for a cloud practitioner in the USA for 2023 is around $91,038 per year, with an average salary of $83,679 per year.

With that said, compensation is relative and will depend on your field and chosen industry, demand, previous experience, skills, and location. The average salary for a cloud practitioner may be higher in different regions in the USA and lower in other countries.

AWS Cloud Practitioner Certification Prerequisites

The AWS Cloud Practitioner certification is a great place to start your cloud computing learning journey and a new career in the cloud.

It is an entry-level certification intended to provide fundamental knowledge and a general overview of AWS and its infrastructure. It doesn't require any previous experience or specific prerequisites.

With that said, having an understanding of the AWS platform and cloud computing terminology and concepts can be helpful during your learning process.

To understand the core concepts of cloud computing and AWS, you can read through the AWS Cloud Essentials Guide by AWS.

AWS Cloud Practitioner Certification Curriculum

The four major topics you will learn while studying for the AWS Cloud Practitioner certification fall into the following categories:

• Cloud concepts (26%), such as learning about cloud computing topics, how cloud-based applications work and scale, the AWS core infrastructure, and its architectural principles.

• Security and compliance (25%), such as learning security and compliance best practices for the AWS platform.

• Technology (33%), such as learning about AWS services and tools and their use cases.

• Billing and pricing (16%), such as learning about AWS billing, pricing models, support, and account management.

To learn more about the curriculum, AWS provides a complete exam guide, which covers the key modules in detail.

AWS Cloud Practitioner Certification Study Materials

You first need to create an AWS account.

AWS provides a free 12-month subscription to become familiar with the AWS console and its services.

When it comes to courses, you can use the AWS cloud essentials learning plan built by AWS, which goes over the recommended curriculum. This course covers AWS cloud, services, pricing, and security.

freeCodeCamp also offers an extensive 13-hour study course.

It's also a good idea to go through some practice questions and practice exams by the official page on Amazon to test whether you are prepared enough for the certification exam.

AWS Cloud Practitioner Certification Exam Details

Once you've created your AWS certification account, to schedule the AWS Cloud Practitioner exam, sign in to aws.training and click "Certification", where you can register and schedule the exam online or at a location near you.

The exam level is foundational, and the exam code is CLF-C01.

The exam costs $100 and is available in English, French, German, Indonesian, Italian, Japanese, Korean, Portuguese, Simplified Chinese, Spanish, and Traditional Chinese.

The exam is 90 minutes long and consists of 65 multiple-choice, multiple-response questions. The minimum passing score is 700 points.

Lastly, the AWS certifications are valid for three years, and you will need to renew them once they expire.

Conclusion

Hopefully, you found this article helpful and have a better understanding of what the AWS Cloud Practitioner certification entails.

Thank you for reading, and best of luck on your exam.