Muhammad Zarak Bin kaleem’s Post

Ingress NGINX is reaching the end of an era — and Gateway API is stepping into the spotlight. 🚀 For nearly a decade, Ingress NGINX has been the silent backbone of Kubernetes traffic, routing billions of requests every single day. But starting March 2026, the core Ingress controller will enter maintenance retirement. Not a shutdown — but a clear signal that the ecosystem is moving on. And what replaces it isn’t just an upgrade… It’s a whole new way of thinking about Kubernetes networking: Gateway API. 🔹 Why Gateway API matters It brings a modern, future-proof model built for real-world complexity: • A clean, layered architecture (Gateway → Route → Policy) • Built-in multi-tenancy and delegation across namespaces • First-class support for HTTP, TCP, UDP, gRPC, WebSockets • Native ways to express mTLS, auth, rate-limiting, retries • A vendor-neutral design aligned with major cloud providers Where Ingress was simple and limited, Gateway API is intentional, flexible, and designed for large environments. No need to panic — your existing Ingress objects won’t break. But now is the right moment to start experimenting, testing, and planning the transition. 🧪 What about you? Have you already started playing with Gateway API? Or are you waiting for the tooling and controllers to mature a bit more? Curious to hear how teams are approaching this migration. #Kubernetes #Ingress #DevOps #CloudNative #SRE #Networking

Today I lost hours to an “AccessDenied” error that wasn’t an access problem. CloudFront + S3 static sites have a sharp edge that AWS hasn’t explained very well. I kept getting this response: <Error>  <Code>AccessDenied</Code>  <Message>Access Denied</Message> </Error> Naturally, I checked:        S3 bucket policy        Origin Access Control (OAC)        CloudFront permissions        IAM conditions Everything was correct. The real issue was a wrong CloudFront Origin Path sourced from git action workflow with site as the bucket root folder. What really happened. CloudFront builds the S3 request like this: Origin Domain + Origin Path + Viewer Request Path. So when my files moved from: /site/index.html to /index.html, but the Origin Path was still /site, CloudFront request, /site/index.html. That object didn’t exist. S3 returned AccessDenied – even though this was really a path mismatch / missing object, not a permission issue. Why does this matter? It matters because the error message sends engineers in the wrong direction, debugging IAM that is already correct. It shows how misleading “AccessDenied” can be in AWS. What I wish AWS would do. Instead of: “AccessDenied”, return something like: “Object not found at resolved origin path” or “Check CloudFront Origin Path configuration”. Clear errors save real engineering time. Lesson Learned CloudFront Origin Path must exactly mirror your S3 folder structure or be empty if your files are at the same bucket root. This is one of those problems you only truly understand after hitting it in live environment. If you have been there too, you know the feeling. #AWS #CloudFront #S3 #DevOps #Infrastructure #Terraform #LearningInPublic

Why Is Nginx So Popular? Nginx has become one of the most widely used web servers in the world — and for good reason. Let’s break down why engineers and companies rely on it so heavily 👇 🔹 High-Performance Web Server Nginx is built on an event-driven, non-blocking architecture, allowing it to handle thousands of concurrent requests with very low memory usage. This makes it much faster and more efficient than traditional thread-based servers. 🔹 Reverse Proxy & Load Balancer Nginx sits in front of backend services and: Hides internal servers Distributes traffic evenly Improves reliability and scalability This is why it’s commonly used in microservices and cloud architectures. 🔹 Powerful Caching Layer Nginx can cache responses and serve them instantly without hitting the application server. ✅ Faster response times ✅ Reduced backend load ✅ Better user experience 🔹 SSL Termination (Offloading) Nginx handles HTTPS encryption and decryption, freeing application servers from heavy cryptographic work and improving overall performance. 🔹 Simple but Powerful Architecture With a master process + worker processes model, Nginx is: Stable Easy to scale Easy to maintain In short: Nginx is popular because it’s fast, lightweight, scalable, and versatile — perfect for modern, high-traffic systems. 💬 Are you using Nginx as a web server, reverse proxy, or load balancer? #Nginx #WebServer #Backend #DevOps #SystemDesign #SoftwareEngineering #Learning

