Eldad Stinbook’s Post

The "Testing Pyramid" is dead for Serverless. 🧪🔥 In the monolith era, complexity lived inside the code. In 2026, complexity has migrated to the arrows between the boxes. If you are testing Lambda functions in isolation, you’re essentially testing a steering wheel without the car. In serverless, your function is often just "AWS glue," and a unit test won't tell you if that glue actually holds. Why the old playbook is failing your team: 🔸 Unit tests ignore cold starts: A mock will never show you that 3-second lag that kills your UX. 🔸 IAM errors are invisible locally: Your code might be perfect, but if the permission is missing on the real infra, it’s a fail. 🔸 The "Simulation Gap": LocalStack is a great feat of engineering, but it isn’t AWS. False negatives from simulations waste more time than they save. The move? The Testing Honeycomb. 🍯 It’s time to prioritize integration tests over isolated unit tests. The workflow is actually simpler than people think:  1. Spin up an ephemeral CloudFormation or CDK stack.  2. Execute your code locally but point it at those real AWS services (Remocal testing).  3. Debug in your IDE while hitting the live infrastructure.  4. Tear it all down when the PR is merged. The Reality Check: If one hour of developer rework costs more than your monthly AWS bill (and it definitely does), you’re paying a premium to work slower with mocks. Stop the "Testing Theater." Test where the complexity actually lives: in the connections. What’s the strategy for your current project? Real infra or are you still deep in Mocks? 👇 #Serverless #AWS #Lambda #DevOps #SoftwareTesting #QA #CloudComputing #BackendDevelopment

🧱 We started with Microservices. We learned our lesson. Here's what real projects taught us about one of software's most debated architecture decisions. Early on, the pitch for microservices was easy to sell: "Independent deployments." "Scales per service." "Teams work in parallel." It sounded like the right call. So we went all in. 😅 What actually happened: ❌ A small feature change touched 4 services ❌ Debugging a single bug meant tracing logs across 6 containers ❌ Local dev setup took longer than writing the actual code ❌ Network latency between services introduced bugs we didn't expect ❌ Distributed transactions became a nightmare ❌ The team spent more time on infra than product We had built a distributed monolith. All the complexity of microservices. None of the benefits. 🔄 So we pulled back. We rebuilt the core as a Monolith — but a clean, well-structured one. ✅ Single deployable unit, fast to iterate ✅ Shared codebase — easier onboarding ✅ No network hops for internal logic ✅ Debugging became human again ✅ We shipped features 3x faster 📌 The lesson we carry into every project now: A Monolith is not a failure. A Monolith is not "legacy." A Monolith is the right default — until it isn't. Microservices solve scaling and team autonomy problems. If you don't have those problems yet, you're paying a tax you don't owe. ────────────────────────── Start with a Monolith. Keep it clean and modular. Extract services only when the pain is real — not hypothetical. The best architecture is the one your team can actually maintain. ────────────────────────── Have you gone through this same cycle? What's your take — Monolith or Microservices from day one? #SoftwareArchitecture #Microservices #Monolith #LessonsLearned #SoftwareEngineering #TechLeadership #SystemDesign #EngineeringCulture

Part 1: It’s Not Just About Microservices Breaking a monolith into microservices is like slicing a pizza into 50 pieces it looks organized, but without the right strategy, toppings will scatter, and someone will fight over the last slice. Microservices alone aren’t enough to make your system resilient, scalable, or maintainable. That’s where cloud native architecture patterns come in they’re the secret ingredients that prevent chaos and ensure your pizza (I mean system!) stays intact. Distributed systems can be messy: services miscommunicate, failures cascade, and engineers spend hours debugging issues that feel like déjà vu. Patterns provide repeatable, battle tested solutions to reduce cognitive load, create a shared language among teams, and anticipate failures before they snowball. They turn microservices from spaghetti code into an orchestra that actually plays in harmony. Real world example: Imagine deploying a new payment service across multiple clusters. Without patterns, logs are scattered, monitoring is inconsistent, and even minor failures ripple through the system. With patterns, each service communicates predictably, recovers gracefully, and scales without chaos. Why it matters: Teams scale confidently without fearing random outages. Onboarding engineers becomes simpler as patterns create a shared mental model. Resilience is built in, not patched later. Our first hero is the Sidecar: your application’s loyal sidekick. How does it help without adding complexity? That’s coming in Part 2… #CloudNative #DevOps #Microservices #Kubernetes #Patterns #TechLeadership #SoftwareEngineering #Innovation #Curiosity

