- Vishakha Sadhwani
- Posts
- Week 3 — Infrastructure as Code & Containerization
Week 3 — Infrastructure as Code & Containerization
The Shift from Clicking on console to coding/scripting
Hi Inner Circle,
Welcome to Week 3.
Last week, we covered the backbone — networking, IAM, and storage.
I hope you’re solid on those foundations, because as we go further, things are going to get COMPLEX— I mean very COMPLEX (yes, the caps are on purpose ~ take this seriously!).
This week, we’re stepping into the muscle of the cloud: infrastructure and compute.
Every application ultimately needs to “run” somewhere.
For years, that meant a virtual machine you spun up manually and configured line by line. Over time, the industry has moved toward automation and containers, and in Week 4 we’ll take this further into serverless and Kubernetes.
Let’s break down the journey.
⸻
Virtual Machines & the Old Way of Provisioning
In the early cloud days, deploying an app meant:
Launch a VM → Go to AWS EC2 or GCP Compute Engine, select an OS, and boot an instance.
Manually SSH in → Install dependencies (apt-get install nginx), configure your web server, and tweak settings.
Repeat → Every new server required the same steps — often prone to human error.
Why it matters: This is still the foundation. If you don’t understand how to bring up a VM, you’ll struggle to appreciate the automation layers that came later.
Resources:
Mini Project: Spin up a Linux VM, SSH in, and install Nginx - YouTube Video here.
⸻
Snapshots & Images
Manual configuration is fragile. If a VM crashes, you don’t want to rebuild everything.
Snapshots: Capture the disk state of a VM.
Images: Create reusable templates (AWS AMIs, GCP Custom Images) that can launch pre-configured servers.
Why it matters: This was the first step toward repeatability in infrastructure. Instead of repeating manual steps, you could clone golden images.
Resources:
Another video tutorial here ( note the configuration steps can be used to deploy in any cloud provider)
Mini Project: Install Nginx on a VM → create an image → launch a new VM from that image → confirm it already has Nginx running.
⸻
Infrastructure as Code (IaC): The Modern Flow
Snapshots helped, but they didn’t solve configuration drift. Teams started writing shell scripts (bash, Ansible, Chef, Puppet) to configure servers after launch.
That worked… until infra grew into hundreds of servers across multiple regions.
This is where Infrastructure as Code (IaC) came in.
The evolution:
Stage | Approach | Pain Point | Solution |
Manual | Click UI → Launch VM → SSH + install packages | Error-prone, inconsistent | Snapshots/Images |
Scripts | Bash/Ansible/Chef after boot | Hard to maintain, not versioned | Config Management |
IaC | Terraform/CloudFormation templates define infra | Consistent, automated, reproducible | Modern standard |
Why IaC matters:
Declarative: Describe what you want, not step-by-step how to do it.
Versioned: Store in Git, review changes like code.
Automated: Provision hundreds of servers with one command.
Consistent: Same template works across environments.
Quick comparison of IaC tools:
Tool | Language | Cloud Scope | Key Strength |
Terraform | HCL (HashiCorp Config Language) | Multi-cloud | Most popular, huge ecosystem of modules |
AWS CloudFormation | JSON/YAML | AWS-only | Deep integration with AWS services |
Pulumi | Python, TypeScript, Go, C# | Multi-cloud | Use real programming languages instead of DSLs |
Azure Bicep | Bicep (DSL for Azure) | Azure-only | Simplified alternative to ARM templates |
Resources:
Mini Project: Write a Terraform file that provisions a VM with Nginx. Destroy and recreate it with one command.
Reference videos here.
⸻
Containerization: The Docker Fundamentals
Even with IaC, VMs are still “heavy.” Each VM runs a full OS, which means slower startup and more overhead.
Docker is the prerequisite for Kubernetes. Know these commands to manage your containerized applications locally.
Docker Command | Function | Real-World Use |
| Creates an executable image from a Dockerfile and its context. | Turning your application code into a portable, cloud-ready artifact. |
| Creates and starts a container from a specific image. | Testing your application in an isolated environment on your laptop. |
| Lists all currently running containers. | Quickly checking the health and status of your running workloads. |
| Fetches the logs from a running container. | Debugging application errors inside the container environment. |
| Runs a command inside a running container. | Shelling into a running container for quick inspection or troubleshooting (e.g., |
Why it matters: Containers standardize the execution environment, making handoffs between development, testing, and production seamless.
Resource: Work through this great, simple Hello World Node.js Docker project on GitHub to practice your commands: github.com/dockersamples/helloworld-demo-node.
Resources:
⸻
Container Registries
Now you need a way to share containers. Enter registries:
Public: Docker Hub
Private: AWS ECR, GCP Artifact Registry, Azure Container Registry
Why it matters: Registries are the “app stores” for containers. Without them, DevOps pipelines can’t scale.
Resources:
Another reference video here.
Mini Project: Push your Nginx container to Docker Hub and pull it on another machine.
⸻
PaaS Deployments
What if you don’t want to manage VMs or clusters at all?
Platforms like Google App Engine let you deploy an app directly managing runtime and other dependencies. You get an option to choose container based environments as well.
The provider manages scaling, patching, and infra.
Why it matters: PaaS is the bridge between containers and serverless. Great for startups, less flexible for advanced infra.
Resources:
Mini Project: Deploy your Nginx app on App Engine or Elastic Beanstalk. Compare setup effort vs running it on a VM.
⸻
Action Items for Week 3
Launch a VM, SSH in, and install Nginx.
Take a snapshot/image and relaunch from it.
Write a Terraform file to deploy the same VM automatically.
Containerize Nginx with Docker.
Push your image to Docker Hub or a cloud registry.
Deploy to PaaS and compare experience.
⸻
Conclusion
That’s your TL;DR for Week 3.
We started with the old way (manual VMs), evolved to images and automation, and ended with containers and PaaS. This is the natural journey cloud teams went through — and the one you should practice too.
Next week → we’ll push forward into Serverless and Kubernetes. You’ll learn how functions scale without servers and how Kubernetes orchestrates containers at scale.
Good Luck with this week!
-V
Seeking impartial news? Meet 1440.
Every day, 3.5 million readers turn to 1440 for their factual news. We sift through 100+ sources to bring you a complete summary of politics, global events, business, and culture, all in a brief 5-minute email. Enjoy an impartial news experience.