In this blog, I’m going to walk you through how I deployed Ansible AWX on a Kubernetes cluster using Helm. This was one of the most hands-on projects I’ve worked on — it involves setting up the K8s cluster from scratch, installing the container runtime, deploying Helm, and finally getting AWX up and running. I also hit a few real errors along the way, so I’ll share exactly how I fixed them.
It was one of those projects that looks simple on paper but turns into a chain of small problems once you actually start doing it.
Here’s the overall flow I followed:
The goal was pretty straightforward:

• Set up a Kubernetes cluster on Ubuntu 22.04
• Install containerd
• Get Helm working
• Deploy AWX using the AWX Operator
• Fix whatever broke along the way (this part took the longest 😅)

Setting Up the Kubernetes Cluster on Ubuntu 22.04
Before anything else, I want to quickly explain the two types of nodes in a K8s cluster since this matters for the setup:
Master Node — manages the control plane, API calls, pods, services, and everything else in the cluster.
Worker Node — runs the actual containers. Pods can spread across multiple worker nodes for better resource management.
Step 1 — Update and Upgrade (All Nodes)
I started by logging in as root and running updates on all nodes:

hostnamectl set-hostname siri-awx-01 # run on master node
hostnamectl set-hostname siri-awx-02 # run on worker node
exec bash

apt update
apt upgrade

Step 2 — Disable Swap
swapoff -a
sed -i ‘/ swap / s/^(.)$/#1/g’ /etc/fstab
**Step 3 — Load Kernel Modules*
tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

Step 4 — Configure Kernel Parameters
tee /etc/sysctl.d/kubernetes.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sysctl –system

Installing Containerd Runtime (All Nodes)
apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmour -o /etc/apt/trusted.gpg.d/docker.gpg

add-apt-repository “deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable”

apt update
apt install -y containerd.io

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sed -i ‘s/SystemdCgroup = false/SystemdCgroup = true/g’ /etc/containerd/config.toml

systemctl restart containerd
systemctl enable containerd

Installing Kubernetes Components (All Nodes)
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg –dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo ‘deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /’ | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Initialising the Cluster (Master Node — siri-awx-01 Only)

systemctl enable kubelet && systemctl start kubelet
kubeadm init

$:mkdir -p $HOME/.kube
$:cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$:chown $(id -u):$(id -g) $HOME/.kube/config

Tip: If you forget to save the kubeadm join output, regenerate it with:
bashkubeadm token create –print-join-command

$kubectl get nodes

Join Worker Node (siri-awx-02)
Run this on siri-awx-02 (use your actual token from kubeadm init output):

kubeadm join 192.168.237.144:6443 –token uhkvxh.mjp6aiyhy18vaxh0
–discovery-token-ca-cert-hash sha256:c0200907cc68957eea6d9cc4ad314282fb58ac92bceef2416e8212040441f130

Install Calico Network Plugin (siri-awx-01 Only)

curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml -O
kubectl apply -f calico.yaml
kubectl get nodes
kubectl get pods -n kube-system

Installing Helm

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Deploying Ansible AWX Using Helm

helm install ansible-awx-operator awx-operator/awx-operator -n awx –create-namespace
kubectl get pods -n awx

Setting Up Storage — StorageClass, PV and PVC
local-storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-storage
namespace: awx
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

kubectl create -f local-storage-class.yaml
kubectl get sc -n awx

pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: postgres-pv
namespace: awx
spec:
capacity:
storage: 10Gi
volumeMode: Filesystem
accessModes:

• ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
  path: /mnt/storage # Mount point should available on worker node
  nodeAffinity:
  required:
  nodeSelectorTerms:
  • matchExpressions:
    • key: kubernetes.io/hostname
      operator: In
      values:
      • siri-awx-02 # worker node hostname

pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-13-ansible-awx-postgres-13-0
namespace: awx
spec:
storageClassName: local-storage
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 2Gi

