Sumit Kumar’s Post

Beyond Hosting: The Evolution of the Cloud Native Ecosystem. Cloud computing has shifted from being a simple storage solution to becoming a complex, automated engine. Today, the challenge isn't just "being on the cloud," but managing the immense complexity of modern infrastructure without overwhelming your operations team. The Core Pillars of Modern Infrastructure: -Declarative Provisioning: Using Infrastructure as Code (IaC) with tools like Terraform or OpenTofu to ensure environments are repeatable and immune to manual error. -Container Orchestration: Leveraging Kubernetes to manage the lifecycle of applications, ensuring they are self-healing and highly available. -Continuous Delivery: Transitioning to GitOps and automated pipelines (CI/CD) where every change is tested, scanned, and deployed without human intervention. -Observability and Insights: Moving beyond basic monitoring to deep observability using the LGTM stack (Loki, Grafana, Tempo, Mimir) to understand system behavior in real-time. The objective is to create an environment where infrastructure is invisible - a silent, powerful foundation that allows engineering teams to focus entirely on innovation rather than troubleshooting. #CloudNative #DevOps #SRE #Infrastructure #Kubernetes #Automation #TechTrends

I’ve published a new, production-focused article on deploying Keycloak 26.5.0 in a High Availability (HA) setup, designed for real-world enterprise environments. The article walks through an HA-first architecture focusing on reliability, scalability, and operational readiness. Key topics covered include: High-availability Keycloak architecture Infinispan clustering using JDBC_PING PostgreSQL-backed cluster discovery Secure HTTPS configuration Load balancer integration for public and internal access Operational scripts and systemd service management Production best practices for stability and scalability This guide is intended for teams running Keycloak as part of enterprise IAM, microservices platforms, or API gateway ecosystems, and aims to provide a practical, deployment-ready reference. You can read the full article here: https://lnkd.in/d-YSgVx2 I welcome feedback and discussion, especially insights from real-world production deployments. #Keycloak #IAM #DevOps #Security #HighAvailability #Authentication #Cloud #PlatformEngineering

This installment focuses on deploying real services into a previously bootstrapped cross-cluster EKS mesh using App Mesh and Cloud Map. You’ll walk through setting up two demo microservices—one in each EKS cluster—with automatic Envoy sidecar injection to integrate them into the mesh. The process involves defining virtual nodes, virtual services, and routers, followed by registering services with Cloud Map for dynamic DNS resolution. You’ll verify communication from one cluster to the other via HTTP calls and observe how requests are routed seamlessly across regions through the shared service mesh. With observability hooks into AWS X-Ray and Prometheus, you’ll also validate traces and metrics to ensure everything is working as expected. This step confirms your hybrid, multi-cluster architecture is functionally integrated and ready for secure, production-ready traffic management. #aws #eks #appmesh #cloudmap #servicemesh #kubernetes #crosscluster #envoyproxy #microservices #xray #prometheus #hybridcloud #observability #multiregion #devops #sre

Completed Kubernetes: Cloud-Native Ecosystem on LinkedIn Learning - a solid deep dive into what actually surrounds Kubernetes in real-world platforms. This wasn’t about “just running pods.” It was about understanding how Kubernetes fits into a broader cloud-native stack. Key takeaways: The role of CNCF and why Kubernetes thrives as an open ecosystem How tools like Prometheus, Grafana, Envoy, and CoreDNS complement Kubernetes The importance of observability, networking, and service discovery in microservices Why Kubernetes is the control plane, not the entire platform How cloud-native design enables portability, resilience, and scalability across environments Kubernetes makes sense only when you see the ecosystem around it not as a single tool, but as a platform built from many focused components. Onward to applying this in real cloud environments. ☸️🔥Check it out: https://lnkd.in/eD9pMWB4  #Kubernetes #CloudNative #CNCF #DevOps #Containers #Microservices #Observability #SRE 

Before vs After Terraform – A Practical Shift in Cloud Operations Before Terraform, infrastructure depended heavily on manual requests, handoffs between teams, and long provisioning cycles. Changes were slow, error-prone, and difficult to track. After Terraform, infrastructure becomes code. Templates replace tickets. Automation replaces manual approvals. Governance is built in, not added later. This shift brings: Consistency across environments Faster, repeatable deployments Version-controlled infrastructure Clear ownership and accountability Infrastructure as Code isn’t about tools alone—it’s about discipline, predictability, and doing things the right way, every time. #Terraform #InfrastructureAsCode #DevOps #CloudEngineering #Automation #PlatformEngineering #DevSecOps

