Forem: asim-makes

Decoupling at Scale: My Deep Dive into AWS Event-Driven Architecture (API Gateway, EventBridge, SQS)

asim-makes — Wed, 22 Oct 2025 17:04:56 +0000

Hey everyone!!!

Tihar is here in Nepal 🎉. With the holiday break on, I decided to wrap up another portfolio project: designing and deploying a complete, event-driven e-commerce order processing system on AWS.

I’ve previously built a few monolithic REST APIs, but this time I wanted to challenge myself and understand how microservices differ from monolithic systems in practice. So I chose a microservices architecture centered around an Event Bus (Amazon EventBridge).

While the project follows a microservices pattern, my main goal wasn’t to build a fancy UI or user-facing backend — instead, I focused on AWS architecture, infrastructure, and operational maturity.

To push myself deeper into the IaC world, I decided to deploy everything using raw CloudFormation YAML — no SAM, no CDK, no Terraform.

Contrary to popular opinion, I actually found CloudFormation to be a super fun tool once you get used to its structure and declarative nature.

🧱 Tech Stack Overview

Category	AWS Service(s)	Notes
IaC	CloudFormation (raw YAML)	Full IaC deployment — no SAM/CDK/Terraform
Compute	AWS Lambda (x5 microservices)	Each service is independent
Data Storage	DynamoDB (x4 tables)	One per service for isolation
Integration & Routing	API Gateway, EventBridge	Event-driven communication
Buffering & Resilience	SQS (x4 + DLQs)	Protects against message loss/failure
Notifications	SNS (x1)	Sends real-time alerts to users
Observability	CloudWatch	Logs, metrics, alarms for all services

🏗️ Architecture Diagram

High-level architecture showing all AWS services and their interactions

API Gateway receives the customer's order and passes it to the Order Service Lambda.
The Order Service simply logs the initial order and publishes an event to EventBridge.
EventBridge immediately routes this event to the Inventory Service:
- i. If in stock, Inventory Service publishes its own event.
- ii. If out of stock, it notifies the user via SNS.
The Payment Service listens for events sent by Inventory Service:
- i. A successful payment results in a "Payment Successful" event, triggering the Shipping flow.
- ii. A failed payment triggers a compensation action (like restocking the item and notifying the user via SNS).
Finally, the Shipping Service processes the paid order using SQS and DLQ for reliability.

⚙️ Building the microservice stack

All microservice stacks forming the complete event-driven e-commerce system

a) Base Infra Stack

The three core pieces defined in this stack are a Customer Managed Key for encryption (CMK), a central Event Bus, and an Operations Alerting Topic.

I defined a Customer Managed Key (CMK) using AWS::KMS::Key. I decided to go with the CMK instead of the default AWS keys because I wanted to see practice with KMS practically. I have read about CMK during my SAA-C03 preparation but the concept never sticked to my head and so I made many mistakes answering the practice questions on encryption. But once I implemented it in this project, the whole concept really sticked to my head. Owning the CMK gives me complete control over its usage and policy. During the key creation, I also need to create a policy for the key; I defined to allow the root user full control, grant general usage (encrypt, decrypt, etc.) to all principals within the account, and explicitly authorize specific AWS services (SNS, SQS, DynamoDB, EventBridge, and CloudWatch) to use the key for their encryption. To maintain best practices, I've also enabled automatic key rotation.

Next, I established the communication backbone for the microservices architecture with an AWS::Events::EventBus named EcomEventBus. In an event-driven world, this bus acts like the main switchboard. Services won't communicate directly; instead, they'll simply publish events in the event bus and other services can define rules to subscribe only to the events relevant to them. This service allowed me to decouple the e-commerce services, so that they can evolve independently without breaking each other.

Finally, for the alerting mechanism, I created The OpsAlertTopic, which is an SNS topic. I integrated the custom KMS key here, ensuring every message published to this topic is encrypted, maintaining encryption at rest for sensitive operations data. To make these resources accessible to all other stacks, I used the Outputs section to export the ARN values of the KMS key, the Event Bus, and the Ops Topic. This completed the foundation of my project.

Custom KMS key configured for encryption with automatic rotation

Custom EventBridge bus (EcomEventBus) for event routing

OpsAlert SNS topic with KMS encryption for secure notifications

b) Order Stack

This stack defines the complete Orders Service of my e-commerce platform. The stack is a self-contained microservice and is exposed to both internal events and external HTTP requests.