kubectl apply -f pv.yaml
kubectl create -f pvc.yaml
kubectl get pv,pvc -n awx

Deploying AWX

kubectl create -f ansible-awx.yaml

kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager -n awx

Accessing the AWX Web Interface

kubectl expose deployment ansible-awx-web –name ansible-awx-web-svc –type NodePort -n awx
kubectl get svc ansible-awx-web-svc -n awx

Get admin password

kubectl get secret ansible-awx-admin-password -o jsonpath=”{.data.password}” -n awx | base64 –decode ; echo

AWX is now accessible at http://: — in my case port 32418. Log in with username admin and the decoded password.

Errors I Hit and How I Fixed Them
Error 1 — Node Taint Issue (Pods Stuck in Pending)

Warning FailedScheduling 2m37s default-scheduler

0/1 nodes are available: 1 node(s) had untolerated taint
{node.kubernetes.io/not-ready: }

First, check the actual taint on your node:
kubectl describe node siri-awx-01 | grep Taints

Taints: node.kubernetes.io/not-ready:NoSchedule

Remove it

kubectl taint nodes siri-awx-01 node.kubernetes.io/not-ready:NoSchedule-

node/siri-awx-01 untainted

After removing the correct taint, pods started coming up properly.

Error 2 — ImagePullSecret Error
FailedToRetrieveImagePullSecret Unable to retrieve some image pull secrets
(redhat-operators-pull-secret); attempting to pull the image may not succeed.

Debug with:
bashkubectl logs awx-operator-controller-manager-6586fccbdd-xtdvj -n awx
kubectl get events -n awx

Fix — edit the deployment and comment out the imagePullSecrets section:

kubectl edit deployment awx-operator-controller-manager -n awx
Kubernetes automatically picks up the changes. No manual restart needed.
Accessing the AWX Web Interface
kubectl expose deployment ansible-awx-web –name ansible-awx-web-svc –type NodePort -n awx
kubectl get svc ansible-awx-web-svc -n awx

Get admin password

kubectl get secret ansible-awx-admin-password -o jsonpath=”{.data.password}” -n awx | base64 –decode ; echo

AWX is now accessible at http://: — in my case port 32418. Log in with username admin and the decoded password.

Final Verification
Once logged in, I ran a demo playbook to make sure everything was wired up correctly. Seeing that first successful job run in the AWX UI after all of this setup was genuinely satisfying.

This wasn’t a smooth “follow steps → done” kind of project.

It was more like:

set up cluster → something breaks
fix networking → something else breaks
fix storage → something else breaks again
finally get AWX running → feels like victory

But I did learn a lot about how Kubernetes actually behaves when things aren’t ideal.

If you’re doing this yourself and hit weird issues, you’re probably not alone—most of the fixes I found were pieced together from random threads and trial-and-error.

Still worth it though.

• happy to help!
  — Sireesha

In this beginner walkthrough based on the Microsoft Learn guided exercise we configure a private Azure Blob Storage account for internal company documents.

Imagine your company stores HR files, contracts, or financial reports. You need them available 24/7, protected from public access, and cost-efficient to store long-term. That’s exactly what this guide sets up.

What we will build:
•A private storage account with GRS redundancy
•A restricted blob container for internal documents
•A time-limited SAS token for partner access
•Automated lifecycle rules to move blobs to Cool tier after 30 days
•Cross-account object replication for public website backup

Overview
The solution uses a single private storage account containing two blob containers: one for internal documents and one named ‘backup’ that receives replicated content from the public website storage account.

In the portal, search for and select Storage accounts.
Select + Create.

Select the Resource group created in the previous lab.

Set the Storage account name to private. Add an identifier to the name to ensure the name is unique. Tip : Storage account names must be 3–24 characters, all lowercase, no spaces or special characters. Try something like privatecompany2025. Azure will tell you if it’s already taken.

Select Review, and then Create the storage account.

Wait for the storage account to deploy, and then select Go to resource.

Configure the appropriate level of redundancy.