🚀 Ingress in Kubernetes – More Than Just an Entry Point In Kubernetes, exposing applications to the outside world is not just about opening a port — it’s about control, security, and scalability. That’s where Ingress plays a critical role. When external traffic enters your cluster, it doesn’t randomly land on a Pod. It first reaches the Ingress layer, which acts like a smart traffic manager. Because it operates at Layer 7 (Application Layer), Ingress understands HTTP and HTTPS. This means it can inspect hostnames, URL paths, and even apply rules before forwarding traffic. For example, imagine you’re running a full e-commerce platform inside your cluster: 1. shop.example.com → frontend-service 2. shop.example.com/api → backend-service 3. admin.example.com → admin-service Instead of creating multiple LoadBalancers (which increases cost and complexity), you use a single Ingress resource to define routing rules. Clean, efficient, scalable. Ingress can also: * Perform TLS termination (manage SSL certificates centrally) * Redirect HTTP → HTTPS * Enable path-based and host-based routing * Integrate with authentication and rate limiting (depending on the controller) Once traffic is routed, it moves to a Service, which operates at Layer 4 (Transport Layer). The Service handles TCP-level load balancing and distributes requests across healthy Pods. Even if Pods are scaled horizontally or restarted, the Service ensures uninterrupted traffic flow. 🔁 Complete Traffic Flow in Production Client → Ingress (Layer 7 routing & SSL) → Service (Layer 4 load balancing) → Pods (Application containers) This layered separation is powerful: * Ingress controls how traffic enters * Service controls how traffic is distributed * Pods focus on business logic Understanding this architecture is essential for anyone working with EKS, GKE, AKS, or on-prem Kubernetes clusters. Ingress is not just a networking object — it’s the backbone of production-grade traffic management. If you're building microservices, scaling applications, or preparing for DevOps interviews — mastering Ingress is a must. #Kubernetes #DevOps #CloudNative #Ingress #Microservices #SRE #PlatformEngineering

💡 𝗪𝗵𝘆 𝗱𝗼 𝘀𝗼𝗺𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝘀𝗰𝗮𝗹𝗲 𝗲𝗳𝗳𝗼𝗿𝘁𝗹𝗲𝘀𝘀𝗹𝘆 𝘄𝗵𝗶𝗹𝗲 𝗼𝘁𝗵𝗲𝗿𝘀 𝗯𝗿𝗲𝗮𝗸 𝘂𝗻𝗱𝗲𝗿 𝗽𝗿𝗲𝘀𝘀𝘂𝗿𝗲? One big reason is 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲. Modern cloud-native platforms like Kubernetes and containers such as Docker work best when applications follow a set of design principles known as the 𝟭𝟮-𝗙𝗮𝗰𝘁𝗼𝗿 𝗔𝗽𝗽 𝗺𝗲𝘁𝗵𝗼𝗱𝗼𝗹𝗼𝗴𝘆, introduced by engineers at Heroku. The idea is simple: Build applications in a way that makes them 𝗽𝗼𝗿𝘁𝗮𝗯𝗹𝗲, 𝘀𝗰𝗮𝗹𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗲𝗮𝘀𝘆 𝘁𝗼 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻 𝗮𝗰𝗿𝗼𝘀𝘀 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀. Here’s a quick look at the 𝟭𝟮 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀: 🔹 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲 – One codebase tracked in version control, deployed multiple times. 🔹 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀 – Explicitly declare dependencies instead of relying on the system environment. 🔹 𝗖𝗼𝗻𝗳𝗶𝗴 – Keep configuration in environment variables, not hardcoded in the code. 🔹 𝗕𝗮𝗰𝗸𝗶𝗻𝗴 𝗦𝗲𝗿𝘃𝗶𝗰𝗲𝘀 – Treat databases, queues, and caches as attachable resources. 🔹 𝗕𝘂𝗶𝗹𝗱, 𝗥𝗲𝗹𝗲𝗮𝘀𝗲, 𝗥𝘂𝗻 – Separate build, release, and runtime stages. 🔹 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀 – Run apps as stateless processes. 🔹 𝗣𝗼𝗿𝘁 𝗕𝗶𝗻𝗱𝗶𝗻𝗴 – Export services via ports rather than relying on external web servers. 🔹 𝗖𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝘆 – Scale by running multiple processes. 🔹 𝗗𝗶𝘀𝗽𝗼𝘀𝗮𝗯𝗶𝗹𝗶𝘁𝘆 – Fast startup and graceful shutdown. 🔹 𝗗𝗲𝘃/𝗣𝗿𝗼𝗱 𝗣𝗮𝗿𝗶𝘁𝘆 – Keep development and production environments similar. 🔹 𝗟𝗼𝗴𝘀 – Treat logs as event streams. 🔹 𝗔𝗱𝗺𝗶𝗻 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀 – Run administrative tasks as one-off processes. Many modern practices we use today—𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀, 𝗖𝗜/𝗖𝗗 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀, 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀, 𝗮𝗻𝗱 𝗰𝗹𝗼𝘂𝗱-𝗻𝗮𝘁𝗶𝘃𝗲 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁𝘀—naturally align with these principles. Whether deploying to Amazon Web Services, Google Cloud, or Microsoft Azure, the 𝟭𝟮-𝗙𝗮𝗰𝘁𝗼𝗿 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝗵𝗲𝗹𝗽𝘀 𝗯𝘂𝗶𝗹𝗱 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗮𝘁 𝗮𝗿𝗲 𝗲𝗮𝘀𝗶𝗲𝗿 𝘁𝗼 𝘀𝗰𝗮𝗹𝗲, 𝗱𝗲𝗽𝗹𝗼𝘆, 𝗮𝗻𝗱 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻. For anyone working in 𝗖𝗹𝗼𝘂𝗱, 𝗗𝗲𝘃𝗢𝗽𝘀, 𝗼𝗿 𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴, understanding these principles is a huge advantage. #DevOps #CloudNative #SoftwareEngineering #12FactorApp #Kubernetes #Docker #Microservices

