A while long ago, a friend asked for some advice regarding introducing an API gateway (API GW) into his company.
As I was a little bit surprised about my own answer, I want to share it here.
Context
Paraphrasing the question:
I am working in a company that has three different development teams. Each team is building their own services, which are exposed directly to our customers. There are lots of inconsistencies between the APIs exposed by the three services, which our customers have to deal with. Would you recommend us to introduce an API gateway?
As we both have worked together, we had a shared understanding about what we meant by an API gateway. Given the broad and generic term that it has become, the main functionalities of our API gateway were:
- One place to have all the common functionality required when exposing APIs externally: authentication, authorization, rate limiting, A/B testing and other routing requirements. Also it can take care of some caching, downstream service error handling and i18n.
- Make the heterogeneous internal services look homogeneous to external clients: naming conventions, concepts, url structure, versioning, timestamps, pagination, …
- Provide a more coarse-grained API.
- Keep backwards compatibility on external facing APIs, while internal services can evolve.
And from an architecture point of view, the change would be from this:
To this:
Pure technical answer
Nobody would argue that having a homogeneous, coherent API that shields clients from possible internal API changes is very valuable.
Our clients will love it.
Our developer will love it.
But you need to think about the cost.
What the cost is
When we talk about cost, we usually put too much emphasis on the initial investment.
As I told my friend:
I think the initial cost of building the API GW is not huge. You can build it over a weekend, or a team of four can do it over a couple of months.
Jokes aside, that last sentence has a kernel of truth, which gives us a clue about the kind of cost we should be more wary of.
Keeping with the conversation:
The issue that I see is the maintenance: who is going to own the API gateway?
Because the most important thing on the architecture change is the change on team dynamics, from:
To:
With this new team setup, you have to start thinking about how the different teams will interact between each other:
- How internal service changes will need to be implemented and rolled out?
- What information needs to be shared between the API team and the other teams?
- What meetings will be required?
- Who will decide on priorities?
- Where will some of the functionality will be implemented: API GW or internal services?
- Who can veto an API change?
- Who can veto an internal service change?
- How will support be handled?
- ...
This is not to say that the new architecture is worse, but that all these questions should be taken into consideration when deciding if an API Gateway should be introduced or not.
Of course, this new team setup is just one of the possible ones. There are plenty of others (none of which is wrong) that will give different answers to the questions above, like:
Shared responsibility, no accountability
Where all teams own the API gateway, but nobody takes accountability.
The API Council
Where all teams agree to meet monthly to agree on API rules, and that is the only agreement that is ever reached.
The Architects Overlords
Where all powerful beings dictate the API rules for mortals to implement.
The Ignored Embedded Architects
Where architects work along side the development teams, and meet monthly to whine about how their wise advise is completely ignored.
The All Powerful API Framework
Where the Platforms team provides a mandatory API framework so that teams can run their own API-rules-compliant gateways, and where all teams do their best to avoid, circumvent and replace with battle tested Open Source alternatives.
A Team oriented answer
So to answer the question "Should I introduce an API Gateway in my workplace?" the main concern, and what you should focus on, is not the technical aspect of it.
The important question to answer is:
What are the team dynamics that you want for you company, given its current context?
Conway's law at its best.
Top comments (0)