API Connect

Modern application development practices mandate a more decentralized approach in order to improve productivity and agility, by giving teams more autonomy to self-serve. What does that really mean from an API management perspective. Should the decentralized approach be applied right down at the infrastructure level, increasing the number of gateways and other components such that each team has their own? Or is it perhaps just about application teams being able to independently use shared capabilities of API management in a well isolated multi-tenant fashion. Which parts of the infrastructure might benefit from decentralization, and to what granularity. This post explores the deployment of the API management componentry in the light of modern application development methods to see what decentralization really means in this context.

In Part 4 of a recent podcast series on agile integration architecture (AIA), we very briefly explored this and other aspects of how API management enable a more agile approach to integration. This post gives us an opportunity to add a little more depth to the points raised.

What’s wrong with separate infrastructure for each API implementation?

An overly simplistic view of decentralization might lead us to the conclusion that every team, or worse still every component, might need its own dedicated API management infrastructure. At a minimum this would mean an API gateway for each API implementation.

[caption id="attachment_10826" align="aligncenter" width="543"] An overly simplistic view of decentralizing API infrastructure[/caption]

It is easy to see how this would quickly get out of hand, with each team having to manage their own API management infrastructure alongside their implementation. Furthermore, the mapping between exposed APIs on the gateway and the underlying implementations may well not be a neat one to one. An API’s coverage might spread across many different implementations. Furthermore, an API might be exposed in a number of different forms, to satisfy different channels and/or types of consumer. How would we then split up the gateways? The above example suggests we are looking at decentralization from the wrong perspective.

The personal side of API management

Decentralization is really about people, not technology. At a high level it is about giving the business greater agility when bringing new ideas to market. On the ground, that translates to a less centralized governance and increased team autonomy. The ability for teams to make architecture and technology choices at the local level rather than being bound by company-wide procedures and standards. To implement decentralization, what we need is not necessarily decentralized infrastructure, but more decentralized ownership. This means enabling teams to self-service their own needs, even if that happens to be on a shared infrastructure.

Arguably, API management was introduced precisely because of the needs of decentralized ownership. To understand what we mean by this, let’s go back a little to the days of service oriented architecture (SOA). For an application team to expose a web service in a well governed way they would have to revert to help from centralized integration teams. Service exposure was sufficiently complex that it required specialized skills in the deep and complex integration, gateway and service registry technologies. An application development team would have to do a lot of learning and configure a lot of infrastructure if they were to expose their own web services in a well-managed way. On the way they would have to understand how to manage identities, handle base access control, manage versioning and deprecation, implement consumer-based traffic control, and then consider what monitoring and analytics needs they and their consumers may have too. When new consumers needed to be onboarded, this would likely further involve the team to set up the relevant access. A pretty long list, that would take them away from their day job of writing a business application. Hence the exposure of web services was given to a separate centralized team of specialists. Implementing web services therefore involved both the application and integration team which significantly slowed down the pace of delivery.

[caption id="attachment_10825" align="aligncenter" width="608"] A summary of the core API management capabilities[/caption]

API management set out to change all that and make it much easier for someone from an application development team to expose their own web services (although by now they were called APIs). They would no longer need help from a separate team of specialists. Many associate “APIs” with the move from complex course grained, SOAP-based web services to more fine-grained HTTP/JSON based RESTful interface. There’s some truth to that, but it hides a more important story. The real change was the refinement of the requirements around exposing interfaces to new audiences. In short API management capabilities enable non-integration specialists to expose their own APIs.

Whilst API management capabilities may still have rich and complex products performing the hard work under the covers, these are now largely hidden from the user. They provide a straightforward user interface specific to the task of API management. This enables application developers to define and expose their interfaces themselves. The API management capability does the rest. For example, you don’t need to know how to configure the API gateway directly as the API manager configures the gateway for you. It also pushes the API definitions out to a developer portal. The portal enables consumers to discover the APIs they want to use and simple mechanisms to self-subscribe to their use. Then at runtime, metrics on usage are collated automatically and made available to both the API consumer and provider, potentially even with billing mechanisms involved too. Notice, nowhere in the above did we mention the need for a separate team required to expose the API. The complex work that the central team used to do has been embedded in the API management tooling. The role of defining and exposing APIs can then be “decentralized” out to the teams building the APIs, and the consumers of the APIs.

Decentralized ownership, with centralized infrastructure?

API management therefore enables decentralized ownership of API exposure. What then does this mean in terms of how the API management capability is actually implemented? We have already discussed that decentralizing the infrastructure, with for example a separate gateway for each implementation, is likely to add unnecessary complexity. Could we just have one API management infrastructure across all APIs yet still provide decentralized ownership?

[caption id="attachment_10824" align="aligncenter" width="872"] Decentralized ownership, centralized infrastructure [/caption]

A good API management capability should provide strong multi-tenant capabilities such that it can happily expose APIs from multiple separate implementations and yet still provide good isolation. For example, managing heavy traffic through one API (and perhaps limiting it in relation to the policy defined for its consumers) should have no effect on the performance characteristics of any other APIs also passing through the gateway at the same time. Equally there should be zero chance of any leakage of runtime data between APIs. This should be true of course not only on the gateway, but also in the other components. There should be no risk that the people configuring one set of APIs via the API management user interface can make changes, or even see, the other API configurations that are present. The portal access should separately control portal pages for each independently administered API. The rules as to who could view and subscribe to the APIs would also be separate for each API. So, in short, each API is defined, managed and administered only by the team that created it, and is made available to only those consumers that they deem appropriate. A true multi-tenant architecture.

