
## Introduction

In [Part 1](./ecs-fargate-deep-dive-part-1.md), we pulled back the curtain on **how ECS Fargate works**: Firecracker microVMs, ENIs, IAM, and the hidden host fleet.  

Now it’s time to get hands-on. We’ll spin up Firecracker locally, boot a microVM, and even simulate the ENI networking model.  

### Why Should You Care?

Running Firecracker yourself helps you:  

- See how AWS runs **each Fargate task inside its own VM**.  
- Understand **boot performance** and why Fargate cold starts take 30–60s.  
- Learn how ENIs map to **VPC-level isolation**.  
- Debug networking limits by replicating them locally.  

### Scenario Overview

We’ll simulate a Fargate task locally:  

- Launch a Firecracker microVM.  
- Attach a minimal Linux root filesystem.  
- Configure a TAP interface for networking (like an ENI).  
- Map this setup back to ECS Fargate’s architecture.  

Goal: see how isolation and networking work in practice.  

---

## Deep Dive: Step-by-Step Setup

### Prerequisites

Run this on a Linux host (Ubuntu VM, EC2, or Multipass).  

```bash
sudo apt-get update
sudo apt-get install -y git curl wget build-essential \
    unzip cmake pkg-config libseccomp-dev

# Download Firecracker

curl -LOJ https://github.com/firecracker-microvm/firecracker/releases/download/v1.8.0/firecracker-v1.8.0-x86_64.tgz
tar -xvf firecracker-v1.8.0-x86_64.tgz
sudo mv release-v1.8.0-x86_64/firecracker /usr/local/bin/

### Kernel & RootFS

curl -LO https://s3.amazonaws.com/spec.ccfc.min/img/hello/kernel/vmlinux.bin
curl -LO https://s3.amazonaws.com/spec.ccfc.min/img/hello/fsfiles/x86_64/rootfs.ext4


### Launching a MicroVM

rm -f /tmp/firecracker.socket
firecracker --api-sock /tmp/firecracker.socket &

# VM config + boot source
curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/machine-config' \
  -H 'Content-Type: application/json' \
  -d '{"vcpu_count":1,"mem_size_mib":512,"ht_enabled":false}'

# Kernel
curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/boot-source' \
  -H 'Content-Type: application/json' \
  -d '{"kernel_image_path":"./vmlinux.bin","boot_args":"console=ttyS0 reboot=k panic=1 pci=off"}'

# RootFS
curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/drives/rootfs' \
  -H 'Content-Type: application/json' \
  -d '{"drive_id":"rootfs","path_on_host":"./rootfs.ext4","is_root_device":true,"is_read_only":false}'

## Start the VM

curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/actions' \
  -H 'Content-Type: application/json' \
  -d '{"action_type":"InstanceStart"}'

## You’ll see a minimal Linux VM booting instantly.

###Networking Simulation

### Fargate gives each task its own ENI. We’ll mimic this with a TAP device:

sudo ip tuntap add tap0 mode tap
sudo ip addr add 172.16.0.1/24 dev tap0
sudo ip link set tap0 up


### Attach it to Firecracker:

curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/network-interfaces/eth0' \
  -H 'Content-Type: application/json' \
  -d '{"iface_id":"eth0","host_dev_name":"tap0","guest_mac":"02:FC:00:00:00:01"}'


### Inside the VM, bring up eth0 and assign an IP. Now the microVM talks to the host — exactly how a Fargate task talks to your VPC.

```

### Mapping Back to Fargate

- Firecracker VM → Your Fargate task’s isolated runtime.

- RootFS → Base container environment + ECS runtime + your container image.

- TAP device → Equivalent of a VPC ENI.

- API config → ECS Scheduler telling Fargate what to run.

### Architecture

```mermaid
flowchart TD
    subgraph LocalLab["Local Firecracker Lab"]
        subgraph Firecracker["MicroVM"]
            Kernel[Linux Kernel]
            RootFS[RootFS + Container Runtime]
            IF1[eth0 (TAP)]
        end
        Host["Linux Host"] --> Tap[tap0]
        Tap --> IF1
    end

    subgraph AWSFargate["AWS Fargate Analogy"]
        subgraph Task1["Fargate Task"]
            MVM1[Firecracker microVM]
            ENI1[ENI (VPC IP)]
        end
        VPC1[VPC Subnet + Security Group]
    end

    Tap -. maps to .-> ENI1
    Firecracker -. maps to .-> MVM1
    Host -. maps to .-> VPC1

```

