Let's face it: one of the most widely used and abused terms in many technology discussions is microservice. A common pitfall in this industry is for leaders and engineers to use the terms "APIs" and "microservices" interchangeably. They should not. Just because something has an API does not make it a microservice.
The impact of using the two terms improperly is potentially significant. It not only creates an unnatural blend that dilutes the meaning of them both. Interchanging their meanings can lead to misaligned communications, misplaced expectations, misdirected investments, and undesired outcomes.
The pitfall in perception potentially steers organizations toward too many dependencies. And teams adopting microservices without understanding their inherent tradeoffs could introduce distributed monoliths that are even more chaotic than a traditional monolith, because they introduce additional and unnecessary complexities and establish brittle, hard-to-manage systems.
Treating APIs and microservices without distinction is like imagining that all antibiotic, allergy, and pain killer pills do the same thing. We've learned over and over that treating APIs with no regard for their unique purposes and boundaries can have not only profound consequences on the discoverability of the API but can also have serious potential to damage a product team’s output and velocity.
Convinced? Then let's get some serious defining done.
Key takeaways and recommendations
You can add miles of success to your digital business transformation journey as you master the Iceberg of API Strategy. Two distinct activities in the iceberg are Application Architecture and Lifecycle Management, with one centering on rightsizing the microservice and the other covering API enterprise reuse management.
How you approach application architecture and lifecycle management determines whether your overall investment in digital transformation is maximized or jeopardized. Having an ill-defined purpose, a lack of clear taxonomy, or confused management in these areas can jeopardize your digital transformation.
Three concrete ways to make the most of your investment include:
- Create a clear, consistent, and opinionated definition of microservices within your organization. Don't let teams be distracted by the many definitions out there. Clarity helps people who work together avoid miscommunications and the unintentional creation of a distributed monolith.
- Institute strong, modular boundaries between reusable and private APIs. Institute strong modular boundaries and establish the distinction between boundary/reusable APIs and inner/private APIs. Setting this demarcation between application architecture and enterprise architecture for all internal APIs and microservices encourages the "you build it, you run it" principle and promotes both product-centricity and platform-enablement.
- Implement your taxonomy. Take valuable follow-up steps to implementing the “Interface Reuse Intention” taxonomy (Boundary vs. Inner API). Leverage this taxonomy to help to apply the right level of scrutiny and investment needed based on the type of the interface, drive better discoverability, and assign or automate the relevant security policies or patterns.
Intention of a microservices architecture (MSA)
The main intention of a microservices architecture is to create the internal design and implementation details of a system. Microservices reduce coupling and optimize the speed of delivery and ease of scale. This is meant as an internal implementation detail. You can still have an API that is extremely hard to update or to scale—attributes that are not shared with a microservice architecture.
Done right, MSA provides great benefits. But success relies on implementing a full circle of processes, design, and organization. Break that circle, and you could destroy its benefits and retain only its complexity at a significantly prohibitive cost.
Microservices are not an investment in reuse
In microservices—where you should be optimizing for speed of change and agility—reusability functions only as an anti-pattern. A microservices architecture is an application architecture, not an enterprise architecture. These fine-grained APIs are not intended to be used outside the boundaries of the application or the system they compose. Given their objectives to optimize team velocity and speed to market, microservices are not prime targets for reuse.
Microservices are an investment in agility
Modularizing your system and rightsizing your components is the art of MSA. Your application should have the smallest number of microservices necessary to deliver the agility desired by the business.
When modernizing your system, follow Domain Driven Design (DDD) to guide the rightsizing of the service. It's not an all-or-nothing design decision. You don't have to begin with a bias toward one size or another; optimizing for business agility could require a miniservice or a private monolith. Twilio's Goodbye Microservices article reflects some of the hurt that microservices can deal to productivity and performance.
If you hear something like "We’re adopting Kubernetes" and "We're modernizing all our applications to use microservices architecture," proceed with extreme caution—such statements are frequently associated with well-intentioned initiatives to modernize application delivery. But the full implications of buzzwords like microservices and Kubernetes and cloud-native are often not understood when used in that context. Deploying your applications to Kubernetes or to the cloud or using a service mesh or Istio does not mean you are delivering microservices. And not every system is even best suited for microservices. It's important to understand that systems that are simply predictable and stable may be a poor fit for MSA.
Two layers of management
Note that in contrasting microservices with APIs, I identify two distinct management layers as foundational concepts in realizing the benefits of both MSA and APIs:
- Rightsizing services within a domain
- Managing system domain boundaries
Let's look at these management layers in more detail.
Rightsizing services within a domain
Following the “You build it; You run it” principle, you should define the rightsizing of a microservice as an "application architecture" activity distinct from an "enterprise architecture" activity. This definition calls for the product-centric autonomous teams within each domain to optimize business agility with a domain-focused approach.
Managing system domain boundaries
The enterprise API Management responsibility focuses on three objectives:
- Mapping and managing the domain boundaries
- Optimizing these APIs for reuse and inter-domain interactions
- Managing contracts' discoverability, usability, inventory, and security
Sample taxonomy: Interface reuse intention
It is in following this approach, versus the widely vague classification of APIs and microservices, that the taxonomy of Boundary/Reusable APIs and Inner/Private APIs is more reliably established.
Consider the elements of this definition:
- System Domain defines a logical boundary around a group of related APIs that implement associated business capabilities or functions using a common data model and business vocabulary. System domains are managed for alignment with the company's value streams, business capabilities map, or technical capability domains.
- Inner/Private APIs refer to the majority of the internal APIs that are “insiders” to a system domain. They communicate with other private APIs inside the domain. They can also call out to other domains through the ingress gateway that is configured to access the other domain Boundary APIs. These are right sized as microservices or miniservices to optimize internal domain velocity.
- Boundary/Reusable APIs are fewer in number. They represent and encapsulate the core capabilities of the domain or behaviors that are to be reused by other systems. Boundary APIs advertise the domain capabilities, and they are configured to enable cross-domain communication and cross-domain reuse. They represent the contract and interaction model with their respective external world.
Conclusion
Although often used interchangeably, microservices and APIs have distinct purposes and offer unique benefits. Understanding when and where to use these components will make your digital transformation more successful.