🚀 The "Cloud-Native Survival Kit": From Docker to Chaos 🛠️ If you are building in the cloud in 2026, you aren't just "writing code" anymore—edging into the Platform Era is a requirement. Whether you're a Dev, an SRE, or an Architect, here is the 5-layer stack you need to master. Save this cheat sheet for your next system design interview or production deployment! 📌 1️⃣ The Foundation: Docker & Kubernetes Containers package the app; K8s orchestrates the chaos. The Goal: Immutable infrastructure. Pro Tip: Move away from "fat" images. Use Multi-stage builds to keep your attack surface small and your deployment speed high. 2️⃣ The Delivery: Helm Charts Stop copy-pasting YAML files. Helm is the package manager that makes Kubernetes "templated." Key Concept: values.yaml is your control plane. Use it to toggle features between Staging and Production without touching the core logic. 3️⃣ The Journey: Cloud Request Flow Where does a packet go? The Path: User ➡️ Route53 (DNS) ➡️ Global Load Balancer ➡️ Ingress Controller (Nginx/Envoy) ➡️ K8s Service ➡️ Pod. The Bottleneck: Always watch your Ingress. It’s where SSL termination and WAF rules live. 4️⃣ The Traffic Cop: Service Mesh (Istio/Linkerd) When you have 50 microservices talking to each other, you need a "Mesh." mTLS: Automatic encryption between services. Traffic Splitting: Send 5% of users to a "Canary" version to test new features safely. Observability: Visualizing your "Service Graph" to see exactly where a request is slowing down. 5️⃣ The Resilience: Chaos Engineering & DR If you haven't tested a failure, you don't have a reliable system. Chaos Monkey: Randomly killing pods to ensure the "Self-Healing" logic actually works. DR Strategy: Moving from Backup/Restore (Hours of downtime) to Multi-Region Active-Active (Zero downtime). 💡 The Bottom Line: Tools like Docker and K8s get you into the game. Service Mesh and Chaos Engineering help you win it. 🏆 Which part of the cloud-native stack do you find the most challenging to manage? Let's discuss in the comments! 👇 #CloudNative #Kubernetes #DevOps #SRE #SoftwareEngineering #Docker #SystemDesign

You don't move to microservices because your app is big. You move because your organization is big. A few years ago, I thought moving to microservices was a sign that a company had "made it". Big tech uses microservices. Conference talks praise microservices. Job descriptions demand microservices. So obviously... microservices must be the goal, right? Then I actually worked on a distributed system. And my perspective changed completely. 𝗪𝗲 𝗱𝗶𝗱𝗻'𝘁 𝘀𝘂𝗱𝗱𝗲𝗻𝗹𝘆 𝗯𝗲𝗰𝗼𝗺𝗲 𝗳𝗮𝘀𝘁𝗲𝗿 𝗮𝗳𝘁𝗲𝗿 𝘀𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀. 𝗪𝗲 𝗯𝗲𝗰𝗮𝗺𝗲 𝘀𝗹𝗼𝘄𝗲𝗿... 𝗳𝗼𝗿 𝗮 𝘄𝗵𝗶𝗹𝗲.  • Deployments got harder.  • Debugging got harder.  • Local setup got harder.  • Monitoring became a full-time job. We didn't just split the code. We split the problems. That's when I realised something important: Microservices don't solve scaling problems first. They solve team problems first. 𝗔 𝘄𝗲𝗹𝗹-𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵 𝗶𝘀 𝗶𝗻𝗰𝗿𝗲𝗱𝗶𝗯𝗹𝘆 𝗽𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝘄𝗵𝗲𝗻:  • your team is small  • your product is evolving fast  • your biggest goal is shipping features quickly 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝘀𝘁𝗮𝗿𝘁 𝗺𝗮𝗸𝗶𝗻𝗴 𝘀𝗲𝗻𝘀𝗲 𝘄𝗵𝗲𝗻:  • multiple teams are stepping on each other's toes  • deployments become risky and slow  • ownership becomes unclear  • coordination becomes the bottleneck And the trade-off is real: You exchange code simplicity for system complexity. 𝗧𝗼𝗱𝗮𝘆 𝗺𝘆 𝗿𝘂𝗹𝗲 𝗼𝗳 𝘁𝗵𝘂𝗺𝗯 𝗶𝘀 𝘀𝗶𝗺𝗽𝗹𝗲:  • Start with a monolith.  • Grow into microservices when the pain becomes obvious.  • Not when the trend becomes popular. Curious to hear others' experiences: Did your team move too early, too late, or just in time? #Microservices #Monolith #SoftwareArchitecture #BackendEngineering #SystemDesign