The service's data layer is the OrdersTable (DynamoDB), keyed by orderId. PITR and CMK-based SSE are enabled via !ImportValue MyKmsKeyArn.

The primary part of the service is the OrderLambda function (Python), handling two different input types:

HTTP Request Handling

Handles POST requests from API Gateway, validates input, stores order in DynamoDB, and publishes OrderPlaced event to EventBridge.
EventBridge Event Handling

Updates order status based on events: StockConfirmation, PaymentConfirmation, and ShipmentCreated events.
Access Control and API Exposure

IAM Role grants minimal privileges. Exposed via API Gateway POST /orders.
EventBridge Rules

Rules trigger Lambda for failure events and shipments using content filtering.

Order microservice architecture — Lambda, DynamoDB, and API Gateway setup

EventBridge rules linking Order service with other microservices

OrdersTable in DynamoDB showing stored order data

c) Inventory Stack

The Inventory Service ensures stock checks and rollback via asynchronous messaging. It includes InventoryTable, SQS queues, and a Lambda for stock management and compensation.

Messages are first routed to InventoryQueue (SQS) for buffering. The Lambda then processes messages to decrement or increment stock quantities. Conditional updates prevent negative inventory.

On stock failure, a StockConfirmation event is published back to EventBridge; on payment failure, rollback happens via InventoryCompensationQueue.

InventoryTable storing product stock and metadata

Primary InventoryQueue used for processing OrderPlaced events

InventoryCompensationQueue used for handling rollback after payment failures

EventBridge rule routing stock confirmation events to the Inventory Service

Rule forwarding StockConfirmation events to SNS for customer notifications

InventoryLambda implementation handling stock decrement and compensation logic

d) Payment Stack

The Payment Service manages mock payment transactions and communicates success or failure. It uses PaymentTable (DynamoDB) with PITR and KMS encryption.

It starts only after stockConfirmed: true and processes messages from PaymentQueue (SQS). The Lambda simulates payment outcomes and publishes PaymentConfirmation events.

A CloudWatch Alarm monitors the Lambda for errors and sends notifications via OpsNotificationTopic.

Failures are routed to PaymentFailureTopic (SNS), which notifies customers with personalized messages.

PaymentTable holding transaction status and metadata

EventBridge rule triggering payment service upon stock confirmation

SNS topic used for customer notifications on payment failure

Sample payment failure email notification sent via SNS

CloudWatch alarm monitoring PaymentLambda errors and notifying via SNS

e) Shipping Stack

The Shipping Service finalizes order fulfillment. It uses ShippingTable (DynamoDB), SQS queues, DLQ, and Lambdas for shipping and reprocessing.

The PaymentConfirmedToShippingRule routes successful payment events to ShippingQueue.

ShippingLambda simulates an external API call — on success, it stores shipment data and publishes a ShipmentCreated event. On failure, SQS retries and finally moves messages to ShippingDLQ.

A CloudWatch Alarm watches the DLQ and notifies the Ops topic if any failed shipments exist.

A second Lambda (DLQProcessorLambda) polls the DLQ, reprocesses stuck shipments, and publishes a ShipmentCreatedByDLQ event — ensuring reliability.

ShippingQueue buffering messages for the shipping service

ShippingDLQ for handling failed shipment messages

CloudWatch alarm monitoring DLQ message count

Example alert email for a shipping DLQ trigger

Conclusion

This project literally really stands as a significant milestone for me in my cloud journey.The most memorable takeaway from this deep dive wasn't just the final architecture, but the process of building it. Contrary to the popular notion that YAML-based Infrastructure as Code (IaC) is tedious or overly complex, I found the experience of writing CloudFormation templates in YAML to be surprisingly enjoyable and engaging.

My previous infrastructure work with AWS CDK felt abstracted and high-level. Working directly with CloudFormation felt like building with fundamental, plain English blocks. I had no choice but rely on AWS documentation, which allowed me to understand different properties of resources. Explicitly defining resource relationships gave me a visual, low-level appreciation for how these services connect. This project highlights my commitment to understanding the how and why behind every cloud resource.

Now that I am done with two IaC tools offered by AWS, I will look forward to work with ECS and Docker.

Credits:

Photo by Avi Waxman on Unsplash

Building Production-Grade Multi-Tier Web Infrastructure on AWS with CDK & CLI Only

asim-makes — Mon, 13 Oct 2025 09:22:39 +0000