### Takeaways

- Each Fargate task is a microVM, not just a container.

- ENI-per-task makes tasks first-class citizens in your VPC.

- Running Firecracker locally shows why Fargate cold starts exist.

- Debugging ENIs locally helps anticipate VPC IP exhaustion issues.

---

### Conclusion

By running Firecracker locally, you’ve just recreated the core of ECS Fargate. Every time you launch a task in AWS, the same steps happen — at massive scale, across AWS’s hidden fleet.

In Part 3, we’ll dive into real-world gotchas: ENI scaling limits, cold start tuning, and how observability works when you don’t control the host.


In the second part of our ECS Fargate Deep Dive, we get hands-on with Firecracker — the lightweight VMM that powers Fargate — and simulate task isolation and networking locally.

ECS Fargate Deep Dive Part 2: Firecracker in Action


## Introduction

This is Part 1 of our ECS Fargate Deep Dive series. In these posts, we’ll strip away the abstraction and look at what’s really happening under the hood when you launch a Fargate task.  

We’ll cover internals like **Firecracker microVMs, ENI networking, IAM roles, storage and scheduling** - the things AWS doesn’t show you in the console. 

### ECS Fargate: Behind the Scenes of Serverless Containers

When you launch a task on ECS Fargate, it feels like magic — no EC2 instances, no cluster autoscaling, just containers running. But what’s actually happening under the hood?

Let’s peel back the layers.

### Why Should You Care?

Fargate feels “serverless for containers” — but knowing how it works helps you:  

- Debug **networking issues** (e.g. ENI/IP exhaustion).  
- Understand **cold starts and scaling behaviour**.  
- Make **cost vs flexibility trade-offs** between ECS on EC2 and Fargate.  
- See why Fargate is safer in multi-tenant workloads.  

### What Fargate Really Is

Fargate isn’t a special kind of ECS cluster. It’s an AWS-managed capacity layer that runs your containers in lightweight microVMs. You pick CPU, memory, networking, and IAM roles — AWS handles the hosts, patching, and kernel security. 

## Deep Dive: What Actually Happens

### Firecracker MicroVMs

- Each Fargate task = one Firecracker microVM.  
- Built on **KVM**, stripped down for speed.  
- Isolation is stronger than plain Docker namespaces.  
- Each has its own kernel, cgroups, and seccomp profile.  

This is why tasks don’t share kernels, unlike ECS on EC2.  

### Networking

When you start a Fargate task:

- AWS provisions an Elastic Network Interface (ENI) in your VPC.
- Every task gets its own **Elastic Network Interface (ENI)**.  
- The ENI is placed directly in your VPC subnet and directly to the microVM.  
- Security groups/NACLs apply directly to the task.  
- From a network perspective, tasks behave like first-class EC2 instances. This is why Fargate tasks look and feel like EC2 instances on the network.
 
### Storage & Security

- **Ephemeral storage**: 20 GiB by default (up to 200 GiB). Dies with the task.
- **Persistent storage**: use EFS mounts if needed.  
- **IAM Roles for Tasks**: AWS injects temporary credentials directly into the microVM.
- No SSH/SSM access — AWS fully manages the hosts.  

### Scheduling & Scaling

1. ECS control plane tells Fargate: “Run this task with X CPU, Y memory.”  
2. Fargate provisions a microVM, attaches an ENI, pulls the image and starts the task.
3. Scaling = AWS spinning up/destroying microVMs behind the scenes.

## Performance & Limits

- **Cold starts**: ~30–60s (microVM boot + ENI attach + image pull).  
- **Resource limits**: 0.25–16 vCPUs, 0.5–120 GiB RAM.  
- **Restrictions**: no privileged mode, no GPUs, no custom kernels. Can't run DinD (docker in docker) in a task. 
- **Cost model**: billed per vCPU-second + GiB-second.  

---

### ECS on EC2 vs ECS Fargate

