Microservices

The architectural approach that lets large organisations build software the way start-ups do — fast, independent, and resilient.

Over 85% of Fortune 500 companies have adopted microservices architectures for at least some portion of their technology estates, according to a 2025 survey by O'Reilly. The approach — breaking large applications into small, independently deployable services — has become the default way enterprise software is built. But microservices are not a free lunch: they introduce distributed systems complexity that costs organisations an estimated $300,000-500,000 per year per service to operate effectively. For C-suite leaders, the question is not whether microservices are the right architecture, but where and how to apply them for maximum business return.

What It Is

Microservices architecture is an approach to building software applications as a collection of small, independent services, each responsible for a specific business capability. Each service runs its own process, communicates with other services through well-defined APIs (typically over HTTP or message queues), and can be deployed, updated, and scaled independently. Think of it this way: a monolithic application is like a single Swiss Army Knife — it contains every tool you need, but opening one tool means handling the entire knife. Microservices are like a professional toolkit — each tool is separate, purpose-built, and can be upgraded or replaced without affecting the others.

In a typical e-commerce platform built with microservices, the user authentication service, product catalogue service, shopping cart service, payment processing service, recommendation engine, and order fulfilment service are each separate codebases, maintained by separate teams, and deployed on separate schedules. If the recommendation engine needs an update, that service can be deployed without touching any other part of the system. If payment processing experiences high demand during a sale, only that service needs to scale up — saving infrastructure costs compared to scaling the entire monolithic application.

The microservices approach emerged from the recognition that monolithic architectures — where all functionality is bundled into a single codebase and deployment unit — become increasingly difficult to manage as they grow. A small monolith is simple to develop and deploy, but a monolith with millions of lines of code, hundreds of developers, and dozens of teams becomes a bottleneck: every change requires coordination across teams, deployments are risky because any change can break anything, and scaling the entire application for one high-demand component wastes resources.

Why It Matters for Business

Microservices directly impact organisational agility. Amazon, one of the pioneers of microservices, deploys code every 11.7 seconds on average across its thousands of services — a velocity impossible with a monolithic architecture. Each of Amazon's services is owned by a small, autonomous team (the famous "two-pizza team" model), enabling independent decision-making and rapid iteration. Netflix similarly operates over 700 microservices, each owned by a dedicated team, enabling the company to push hundreds of production changes daily without coordinated release schedules.

The architecture also improves system resilience. In a monolith, a bug in one component can crash the entire application. In a microservices architecture, a failure in the recommendation service might degrade the shopping experience, but the checkout service continues to function, and customers can still complete purchases. This isolation of failures is critical for systems requiring high availability. Target Corporation adopted microservices for its e-commerce platform in 2018 after a series of high-profile outages during peak shopping events; since the migration, the platform has maintained 99.99% availability during Black Friday traffic spikes.

However, microservices introduce operational complexity that is expensive and requires significant engineering maturity. Distributed tracing, service discovery, circuit breakers, API gateways, and observability tooling are all necessary — and each adds cost and cognitive load. Organisations that adopt microservices without investing in platform engineering and DevOps capabilities often end up with a "distributed monolith" — the complexity of microservices with none of the benefits. This anti-pattern is estimated to affect 30-40% of microservices adopters.

Enterprise Use Cases

Uber built its platform on microservices from early in its history, eventually growing to over 4,000 microservices by 2020. Each service handles a specific capability — trip matching, surge pricing, driver payments, map rendering, fraud detection. This architecture enabled Uber to scale to 25 million trips per day across 70 countries, with each market able to customise its service independently. However, Uber also represents a cautionary tale: by 2022, the company began consolidating some services, recognising that excessive granularity created management overhead. The lesson for executives is that microservices should be bounded by business capability, not by technical function.

Spotify's "squad" model is the most cited example of organisational structure aligned with microservices architecture. Each squad — a cross-functional team of 6-12 people — owns a specific feature area and the corresponding microservices end-to-end. This model enables Spotify to ship features to its 600 million users without cross-team coordination bottlenecks. The company's backend comprises over 1,500 microservices, each independently deployable. In insurance, Liberty Mutual rebuilt its claims processing system as a set of microservices, reducing the time to introduce new insurance products from 18 months to 3 months and enabling real-time claims processing that cut settlement times by 40%.

The UK Government Digital Service (GDS) built the GOV.UK platform using microservices, enabling over 50 million citizens to access government services through a unified digital platform. The architecture allows individual departments to update their services independently, and the platform handles over 2 billion page views per year with high reliability.

Vendor Landscape

The microservices ecosystem is vast and predominantly open-source. Container orchestration is dominated by Kubernetes. Service mesh technologies — Istio (backed by Google and IBM), Linkerd (backed by Buoyant), and Consul Connect (by HashiCorp) — provide the communication layer between services. API gateways include Kong (open-source and enterprise, with pricing from $35,000 per year), Apigee (acquired by Google, enterprise pricing from $500 per month), and AWS API Gateway ($3.50 per million requests). Observability platforms essential for microservices — Datadog, New Relic, Dynatrace, and Grafana — range from $15 per host per month to enterprise contracts exceeding $500,000 annually. AWS, Azure, and Google Cloud each offer comprehensive suites of managed services specifically designed for microservices architectures.

Strategic Considerations

Start with a monolith and extract microservices as clear boundaries emerge — this is the approach recommended by Martin Fowler and practised by most successful adopters. Premature decomposition into microservices is one of the most costly architectural mistakes, creating operational overhead without commensurate benefits. Adopt microservices when you have clear business boundaries, multiple teams needing independent deployment cadences, and the DevOps maturity to operate distributed systems. Ensure your organisation has robust observability (monitoring, tracing, alerting) before decomposing services — you cannot manage what you cannot see. Invest in a platform engineering team that provides shared infrastructure, CI/CD pipelines, and developer tooling, so individual service teams can focus on business logic rather than operational plumbing. Finally, measure the total cost of ownership honestly: when you account for networking, observability, orchestration, and the cognitive load on developers, microservices are more expensive than monoliths for small-scale applications. The economics tip in favour of microservices only at scale.