The rise of microservices architectures drastically changed the software development landscape. In the past few years, we have seen a shift from centralized monoliths to distributed computing that benefits from cloud infrastructure. With distributed deployments, the adoption of microservices, and system scaling to cloud levels, new problems emerged, as well as new components that tried to solve the problems.
By now, you most likely have heard that the service mesh or Istio is here to save the day. However, you might be wondering how it fits with your current enterprise integration investments and API management initiatives. That is what I discuss in this article.
Solving the interaction challenges
Netflix was the first to separate out the application networking layer and they created their famous OSS stack including Hystrix, Eureka, and Ribbon among others. Docker, in turn, developed the container runtime and the image format allowing Google to work on abstracting their infrastructure and open source Kubernetes, one of the most important projects of this new cloud-native wave. Soon developers all around the world realized Kubernetes offered new tools to solve the problems Netflix targeted in the past.
Subsequently, the Envoy proxy—a high-performance, distributed proxy originally developed at Lyft—provided the foundations for the service mesh. The service mesh is the connectivity between application services that adds capabilities like resiliency, security, observability, routing control, and insights. Istio, an implementation of a service mesh, allows applications to offload these capabilities from application-level libraries down to a layer below.
At the same time, along with the technical changes described above, organizations started their business journey into digital transformation. The traditional approach for how to profit from established channels was shocked by the emergence of new digital-native challengers in every vertical.
From Uber to Airbnb disruption by software, new players appeared in the field to take market share or to offer new ways to tap into unexplored markets. The interaction among these players added to changes in regulations in regions like the European Union, lead to the growth of new ways to create value by providing access to their systems and processes. Thus, we call the “API economy” the effects of organizations developing software applications to access software via APIs to create new functionality and value, both for themselves and the wider world. My colleagues Steve Willmott and Manfred Bortenschlager wrote an insightful book called Winning the API economy about this topic. I encourage you to take a look.
Taking control of your APIs
In the API economy, a focus on the value of an API is crucial. That’s why most API designs specifications are carefully crafted from the business perspective and go beyond the raw service to service communication. In the business API world, managing the relationship between the internal and external API consumers and API creators requires a well-crafted strategy.
API management enables teams to provide easy discovery and documentation of hundreds of available API assets and flexible ways to address the types of access for different developer teams, as well as straightforward consumption billing and invoicing. API management takes care of these types of requirements for the API owners.
API management addresses even more than discovery and documentation for an API initiative, however. The best products also offer:
- Access control and security
- “API as a Product”
- API subscriptions plans and usage limits
- Analytics and reporting
- Developer engagement
- Billing and invoices
The API gateway is the element traditionally used to enforce these requirements and comply with other general policies. As my colleague Joaquim Moreno Prusi states in his blog post, API Management and Service Mesh,
“API management is NOT (only) rate limiting.”
Following the same train of thought, let’s not stop there; instead, let’s expand the idea with the following statement:
“You don’t get API management by using an API gateway.”
As I mentioned before, API management involves more than just implementing the gateway pattern for API calls. Most of the time, you will need to decouple the actual management components from the policy enforcement point.
The network of microservices
Because a managed API responds to a business goal, many times you will find that what’s behind in the implementation side is that many service calls address a single API request. With the increase of services, the interactions between them grow too and expand the complexity of managing the network. The more pieces you add to the architecture, the more places it can fail. Christian Posta does an interesting recap of some of these problems in his blog post The hardest part of microservices: Calling your services.
Hence, the service mesh helps teams to solve in a more elegant way some of the previous concerns like service calls, load balancing, observability, and resiliency. A mesh, implemented with Istio, for example, removes all the Netflix code embedded in the services and delegates the implementation to the proxy sidecar. Configuration, then, is also managed independently from the business logic and code. In this way, sysadmin teams can take back control over how the service interactions are monitored and enforced.
Until now, most of the interactions between APIs and services respond to very generic concerns. However, a third stage opens when we need to deal with domain-specific interactions. Making decisions based on the business context of a service call goes far beyond the generic approach that API management or service mesh can provide. Some providers propose bundling everything together just to justify legacy components. In my case, I prefer to avoid this proposal because I agree with ThoughtWorks on the risks of dealing with overambitious API gateways.
Therefore, when dealing with “connect and compose” requirements, it is better to delegate the implementation to well-tested, distributed integration frameworks that implement already known enterprise integration patterns. Developers and integrators can use these tools to correctly handle the orchestration, data transformation, or content routing at the business domain level.
Common ground for service mesh, API management, and enterprise integration
As we have seen in the previous paragraphs, we have solutions that have common ground to address modern application development. However, they focus on solving targeted aspects of the problem because they were conceived to solve different problems in the beginning. For this reason, we don’t see them as competitors or replacements for each other, but as complementary options that need to be deployed in a well-designed architecture.
The following image gives a very high-level overview of targeted users and the concerns and common features of API management, service mesh, and application integration.
Service mesh will be able to do some rate limiting, but it won’t be able to handle subscription-plan-based security. It will be able to do some routing and retries, but there will be a large overhead to make content-based decisions.
I must acknowledge that playing together is a challenge, because technology is never still and things like serverless and K-native are popping up everywhere. As Christina Lin shares in her My 2 cents on the future of integration, when dealing with real-life architecture design, you still need logic to “be written somewhere.” So I’m sure many other solutions will land to address newly discovered issues.
Trying to make a decision? Remember the common saying “when you’re a hammer everything looks like a nail.” Beware of people trying to solve everything with the same tool when you really need a wide range of toolsets.
No comments:
Post a Comment