Epetech Narrative: From Friction to Flow

The Epetech Story

Epetech, Inc. is a fictional North American healthcare technology company. Its core mission is to provide better health outcomes by offering mobile and web services that allow people to track health vitals and securely share that data with their doctors using consumer electronic devices.

The accessibility of its web services to third-party developers and business partners is the area driving significant market expansion, and the company plans to double its engineering headcount soon.

To support its ambitious goals, Epetech adopted a modern distributed services architectural (microservices) strategy built around domain-driven software design principles. However, as the business scaled, the lack of a coherent platform and infrastructure lifecycle strategy created a culture of engineering friction that undermined the promise of microservices.

The Epetech narrative follows how the organization moved from ticket-driven silos and brittle deployment processes to a cohesive engineering platform that treats infrastructure, security, and governance as self-service, productized capabilities.

The Challenge: Engineering Friction

Despite the technical foresight in adopting microservices, Epetech's lack of a clear infrastructure lifecycle strategy led to crippling bottlenecks. Developers were forced to coordinate and open tickets across technical silos—including networking, security, DNS, and operations teams—just to get basic dependencies.

They found themselves spending up to half their time on lead-time planning and coordination rather than delivering business value. This immense friction led to slower maintenance efforts, rising production incidents, frustrated customers, and higher support costs.

The application deployment process was fragmented, requiring multiple handoffs and approvals—such as SAST testing, CVE scans, OWASP scans, and Database changes—each owned and configured by a separate team. Application deployments frequently took weeks to complete, and operational ownership was unclear.

The Catalyst: The Platform Team & LaunchPad

Recognizing that common sense and existing structures would not solve this problem, Epetech's leadership, including the SVP of product engineering and the CTO, initiated a cultural and technological transformation. They decided to build an internal product that provides a genuinely self-service experience where developers can imagine, design, build, release, and operate their applications with agility and greater operational resiliency.

A dedicated platform team was assembled, initially led by Emma, a senior DevOps engineer. Emma's team began with six diverse engineers experienced in automation, networking, and configuration. Their immediate customer, the early adopter, was the Customer Profile domain product owner, which included two subdomain teams operating six individual APIs.

The platform team committed to viewing their platform as an internal product and gave it the name LaunchPad, Epetech’s internal developer platform (IDP). LaunchPad’s mission is to allow developers to imagine, design, build, release, and operate their applications with agility, high engineering quality, greater operational resiliency, and confidence in meeting compliance requirements.

To manage the platform's evolution, they appointed a platform product manager, Alex, whose role was crucial in bridging the gap between technical execution and user needs by conducting user research, tracking KPIs, and shaping the platform roadmap from a product-first perspective.

Epetech Organizational Structure & Teams

Epetech adopted Team Topologies to structure its organizational change, ensuring that the platform team functioned as an internal product delivery team, supporting the customer-facing stream-aligned teams instead of acting as a traditional centralized “ops” bottleneck.

Core Team Structure (Team Topologies)

• Stream-aligned Teams (The Customers): Internal development teams aligned with continuous flows of work and specific business value streams. For Epetech, an example is the Customer Profile domain team. Other examples include the E-commerce team, the Mobile App team, and the Inventory Management team.
• Platform Team (Internal Product Delivery): Led by Emma, this team creates and maintains the engineering platform product (LaunchPad). Their customers are the stream-aligned teams, and they provide capabilities as well-defined services.
• Enabling Teams: Teams that provide expertise and guidance, such as Site Reliability Engineering (SRE) specialists or security experts, working temporarily with stream-aligned teams to build capabilities, uplift practices, and disseminate knowledge.
• Complicated Subsystem Teams: Teams that focus on highly specialized or complex areas, although the initial platform design focuses on modularizing capabilities to avoid requiring this structure except where strictly necessary.

Domain-Driven Platform Organization

The platform team, while starting as a single unit, architected its work around principal product domains to ensure loose coupling and scalability. Initially, the single team's responsibilities were divided into two main organizational areas:

As the platform matures, this initial structure evolves, spinning up dedicated domain teams for specialized areas like Security & Identity, Observability, or Core Control-Plane, while continuing to align platform capabilities with clear customer value streams.

Epetech Platform Case Studies & Usage

The Epetech case study is used throughout the book to illustrate key concepts, successful strategies, and the measurable outcomes of platform engineering. The following themes highlight how LaunchPad, Epetech’s internal developer platform, turns microservices chaos into sustainable delivery flow.

1. Platform Governance and Compliance

Epetech uses its platform to transform governance and compliance from burdensome silos into automated safeguards. LaunchPad implements the strategy of compliance at the point of change, separating the work of becoming compliant (performed by developers) from the verification that this work occurred (performed automatically by the platform control plane).

