👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

✉️ In Today’s Newsletter

Deep Dive:

- The 3 extra factors shaping today’s cloud-native world
- Why DevOps engineers should care about the 15-Factor App
- Look in to Telemetry, AuthN/AuthZ, and API-First factors.

Kubernetes Concepts:

- A look in to Kubernetes Body Based Routing
- Kubernetes HPA Tolerance Levels
- Mount OCI Image as Volume in Kubernetes Pods

Guides & How-tos:

- GitHub Actions OIDC with AWS
- Hands on Guide for ExternalDNS on EKS
- Running MySQL on Kubernetes Using Operator

Interesting Reads:

- Pinterest’s Scalable Spark Architecture on AWS EKS…and more
- AWS Cloud Control API MCP Server
- Tuning Linux Swap in Kubernetes 1.34

🧰 Remote Job Opportunities

1. Turing: DevOps Engineer

2. Selina: DevOps Engineer

3. Thecreditpros: Senior AWS DevOps Engineer

4. Greenlight: Senior Engineer, Production Operations

5. Acquia: Associate Site Reliability Engineer

6. Stryker: Senior DevOps Engineer (Hybrid)

The 12 factor app methodology was introduced by Heroku in 2011.

It acts as a set of standards when DevOps engineers and developers work together when taking microservices from dev to prod.

Why should this matter to a DevOps Engineer?

When developers and platform/AppOps teams work together, things can get messy if there are no common rules. Everyone may do things differently, which leads to surprises, delays, and even broken deployments.

You can look at the 15-Factor App method as a set of rules (like a playbook) that both developers and platform teams agree to follow.

In short, the 15-Factor method is about a shared set of rules or standards that keep Dev and Ops in sync, so apps are easier to build, secure, deploy, and run.

And the best part?

Even if you are working across multiple project teams in the same organization, everyone follows the same playbook, so collaboration stays smooth and predictable.

12 Factor to 15 Factor Apps

While the original twelve factors still remain relevant, the following three additional factors have been added to the modern cloud-native applications by Kevin Hoffman in his book Beyond the Twelve-Factor App

1. Telemetry

2. Authentication & Authorization

3. API First

Lets understand what it really means.

13. Telemetry

The 12-factor logs idea is not enough for todays distributed systems where observability plays a key role.

When it comes to observability, Telemetry adds tracing and metrics to answer why things break, not just what broke.

For example,

When you have 1000 users hitting your app, you need a way to know what is really happening inside. Just looking at logs is not enough. This is where telemetry comes in.

Lets look at two examples where telemetry helps.

1. Response times spiking: metrics + traces will show you if requests are taking longer than usual. For example, API calls that normally finish in 100ms are now taking 2 seconds.

2. Service call stuck: Telemetry can show that a downstream service (like the payment API or database) is not responding, and your requests are timing out.

To get started,

Add OpenTelemetry SDK/auto-instrumentation. Emit traces for each request, metrics like request duration and error rate, and logs with the trace ID included.

Use an OTel Collector DaemonSet to receive data and export to Prometheus (metrics), Jaeger (traces), and Loki (logs)

14. Authentication & Authorization

In the original 12-factor app guidelines, security was not given much direct attention. The focus was more on code, config, dependencies, logs, and deployment practices.

Security was assumed to be handled somewhere else.

But in the 15-factor update, security got pulled into the spotlight. The update made security (auth/authz) a first-class concern, something you must design and implement as part of the app itself.

Every modern cloud app must treat identity and permissions as a built-in feature, not an afterthought.

You cant just rely on the network being “private” or trust everything inside your cluster. APIs and services should have strong, consistent auth (who you are) and authz (what you are allowed to do).

So in 15-factor way, every request must carry a verified identity token (like OAuth2/JWT). The service validates it before doing anything.

15. API First

First you need to understand what is an API contract.

An API contract is like a formal agreement between two systems. For example, your frontend app and your backend service.

It clearly dictates,

• What requests are allowed (endpoints, methods like GET/POST).

• What data you must send (query params, body fields, headers).