In the storage account, in the Data management section, select the Redundancy blade.
Ensure Geo-redundant storage (GRS) is selected.
Refresh the page.

What is GRS? Geo-Redundant Storage automatically copies your data to a second Azure region. So if a data center goes down, your files are still safe and accessible.

Review the primary and secondary location information.
Save your changes.

In the storage account, in the Data storage section, select the Containers blade. Select + Container.
Ensure the name of the container is private.
Ensure the Public access level is Private (no anonymous access).

Why Private? Setting the container to Private means no one can view or download files using just a URL. They need a key or a special token. This is what keeps internal company files away from the public internet. As you have time, review the Advanced settings, but take the defaults. Select Create.

For testing, upload a file to the private container. The type of file doesn’t matter. A small image or text file is a good choice. Test to ensure the file isn’t publically accessible.

Select the container.
Select Upload.
Browse to files and select a file.
Upload the file.
Select the uploaded file.
On the Overview tab, copy the URL.
Paste the URL into a new browser tab.

Verify the file doesn’t display and you receive an error. You should see a ResourceNotFound or 403 (Forbidden) error, this is correct! It confirms your container is properly locked down.

What is a SAS Token? A Shared Access Signature is like a temporary visitor badge. Instead of giving your partner your account password, you generate a special link that expires after a set time and only allows the permissions you choose (e.g., read-only). Once it expires, the link stops working automatically.

An external partner requires read and write access to the file for at least the next 24 hours. Configure and test a shared access signature (SAS).

Select your uploaded blob file and move to the Generate SAS tab- Select Generate SAS token and URL. Copy the SAS URL immediately. Azure will not show it again once you close this panel.Treat it like a password; don’t share it publicly. In the Permissions drop-down, ensure the partner has only Read permissions.Verify the Start and expiry date/time is for the next 24 hours or time requested.

Copy the Blob SAS URL to a new browser tab.
Verify you can access the file. If you have uploaded an image file it will display in the browser as you have seen in the screenshot. Other file types will be downloaded.

Configure storage access tiers and content replication.

To save on costs, after 30 days, move blobs from the hot tier to the cool tier. Hot vs Cool Storage: Azure charges you based on how often data is accessed. Hot tier is for files you access frequently, faster but pricier. Cool tier is for files you rarely touch — slower but cheaper. Lifecycle rules automate the switch so you don’t have to do it manually.

Return to the storage account.
In the Overview section, notice the Default access tier is set to Hot. In the Data management section, select the Lifecycle management blade. Select Add rule.Set the Rule name to movetocool.
Set the Rule scope to Apply rule to all blobs in the storage account.
Select Next.Ensure Last modified is selected.Set More than (days ago) to 30.In the drop-down select Move to cool storage.

As you have time, review other lifecycle options in the drop-down.
Add the rule.The public website files need to be backed up to another storage account.

In your storage account, create a new container called backup. Use the default values. Refer back to Lab 02a we did if you need detailed instructions.

Navigate to your publicwebsite storage account. This storage account was created in the previous exercise. If you don’t already have a public storage account, create one using the same steps in Step 1 above, and name it publicwebsite. Create a container inside it called public and upload any file to it.

In the Data management section, select the Object replication blade. Select Create replication rules.
Set the Destination storage account to the private storage account.
Set the Source container to public and the Destination container to backup. Once done you can click create.

That’s it — we’ve successfully concluded that the necessary steps needed to create a redundant storage account.

Great work! Here is what you have built:

Feature What It Does

GRS Storage Account – Keeps data safe across regions.
Private Container – Blocks public internet access.
SAS Token Grants time -limited partner access Lifecycle
Rule – Saves cost by moving old data to Cool tier Object Replication Auto – backs up your public website files.

Next steps: When you have time you could Explore Azure RBAC(https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) to control who in your team can manage storage, or try Azure Key Vault to manage SAS keys securely.

I did truly appreciate any insights or additions that could help enhance this article!

