Davi Diogo

At the last KCDC, I did a talk on "Modularizing the Monolith". Probably half the time was spent just on techniques for discovering and defining boundaries. People will still get boundaries terribly wrong with modular monoliths but the stakes are much lower. If you got your boundaries wrong with your microservice architecture, guess what! They'll still be wrong in your modular monolith. You'll still have a big ball of mud, but at least it's not a distributed monolith? Discovering and defining boundaries is hard. Distributed systems are harder. Doing both is harder-er.

158

6 Comments

Can microservices share a database? ---------------------------------------- Classic wisdom (gyan) says no, they should not, but what happens in complex real world scenarios? Microservices thrive on autonomy. A shared database introduces tight coupling, deployment friction, and unclear ownership. One schema change can ripple across services, breaking independence. But when two services belong to the same domain and evolve together, sharing a database can be a practical shortcut—especially in early stages or modular monoliths. If schema ownership is clear and the services aren’t expected to diverge, it simplifies development and delivery. Still, it’s a tradeoff. You gain speed but risk scalability and flexibility. Alternatives like API contracts or event-driven syncs offer cleaner separation but add complexity. Some common scenarios where I have had two different service share a database: - You have a consumer service that ingests external data, materializes it and is then served by an API. - A producer and a consumer sharing a database, when both are in the same busienss domain, owned by the same team and are practically doing a "task" by breaking it into two parts for efficiencey and scale. In all cases, the thing that made this maintainable was: having both services in a monorepo, sharing the database using a well defined shared library (in the same monorepo) which abstracts that database and exposes business domain data. The key is knowing when to bend the rules—and why. #Microservices #Architecture #PrincipalEngineer #SystemDesign #Tradeoffs #EngineeringLeadership

126

16 Comments

📢Playwright Workspaces now Generally Available 1️⃣Run end-to-end tests across multiple browsers and devices 2️⃣Azure App Testing now brings together Playwright Workspaces and Azure Load Testing into a unified experience. 3️⃣Use tools such as Playwright, JMeter, and Locust - all from a single, integrated hub in the Azure Portal Learn more 👉https://lnkd.in/dknw9ayP #programming #development #ai #playwright #testing #msft

204

4 Comments

🔥 The $10M Question Every Engineering Leader Faces: "We ship 50x/day but crashed on Black Friday" "We have 99.99% uptime but competitors ship 3x faster" Sound familiar? Here's why you're stuck... ⚡ Speed vs. Stability: The Hidden War - Team A: Deploys hourly. Then boom—3AM outage, $2M lost. - Team B: Perfect uptime. Lost 40% market share to faster competitors. Plot twist? Elite teams do BOTH. Here's how 👇 🎯 Speed Metrics (DORA 2024) • Deploy like Netflix (1000s/day): • Deployment Frequency: Ship real value daily • Lead Time: Idea → Customer in hours • Recovery Time: Fix before Twitter notices • Change Failure Rate: Ship fast, don't break Reality: AI adoption = 3.4% better code quality | Accelerate State of DevOps Report DORA but only with these basics. 🛡️ Trust Metrics (SRE) • Reliable like Google for critical services (99.999%): • Availability: Your "always on" promise • Latency: Milliseconds matter • Error Budget: Permission to innovate • Saturation: Catch fires early Money talk: 0.1% downtime = ~$500K lost for $5B companies. 🤯 The 2024 Plot Twist • 75% of teams use AI daily • BUT: AI decreased stability by 7.2% without proper fundamentals • 39% don't trust AI-generated code Translation: Tools won't save you. Process will. 💰 Business Impact Speed wins when: • First-mover advantage • 2x faster delivery = 30% better retention Reliability wins when: • Black Friday/Cyber Monday • Enterprise SLAs = contracts 🚀 Elite Performer Playbook Top 10% do THREE things: 1. Measure BOTH religiously • Speed in sprints • Reliability in dashboards 2. Make explicit trade-offs • "99.9% this quarter to ship Feature X" 3. Platform engineering bridges both • Self-service (speed) • Guardrails (reliability) 🎪 Rate Your Team: 1. Speed demons? 🏎️ Deploy daily ✓ but on-call nightmare ✗ 2. Reliability fortress? 🏰 Zero complaints ✓ but ship quarterly ✗ 3. Elite? 🦄 Both metrics up ✓ Teams happy ✓ 💬 The key Question: "If you could improve ONE metric 50%—deployment frequency OR availability—which drives more revenue?" Drop your answer 👇 P.S. – Teams measuring both are 2.4x more likely to exceed goals. Which side are you? - https://lnkd.in/eDJsYVD5 - https://lnkd.in/eUpWfXeS #DevOps #SRE #PlatformEngineering #DORA #AI #Engineering

27

7 Comments