🚀 Start 2026 by shipping, not just planning. Deployed a containerized web server on GCP using Docker + NGINX to host a simple “Happy New Year 2026” site. High-level execution (clean & production-oriented): ✅ Provisioned a Compute Engine VM ✅ Installed & hardened Docker runtime ✅ Pulled website source from GitHub ✅ Ran NGINX container with mounted web content ✅ Exposed service via GCP firewall (port 80) ✅ Verified via public IP Nothing fancy on the UI — but the foundation is solid: Container-first approach No dependency on host config Ready for CI/CD, HTTPS, or scaling Real DevOps is about repeatable deployments, not just “getting it to work.” 🎉 Happy New Year 2026 — building reliable systems, one deployment at a time. #DevOps #GCP #Docker #NGINX #CloudEngineering #Infrastructure #HappyNewYear2026 #BuildInPublic 🔥 Next iteration: CI/CD + HTTPS + load balancing. Keeping it simple, scalable, and production-ready.

This tutorial will guide you through implementing the Gateway API based on Nginx Gateway Fabric, helping you prepare your infrastructure for the post-Ingress era. By Janakiram MSV

𝗖𝗹𝗼𝘂𝗱𝗙𝗿𝗼𝗻𝘁 𝗶𝘀𝗻’𝘁 𝗷𝘂𝘀𝘁 𝗳𝗼𝗿 𝘀𝘁𝗮𝘁𝗶𝗰 𝘄𝗲𝗯𝘀𝗶𝘁𝗲𝘀. When used correctly, CloudFront can: ⚡ Reduce backend load 🚀 Improve API response times 📈 Handle traffic spikes smoothly Many teams still underuse CloudFront and miss out on 𝐫𝐞𝐚𝐥 𝐩𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐚𝐧𝐝 𝐜𝐨𝐬𝐭 𝐛𝐞𝐧𝐞𝐟𝐢𝐭𝐬. 👉 𝐑𝐞𝐝𝐢𝐬 𝐬𝐚𝐯𝐞𝐬 𝐲𝐨𝐮𝐫 𝐝𝐚𝐭𝐚𝐛𝐚𝐬𝐞 👉 𝐂𝐥𝐨𝐮𝐝𝐅𝐫𝐨𝐧𝐭 𝐬𝐚𝐯𝐞𝐬 𝐲𝐨𝐮𝐫 𝐛𝐚𝐜𝐤𝐞𝐧𝐝 & 𝐧𝐞𝐭𝐰𝐨𝐫𝐤 👉 𝐂𝐃𝐍𝐬 𝐚𝐫𝐞𝐧’𝐭 𝐣𝐮𝐬𝐭 𝐚𝐛𝐨𝐮𝐭 𝐜𝐚𝐜𝐡𝐢𝐧𝐠 𝐟𝐢𝐥𝐞𝐬 — 𝐭𝐡𝐞𝐲’𝐫𝐞 𝐚𝐛𝐨𝐮𝐭 𝐬𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐚𝐧𝐝 𝐫𝐞𝐬𝐢𝐥𝐢𝐞𝐧𝐜𝐞. Are you using CloudFront only for static assets, or also for APIs? #AWS #CloudComputing #BackendEngineering #SystemDesign #DevOps