title: “Welcome to the Distributed Systems World — The Challenges Nobody Warned You About”
published: false
description: A friendly tour of the six big headaches that come with distributed systems, with small .NET examples.
tags: distributedsystems, dotnet, architecture, beginners
series: Fundamentals of Distributed Systems
cover_image:

You wrote your first ASP.NET MVC app. Controller, service, a SQL database — beautiful. It runs on your laptop, it runs on one server, life is good.

Then somebody says the word “microservices” in a meeting and suddenly there’s talk of replication and CAP theorems and consensus algorithms named after Greek philosophers. Cool, cool, cool. Everyone is nodding. You are also nodding.

This series is for that moment. We’re going to walk through the world of distributed systems together — slowly, with pictures, with small bits of .NET code, and without pretending any of it is obvious. By the end you’ll actually know what those words mean, and more importantly, you’ll know why they exist.

This first article is the lay of the land: what a distributed system even is, and the six big challenges that show up the moment you have more than one machine.

Let’s go.

So… what is a distributed system?

The textbook definition is annoying, so here’s the human one:

A distributed system is a bunch of computers that work together so that, to the user, they look like one computer.

That’s it. That’s the whole idea.

Think about what happens when you order food on an app. You tap a button. Two hundred milliseconds later you see “Order placed.”

In that 200 ms, this happened behind the scenes:

• A load balancer picked one of dozens of identical web servers to handle your tap
• Your request hit a payments service that might literally be in another country
• The order got written to a database that’s split across many machines
• A message landed in a queue telling the restaurant’s screen to start beeping
• A cache somewhere updated so the next person sees the right available stock

A whole little conversation between machines. You saw one button. They had a committee meeting.

That conversation — coordinating many independent machines to behave like one trustworthy system — is the entire field of distributed systems. And it is genuinely hard.

Why don’t we just… not?

Fair question. One machine is way simpler. So why does anyone leave?

Three reasons:

1. Scale. One machine has a ceiling. Best CPU, max RAM, fastest disk — there’s still a top. The moment your traffic punches through it, your only move is more machines.

2. Availability. Single machines die. Hardware fails, kernels panic, somebody trips on a power cable. If your whole app lives on one box, your whole app dies with it. With many, the survivors keep serving.

3. Geography. Light is fast but not infinite. A user in Tokyo hitting a server in Virginia waits roughly 150 ms just for the round trip — before the server does any work. To feel “instant” worldwide, you need machines close to people.

So we go distributed. And in exchange we inherit every problem in the rest of this article. Distribution is not free. You’re trading simplicity for capability.

Now, the challenges.

Challenge 1: The network is a liar

Inside one process, when you call a method, it works. The CPU doesn’t “lose” your function call. Methods don’t sometimes arrive twice. Life is sane.

The network is not sane.

The moment your code talks to another machine, your message can be:

• Lost — never arrives, no error, no nothing
• Delayed — arrives five seconds after you gave up waiting
• Duplicated — the same request lands twice (and your “charge the credit card” endpoint runs twice 🙃)
• Out of order — request #2 arrives before request #1

There’s a famous thought experiment called the Two Generals Problem: two generals on opposite hills need to attack at the same time. They send messengers through enemy territory. The brutal twist: there is mathematically no way for both to be 100% sure the other one got the message. Not “hard.” Actually impossible.

That’s the network. Every cross-machine call lives with that uncertainty.

Here’s what this looks like in practice. The bad version we’ve all written:

// Pretending the network is reliable. It isn't.
var result = await _httpClient.GetAsync("/api/orders/42");
var order = await result.Content.ReadFromJsonAsync<Order>();

The version that respects reality:

try
{
    using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(3));
    var result = await _httpClient.GetAsync("/api/orders/42", cts.Token);
    result.EnsureSuccessStatusCode();
    return await result.Content.ReadFromJsonAsync<Order>();
}
catch (TaskCanceledException)   { /* timed out — now what? retry? fail? */ }
catch (HttpRequestException)    { /* the connection died — same question */ }

