TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
Cloud attacks have a new entry point. It's your running applications.
That’s why a new category is emerging: Cloud Application Detection and Response (CADR).
This guide breaks down what CADR is, why runtime is the only place real attacks can be detected, and how security teams are protecting applications, cloud infrastructure, and AI systems in production.
If you’re responsible for securing modern cloud workloads, this is a concept you’ll want to understand.
👀 Remote Jobs
Trust Wallet is hiring a Senior Platform Engineer
Remote Location: Worldwide
Canonical is hiring a Cloud Engineering Manager
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
Looking to promote your company, product, service, or event to 48,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
When to Use Event Driven vs Containerized Architectures in AWS
Every AWS architecture decision starts with the same question: what is the shape of the work? Some work arrives in a steady stream of requests that need immediate responses. Some work arrives in bursts and can be processed asynchronously. Some work is tightly coupled and needs shared state. Some work is completely independent and benefits from isolation. The architecture you choose should match the shape of the work, not the other way around.
Two architectural patterns dominate modern AWS deployments.
Event driven architectures use Lambda, SQS, SNS, and EventBridge etc., to process work asynchronously, reacting to events as they arrive.
Containerized architectures run long processes on ECS or EKS, handling requests synchronously and maintaining their own state.
Most production systems use both, but knowing when each one earns its place requires understanding what each pattern actually optimises for.
The Architectural Split: Monolith vs Microservices
Before choosing between event driven and containerized, teams first navigate the monolith to microservices transition. This transition is what introduces the complexity that makes the choice between patterns meaningful.
A monolith bundles frontend, backend logic, and storage into a single deployable unit. Everything shares a process, a database, and a deployment cycle. Changes to any part require redeploying the whole thing. This is not inherently bad. For small teams and early-stage products, the operational simplicity of one thing to deploy and one thing to monitor is genuinely valuable.
Microservices split that monolith along functional boundaries. Each service owns its domain, its deployment cycle, and its database. An API Gateway or Backend for Frontend layer sits in front, routing requests to the right service. Services that previously shared a database now communicate over the network.
This split introduces a new problem: services need to talk to each other. In a monolith, a function call between two components costs nanoseconds and happens in-process. Between microservices, that same interaction crosses a network boundary, introduces latency, and adds failure modes.
How you handle that inter service communication is exactly where the choice between event driven and containerized patterns becomes consequential.
The Microservices Complexity Trap
The transition to microservices solves some problems and creates others. The one that causes the most operational pain is uncontrolled fragmentation.
Imagine a spectrum.
On the far left, your system has a manageable number of services:
🟨 ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️
On the far right, the system has fragmented into too many services:
⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ 🟦
The red square on the left is where microservices worked well initially:
🟨 ⬜️ ⬜️ 🟥 ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ 🟦
The green square is where the system ended up, due to uncontrolled growth:
🟨 ⬜️ ⬜️ 🟥 ⬜️ ⬜️ ⬜️ ⬜️ ⬜️ 🟩 ⬜️ ⬜️ 🟦
The gap between 🟥 and 🟩 is the misaligned complexity.
More services than the team can reason about, more inter service communication than the network can reliably handle, and more deployment coordination than the CI/CD pipeline was designed for.
This complexity gap is where architecture decisions have the highest leverage. A containerized service that talks synchronously to eight other services is fragile in ways that an event driven service producing events that others consume is not. Getting the communication pattern right before the service count grows is easier than refactoring after the complexity is already embedded.
Event Driven Architecture on AWS
Event driven architecture decouples the producer of an action from the consumer of that action. A service does its work, emits an event, and stops caring what happens next. Other services subscribe to events they care about and react independently.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
Paid subscriptions get you:
• Access to archive of 250+ use cases
• Deep Dive use case editions (Thursdays and Saturdays)
• Access to Private Discord Community
• Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
• Quarterly 1:1 'Ask Me Anything' power session
