Building & Running a Serverless Platform: Beyond Infrastructure • Shilpa Nagavara • GOTO 2025

The goal of platform engineering is to manage system complexity and deliver leverage to the business by taking a curated, product-centric approach to developing platforms as software-based abstractions. A platform is a foundation of self-service APIs, tools, and knowledge arranged as a compelling product. This provides leverage, where the work of a few engineers makes larger application teams more productive by removing duplicate work or creating new business value.

Categories of Platforms

Platforms can be broadly categorized into three types:

1. Internal Developer Platform (IDP): Helps in provisioning infrastructure, CI/CD pipelines, templates, etc.
2. Internal Integration Platforms: Software solutions that connect applications to share data and workflows internally.
3. External/Internal Integration Platform: The organization’s digital platform that exposes business capabilities to customers and third parties.

---

The Three Phases of Platform Engineering

Building a platform involves three key phases: Ideation, Construction, and Operation.

1. Ideation Phase

This phase focuses on the “what” and “why” of the platform. Key principles include:

• Treat the Platform as a Product: The platform is not just a technical abstraction but a solution to a real pain point. This involves focusing on user journeys, feedback loops, and continuous improvement.
• Build Customer Empathy: Understand the customer’s needs and focus on the business logic and user experience. The platform should perform undifferentiated heavy lifting, making consumers faster and more autonomous by reducing friction like meetings and tickets. Discoverability and up-to-date documentation are crucial.
• Define Capabilities: Platforms should be built around modular and composable capabilities that encode deep domain knowledge. For example, a simple “Document Management Platform” that handles uploads/downloads can evolve to include access control, malware scanning, and customer-specific configurations.
• Align with Business Goals: Technical capabilities must continuously align with business objectives. The document platform, for instance, can evolve to support a business goal like “contract management” by adding capabilities for template management, document generation from templates, and signature management.

At the end of the ideation phase, you should have clarity on team ownership, success metrics (KPIs), data entities and their lifecycles, and high-level API and event contracts.

2. Construction Phase

This phase is guided by the five pillars of the AWS Well-Architected Framework.

• Security:

  • Threat Modeling: Perform data classification (e.g., PII, public) and use frameworks like STRIDE for data flow modeling to identify and mitigate threats.
  • Code Security: Scan for checked-in secrets and outdated/vulnerable packages.
  • Penetration Testing: Actively test the platform for vulnerabilities.

• Cost:

  • Cost Modeling: Conduct a “build vs. buy” analysis and understand the Total Cost of Ownership (TCO), including fixed costs (VPCs), vendor costs (e.g., DocuSign), and build/operate costs.
  • Unit Cost: Analyze the cost to serve a specific tenant, customer, or user.

• Operational Excellence:

  • CI/CD & Auditability: Implement robust pipelines and ensure auditability beyond CloudTrail to trace requests in a distributed system.
  • Observability: Treat observability as a first-class citizen. Identify key metrics, ensure end-to-end traceability, and build compelling dashboards.
  • Deployment Strategy: Plan deployment strategies (Canary, Blue/Green) and manage the entire lifecycle of feature flags to avoid technical debt.

• Reliability:

  • Capacity Planning: Establish baseline traffic expectations.
  • Failure Management: Implement patterns like outbox, back-off retries, and graceful failure.
  • Disaster Recovery (DR): Define a clear DR strategy, including data backup, multi-region support, and post-recovery plans.
  • Service Level Objectives (SLOs): Define SLOs for latency, throughput, and MTTR as a contract with consumers.
  • Chaos Engineering: Proactively test for failures (e.g., what happens if a database or region goes down?).

• Performance Efficiency:

  • Performance Testing: Analyze unit latencies (database reads/writes, Lambda cold/warm starts) and end-to-end latency.
  • Load & Stress Testing: Understand the platform’s breaking points to define throttling limits and perform necessary optimizations (e.g., Lambda package sizes).

3. Operation Phase

Once the platform is in production, the focus shifts to maintaining and evolving it.

• Deploy Without Disruption: Releases must be safe and reliable. Backward compatibility is sacrosanct. Have a clear plan for migrating customers to newer versions and deprecating old ones to avoid maintenance overhead.
• Continuous Security: This is non-negotiable. Constantly monitor egress traffic and use tools like AWS Inspector for continuous vulnerability scanning.
• Reliability First, New Capabilities Later: Trust is paramount. A stable, reliable platform is more valuable than one with many shiny but unreliable features.
• Metric-Driven Evolution: All optimizations and new features should be driven by data, not gut feelings. Track metrics like adoption rate, usage patterns, and customer satisfaction to guide the platform’s evolution.
• Communicate, Communicate, Communicate: Building trust requires a strong communication plan. Establish channels (e.g., Slack, email) to inform customers about new capabilities, roadmaps, and issues. Actively gather feedback to close the loop.

---

When to “Refresh” Your Platform

There are scenarios where you must re-evaluate and potentially reshape your platform:

1. Built for a Single Use Case: If the platform was built for one specific customer, it may be too specialized and not easily adoptable by others. It needs to be generalized.
2. Emergence of “Shadow Platforms”: If other teams start building their own solutions (e.g., using their own S3 bucket instead of the document platform), it’s a sign that your platform is too complex or difficult to adopt.
3. “Rail Tracks” vs. “Paved Paths”: A platform should be a flexible “paved path” that accommodates various users and use cases (walkers, cyclists, cars), not a rigid “rail track” that only works for a specific type of train.
4. Generalizing a Niche Service: When a service built for one team’s specific need is turned into a platform, it must be re-evaluated from the ideation phase to ensure it serves a broader audience, breaking free from its original narrow vision.

• Tags:
• Platform Engineering
• Cloud Computing
• AWS
• Software Architecture
• System Design
• Serverless
• Well-Architected Framework