Notice the comments. The catch blocks aren’t really about logging — they’re about decisions. Do I retry? How many times? If I retry a “charge card” call, am I charging twice?

We’ll spend a whole article on this later — timeouts, retries with backoff, idempotency keys, circuit breakers. The toolbox for living with a lying network.

For now, the takeaway is just: the network will betray you. Code defensively.

Challenge 2: Many copies, one truth

Okay, so now you’ve got many machines holding your data. That’s great — if one dies, the others still have it. But it creates a new problem nobody warned you about.

If I write X = 5 to machine A, and you read X from machine B before A has told B about the change, what do you see?

The old value? The new one? An error? Pick one and you have to live with the consequences.

The standard solution is a pattern called leader-follower replication, and underneath it sits a family of algorithms called consensus — Paxos, Raft, Zab. Different names, same vibe:

1. One node is elected the leader. Everybody agrees on who it is.
2. All writes go through the leader. No exceptions.
3. The leader writes the change to its own log, then ships it to all followers.
4. The leader waits until the majority of followers say “yep, got it.”
5. Then it commits and tells the client “done.”

That “majority” rule is the magic. It’s called a quorum, and it guarantees that two conflicting decisions can never both win — even when some machines crash, even when the network is being weird.

The cool part? You’re already using this. You just don’t think about it:

• SQL Server Always On availability groups → leader-follower
• PostgreSQL streaming replication → leader-follower
• MongoDB replica sets → leader-follower
• Kafka ISR (in-sync replicas) → leader-follower-ish

Same picture, different sticker.

Challenge 3: How do you grow?

Traffic doubles. Then doubles again. You have two moves:

Scale up (vertical) — make the machine bigger. More CPU, more RAM, faster disk. Your code doesn’t change at all. Easy.

The downside? There’s a biggest machine on Earth, and you can hit it. Also, no matter how huge it is, it’s still one machine. When it dies, everything goes with it.

Scale out (horizontal) — add more machines and split the work across them. Growth is basically unlimited. One dies? The others shrug and keep going.

The downside? Now your code has to handle coordination. State, sessions, locks, ordering — all the things that were free on one machine now need real engineering.

For an ASP.NET MVC app, scaling out usually means three things:

Web tier: run many copies of your app behind a load balancer. Easy if your controllers are stateless. The classic gotcha is in-memory session — works perfectly with one server, breaks horribly with two. The fix:

// Program.cs — sessions that survive across many instances
builder.Services.AddStackExchangeRedisCache(o =>
{
    o.Configuration = builder.Configuration.GetConnectionString("Redis");
});
builder.Services.AddSession();
// Now any web server can serve any user, any time.

Service tier: break the monolith into smaller services that scale independently. Maybe payments needs 10× the instances and search needs 2×. You can’t do that when they’re all one app.

Data tier: read replicas for read-heavy workloads, and partitioning for write-heavy ones — which is the next challenge.

Challenge 4: When the load isn’t fair

So your data outgrew one machine. You split it across many — this is called partitioning (or sharding, same thing). A router decides which machine handles which request, usually by hashing some key like userId.

Beautiful. In theory.

In practice, here’s what happens. You shard your users across three partitions. Then one influencer with 50 million followers does a livestream. Every request involving that user — their profile, their feed, their comments, their everything — slams partition #2. Partition #1 is bored. Partition #3 is napping. Partition #2 is on fire.

This is the hot partition problem, and it’s one of the most common ways distributed systems fail in production. Not because the total load is too high. Because the load is uneven.

How do you fix it? A few moves:

