Do you remember the time when the world was young and we were running one API Gateway and one Developer Portal? Back then they were called API Portals, but it’s a story for another time.
APIs are everywhere … and so should be API Gateways. Is it reasonable to expect all the API traffic to be routed via one, central API Gateway? Or should API Management be invisible and blend into the landscape? What is the right number of gateways to have? The answer is both simple and complex.
It’s simple, because you can, and should run as many gateways as you need. If you no longer need one, you just decommission it. Need one more for a few days or hours? Run it, use it, then remove it.
It’s complex, because the more gateways you have, the more complex and distributed the landscape is, the more difficult it will be to manage and administer them. Sometimes, I may want to organize my gateways based on where they run geographically, e.g. maintain American gateways separately from European gateways. In another case, I may divide the gateway landscape base on the purpose they serve e.g. client facing gateways or gateway hosting API products, supporting or backend gateways etc.
This calls out for an API Control Plane solution. One that would tell API platform providers how many runtime they have and if all is healthy and provides enough capacity for API product managers to host their API products and monitor and analyze their use across the entire landscape. More about the control plane soon.