content_image/974864.jpg content_image/974870.jpg
<img src='content_image/974864.jpg'>

It is easy to see how this might quickly get out of hand. Does each gateway need its own API manager and Developer Portal? It would be painful if each team had to manage their own API management infrastructure alongside their implementation. Furthermore, the mapping between exposed APIs on the gateway and the underlying implementations might not be one to one. An API’s coverage might spread across many different implementations. An API might be exposed in many different forms to satisfy different channels or types of consumer. How would you split up the gateways? Figure 3-8 suggests that in the case of API management that you should not be looking at decentralization from an infrastructure perspective. 

You might notice that we deliberately used the phrase decentralized integration ownership . We are intentionally emphasizing that it is the ownership that must be decentralized among teams and not necessarily among the infrastructure as well. In the case of API management, the thing you are decentralizing is the ownership over the ability to administer APIs (the provider perspective) and the ability to discover, subscribe, and use them (the consumer’s perspective). API management deliberately designed to make it easier to decentralize ownership of the APIs so that providers and consumers could administer their own APIs without referring to a central team. 

We already described that distributing the infrastructure, for example, with a separate gateway for each implementation, adds unnecessary complexity. As shown in Figure 3-9, could you have one API management infrastructure across all APIs and still provide decentralized ownership? 

<img src='content_image/974870.jpg'>