☁️🚀 Building Production-Ready Cloud Systems Isn’t About Servers: It’s About Reliability Spinning up virtual machines is easy. Building production-ready cloud infrastructure is something else entirely. I’ve learned that reliable cloud systems are built on four non-negotiable pillars: 1️⃣ Infrastructure as Code (IaC) Everything must be reproducible. Terraform replaces guesswork with versioned architecture. 2️⃣ CI/CD Automation If deployment depends on humans, failure is only a matter of time. Pipelines enforce consistency, testing and security before production ever sees code. 3️⃣ Container Orchestration with Kubernetes Kubernetes isn’t about containers it’s about resilience: self-healing, rolling updates, isolation and horizontal scaling. 4️⃣ Observability & Security by Design Monitoring, logging, IAM, RBAC and SSL are not afterthoughts. They are baked into the system from day zero. This is the difference between infrastructure that merely runs and infrastructure that truly scales. #CloudEngineering #DevOps #PlatformEngineering #InfrastructureAsCode #Kubernetes #AWS #Terraform #CI_CD

Containers have changed how we build applications — but managing them at scale is where the real challenge begins. That’s where Docker and Kubernetes shine together. Docker focuses on creating lightweight, portable containers that behave the same everywhere — from a developer’s laptop to the cloud. Kubernetes takes those containers and runs them intelligently in production by handling scaling, healing, networking, and availability automatically. The Real Impact When combined, Docker and Kubernetes enable teams to: Deploy applications with confidence Scale effortlessly as demand grows Reduce downtime through self-healing systems Support modern architectures like microservices If you’re working in DevOps or cloud engineering, understanding this duo is a game-changer. #CloudComputing #DevOpsJourney #DockerContainers #KubernetesOrchestration #SRE #ModernInfrastructure

Your Kubernetes cluster is probably over-provisioned by ~300%. Here’s how I know. At a previous company, we ran ~50 services on Kubernetes. Everything looked fine until we compared requested vs. actual usage. Requested: 400 CPU cores, 800GB RAM Used: ~120 CPU cores, 250GB RAM We were paying for capacity we didn’t need. Why this happens: Developers set conservative requests (“better safe than sorry”) Requests are set once and never revisited No visibility into usage vs. requests Cloud bills rise, but the waste stays hidden So we spent a month right-sizing. What we did: Measured real usage with Prometheus/Grafana over 30 days (focused on peaks, not averages) Adjusted requests to ~150% of peak usage Enabled Vertical Pod Autoscaler (VPA) to continuously tune requests Added cost visibility with Kubecost so teams could see what they were spending Results: 60% reduction in requested resources ~$40K/month lower cloud costs Better node utilization and bin-packing No performance regressions The key lesson: Kubernetes resource requests are guesses unless you measure. Teams over-request because they fear OOMKills or throttling understandable, but expensive. Recommendations: Start with reasonable requests, not worst-case fantasies Monitor usage from day one and adjust regularly Review resource allocations quarterly Use HPA for traffic, not oversized pods Enforce namespace quotas Make costs visible optimization follows visibility The cloud makes wasting money easy. Kubernetes makes wasting money easy at scale. Measure. Optimize. Repeat. How does your team handle Kubernetes right-sizing? #Kubernetes #DevOps #FinOps #CloudCosts #CostOptimization #ResourceManagement

Working on a production-style microservices project. Current focus is handling configuration and secrets correctly in containerized environments. What was considered: • Avoiding hard-coded values inside images • Separating configuration from application code • Using environment-based configuration for flexibility across stages Outcome: Configuration management is a design decision, not an afterthought. #DevOps #Containers #Cloud

Do you know how multiple Kubernetes clusters are used to achieve true high availability across regions? When a user hits a global URL, the request is first handled by a global load balancer such as Route53, Cloudflare, or AWS Global Accelerator. This layer decides which Kubernetes cluster should receive the traffic based on factors like geographic proximity, latency, and health checks. If the nearest region is unavailable, traffic is automatically redirected to the next healthiest cluster, ensuring the application remains accessible even during regional outages. Once the request reaches the selected cluster, it enters through an Application Load Balancer or Ingress controller. This is where Kubernetes takes over and routes the traffic based on the Ingress rules defined inside the cluster. Depending on the path or hostname, the ALB forwards the request to the correct Kubernetes service, which then sends it to the appropriate pod running the application. From the user’s perspective, it’s just one seamless request, but behind the scenes it has passed through multiple intelligent routing layers. What many people don’t realize is how this traffic crosses cloud networking boundaries so smoothly. Each Kubernetes cluster runs its own load balancer that is exposed to the internet, and that load balancer is what bridges the outside world into the private VPC where the cluster lives. The global load balancer simply points users to these regional entry points, and from there the Application Load Balancer ensures the traffic safely reaches the correct service inside the cluster. This layered approach is what makes modern cloud platforms so resilient. Even if an entire region goes down, users are silently routed to another cluster in another part of the world, often without noticing anything happened. That’s the real power of multi-cluster Kubernetes architecture. #Kubernetes #CloudArchitecture #HighAvailability #DevOps #SRE