| Feature       | ECS on EC2                         | ECS Fargate                          |
|---------------|------------------------------------|--------------------------------------|
| Host control  | You manage AMIs & patching         | AWS manages hosts                     |
| Isolation     | Shared kernel (namespaces)         | Firecracker microVM per task          |
| Networking    | Shared ENI or `awsvpc`             | Dedicated ENI per task                |
| Flexibility   | Privileged, GPU, custom AMI        | Limited, no host access               |
| Cost model    | Pay per instance (even idle)       | Pay per task-second                   |


---

## Architecture Diagram  

```mermaid
flowchart TD
    ECS[ECS Control Plane] -->|Schedules Task| AWS_Fargate["AWS Fargate Host Fleet"]

    subgraph AWS_Fargate
        subgraph Firecracker1["Task A (Firecracker microVM)"]
            C1[Containers]
            ENI1[ENI]
        end
        subgraph Firecracker2["Task B (Firecracker microVM)"]
            C2[Containers]
            ENI2[ENI]
        end
    end

    ENI1 --> VPC1[VPC Subnet + Security Group]
    ENI2 --> VPC2[VPC Subnet + Security Group]
```

### Takeaways

- Each Fargate task runs in its own microVM, not a shared host kernel.

- Networking is first-class: ENI per task, direct VPC integration.

- You give up host control in exchange for security + simplicity.

- Cold starts, ENI limits, and no privileged mode are the main gotchas.

### How to Think of It

Fargate is basically AWS Lambda for containers:

- Instead of functions, you run containers.

- Instead of ephemeral processes, you get microVMs.

- You trade host control for simplicity, security, and auto-scaling.



In the first part of our ECS Fargate Deep Dive, we break down what happens behind the scenes when you run a task on Fargate — Firecracker microVMs, ENIs, IAM and the hidden host fleet.

ECS Fargate Deep Dive Part 1: How Fargate Really Works


## Introduction

This is Part 1 of our Container Networking Deep Dive series. In this hands-on deep dives, we show how to simulate container-like networking using Linux primitives: ip netns, veth pairs, and routing tables.

We're building it all from scratch. Think of it like plugging an Ethernet cable between two interface cards — one inside a Linux network namespace (our "container") and the other in the host.

### Why Should You Care?

Understanding the low-level mechanics and first principles behind container networking — without relying on Docker or Kubernetes — gives you ultimate debugging power. This series is designed to demystify how containers, pods, bridges, overlays and CNI plugins actually work under the hood.

### Scenario Overview

Prerequisites:

- Make sure to have `multipass` installed (if on macOS) or have a VM setup via UTM/VirtualBox.

We’ll set up:

- A VM using Multipass
- A network namespace (what containers are under the hood)
- A veth pair connecting host and namespace
- IP addresses on both ends
- Routing so they can talk

Goal: ping the namespace from the host and vice versa.

## Deep Dive: Step-by-Step Setup

### Provisioning the VM

Create a Makefile to provision the VM and transfer the files to it.

```bash
NAME=netns-lab
IMAGE=22.04
SCRIPT=scenario1.sh

up:
	@if multipass info $(NAME) >/dev/null 2>&1; then \
		echo "$(NAME) already exists. Skipping launch."; \
	else \
		echo "Launching $(NAME) VM..."; \
		multipass launch --name $(NAME) --cloud-init cloud-init.yaml --memory 1G --disk 5G; \
	fi
	@chmod +x env.sh scenario1.sh test.sh
	@echo "Transferring files to VM..."
	@for file in env.sh scenario1.sh test.sh; do \
		multipass transfer $$file $(NAME):/home/ubuntu/ || echo "Failed to transfer $$file"; \
	done
```

env.sh is a simple script to set up the environment variables.

```bash
CON="netns1"
IP="10.200.1.1"
```

```bash
#!/bin/bash -e

. /home/ubuntu/env.sh

echo "[+] Creating the namespace"
sudo ip netns add $CON

echo "[+] Creating the veth pair"
sudo ip link add veth1 type veth peer name veth2

echo "[+] Moving one end to namespace"
sudo ip link set veth2 netns $CON

echo "[+] Assigning IP inside namespace"
sudo ip netns exec $CON ip addr add $IP dev veth2

echo "[+] Bringing up interfaces"
sudo ip netns exec $CON ip link set veth2 up
sudo ip netns exec $CON ip link set lo up
sudo ip link set veth1 up

echo "[+] Routing setup"
sudo ip route add $IP/32 dev veth1 || true
sudo ip netns exec $CON ip route add default via $IP dev veth2 || true
```

