APIs vs. Microservices: Why you need both

I spend quite a bit of time helping organizations transform their existing IT platforms to improve reliability, resilience, and stability. A key element in that process is expanding the use of Microservices and APIs. It turns out that most companies that are focused on digital transformation need to deploy both APIs and Microservices in order to get the flexibility and stability they need in order to "move fast with stable infrastructure" (to borrow a phrase from Facebook's Mark Zuckerberg).

Sometimes, when I point out that companies need both APIs and Microservices, things can get confusing. "Microservices have APIs, right?" I am often asked. "Why do you say we need two things?" Well, it turns out the APIs exposed by your microservices are not the same kind of APIs that you want when you leverage those services to solve your business problems (and the problems of your customers). And, more importantly, you'll need both kinds of APIs to build a healthy IT ecosystem.

Confused yet?

Let's break it down...

The Stability of Microservices

One of the key advantages of creating an ecosystem of Microservices is that you get to segment your IT infrastructure into coherent elements. You can release one or more services focused on customer account management, another set of services to handle warehouse activities, another for sales tracking, and so forth. Often these services operate more effectively when implemented with a focus on solving a related set of problems with a single domain. And, during the process of transforming your existing services, you get to create small, more efficient implementations that each live within your defined domains. 

Independently Deployable Units

Even more valuable is the practice of creating and releasing microservices as independent units of IT infrastructure. Many of the companies I work with have built up a large single codebase for meeting their unique business needs. That means even small changes in the system require a build-test-release cycle for the entire codebase. This is usually a grand effort fraught with danger and, because of these challenges, updates are limited to just a few times per year.  

But a microservice approach allows companies to reduce the "surface area" of the codebase they need to change in order to implement an update. And, when done well, releasing smaller units of computing into the IT environment means less disruption and, over time, more forward progress. That's why microservices are so important to adding stability to your existing system. 

Supporting Internal Communications on the East-West Axis

Of course, having lots of services means supporting lots of inter-service communications; that's where APIs come in. And the APIs you need to create here will focus on efficient and secure interactions between existing services (most of them behind the firewall). Often these APIs are referred to as operating along the "east-west" axis of IT communications. 

Designing and building east-west APIs means solving the problems for your internal IT staff. This often means generalized services like data access and workflow management using well-known objects and models that are often unique to your own company's culture and history. And these APIs are used by teams that usually have a shared understanding of the organization's goals and objectives. That means you can create APIs that assume lots of "tribal" knowledge, leverage historical practices, and rely upon internal security modeling. In short, service APIs exist to solve internal challenges; often segmented by department-specific domains (accounting, sales, manufacturing, marketing, etc.).

That's very different from the APIs that your external consumers and partners will need.

The Flexibility of APIs

The internal, domain-centric service API ecosystem is very different from the kind of API ecosystem external users need. Typically, external API consumers (for example, trusted partners, distributors, etc.) are focused on solving their own domain-specific problems. And those problems do not usually match the ones experienced within your organization. In other words, customers have their own unique challenges and need APIs built for *them*.

This customer-focused approach to creating APIs is often at the heart of the API-First movement and epitomized in Clayton Christensen's "Jobs-To-Be-Done" mantra. Essentially, customers don't care about your data model or object model, they just want to solve their current problem. The less they know about your problems, the better! That means the API design for external consumers is needs to reflect that point of view.

Crossing Boundaries with North-South APIs

The key defining element of consumer-focused APIs is that they almost always operate on a "north-south" axis with the "north" end starting at the API consumer or client and the "south" end terminating at the API producer. In this approach, it is important to focus on speed and safety across the network in order to deliver requested data quickly and securely. And there is another important difference between "east-west" service APIs and "north-south" customer APIs: that is the need to cross domain boundaries.

It is not at all uncommon for API consumers to "mix" APIs from several sources into a single client application. Often a business problem like customer onboarding will require interactions with internal customer services, external credit and identity validation services, and even sales and marketing services. That means you'll need to design APIs that cross domain boundaries, not ones that isolate them. This is especially true for cases where you want to provide high-level solutions for external partners. Rather than ask them to understand multiple domain models in order to solve a single problem, well-designed north-south APIs offer a single, coherent interface that addresses the consumer's problem.  

So, it turns out the common approach when solving customer problems is to use APIs to *cross* domain boundaries. That's very different from the approach when working with internal APIs where the goal is to support services *within* domain boundaries. That's why I often talk about Microservices (internal) and APIs (external) differently. And you need both for a healthy IT ecosystem.

The Power of APIs and Microservices Together

The power of internally coherent services accessed through domain-specific APIs is greatly enhanced when it is combined with externally-focus APIs that mix multiple domains to solve a customer-specific problem. This approach has been around for quite a while and is what Mulesoft's Stephen Fishman calls an "Experience API". Focusing the API consumer's experience is the key to creating robust API solutions that follow Christensen's Jobs-To-Be-Done mantra. 

The challenge, however is to *not* design your internal "east-west" API landscape to match your external "north-south" consumer needs. This is basically linking your internal and external models so tightly that even slight changes in customer requirements leads to disruptive modification of your internal microservices. That is a recipe for trouble.

That means keeping your internal and external models loosely coupled is essential in this new IT ecosystem of small, dedicated services and effective task-oriented APIs. One way to do this is to clearly separate the teams that handle the internal services and teams that handle the external experience APIs. This kind of approach is described in the book "Team Topologies" where "Platform Teams" provide the basic services used by "Stream-Aligned Teams" that focus on solving workflow problems. 

Supporting a mix of service-centric internal interfaces with consumer-centric external APIs is the best way to ensure a stable service infrastructure that can support the flexible experience APIs your customers -- and your own developers -- can count on to solve ongoing business problems without needless disruption to your existing IT ecosystem.