How to Restructure Your Organization for Microservice Applications

Hierarchical Organizations

In order to take advantage of much of the value of a service-oriented architecture, you must change your traditional hierarchical organizational structure to a more horizontal one.

Figure 1. Traditional hierarchial organization structure.

The Pod Model

In the pod model, your organization is not split by job functions; instead, it’s split into small, cross-functional teams, called pods. Each team has the capabilities, the resources, and the support required to be completely responsible for a small portion of the overall application — a service or two in the microservice architecture model.

  • Team management
  • Software development
  • Software validation
  • Service operation
  • Service scaling and maintaining availability
  • Security
  • Operational support and maintenance
  • Infrastructure operational maintenance (servers, etc.)
Figure 2. Pod-based organizational structure

Ownership Is the Key

The key to successfully operating the pod model is to create pods with responsibilities that aren’t specific job functions. Rather, their responsibilities are ownership. A pod owns a service or set of services. Ownership means they have complete responsibility for the architecture, design, creation, testing, operation, maintenance, and security of the service. No one else has ownership, only the assigned pod. If anything happens to that service, it is the pod’s responsibility to manage and fix. This completely removes the ability to finger-point to another team when a service fails. The service’s owning pod is the one responsible. This is illustrated in Figure 3, where interconnected services are represented in blue, and the pods that own those services are shown in red.

Figure 3. Every service has an owner.

Cross-Service Finger-Pointing

But what happens if problems cross service boundaries? For example, what happens if Service E in Figure 3 is causing problems for Service C? In that case, it may appear that both services are having problems, and it may not be clear where the root cause of the problem resides. Because the two services are owned by different pods, which pod owns the problem? The answer may be difficult and complex to determine. Finger pointing between Pod 2 and Pod 4 is definitely a possibility.

  • Well-designed and documented APIs. Each and every service in your application must have a well-designed API describing how the service should be used and how to talk to it, and this API must be well-documented across the organization. We are used to well-designed and documented APIs when we are talking about APIs exposed to customers. But it’s equally important to design quality APIs among internal services as well. No service should talk to any other service without using a well-defined and documented API to that service.This makes sure that expectations on what each service does and does not do is clear, and those expectations drive higher-quality interactions and hence fewer application issues.
  • Solid, maintainable SLAs. Besides having APIs, a set of performance expectations around those APIs must be established. If Service C is calling Service E’s API, it’s critical that Service C understand the performance expectations it can expect from Service E. What will the latency be for the API calls it makes? What happens to latency if the call rate increases? Are there limits on how often a service can be called? What happens when those limits are reached?

Pods Need Support

In the pod model, pods have a lot of responsibility and a lot of authority. There is no way that a small team (6–10 people) that composes a pod can handle all aspects of the breadth and depth of responsibility for all aspects of service ownership without support.

Figure 4. Support teams assisting pods


Moving to a service/microservice architecture for your application architecture is a valuable tool to building and managing large, complex applications. However, just changing architectures is not sufficient. You must update your organization structure to support the new architecture model or you won’t be able to effectively utilize the advantages service architectures offer. Without also organizing your teams around these changes, you risk falling back into old habits and processes that will result in lack of ownership and responsibility, and the same general problems you had before you moved to the service architecture.

More Information: The STOSA Model

The pod ownership model is part of the STOSA framework. STOSA stands for Single Team Oriented Service Architecture. It defines a model where service teams — pods — own all aspects of building and operating individual services.I developed this model and introduced it in my book, Architecting for Scale. It’s now available as a standalone model documented at I recommend checking it out.



Supporting developers with insights and tutorials on delivering good software. ·

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Supporting developers with insights and tutorials on delivering good software. ·