https://osmarpetry.dev/tags/devops/Recent content in Devops on Osmar PetryHugoen-USMon, 01 Sep 2025 00:00:00 +0000https://osmarpetry.dev/blog/introduction-to-be-archtitectures/Mon, 01 Sep 2025 00:00:00 +0000https://osmarpetry.dev/blog/introduction-to-be-archtitectures/<h2 id="summary">Summary</h2> <ul> <li>Know the <strong>history</strong> (monolith → services → serverless) to choose the <strong>right shape for now</strong>.</li> <li>Use <strong>dogfooding</strong> to turn internal capabilities into <strong>platforms</strong> and eventually <strong>products</strong>.</li> <li>Pair <strong>tech + finance</strong> on every decision so architecture choices have a clear <strong>P&amp;L story</strong>.</li> </ul> <hr> <h2 id="case-studies-what-they-did--why-it-mattered">Case studies (what they did → why it mattered)</h2> <ul> <li><strong>Amazon</strong>: built infra &amp; tooling for itself first (<strong>dogfood</strong>) → later externalized as <strong>AWS</strong> (new revenue, 2× monetization of the same effort).</li> <li><strong>Netflix</strong>: <strong>hybrid</strong> of microservices + serverless; serverless for bursty/edge workloads, services for core domains → <strong>speed + cost control</strong>.</li> <li><strong>Google</strong>: evolved from large coordinated monoliths to <strong>microservices</strong> as scale/teams grew → <strong>independent deploys</strong> and <strong>targeted reliability</strong>.</li> <li><strong>Uber</strong>: reused <strong>profile, payments, geo, notifications</strong> to launch <strong>Eats</strong> quickly → <strong>time-to-market</strong> by reusing platform primitives.</li> </ul> <hr> <h2 id="decision-heuristics-when-to-pick-what">Decision heuristics (when to pick what)</h2> <ul> <li><strong>Monolith first</strong> when the team is small, domain still moving, and you need <strong>velocity</strong>.</li> <li><strong>Split by domain</strong> (bounded contexts) when teams block each other and deploys become risky.</li> <li><strong>Serverless</strong> for event-driven, spiky, or edge tasks where <strong>operational burden</strong> must be minimal.</li> <li>Always design for <strong>observability</strong> (logs/metrics/traces) and <strong>clear failure domains</strong>.</li> </ul> <hr> <h2 id="dogfooding--productization-loop">Dogfooding → productization loop</h2> <ol> <li><strong>Build</strong> the capability you need (internal API/service).</li> <li><strong>Harden</strong> with SLOs, docs, dashboards.</li> <li><strong>Reuse</strong> across 2–3 internal products (prove generality).</li> <li><strong>Abstract</strong> contracts (versioning, quotas, cost model).</li> <li><strong>Externalize</strong> (SDKs, billing, support) when economics are clear.</li> </ol> <p><strong>Two-sided payoff:</strong> internal reuse lowers <strong>cost/time</strong>, externalization creates <strong>revenue</strong>.</p>