• The platform verifies that requirements, such as successful vulnerability scan records that correspond to the image commit Secure Hash Algorithm (SHA), are present at the time of deployment.
• All deployed custom software must provide an associated software bill of materials (SBOM).
• The platform enforces security policies, such as ensuring that specific internal APIs are only accessible by other Epetech services, reducing the risk of accidental exposure of internally scoped APIs.
• Compliance and governance requirements are implemented as policy-as-code using Open Policy Agent (OPA) and the Rego policy language, allowing fine-grained, auditable, and testable controls.

2. Identity and Access Management

Epetech architected its identity solution to provide a seamless, self-service experience that is independent of any single cloud provider. Identity and access are treated as first-class platform products rather than ad hoc cluster configurations.

• The platform explicitly separates platform customer identity from cloud infrastructure identity, providing flexibility and security without coupling development teams directly to underlying infrastructure solutions.
• GitHub team membership serves as the authoritative source of authorization claims, making access management transparent and aligned with how teams already collaborate on code.
• An external SaaS Identity Provider (IDP), such as Auth0, provides standards-based protocols like OpenID Connect (OIDC) and acts as the intermediary between authentication and authorization claims.
• Developer (user) control-plane access to the Kubernetes API uses the same IDP, with permission policies based on team claims. Epetech is also building a custom Platform CLI (epectl) that leverages OAuth 2.0 device-authorization-grant flow to streamline token and kubeconfig generation from a terminal.

3. Domain Naming and Networking

Epetech established clear, platform-managed conventions for domain architecture and networking, delegating responsibility to the engineering platform instead of individual application teams.

• The domain epetech.io is exclusively owned and managed by the engineering platform.
• The platform exposes a standard set of DNS subdomains and ingress patterns:
  • Production UI traffic: epetech.io and www.epetech.io
  • Production API traffic: api.epetech.io
  • Preproduction testing: dev.epetech.io and qa.epetech.io
  • Initial API testing environments: dev.api.epetech.io for all teams
• Cluster-specific subdomains such as prod-i01-aws-us-east-2.epetech.io and sbx-i01-aws-us-east-1.epetech.io support cluster-wide services like Kiali and other control-plane tooling.
• Developers are free to self-manage the right-of-domain pattern (the path or resource naming after the domain/subdomain) in a self-service way, balancing standardization with autonomy.

4. Technical Platform Implementation and Scaling

Epetech’s architectural decisions emphasize evolutionary design, cloud-native resilience, and long-term scalability rather than one-off project outcomes.

• The company anticipates a merger with Alltech, requiring architectural decisions that support multi-cloud readiness (for example, supporting Google Cloud Platform in addition to AWS).
• The platform uses the Istio service mesh to support platform-managed DNS ingress patterns, traffic management, and advanced routing features.
• Epetech deploys Karpenter for node autoscaling, integrated directly into the control-plane base configuration to enable efficient, cost-aware scaling of compute resources.
• The architecture preserves an evolutionary architecture stance, allowing Epetech to expand into a European region and meet GDPR privacy requirements without replatforming.
• Team structures follow Team Topologies with explicit interaction modes (Collaboration, X-as-a-service, Facilitation). For example, the Inventory Management team collaborated with the Platform team to consume a new messaging system as an X-as-a-service.
• Site Reliability Engineering (SRE) practices are embedded into the platform and stream-aligned teams, with SLOs, SLIs, and error budgets informing how quickly teams can safely ship changes.
• Epetech integrated an intelligent assistant named EpetechBot into the platform to provide deployment assistance, monitoring alerts, knowledge-base access, and code analysis. The company also plans to use Generative AI (GenAI) to produce comprehensive reports with recommendations for system improvements and remediation using observability data.

5. Measurement and Outcomes

Epetech uses data, metrics, and developer feedback to ensure that LaunchPad delivers measurable business value, not just infrastructure automation.

• Metrics are aligned with the four key DORA metrics—Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery (MTTR)—to quantify delivery performance.
• Epetech tracks leading indicators to improve these lagging metrics, such as: the number of code quality violations, test coverage percentage, the ratio of manual to automated tests, incident detection time, and mean time to acknowledge.
• A comprehensive feedback loop ecosystem captures qualitative and quantitative data via periodic surveys, one-on-one interviews, community forums (for open discussion and knowledge sharing), and advisory groups (for strategic alignment and change management).
• By centralizing data and providing observability dashboards for infrastructure costs per application, Epetech addressed shadow IT practices where various business stakeholders maintained fragmented spreadsheets for reporting and budgeting.
• Over time, these measures support a broader cultural shift toward DevOps principles: cross-functional collaboration, continuous integration and delivery, infrastructure-as-code, and proactive monitoring and observability.