There’s nothing technically stopping us from having a separate gateway for each API implementation. However, given the above multi-tenancy capabilities, it is questionable what benefit it would actually have. The configuration, runtime data and performance characteristics are suitably isolated and independently administrable already. We can imagine we might be concerned about a very high level of guaranteed availability and not want to run the risk of being affected by downtime caused by other APIs. However, given to define and expose an API we are generally not delivering code, only configuration, it should be pretty hard for someone defining an API to cause instability on the API management platform. Furthermore, we would expect the API management platform to provide sufficient redundancy, and have fast enough component recovery times that any outages that did occur would be barely noticeable.

Perhaps we should be thinking of API management more as a facility available to our applications rather than as a part of the applications themselves. An analogy would be network infrastructure. We wouldn’t typically expect each application to have its own network routers for example, they’re an infrastructural capability that we share from the platform on which we sit. This is especially true when we use an API management facility that is inherently part of a cloud platform and installed and managed by the vendor. An example of course is the managed offering for IBM API Connect within IBM Cloud. In that scenario it becomes irrelevant how the vendor provides the multi-tenancy, only what level of service it assures.

When might we want separate gateways?

This brings us neatly on to the flip side of the coin. Whilst a gateway per implementation is clearly too granular, there are some reasons you might want, or indeed need to break up some of the API management infrastructure.

A reason to split gateways that we see in today is based on the lines of business. Each line of business may want a completely independent gateway for their part of the organisation. This could be for reasons of independence and decoupling, or it might be down to more practical issues such the different lines of business having different network domains.

[caption id="attachment_10823" align="aligncenter" width="743"] Gateways per business domain[/caption]

As such we see perhaps a gateway per line of business. Note that it may still make sense to share the API management and portal across the enterprise using the multi-tenant capabilities mentioned above. Runtime independence is perhaps more critical in the gateway than it is in the other components.

Ultimately, we are balancing agility against manageability. The technology, largely, will allow the infrastructure to be as physically centralized or decentralized as we want for each of the gateway, portal and API manager components. The more decentralized the infrastructure, the greater the benefits for example of agility, and the more control over downtime. This can be compared against the benefits of a shared infrastructure which would include things such as a smaller number of people to manage the infrastructure, less administrative tasks to be performed, efficiencies of infrastructure usage and so on. Every organization has a different set of priorities, and indeed even within an organization there may be different priorities in each business unit.


The multi-cloud challenge

Looking from a much broader architectural perspective, many organizations today not only have a “hybrid” infrastructure, where they have components spread between on-premises, but also have a “multi-cloud” infrastructure. Their infrastructure is spread across multiple cloud vendors. This might be for reasons of redundancy or perhaps because of certain features required that are only available on some platforms, or because of cloud platforms inherited as a result of using major “software as a service” applications. Each of these platforms may come with its own API management capability, but if we were to adopt all of them the technical diversity would be constantly increasing. It would also make for a disjoined consumer experience if APIs were served from radically different portals and API catalogs.

[caption id="attachment_10822" align="aligncenter" width="681"] Independant gateways to address multi-cloud challenges[/caption]

It may be better to pick one API management capability that is able to manage multiple gateways (one on each of the platforms) from a central API management facility. This could then publish definitions to a single portal that consumers could use to explore and subscribe to all available APIs. It would only be the URLs of the APIs themselves that might give away that they lived on different gateways and even that could be hidden if required.

Conclusion

We therefore have the best of all worlds.

• The simplicity of the API management capability enables decentralised ownership such that teams can completely own the administration of their own APIs.


• The multi-tenancy of the API management facility enables this to be provided by a centralized infrastructure to simplify the overall architecture.


• The architecture is componentized such that for example it could have multiple federated gateways yet still have them all managed centrally.

From a skills perspective, API management technology such as IBM API Connect enables decentralized ownership of API exposure. It makes it straightforward enough for an application team to expose their own APIs rather than requiring a separate team to do that. That of course leads us to more practical questions around decentralization. How ready are you as an organization to transfer that much control to application teams? Just how “DevOps” are you prepared to be. Are teams who normally focus on application creation and maintenance prepared to take on “application operations” responsibilities of exposing APIs too? In which environments? Should they perform the configuration of API exposure even in the production environment, or only in earlier environments. These are much deeper questions about how to refactor roles across the organization that would be better handled in a post of their own. The important point here is that the technology no longer gets in the way. We can decide the organization structure based on the needs of the business rather than the skill-sets required for the technology.

Acknowledgements

Many thanks (in alphabetical order on surname) Aiden Gallagher, Nick Glowacki, Chris Phillips, Sebastian Sutter, Ozair Sheikh for their input and review on the above material.

Further reading

As noted at the beginning, this subtle topic of decentralization is a core part of how organizations are moving to a more agile style of integration. You can read more about agile integration architecture (AIA) in the free eBooklet, or listen to the recent podcasts.

We’ve published a number of posts recently describing how API management contributes to a more agile approach to integration, including the following:

• Microservices and APIs: Defining application boundaries


• Comparing a service mesh with API management in a microservice architecture

A regularly updated list of all posts on AIA is published here.