This post details my journey of designing and deploying a secure, highly available, and scalable **3-Tier Web Application Infrastructure **entirely on AWS using the Cloud Development Kit (CDK) and the AWS CLI. I used a code-only approach to ensure repeatability and automate all operational tasks.

Architecture Diagram

3 Tier Architecture Diagram

VPC Architecture Diagram

Prerequisites: Security and Control

Before writing a single line of infrastructure code, I focused on securing the deployment environment and controlling costs.

💰 Cost Control: Billing Alarms as Guardrails

As someone who have just over a month experience in AWS, overspending is a common fear. I implemented two essential CloudWatch Billing Alarms to monitor estimated AWS charges:

- Safety Net Buffer ($5): A high-level alert created easily via the AWS Console for moderate costs.

- Tighter Threshold ($1): A critical, early-warning alert deployed using the AWS CLI.

This dual approach provides both an easy to use alarm with scripts for automation offering an immediate warning for any unexpected spending spikes.

👤 Principle of Least Privilege: Dedicated IAM User

To ensure secure, auditable deployments, I created a dedicated IAM User with the minimum permissions required.

- Custom IAM Policy: Based on a mental model of required resources (VPC, EC2, RDS, etc.), I defined a custom 3-tier-deployment-policy.

- CLI Access: Generated Access Keys using aws iam create-access-key and securely stored them in a local CLI profile instead of exposing them in scripts.

While running the script, I encountered a frustrating error when attaching the policy to the user: An error occurred (ValidationError) when calling the AttachUserPolicy operation: Invalid ARN: Could not be parsed!.

The root cause was a shell scripting issue: when capturing the policy ARN using command substitution ($()), the tee command in my logging function was writing log messages to Standard Output (stdout), which were then accidentally perfixed to the ARN.

To fix this, I modified the logging function to redirect the tee command's output to Standard Error (stderr) (>&2). This ensured only the valid ARN was captured on stdout for the AWS CLI command.

Infra-as-Code: Writing the Entire Stack in AWS CDK

The AWS Cloud Development Kit (CDK) allowed me to define the entire cloud infrastructure using Python.

Before deploying, I executed the one-time setup command:
cdk bootstrap aws://<account-id>/<region>

This command creates the CDKToolkit CloudFormation Stack, which provisions essential resources (like an S3 bucket and IAM roles) necessary for the CDK CLI to deploy assets and templates. This process is essentially known as bootstrapping.

Modular Design: Constructs, Stacks, and App

I structured the project for clarity and reusability:

Component	Role
Constructs	The basic building blocks; defines how an individual resource or group of resources is created. Example: `VpcConstruct` (defines subnets, NATs, etc.)
Stacks	High-level groupings; instantiates Constructs with environment-specific configurations and parameters. Example: VpcConstruct with specific CIDRs)
App	The entry point; connects all stacks, defines their deployment order, and specifies the target AWS account/region. Example: `cdk deploy` executes the App

The 3-Tier Architecture Breakdown

The infrastructure is divided into three distinct tiers, each with a defined role and strict security groups.

Network Tier: The Private Cloud (VPC)

The is the foundational tier and is a single VPC spanning two Availability Zones (AZs) for high availability and fault tolerance.

Subnet Type	Role	Purpose/Hosts
Public Subnets (3)	For internet-facing resources that require an Internet Gateway (IGW).	Hosts the Application Load Balancer (ALB) and NAT Gateway(s).
Private Subnets (3)	For backend application resources that are isolated from the internet.	Hosts the EC2 Auto Scaling Group (ASG) and RDS database.

One thing that I loved about CDK is the way it abstracts away manual networking setup: It automatically Defining the VPC subnet with proper routes so that I dont have to manually update route table unless I have a specific rqeuirement to do so. And by specifying nat_gateways=1, it automatically provisions a NAT Gateway in a public subnet and updates the private subnet route tables to direct all outbound traffic through it.

Network Stack CloudForamtion Dashboard

Web Tier: The Public Entry Point

The Application Load Balancer (ALB) serves as the internet-facing entry point and is designed as such:

- Security Group: Only permits inbound traffic on HTTP (port 80).

- Target Group: Directs traffic to the application instances on port 8080.

- Health Check: Configured to check the root path (/) to ensure only healthy instances receive traffic.

Web Stack CloudForamtion Dashboard

App Tier: The Application Logic

The application runs on Amazon Linux 2 EC2 instances managed by an Auto Scaling Group (ASG), deployed entirely within the private subnets (with egress).

- Security: The ASG instances are private with egress. They can only be reached by the ALB's security group on port 8080.