• Pick a high-cardinality key. userId is great. country is terrible (good luck when one country has 90% of your traffic).
• Hash the key. Don’t shard by userId directly — shard by hash(userId). The hash spreads things out evenly.
• Split the hot keys. For known whales, write their data across sub-partitions (userId#1, userId#2, …). This is called write-sharding.
• Put a cache in front. Hot reads never even hit the database.

We’ll dedicate a whole article to this — consistent hashing, range vs. hash sharding, the nightmare joy of rebalancing data while the system is still serving traffic. It’s a deep topic.

Challenge 5: Testing this stuff is genuinely brutal

A bug in a regular app is a bug. A bug in a distributed system is a bug that:

• Only shows up under load
• Only on machine #17
• Only after it’s been running for 11 days
• Only when the network adds 200 ms of latency
• At 3 AM
• During a holiday

This is why people obsess over the testing pyramid:

• Many unit tests at the bottom. Fast, pure logic, no I/O. xUnit or NUnit. They run in milliseconds. They catch the dumb stuff before it leaves your laptop.
• Some integration tests in the middle. Your code talking to a real database, a real cache, a real queue. Slower, more useful.
• A few end-to-end tests at the top. The whole system, real browser, real network. Playwright is the go-to. Slow, expensive, but they catch the things nothing else can.

The ratio matters. 70/20/10 is a healthy default. Flip it (lots of E2E, few units) and your build takes 45 minutes and everyone gives up on running tests.

A really clean trick in .NET is TestContainers — it spins up actual SQL Server, Redis, Kafka, whatever, in Docker, just for your test run:

var db = new MsSqlBuilder()
    .WithImage("mcr.microsoft.com/mssql/server:2022-latest")
    .Build();

await db.StartAsync();
// Run integration tests against a *real* SQL Server.
// When tests finish, the container disappears.

No more “works on my machine because I have SQL Server installed but Jenkins doesn’t.”

And beyond normal tests, distributed systems need chaos testing — deliberately killing nodes, dropping packets, freezing clocks. Netflix made this famous with Chaos Monkey. We’ll cover it in the resilience article.

Challenge 6: Shipping is half the job

Here’s the thing nobody tells you when you start: writing the code is maybe half the work. The other half is keeping it running 24/7 across all those machines.

You need three things working together:

A CI/CD pipeline. Every commit gets built, tested, packaged into a container, and deployed automatically. GitHub Actions, Azure DevOps, GitLab CI — pick one. The rule is: humans are not allowed to SSH into production and “just fix it.” That way lies madness.

Observability — the three pillars. When something breaks in production at 2 AM, you need to know what broke and why, fast:

• Logs — what happened. Use Serilog with structured JSON output, not Console.WriteLine.
• Metrics — numbers over time. CPU, requests per second, error rate, p95 latency. Prometheus, Datadog, Application Insights.
• Traces — one user request followed across every service it touched. OpenTelemetry is the standard.

The OpenTelemetry setup is honestly absurd how easy it is:

// Program.cs — distributed tracing in three lines
builder.Services.AddOpenTelemetry()
    .WithTracing(t => t
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddSqlClientInstrumentation()
        .AddOtlpExporter());

Now every request through your MVC app produces a trace that shows every outgoing HTTP call and SQL query, with timings. When someone complains “the page is slow,” you stop guessing and start looking.

Alerting and on-call. Metrics are useless if nobody’s watching. You set thresholds, route alerts to Slack / PagerDuty / Opsgenie, and someone is on call to respond. This is honestly more of a culture problem than a tech problem, but we’ll get into it.

Quick recap

Six challenges. None of them go away. All of them are solvable.

The honest summary: distributed systems aren’t magic, they’re just a long list of trade-offs. Once you see the trade-offs clearly, the technology choices start making sense.

What’s next

Next article we dig into communication between services — synchronous (REST, gRPC) vs. asynchronous (queues and events). When to use which, and we’ll build a small ASP.NET MVC app that uses both.

After that: data and storage, the CAP theorem (without the confusing diagrams), resilience patterns, and observability in depth.

If something in this article felt fuzzy — good. That means we have something to dig into. Drop a comment with the challenge you want explored first and I’ll bump it up the queue.

See you in part 2. 👋

Follow the series for more — every article = simple language, lots of diagrams, small .NET examples.