Centralised or Decentralised APIM

A few months ago Microsoft released a "pay as you go" consumption pricing model for Azure APIM. I have been eagerly awaiting this release because I felt that the move represented a change in the way vendors view APIM and the idea that APIM was no longer just a premium product for for the few but instrea could be a commodity product used by everyone and you just pay for what you use.

With this change in mindshift I began to wonder if this change would affect how we deploy and use APIM within our architecture.

What does centralised APIM look like

With centralised APIM you are likely to have a centre for excellence for APIM or a dedicated team who have a primary part of their job being to look after the APIM instance and to connect the organisations services to the instance.

All services are exposed through the single instance, all seciurity is managed in one places.

What does decentralised APIM look like

With decentralised APIM, each product team building services for their product has their own instance of APIM. The APIM instance is managed by the product team and contains just their own API operations.

Things to consider

With the two different approaches above there are some considerations to be made.

APIM Scale

There are a number of different scale options for APIM. The consumption model will fit really well with the decentralised approach, but the other price models might be too expensive for most organisations to have more than one instance of APIM.

I think the biggest feature difference which may affect things in this scenario is the multi-region support. The premium sku of APIM has this but the others do not at time of writing. The premium sku is most likely to be bought as a centralised APIM platform.

Cost Management

Cost management is a lot more important today than it used to be. The ability to cross charge IT costs are important. With the decentralised approach it is easy to apportion APIM costs for a given instance to the running costs of a product. In the centralised approach this is a lot more difficult.

You will also need to consider scaling challenges with the centralised approach. Lets say I have 2 products which are only small users of the centralised service and 1 product which is a significant majority user. In this case an agreement for splitting the cost may have been made. If i now need to scale and add another node or increase the sku to a higher value version of APIM would the cost split still be fair.

Delivery Constraints & Change Management

I think the area that is likely to cause the most challenges is around delivery and changemanagement. When you come across centralised IT assets they have dependancies with multiple things and managing these dependancies is a big challenge. I could see scenarios where multiple projects might have conflicting requirements or demands on the centralised APIM product or the resources who manage it.

The decentralised approach would take away the conflict over access to resources and platform, but each APIM instance would need to manage its own dependancies.

Support

When it comes to support you either have the product teams managing the decentralised APIM instances or a centre for excellence managing the central instance.

The centralised approach is likely to encounter resource conflicts at some stage which the decentralised approach is less likely to encounter.

Consistency

One of the big advantages of the centralised approach is that it is easier to enforce consistancy and standards on the API implementation and usage. The decentralised approach makes this harder to do. It is still possible but you may have to work harder to keep things consistent.

Discoverability

One of the obvious features of a centralised APIM approach is a single repository and place to go to see all of your API's.

It is perhaps harder to implement discovery patterns when you have a de-centralised approach. By its nature there is no single place to go to find all of the API's. This may or may not make sense depending upon your organisation. IF for example there are no relationships between your products then why would you need a central repository of those API's. It probably just complicates things.

Can we have a bit of Both?

Above you can see that the APIM question falls very distinctively into the usual considerations for a centralised vs a decentralised IT asset. There are a few APIM specific things but lots of the things to think about are common.

The question about whether we can have both options is interesting. You could certainly do this provided you are happy with an additional cost. You could maybe manage product API's in the decentralised approach but then when you want to externalise a subset of your API's to the outside world you may bring them through a centralised APIM which acts as a router and enforces some standard approaches and is managed by the centre of excellence. This centre APIM may also be a consumption based pricing one too.

Explore more on Secure Azure Functions Using API Management