- Outbound Egress: Traffic for updates or external API calls is routed securely through the NAT Gateway.

- Identity & Credentials: An attached IAM role grants permissions for SSM, CloudWatch Logs/Metrics. It has read access to the database credentials stored in Secrets Manager, ensuring no plaintext credentials are ever stored on the instance.

- Observability Config: The CloudWatch Agent configuration is stored in an SSM Parameter Store. The instance user data script fetches the config at startup, making monitoring adjustments easy without ASG redeployment.

App Stack CloudForamtion Dashboard

Database Tier: The Isolated Backend

A PostgreSQL instance on Amazon RDS is deployed in the PRIVATE ISOLATED subnets.

- Isolation: The database has no internet access, inbound or outbound.

- Strict Access Control: Access is only permitted from the application’s ASG Security Group to the RDS Security Group on TCP port 5432.

- Secret Management: RDS credentials are automatically provisioned and stored in AWS Secrets Manager, and only the App Tier's IAM role is authorized to retrieve them.

Operational Excellence: CLI and Observability

For observability, I built a set of Bash scripts utilizing the AWS CLI.

I created scripts for:

- Instance/Target Health Checks: Quick validation of the environment state.

- Resource Information: Fetching details on RDS and EC2 instances.

- SSH via SSM: Secure, tunnel-less access to private instances.

- Application Log Retrieval: Centralized access to application logs.

Script for getting infra info

Leveraging EC2 Metadata

One thing that I learned when doing this project was for checking the local health and configuration of an instance from within the instance itself, the application uses EC2 Metadata. This data is always available locally via the non-routable IP address: 169.254.169.254.

Complete Observability with CloudWatch

The deployed infrastructure is fully observable using the CloudWatch Agent and Alarms.

- Agent Configuration: The agent collects system metrics (like CPU) and combined application logs (including NGINX logs and a custom log for RDS connectivity checks).

- CloudWatch Alarms:

    1. Performance: Notifies if EC2 CPU utilization exceeds 80%.

    2. Capacity: Warns when RDS storage capacity is nearing its limit.

CloudWatch Alarm Dashboard

This setup ensures that the entire environment, from deployment to scaling and health checks is fully automated, secure, and easily monitored from the terminal.

Conclusion

This project demonstrated the deployment of a multi tier web app on AWS using purely code based approach. This project helped me clear my doubts on availability zones, ASG and target groups. It was also a great learning for making secuirty groups to build a complete, isolated subnets. I had a lot of fun doing this project and especially writing the modular code in Python. Up next, I will explore Terraform, which is a declarative configuration language (HCL) and is differnet from the CDK (general purpose programming model). Onward to the next challenge, the cloud awaits! ☁️

Feel free to check my github repo on this project:
https://github.com/asim-makes/3-tier-infra

Serverless Dashboard Architecture Using AWS Lambda, API Gateway, and GitHub Actions

asim-makes — Wed, 24 Sep 2025 02:16:55 +0000

In my ongoing cloud journey, I decided to build a multi-functional serverless dashboard using AWS. The dashboard includes multiple applications like ExpenseApp, WeatherApp, NewsApp, and GitHubApp. Each of these apps runs serverlessly with AWS Lambda, uses API Gateway for routing, and stores data in DynamoDB. For easier deployment, I’ve implemented CI/CD pipelines using GitHub Actions, automating the entire process from code commit to deployment.

Architecture Diagram

Tech Stack Breakdown

Frontend:

The dashboard's frontend, with its various apps, is built using TypeScript. Since I wanted to focus on the infrastructure, I used AI tools to handle this part for me.

Backend:

AWS Lambda: The logic for each app (Expense, Weather, News, GitHub) runs on AWS Lambda functions, written in Python. I also used AI to generate the code for these functions.
API Gateway: This service acts as the router, directing requests to the correct Lambda function based on the API path, such as /ExpenseApp.
DynamoDB: I used this NoSQL database specifically for the ExpenseApp to store user data. To keep the project simple, I decided not to store API keys for the other apps here.

CI/CD:

GitHub Actions: I automated the deployment of both the frontend and backend using GitHub Actions, ensuring that any changes are automatically pushed to AWS without any manual steps.

IAM Roles & Permissions

I created a dedicated IAM user to manage the various resources required by the dashboard. The user is limited to the resources necessary for each app. This user’s permissions include creating and updating Lambda functions, managing API Gateway configurations, accessing DynamoDB, and interacting with S3 for frontend assets. Using a dedicated IAM user is a good security practice, as it follows the principle of least privilege.