🤔 𝗜𝘀 𝘆𝗼𝘂𝗿 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗜𝗻𝗴𝗿𝗲𝘀𝘀 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝗳𝘂𝘁𝘂𝗿𝗲 𝗿𝗲𝗮𝗱𝘆? With the Ingress NGINX Controller headed for deprecation, platform teams face a real inflection point. Stick with a drop in replacement or invest in Gateway API and modernize traffic management for the long term. This is not a future problem. By March 2026, the clock runs out on fixes, patches, and support. That makes traffic management a strategic decision that needs to be made ASAP. The time to decide is now. You can prioritize short term stability or invest in long term velocity. Ingress still fits simple use cases, but Gateway API is built for multi tenancy, advanced routing, and production scale. Need help? We break down the real tradeoffs and the cleanest path forward in our latest blog. Read it here 👉 https://lnkd.in/gK2AqSKA #Kubernetes #DevOps #CloudNative #GatewayAPI #Infrastructure

I gave myself a $15/month budget to run ARK in production. No managed databases. No load balancers. No NAT Gateway. One VM. Everything runs on it. Quick context: ARK helps engineers organize servers, configs, and troubleshooting logs in one place instead of scattered notes. Last post covered the architecture. This one is about the deployment. At PMG, I build on production infrastructure that's been battle-tested. ARK was my first time owning the full stack, from IAM policies to backup strategies to cost tradeoffs. The first real lesson: trying to build Docker images directly on a 1 GB EC2 instance. Builds hung, then got OOM-killed. I thought I'd misconfigured something. Second failure made it clear, the approach itself was wrong. The fix was obvious in hindsight: GitHub Actions builds the images, pushes to GitHub Container Registry, and EC2 just pulls prebuilt artifacts. Sometimes you learn why patterns exist by breaking them first. Docker Compose was the key to making single-instance work. One EC2 box running Caddy for the React frontend, Go backend, and Postgres—all orchestrated through one compose file. None of this is complicated once you understand it. An EC2 instance is a computer. EBS volumes are persistent storage. Elastic IPs prevent DNS breaks. Security groups are firewall rules. But understanding requires building it yourself at least once. V2 is adding RAG-powered search while staying under $15/month. Ask "how did I fix this error last time?" and get an actual answer from your troubleshooting history. Using Amazon Bedrock for embeddings and S3 Vectors as a low-cost vector store. Repo's public if you want to follow along: github.com/srauf24/ark Live: arkcore.dev #aws #docker #production #softwareengineering

Cloudflare's engineering team has published a detailed breakdown of how they manage hundreds of internal production accounts using Infrastructure as Code, and it's worth reading if you're wrestling with configuration governance at scale. The core problem they faced is familiar to anyone running enterprise infrastructure: manual dashboard changes across multiple accounts inevitably lead to drift, inconsistency, and that particular dread when pushing changes to production. Their solution was to treat every configuration as code, enforce peer review, and automate policy checks before deployment rather than auditing after the fact. Their stack combines Terraform with Atlantis for CI/CD, plus a custom tool called tfstate-butler that encrypts each state file with unique keys to limit blast radius if one is compromised. They've also built around 50 Rego policies using Open Policy Agent that run on every merge request, blocking non-compliant changes before they reach production. Three lessons stood out from their experience. First, onboarding teams proved harder than expected because Terraform fluency varies wildly across engineering organisations. They addressed this with cf-terraforming, a CLI tool that auto-generates Terraform code from existing API state. Second, configuration drift is inevitable when urgent incidents tempt engineers to bypass IaC and edit directly in the dashboard. They now run continuous drift detection against the live API. Third, keeping their Terraform provider in sync with a rapidly evolving product suite was a constant struggle until they moved to auto-generating the provider from their OpenAPI specification. The broader point here resonates beyond Cloudflare's specific tooling: dashboards excel at observability and ad-hoc investigation, but consistent governance at scale requires treating configuration as a software engineering problem with version control, code review, and automated testing. For teams still debating whether the upfront investment in IaC tooling is worth it, this post offers a concrete case study of what "shift left" actually looks like when applied to platform configuration rather than application code. https://lnkd.in/eVvfWZnK #InfrastructureAsCode #Terraform #DevOps #CloudSecurity #PlatformEngineering #SRE