We setup:

- We create a namespace called `netns1`
- We create a veth pair called `veth1` and `veth2`
- We move one end to the namespace
- We assign an IP address to the interface in the namespace
- We bring up the interfaces
- We add a route to the namespace from the host
- We add a default route to the namespace from the host

### Test connectivity

```bash
#!/bin/bash

NS=netns1
IP=10.200.1.1

check() {
  echo "[TEST] $1"
  eval "$2"
  echo ""
}

fail_if_empty() {
  if [ -z "$($1)" ]; then
    echo "[FAIL] $2"
    exit 1
  else
    echo "[PASS] $2"
  fi
}

check "Namespace exists" "sudo ip netns list | grep -q $NS && echo 'Found namespace $NS'"
fail_if_empty "sudo ip netns list | grep $NS" "Namespace '$NS' exists"

check "Interface in namespace" "sudo ip netns exec $NS ip link show veth2"
check "Interface on host" "sudo ip link show veth1"
check "Route on host to $IP" "sudo ip route | grep $IP"
check "Ping from host to namespace" "sudo ping -c 3 $IP"
check "Ping from namespace to host IP" "sudo ip netns exec $NS ping -c 3 $IP"
check "Routes inside namespace" "sudo ip netns exec $NS ip route"
```

### Rest of makefile

```bash
run:
	@echo "Running scenario script..."
	@multipass exec $(NAME) -- bash /home/ubuntu/$(SCRIPT)

shell:
	@multipass shell $(NAME)

test:
	@multipass exec $(NAME) -- bash /home/ubuntu/test.sh

destroy:
	@echo "Destroying VM..."
	@multipass delete $(NAME) --purge || echo "$(NAME) does not exist."
```

## Takeaways & Lessons learned

- `ip netns` is the real container under the hood.
- A veth pair gives you point-to-point connectivity. Similar to what a virtual Ethernet cable does.
- You control the routing tables just like in real containers.
- Network namespaces give you isolation.
- veth pairs connect those isolated spaces.
- Routing needs to be explicit.
- You can debug container networking using raw Linux tools.

## Conclusion

We’ve now created our first standalone network namespace with basic connectivity from host to namespace. This is how most CNI plugins start under the hood.

In the next part of the series, we’ll look at creating two namespaces on the same node and wiring them together using a bridge — effectively building a virtual switch.

Stay tuned for Part 2!


In the first part of our Container Networking Deep Dive, we explore how to set up a single network namespace inside a VM and connect it to the host using a veth pair.

Container Networking Deep Dive Part 1: Single Network Namespace on a VM


## Introduction

### What Are We Building? 🧱

In this second part of the series, we connect two network namespaces (netns1, netns2) to the same virtual bridge on a single VM. This mirrors how Kubernetes pods share a flat L2 network on a single node.

### Why This Matters

This setup is the basis of many container networks. It replicates the behavior of a Linux bridge or a virtual switch (like what Docker and most CNIs do).

## Scenario Overview

- Two namespaces: `netns1`, `netns2`
- Each has a veth interface (`veth11`, `veth21`)
- The host side of the veth pairs (`veth10`, `veth20`) is connected to a Linux bridge `br0`
- The bridge has IP `172.16.0.1`
- `netns1` gets `172.16.0.2`, `netns2` gets `172.16.0.3`
- All interfaces are on the same /24 subnet

## Architecture

![cns2](/images/cns2.png)

## Setup

We'll use the same setup script as in the previous part.

```bash
NAME=scenario2
IMAGE=22.04

up:
	@if multipass info $(NAME) >/dev/null 2>&1; then \
		echo "$(NAME) already exists. Skipping launch."; \
	else \
		echo "Launching $(NAME)..."; \
		multipass launch --name $(NAME) --memory 1G --disk 5G; \
	fi
	@chmod +x env.sh setup.sh test.sh
	@echo "Transferring files..."
	@for f in env.sh setup.sh test.sh; do \
		multipass transfer $$f $(NAME):/home/ubuntu/; \
	done
```

Now run the VM setup.

```bash
make up
```

env.sh contains the variables for the scenario.