Policy Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:GetRole",
                "iam:AttachRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/LambdaDynamoDBRole",
                "arn:aws:iam::123456789012:role/LambdaDynamoDBCloudWatchRole"
            ]
        },
      ...

Database Design For ExpenseApp

For the ExpenseApp, I used DynamoDB as the database. I designed the table with the following schema:

Table Name: expenses-table
Partition Key: expenseId (Number)
Sort Key: timestamp (Number)
Attributes: description, amount, category, date, and timestamp.

I used DynamoDB On-Demand capacity mode because this model is ideal for staying within the AWS free tier, as I only pay for what I use, and my simple application's low traffic will likely remain far below the free limits.

Setting Up the Lambda Functions & API Gateway Integration

Each app (Expense, Weather, News, GitHub) has its own Lambda function. Here’s an overview of the integration and automation:

Lambda Function Deployment:
- Each app has its own set of Lambda functions deployed automatically using a deployment script.
- The functions are connected to the API Gateway endpoints: /ExpenseApp, /WeatherApp, /NewsApp, and /GitHubApp.
API Gateway Routes:
- I used API Gateway as the main router for my dashboard. I set up a dedicated path for each part of my app. For instance, I created a specific route called /ExpenseApp for the ExpenseApp. On that route, I added a GET method. Then, I linked it directly to my Lambda function. I used something called Lambda Proxy integration, which is a simple way to make sure the API Gateway sends everything from the request straight to my code so it can handle it.
- API Gateway Configuration Error: A challenge I encountered was an integration error between API Gateway and Lambda functions, which was caused by a mismatch in expected resource paths. The Lambda functions expected paths like /ExpenseApp but were defined under the root path /. This was a frustrating issue because I just could not get the API Gateway align with my Lambda no matter how much permissive my permissions were. Once I adjusted the paths to match, everything worked seamlessly.

Handling CORS (Cross-Origin Resource Sharing)

Another frustrating issue that I ran into was getting CORS (Cross-Origin Resource Sharing) to work. My dashboard's frontend had to talk to different backends, and for some reason, the requests kept getting blocked. I thought I'd solved it by just enabling CORS on the main API Gateway (the root resource), but that wasn't enough. It turns out I had to go into every child resource (like /ExpenseApp and /WeatherApp)and enable it there too. And that was just the start of it. I also had to make sure my Lambda functions included the code snippet to return the correct Access-Control headers in their response. The final challenge was using the AWS CLI for this. I couldn't just pass the headers on a single line because the command line kept messing up the quotes. To fix it, I had to create a separate JSON file just for the headers and then reference that file in my CLI command. This was a tedious trial and error process.

CI/CD Pipeline with GitHub Actions

Backend CI/CD:

GitHub Actions automates the deployment of Lambda functions whenever code is pushed to the repository.

Frontend CI/CD:

The frontend is deployed to S3 buckets automatically whenever changes are committed. The GitHub Actions pipeline builds the frontend assets and uploads them to the appropriate S3 bucket for public access.

AWS CLI for Automation

After the completion of my dashboard, I wanted to challenge myself: how do I get all of this stuff onto AWS without touching the AWS console? Manually creating all those Lambda functions, IAM roles, and API Gateway endpoints would be a tedious and hectic process. That's when I used the AWS Command Line Interface (CLI) to automate the entire process.

I wrote a single deploy_infra.sh script to handle everything. The script is smart enough to check if a resource already exists before trying to create it. For each of my apps, the script first creates the necessary IAM roles and gives each app the basic permissions it needs. For the ExpenseApp, it adds extra access to DynamoDB.

Once the roles are set up, the script moves to function deployment. It takes my Python code, bundles it with any required libraries, and then uploads it to create a new Lambda function. It also pulls any private API keys from a separate file so I don't accidentally expose them.

The final, and perhaps most complex, part was automating API Gateway. The script not only creates a new API for each app but also builds out the routes, like /ExpenseApp and /WeatherApp. It connects these routes to their corresponding Lambda functions using the Lambda Proxy integration. And because CORS was such a pain to configure, I built a special function into the script to handle all of those headers and pre-flight OPTIONS requests automatically.

Finally, the script deploys the entire API and gives me the public endpoint for each app, so I can immediately start testing. This entire process, which would have taken me more than 15 minutes of manual clicking and configuring, is now done with a single command. It's a huge win for me and I learned so much when playing with it.

