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.

👋 👋 A big thank you to today's sponsor GLADLY AI

You shipped it. It works. Tickets are resolving. So why are customers leaving?

Gladly's 2026 Customer Expectations Report uncovered a gap that most CIOs don't see until it's too late: 88% of customers get their issues resolved through AI — but only 22% prefer that company afterward. Resolution without loyalty is just churn on a delay.

The difference isn't the model. It's the architecture. How AI is integrated into the customer journey, what it hands off and when, and whether the system is designed to build relationships or just close tickets.

Download the report to see what consumers actually expect from AI-powered service — and what the data says about the platforms getting it right.

If you're responsible for the infrastructure, you're responsible for the outcome.

Get the data

Powered by: Jobsurface.com

Browse 488 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 55,000+ Cloud Native Professionals? Let's work together. Advertise With Us

In a microservices architecture, your client doesn't knock on dozens of doors, it knocks on one. That single door is your API Gateway.

The diagram above captures the core idea. A client sends every request to the gateway, which handles the messy cross-cutting concerns: routing requests to the right backend service, enforcing authentication, rate-limiting traffic, and writing an audit log. None of your downstream services need to know who sent the request or why, the gateway already figured that out.

AWS API Gateway is the managed embodiment of this pattern. But the gateway itself is only as strong as the security mechanism bolted in front of it. The moment you open a public endpoint, you need to answer one question: how does the gateway decide who gets through?

AWS offers three fundamentally different answers to that question and understanding when to use each one separates a secure production system from a leaky proof-of-concept.

This is the strictest option. The caller signs every HTTP request using AWS Signature Version 4 (Sig v4), a cryptographic signing scheme that uses the caller's IAM credentials to produce a signature embedded in the request headers.

When the gateway receives a Sig v4-signed request, it sends the headers to IAM to validate the signature and retrieve the caller's IAM policy. That policy is then evaluated against the requested resource. If the policy grants access, the request flows through. If not, the caller gets a 403 Forbidden, no explanation, no retry hint.

IAM policies are also cached at the gateway level to avoid hitting IAM on every single request, which would become a latency bottleneck at scale.

When to use this: Internal AWS-to-AWS communication. Lambda calling API Gateway, EC2 calling API Gateway, a backend service calling another team's API, all perfect candidates.

The caller must be an IAM principal (a role or user), which makes this impractical for anything with end-user browser traffic.

What to watch: You need to grant execute-api:Invoke on the specific API ARN in the IAM policy. Misconfigured resource ARNs are the #1 cause of mysterious 403s in this pattern.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)