The irony of microservices architecture is that it creates an enormous appetite for shared capabilities. Every service needs logging. Every service needs deployment pipelines. Every service needs authentication, rate limiting, and health checks. When thirty teams each build their own solutions, you haven't created independence—you've created thirty maintenance burdens.

The organizations that succeed with microservices recognize this paradox early. They invest heavily in platform infrastructure—a carefully designed monolithic foundation that handles the capabilities every service needs. This isn't a contradiction of microservices principles. It's the precondition for making them work.

The question isn't whether you need a platform. It's which capabilities belong there, how you deliver them without creating bottlenecks, and how you evolve the platform alongside the services it supports. Get these decisions wrong, and your platform becomes either an ignored artifact or a bureaucratic obstacle. Get them right, and teams can focus on business logic instead of reinventing infrastructure.

Determining what belongs in a platform requires understanding a simple principle: centralize capabilities where consistency matters more than flexibility. Security authentication is a clear candidate. If teams implement authentication differently, you've created thirty attack surfaces instead of one. Observability infrastructure belongs centrally because correlating logs across services requires standardized formats and shared tooling.

Deployment pipelines represent a more nuanced case. The mechanics of building containers and pushing them to registries benefit from centralization. But teams need flexibility in their deployment cadence, feature flags, and rollback strategies. The platform provides the machinery; teams control when and how they use it.

Some capabilities seem like obvious platform candidates but actually belong with services. Business-specific validation logic, for instance, should stay close to the domain it serves. Caching strategies often depend on access patterns unique to each service. Forcing these into a platform creates awkward abstractions that serve no one well.

The test for platform inclusion isn't technical elegance—it's organizational efficiency. Ask: Does centralizing this capability reduce total cognitive load across teams? If teams must understand the platform abstraction and work around its limitations, you've added burden rather than removing it. Platform scope should emerge from repeated pain points, not architectural diagrams drawn in isolation.

Takeaway

Centralize capabilities where consistency creates more value than flexibility—security, observability, and deployment mechanics are typical candidates, while business logic and service-specific optimizations should remain distributed.

Platform teams face a fundamental tension: provide too little, and teams duplicate effort; provide too much, and you become a bottleneck. The solution lies in self-service interfaces that expose capability without requiring coordination. Teams should provision what they need when they need it, without filing tickets or attending meetings.

This means investing heavily in documentation, sensible defaults, and guardrails rather than gatekeeping. A well-designed platform lets teams deploy a new service in minutes by providing templates that include logging, metrics, health endpoints, and deployment configuration out of the box. Teams can customize, but the default path should be both easy and correct.

The anti-pattern is platforms that require team-by-team consultation. When the platform team must approve every database provisioning request or custom networking rule, you've recreated the centralized IT department that microservices were supposed to escape. Approval processes should be automated wherever possible—policy as code rather than policy as committee.

Self-service doesn't mean no governance. Financial controls, security baselines, and compliance requirements still apply. But enforcement happens through automation, not manual review. The platform prevents deploying containers with known vulnerabilities rather than relying on security teams to catch issues after the fact. Constraints should be invisible until violated, allowing teams to move fast within well-defined boundaries.

Takeaway

Design platforms for self-service with sensible defaults and automated guardrails—teams should be able to provision standard infrastructure in minutes without human approval, while automated policies enforce security and compliance boundaries.

The most dangerous approach to platform development is building for anticipated needs. Platforms designed around predicted future requirements become bloated with unused capabilities while missing the features teams actually want. Successful platforms grow from observed pain, not imagined scenarios.

Start minimal. Your initial platform might include only container orchestration, a CI/CD pipeline, and centralized logging. When three teams independently build similar service mesh configurations, that's evidence for platform investment. When a security incident reveals inconsistent secret management, that's a signal to add secrets infrastructure. Let adoption and frustration guide expansion.

This requires treating the platform as a product with customers—the engineering teams who use it. Platform teams need feedback mechanisms: regular surveys, usage metrics, and direct conversations with service developers. Understanding why teams work around the platform reveals gaps more clearly than feature requests.

Platform deprecation matters as much as platform creation. Technologies evolve, and capabilities that once required centralized investment become commodities. Yesterday's custom deployment system might be replaced by managed Kubernetes services. The platform team's role shifts from building to curating—selecting the right external tools and integrating them cleanly. Healthy platforms shrink as well as grow, shedding responsibilities that no longer justify internal investment.

Takeaway

Grow platforms incrementally based on patterns you observe—when multiple teams solve the same problem independently, that's your signal to centralize, and when external solutions mature, be willing to deprecate internal capabilities.

Microservices without platform investment is a recipe for duplicated effort and inconsistent quality. The freedom to build services independently depends on shared infrastructure handling the capabilities that every service needs. This isn't contradiction—it's architectural maturity.

The platform team's job is enabling, not controlling. Build for self-service, automate governance, and let observed patterns guide what you centralize. Your platform should make the right path the easy path.

Start smaller than you think necessary. Expand based on evidence rather than anticipation. The goal isn't a comprehensive platform—it's the minimal shared foundation that lets teams focus on what makes their services unique.