Website Image

Conclusion

This multi-app dashboard project gave me a good learning experience in designing and implementing serverless architectures with AWS. I was able to focus on cloud engineering aspects (like IAM roles, Lambda functions, and API Gateway), while using GitHub Actions to automate deployment processes. This project was a learning exercise and a portfolio piece to showcase my cloud engineering skills. Moving forward, I’m excited to explore Infrastructure-as-Code tools like AWS CDK or Terraform to further streamline the setup and deployment of serverless applications.

My Cloud Resume: Built on Azure

asim-makes — Sat, 06 Sep 2025 07:48:24 +0000

So a few weeks ago, I decided to take on the Cloud Resume Challenge that I saw online. I skimmed over the challenge and thought it would be interesting for beginner like me to try out. And that is way better than just watching or reading tutorials.

Before going on how I completed the challenge, I will quickly summarize what the challenge is all about:
1) Build a resume using HTML, and CSS.
2) Host the static resume in cloud storage.
3) Make a visitor counter to track how many times my resume is visited with JavaScript, Python, and Database.
4) Make a template to automatically deploy the resources (IaC).
5) CI/CD pipelines for both frontend and backend with GitHub Actions.
6) Make a custom DNS and use HTTPS to visit the websiste.

Simple Archcitecture Diagram of the project

Part 1: Creating a static resume

The very first part was challenging for me as I am not someone who is comfortable with frontend. So for that, I learned basic HTML and CSS and then used a tutorial YouTube video with AI tools to build my resume. The resume was good enough for me.

Part 2: Making the resume a static website

After finishing my resume, I created a storage account in Azure. Azure storage serves files, like a CDN and hence it is the best way to host a static website. First, I need to enable static web by going to the Networking. When I do that, a special container called $web is created. By convention, it looks only at $web when it is serving my site.

Part 3: Frontend Visitor Counter

Before making any JS, I first went to the static resume that I have created, made HTML for displaying visitor counter and then linked the class to JS. The job of the JS is simple" It calls an API and display the number it gets back dynamically. Since I am not into frontend, I leveraged AI tools to write the code for me and understood the snippets it gave me.

Part 4: CosmosDB Database

For the database creation, the challenge suggests to use Azure Cosmos DB Table API in serverless mode. Let me briefly explain what it is. The Table API is a schema-less NoSQL option and the simplest out of the many flavors of APIs that are out there (eg: SQL, MongoDB, etc). To add a new data, I just throw in entities (rows) with whatever properties (columns) that I want. Each entity has:
a) PartitionKey: Groups data
b) RowKey: Unique identifier
Serverless means I am only paying for what I consume and am not reserving capacity. If I were using a normal model like provisioned throughput, I am billed for that capacity whether I use it or not. I created a new CosmosDB resource and made a table for visitor counter.

Part 5: Backend Visitor Counter

For security, the browser should not talk to the database directly because any key/connection string shipped to the browser is public and users can read it. Just as the challenge suggests, I built a small API using Azure Functions with an HTTP trigger. When the JS makes a request, the function reads the current visitor count from CosmosDB, increments it, writes it back, and then returns the new counter to the browser.

The part that really had me banging my head was deploying Azure Functions with Python. I was on Linux and started using Python 3.12 as the runtime stack. I wrote the code, debugged it, checked my host file, even hit the forums and leaned on AI tools but no matter what, I just couldn’t get the function to deploy to my Function App.

After some digging, I learned that Python 3.12 support for Azure Functions is still new and has some dependency conflicts. The build would show as successful in VS Code, but the function itself just wouldn’t show up after deployment. Switching back to Python 3.11 solved the issue immediately.

I finally had an HTTP trigger up and running that connected to my database, got the counter value, incremented it, and stored it back. That little victory felt huge.

Finally, all that was left for this step was to write some test cases. I just was not in the mood to write it on my own, so I skipped it and used AI tools to write it for me.

Part 6: Infrastructure as Code (IaC)

The normal way to create resources in Azure is to go to the Azure portal, click on the resource that I want to create, fill out the information and hit "review+create". This is a manual task and if I need to recreate the same setup, I have to do it again and if I forget a setting, then good luck with it.

