Don’t get me wrong, if you want to just gateway an existing API using AWS, Azure, or Google, it is pretty straightforward. You just have to learn each of their mapping techniques and you can quickly define the incoming request, and out going response mappings without much effort. However, for this exercise I was looking for an end to end actual deployment of an API, not the proxying or Hollywood front for an existing API. If you want to launch a brand new API from an existing datasource, or a brand new API with a brand new data source, I found AWS to be path of least resistance. I was able to launch a full read / write API using AWS API Gateway + AWS DynamoDB with no code, something I couldn’t do on Azure or Google, without specific domain knowledge of their database solutions. I had only light exposure to DynamoDB, and while there were some quirks of the implementation I had to get over, I was able to stand up a completely new API with just a couple hours of work. I could have done similar with Google and Azure, but from what I could tell they would require some code in between the database and the API backend—something I will tackle in future work.
As I was wrapping up this work, and preparing to write some stories about it, I came across a blog post from Red Hat introducing the service binding operator, which as their way of streamlining how you bind backend services in the Red Hat universe. It go me thinking about the need for standards, or at least common approaches to how we map the backend of an API to other APIs, but also how we map the backend of APIs to other common systems. I’m too old and jaded to think we’ll pull together a common standard for everyone to use, but man it would be nice if they weren’t so wildly different. The cognitive load with Azure, even with their pretty slick resource manager, and with Google was just too much for me to tackle in a short time frame. If I can justify the investment I will be diving in deeper on Azure and Google in January, but for now I’ll be focusing on the low hanging fruit with Amazon. While my objective is multi-cloud API deployment, I have lots of work ahead of me to streamline Postman collections that help you quickly deploy different types of APIs just to AWS. I will need someone to tell me they have a need for Azure or Google before I dive in deeper there.
All of this work is about defining one of the more difficult stops along the API life cycle—deployment. API deployment means so many different things to many different people, and is a word that has been hijacked by API management and gateway providers to mean the publishing of an API facade, making it a really difficult thing to actually nail down and discuss. After years of investment in the API life cycle why is API deployment still so complicated? It shouldn’t be. We’ve had all the moving parts for easily deploying from databases, using API definitions, and other approaches for years. Why haven’t they come together into a single suite of open source, cloud, or on-premise solutions. Well, the answer is more business and political than technical, and something I’m not looking to solve. I am just looking for ways to help standardize, streamline, and talk about until API deployment gets a little easier. Right now the challenges in binding APIs deployed via gateways to backend services is largely too cumbersome and technical for the average API provider to realize--we can do better.