```bash
CON1="netns1"
CON2="netns2"
NODE_IP="10.0.0.10"
BRIDGE_IP="172.16.0.1"
IP1="172.16.0.2"
IP2="172.16.0.3"
```

### Creating the Namespaces & Interfaces

setup.sh creates the namespaces and interfaces.

```bash
#!/bin/bash -e
. /home/ubuntu/env.sh

sudo ip netns add $CON1
sudo ip netns add $CON2

sudo ip link add veth10 type veth peer name veth11
sudo ip link add veth20 type veth peer name veth21

sudo ip link set veth11 netns $CON1
sudo ip link set veth21 netns $CON2

sudo ip netns exec $CON1 ip addr add $IP1/24 dev veth11
sudo ip netns exec $CON2 ip addr add $IP2/24 dev veth21

sudo ip netns exec $CON1 ip link set veth11 up
sudo ip netns exec $CON2 ip link set veth21 up
```

### Connecting via Bridge

```bash
sudo ip link add name br0 type bridge
sudo ip link set veth10 master br0
sudo ip link set veth20 master br0
sudo ip addr add $BRIDGE_IP/24 dev br0
```

### Bridging everything together

```bash
sudo ip link set br0 up
sudo ip link set veth10 up
sudo ip link set veth20 up
sudo ip netns exec $CON1 ip link set lo up
sudo ip netns exec $CON2 ip link set lo up
```

### Routing configuration

```bash
sudo ip netns exec $CON1 ip route add default via $BRIDGE_IP dev veth11
sudo ip netns exec $CON2 ip route add default via $BRIDGE_IP dev veth21
```

## Manual testing

Conditions to test:

- Ping from `netns1` to `netns2`
- Ping from `netns2` to `netns1`
- Ping from host to `netns1` & host to `netns2`
- Ping from `netns1` to host & `netns2` to host. 

## AutomatedTesting

test.sh contains the tests for the scenario.

```bash
#!/bin/bash
. /home/ubuntu/env.sh

check() {
  echo "[TEST] $1"
  eval "$2"
  echo ""
}

fail_if_empty() {
  if [ -z "$($1)" ]; then
    echo "[FAIL] $2"
    exit 1
  else
    echo "[PASS] $2"
  fi
}

fail_if_empty "sudo ip netns list | grep $CON1" "Namespace $CON1 exists"
fail_if_empty "sudo ip netns list | grep $CON2" "Namespace $CON2 exists"

check "IP in $CON1" "sudo ip netns exec $CON1 ip a show dev veth11"
check "IP in $CON2" "sudo ip netns exec $CON2 ip a show dev veth21"
check "Ping $IP2 from $CON1" "sudo ip netns exec $CON1 ping -c 3 $IP2"
check "Ping $IP1 from $CON2" "sudo ip netns exec $CON2 ping -c 3 $IP1"
check "Ping bridge from $CON1" "sudo ip netns exec $CON1 ping -c 3 $BRIDGE_IP"
check "Ping bridge from $CON2" "sudo ip netns exec $CON2 ping -c 3 $BRIDGE_IP"
check "Bridge info" "ip a show br0"
```

Run with `make test`.

## Makefile workflow

```bash
run:
	multipass exec $(NAME) -- bash /home/ubuntu/setup.sh
test:
	multipass exec $(NAME) -- bash /home/ubuntu/test.sh
shell:
	multipass shell $(NAME)
destroy:
	multipass delete $(NAME) --purge || echo "Nothing to destroy."
```

```bash
make run # Run the setup script
make test # Run the test script
make shell # Drop into the VM
make destroy # Clean up
```

## Key Takeaways

- A Linux bridge behaves like a virtual switch
- All devices on the same bridge can talk L2 directly
- Namespaces need explicit routing (default route via bridge IP)
- Debugging tools like `ip a`, `ip r`, `ip link` help massively when it comes to networking & troubleshooting.

## Conclusion

You now have a working L2 network across multiple isolated namespaces. This is the basis for pod networking on a single node.

Next up in Part 3: we’ll span this setup across two VMs, and show how to keep everything on the same subnet using a shared L2 segment or VXLAN overlay.


In the second part of our Container Networking Deep Dive, we connect two network namespaces via a bridge on the same Linux host.

Container Networking Deep Dive Part 2: Two Namespaces on the Same Host