Managing a fleet of AWS CDK projects taught me that serverless architecture problems are rarely about the code itself — and that serverless isn't always the answer once you scale. Serverless is excellent for prototyping and getting ideas into production quickly. But the bigger challenges show up when you're running dozens of services: cold starts affecting user experience, Lambda timeout limits forcing architectural workarounds, debugging distributed failures across ephemeral functions, cost unpredictability at scale, and the painful absence of proper local development setups. That last one hits harder than people admit. Without a good local development environment, every code change becomes a deploy-and-pray cycle. You're either waiting for CI/CD pipelines or deploying to a shared dev environment where you're stepping on other developers' toes. Debugging becomes exponentially harder when you can't reproduce issues locally. The real problems weren't just technical — they were in the gaps: missing QA processes, unclear environment boundaries, inconsistent deployment patterns, and communication breakdowns across teams. Here's what actually moved the needle when dealing with multiple serverless services: - Building shared CDK constructs so teams aren't reinventing infrastructure patterns - Treating environments seriously — separate AWS accounts, proper isolation, no "it works in dev" surprises - Investing in local development tooling (LocalStack, SAM Local, or containerized emulation) - Making CDK diffs visible in PRs so infrastructure changes aren't invisible until deployment - Testing at multiple layers: infrastructure validation, API integration tests, and snapshot testing for drift detection - Baking observability into every service from the start — distributed tracing becomes critical when debugging spans 15+ Lambda functions - Writing things down: service ownership, architecture decisions, runbooks The pattern I kept seeing: technical problems are usually workflow problems in disguise. Unstreamlined deployments, missing QA, poor communication — these create more production issues than any single architectural choice. Serverless promises speed and scalability, but speed doesn't mean sustainable. You get sustainable velocity by building the scaffolding that lets teams move fast without breaking things, and by honestly evaluating when serverless makes sense versus when you're fighting the platform. If you're managing multiple CDK stacks and it feels chaotic, you're not alone. The tooling exists, but the discipline to use it well — and knowing when to step back — has to be intentional. #AWS #Serverless #CDK #DevOps #SoftwareEngineering

𝗪𝗵𝘆 𝗠𝗼𝘀𝘁 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗦𝗵𝗼𝘂𝗹𝗱 𝗡𝗢𝗧 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 Hot take: 𝗠𝗼𝘀𝘁 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗱𝗼𝗻’𝘁 𝗻𝗲𝗲𝗱 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀. 𝗧𝗵𝗲𝘆 𝗻𝗲𝗲𝗱 𝗰𝗹𝗮𝗿𝗶𝘁𝘆. Microservices look impressive on diagrams. Multiple services. APIs. Containers. Queues. It feels “senior”. But here’s the truth: 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗿𝗲 𝗮 𝗰𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗶𝗲𝗿. You’re no longer just writing code. You’re managing: • Network failures • Distributed tracing • Data consistency • CI/CD pipelines • Observability For most teams building CRUD-heavy apps or early-stage products, a modular monolith is often faster, simpler, and more stable. Microservices make sense when: • Teams are large • Domains are clearly separated • Scaling needs are real • DevOps maturity exists 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝘀𝗵𝗼𝘂𝗹𝗱 𝗳𝗼𝗹𝗹𝗼𝘄 𝗰𝗼𝗻𝘀𝘁𝗿𝗮𝗶𝗻𝘁𝘀 — 𝗻𝗼𝘁 𝘁𝗿𝗲𝗻𝗱𝘀. Curious: 𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝘀𝗲𝗲𝗻 𝘁𝗲𝗮𝗺𝘀 𝗮𝗱𝗼𝗽𝘁 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝘁𝗼𝗼 𝗲𝗮𝗿𝗹𝘆? 𝗢𝗿 𝗱𝗼 𝘆𝗼𝘂 𝗽𝗿𝗲𝗳𝗲𝗿 𝘀𝘁𝗮𝗿𝘁𝗶𝗻𝗴 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱? #SystemDesign #SoftwareArchitecture #Microservices #BackendEngineering #DistributedSystems #TechLeadership #ScalableSystems #EngineeringMindset