• What response you will get back (status codes, JSON structure, error messages).

The API First factor states that, design the API contract first, then build everything (services, UI, docs) around it. Treat the API like a product.

In short, API First means, before coding, write an OpenAPI spec for /orders, /orders/{id}, error shapes, and versioning rules.

Body Based Routing

Body-based routing is a traffic management where the API gateway (or proxy) looks inside the request body, meaning the actual data you send, like JSON and then decides where to send the request.

Body-based routing is particularly useful in LLM inference, multi-model serving, or custom workflows where one URL might serve many different kinds of requests based on what is inside the request body.

👉 Read the full guide here

HPA Tolerance Levels

HPA Tolerance Levels is a new alpha feature in Kubernetes v1.33 that allows you to customize how sensitive your Horizontal Pod Autoscaler (HPA) is to metric changes

This means you can make HPA respond faster when traffic increases (scale up quickly) and wait longer when traffic slows down (avoid scaling down too fast).

👉 Read the full step-by-step guide here

Mount OCI Image as Volume in k8s Pods

Kubernetes version 1.31 has introduced a new alpha feature that allows you to use OCI image volumes directly within Kubernetes pods. In Kubernetes version 1.33, it has been changed to a beta feature.

This is particularly useful for ML projects dealing with LLMs.

However, you can use this feature for any workload that benefits from shipping data inside an image (datasets, configs, static assets, or even tools)

👉 Read the full step-by-step guide here

GitHub Actions OIDC with AWS

OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in AWS without needing to store AWS credentials as long-lived GitHub secrets.

This means that a GitHub Actions workflow can request a short‑lived OIDC token from GitHub, present it to AWS IAM, and get a temporary role. There is no need to store access keys in secrets.

👉 Read the full step-by-step guide here

Automating DNS With External DNS on EKS

When you work on Kubernetes projects, In most cases, you need to expose services using an internal or Public DNS service.

In many organizations, this is usually done manually by the DevOps or network team. But you can automate this process using ExternalDNS (If Network/Sec team permits it 😀 )

ExternalDNS is a simple tool that manages DNS records for you and keeps them in sync with your Kubernetes Ingress or Service objects.

👉 Read the full step-by-step guide here

Managing MySQL on Kubernetes With Operator

Let's say you are managing a MySQL cluster manually on Kubernetes. It can quickly become complex.

For example, you need to provision persistent volumes, configure StatefulSets, handle secrets, and set up replication and failover mechanisms.

MySQL Operator automates the MySQL cluster creation using Kubernetes objects (Custom Resources, Statefulset, etc) and manages a MySQL cluster for you.

👉 Read the full step-by-step guide here

Keep Yourself Updated

1. AWS Cloud Control API MCP Server: The CCAPI MCP Server lets developers manage AWS resources with plain language commands, instead of writing configs. It uses the AWS Cloud Control API, which supports create, read, update, delete, and list actions for 1,200+ AWS resources.

2. Tuning Linux Swap for Kubernetes: Kubernetes v1.34 is bringing NodeSwap support, letting you use swap space on Linux nodes. This blog breaks down the key kernel tweaks you need to avoid OOM crashes and keep your clusters running smoothly.

3. Pinterest’s Scalable Spark Architecture on AWS EKS: Pinterest replaced its old Hadoop setup (called Monarch) with Moka to improve efficiency, cost savings, and flexibility. The shift highlights how modern companies are moving away from legacy systems to cloud-native, containerized, and Kubernetes-based architectures.

4. How Top Tech Teams Use AI to Boost Dev Productivity: AI is not a magic solution, but when applied right, it can 10x developer experience and productivity. Top tech teams like Slack, Shopify, and Pinterest are using AI to fix real developer pain points, from test migrations to flaky code.

2 Ways I Can Help You

1. Kubernetes & CKA Course: Master Kubernetes with real-world examples and achieve CKA Certification with my Comprehensive Course.

2. CKA Exam Practice Questions & Explanations: 80+ practical, exam-style scenarios designed to help you pass the CKA exam with confidence.