Containerising applications has become the norm in the IT/DevOps industry, allowing developers to condense their application code and all its dependencies in a lightweight and portable environment so that these applications can be deployed anywhere virtually.

Before going into containers, we must first understand why they were designed.

Let’s just say a Python application has been developed, the next logical step would be to deploy it; this can be complex as well as time-consuming. This is because a running app requires a myriad of configurations, ranging from the allocation of resources to setting up environmental variables.

Another consideration for the application is the ability of it being portable. If a developer needs to change the deployment environment or move to another cloud provider, they will need to repeat many steps of the deployment process. Once again, this can be a mundane process.

Containers efficiently solve the issues by packaging the codebase for the application with all the required dependences — including tools, libraries, config files and run-times. This process of containerisation ensures a lightweight and secure package (depending on how it’s done) known as a container image.

This image can then be used to deploy a containerised application in any environment required, thus giving the developers the much-needed freedom to design and develop apps without having to think about other constraints. Some common container runtimes are Docker, containerd and CRI-O.


![Cargo ships in reference to containers](/images/containers-intro.png)

Many large IT organisations became frustrated with 4–6 month releases and sluggish deployments. Organisations like Netflix and many others began to embrace microservices, thus helping them overtake their fellow competitors — who also had a similar plan. So applications began being built using microservices, heavily transforming into a more DevOps and Agile culture; larger teams were split into smaller ones to allow for this transformation.


DevOps cycle releases
Then came along issues whilst building microservices. Amongst those issues was containerising applications so that they are deployable on any environment, including a Dev’s one. As mentioned before, it was the idea of containers that solved this issue and then this lead to another issue which was managing these containers. This is where the story of Kubernetes began.

So, Kubernetes is a container orchestration platform or in simple terms, an application management platform.

Fun fact: The name Kubernetes itself stems from an ancient Greek word for “helmsman”, meaning he who steers a ship thus telling the story behind the K8s logo. Another name for Kubernetes (you hear it quite often) is “K8s” — the reason for this name is, the 8 letters between the “k” and the “s” in Kubernetes.

Note: From now on, K8s may be used to refer to Kubernetes sporadically.


![The Galver depicting the Kubernetes control mechanism](/images/ship.png)

## Why Kubernetes overtook its competitor OpenStack?

Although K8s and OpenStack have produced similar level of interests, they are slightly different from each other. In the end, Kubernetes has succeeded where OpenStack fell behind. The reason being, Kubernetes’ ability to provide business value and focus on the bigger picture which is the Enterprise IT applications. On the other hand, OpenStack orchestrated infrastructure and no matter how good your infrastructure management is, if you are not solving business problems, what use is it?

## Okay, so how does Kubernetes help me or my company ?

As mentioned before, Kubernetes enables a “microservice” approach to building modern application and larger teams can be split into smaller ones — leading to a much faster time to market, deployments of applications are always being updated and later versions are released.

**Costs of IT infrastructure are more optimised**. K8s can help your organisation largely cut infrastructure costs especially if they’re operating at a huge scale. Prior to the introduction of K8s, IT and Sys Admin, commonly over-provisioned their infrastructure to handle unexpected spikes. K8s is wise enough to schedule and put together containers, while taking into consideration available resources.

Nowadays, the success of applications doesn’t merely depend on features, but also on the scalability of the application. For indeed, if an app cannot scale properly, it will not perform at its best. Kubernetes is critical in this process as it scales and improves app performance. Let’s say we have a service which takes up high-CPU and its quite dynamic, meaning it changes based on business conditions; the solution required here would be something that can scale up the app so that new VMs are automatically created or scaled down when the load is reduced. Kubernetes offers just that capability by scaling up the app as the CPU usage goes above a certain threshold and scales back as a result, optimising the infrastructure utilisation. This feature of K8s auto-scaling known as Horizontal Pod Autoscaler (HPA) is not limited to managed metrics and custom metrics can also be used to trigger the auto-scaling process.

This article mentions only a few of the main benefits of Kubernetes and its various benefits can be spoken about for days.

What is next?

I’m currently on a journey to learn more about the ever-growing ecosystem of containers, container orchestration and the DevOps culture. Expect to see more articles and open-source contributions. Stay tuned for more!

A look at the ever-changing landscape of modern applications

Posts tagged with: containers