IaC is a way of solving it where I deploy my infrastructure in code like JSON, YAML, etc. I used Bicep to deploy my resources which is just a way to declare I need a Storage Account in this resource group, I need a Function App with this plan and runtime, etc. Bicep generally has 3 sections:
a) Parameter
b) Resource
c) Deployment
Parameter section defines the variable that will be used throughout my bicep file. Resource section defines the infrastructure. Deployment section just deploys the code. The code can be deployed using the simple command:
az deployment group create --resource-group RESOURCE_GROUP_NAME --template-file BICEP_FILE

This part was not frustrating as there were plenty of resources out there which does exactly this. So I did this step easily.

Part 7: CI/CD for Backend

First let us understand some theory. So when I make some changes to my code and upload it, that's it. If i want the change to be reflected in my Azure resource, then I have to do it manually by going to that resource and uploading the new changes again. However, I can automatically deploy changes and this is where CI/CD comes in.

CI stands for Continuous Integration. Every time I make a change and push it to GitHub, my code is automatically tested.

CD stands for Continuous Deployment. If the test passes, my code and infra changes are automatically deployed to Azure.

For this, I need to use GitHub Actions. It is a way to write automation scripts that run whenever certain events happen in my repository like a change is pushed to a repo.

I first attempted to deploy both the infra and trigger using the single bicep file but the approach was wrong. Bicep is for infra and its sole purpose is to provision and configure resources. Embedding the code in bicep template means every time I run the template, it would redeploy the code which makes the code harder to debug and manage.

So to deploy the code, I used GitHub Actions. This pipeline runs every time I push the code to the repository. To build GitHub actions, I createdsingle workflow file: .github/actions/main.yml and added two jobs:
a) build-and-test: This job is for CI. So this job must be passed to move to the next job and to pass it, the tests i have written earlier runs. If the test passes, then it moves to the second job else the whole deployment process fails.
b) deploy-to-azure: This job is for CD. Dependency is created so that the job only runs after the first job is executed. A secret is created in the project repo so that sensitive information is not hardcoded in the workflow file.
az ad sp create-for-rbac --name "myGitHubActionsServicePrincipal" --role contributor --scopes /subscriptions/sub_id --sdk-auth
This secret is used to login to Azure. After logging in, bicep template is deployed. After deploying the function app, the function (HTTP Trigger) is zipped and then deployed.

Like Part 5, this was the most frustrating part of the project and it took me a day to solve it. No matter how many times I debugged the code, the Azure Function just wouldn’t deploy. I searched online forums, used AI tools to check my syntax, and tried different deployment methods but the function just won't appear. So as a last resort, I installed requirements like this:
pip install -r requirements.txt --target=".python_packages/lib/site-packages"
and the function was deployed. Even though I explicitly specified Python 3.11 in my workflow, the GitHub Actions runner ignored it and defaulted to Python 3.12. So the above code ensures that the workflow actually runs with the right Python version and installs all dependencies into the location Azure Functions expects. After this change, deployment finally worked.

Part 8: CI/CD for Fronotend

Once the backend is running, the next step is to make updating the frontend file automatically to the storage account. I created a new GitHub repository just for static website files. I wrote a small workflow that runs automatically whenever I push new code to the repository. The workflow takes the new files and uploads them to the Azure Storage $web container, replacing the old version. Finally, I need to purge Azure CDN cache so that I can see the latest changes in the domain instead of the old cached version.

Part 9: HTTPS and DNS

This was the final step for me. The main goal of this step is to make my resume website publicly available at an address of my own. To complete this, the very first thing I need is a custom domain. To get a custom domain, I need to register a domain from a registrar. A small amount of fee needs to be paid to the registrar to get the domain. So upon searching, I choose the cheapest domain .cloud from Hostinger. I then need to create an Azure Front Door and add domain to it. After adding domain, Azure provides a TXT and CNAME record which needs to be copied to my custom domain. This is done so that my custom domain points to the Azure Front Door. I can make my domain point directly to storage account but if I do that, I would need to buy TLS/SSL certificate for HTTPS from third party CA. But Azure FrontDoor with AFD Managed Certificate handles that automatically.
Finally, I created a routing rule so that when someone visits to my custom domain, they will be forwarded to the storage account.

So this is the final result of the challenge.

Conclusion

For a long time, I was caught in the cycle of "learning by reading" where I would read theories and concepts but never apply them. I had a myriad of knowledge in my head, but no real experience to back it up.

This challenge forced me to break free from that cycle. I didn't start by reading about Azure Functions, CI/CD pipelines or Infrastructure as Code; I went head first, actually built them and then forced myself to learn the basic theory. I admit that the process was messy, full of debugging and unexpected errors, but it was in those moments that the theoretical concepts made sense to me.

This project also pushed me to explore a wide range of services, from Azure Storage to CosmosDB, without getting lost in a single one. While my knowledge lacks depth right now, I am starting to have a mental map of how all the pieces of a modern web application fit together.

I had a lot of fun, frustration and learned many things doing this project. I highly recommend any new comers like me to complete this project.

Photo by Vladimir Anikeev on Unsplash

🐧Week 1 of my Cloud Journey - Building a Strong Linux Foundation

asim-makes — Sat, 16 Aug 2025 12:18:29 +0000

It’s been an exciting first week in my cloud journey. While I’ve had some past experience with Linux and basic scripting, it’s been a while since I last explored the cloud. So, I dedicated this week to revisiting the fundamentals and bridging the gap between my existing skills and the next phase of my learning.

I started by moving around directories, installing software, and managing files. I first learned about package management — a tool to find software from repositories, install it, update it, and remove it. Package management taught me that every distribution has its own way of handling software, but the core principle remains same.

Then came process management. At first, “killing” a process was confusing because I had to read about signals and what they actually did. But I soon realized they’re simply different ways of telling the system to stop something that’s not working as intended. Running commands like ps, top, and kill gave me a real snapshot of how the system works in Linux. I knew how to do this in Windows, but in Linux, I had no idea until now.

Next, I dove into user management — creating new users and groups, assigning permissions, and switching between accounts. It was so simple in Linux. In Windows, it’s such a time-consuming process, but in Linux, one or two quick commands and my new user is ready.

I also explored scheduling with cron. Automating simple tasks, like running backups at a specific time, made me realize how much I enjoy automation. But I soon discovered cron’s limitations when I wanted to schedule tasks without fixed times. For example, I wanted to run a script every day, but what if I missed a day? Cron doesn’t handle that, so I had to use Anacron, which exactly handles those edge cases.

On the surface, these might look like random Linux commands and scripts. But in reality, this week gave me important lessons that apply directly to cloud engineering:

Automation is key. If I repeat something, script it.
Know what’s running. Process and service management is the backbone of troubleshooting in the cloud.

Conclusion

For Week 2, I’ll be switching tools a bit. My focus will be on Python and boto3, the AWS SDK for Python, so I can start interacting with cloud services. I’ll also try to set up my AWS account (I cant set it up right now because I dont have a dollar card yet) and get it ready for hands-on practice.

Step by step, the journey continues 🚀.

🚀 Day 0 of my Cloud Journey - Cutting through the Noise

asim-makes — Sat, 09 Aug 2025 15:26:50 +0000

Hi, I’m Asim Baral.
From tomorrow, I’m starting my journey toward becoming a Cloud Engineer. I’ve decided to stop overthinking, stop scrolling through endless “is this field safe?” posts, and instead focus on building real skills and taking consistent action.

I currently work as an IT Support Engineer (troubleshooting, M365, and more). Now, I’m ready to level up into cloud engineering.

So this is my high level overview of the roadmap that I have created:

Phase 1: Foundational Level

Deadline: 1-2 months

In this phase, I will focus on these areas

AWS Fundamentals
Focus on Linux and Networking
Python for basic cloud and automation
Scripting and Text Processing
Basic Portfolio

Phase 2: Core Level

Deadline: 3-5 months

In this phase, I will focus heavily on certs and building portfolio projects.

AWS Associate Level Cert (SAA-C03)
Hands on Projects

Phase 3: Specialization

Deadline: 6-12 months

In this phase, I will focus on deepening my skills in the most in-demand technologies and build a more complex project that showcases my readiness for a professional role.

Terraform, Docker or Kubernetes (Any one of them)
Basic CI/CD pipelines
Advanced Project

By the end of 1 year, here are my deliverables:

SAA-C03 cert
4-5 portfolio projects
Intermediate on Linux
Know how to use Terraform, Docker or Kubernetes

To be accountable, I will post weekly updates on dev.to with my progress, challenges and the lessons that I have learned. Soon, I will be transitioning to linkedin (maybe 1 or 2 months from now) to not only post updates but also to actively engage on community.

Conclusion

No career path is safe or immune to change. Every career path has endless noise of "Is this field safe", "Can I get an entry level job with this", "Will AI take over my job", "I got rejected with such good portfolios, so this field is cooked", and yada yada. The only thing I can do is to keep learning new skills, be adaptable and have the willingness to learn.

This post marks by Day 0. Let there be noise. It stays outside. My growth happens here.