Are you going to the APIStrat Conference in Nashville, or the API City Conference in Seattle?

API Deployment Is About Publishing Them Wherever They Are Needed

This is a sponsored post by my friends over at SlashDB. The topic is chosen by me, but the work is funded by SlasDB, making sure I keep doing what I do here at API Evangelist. Thank you SlashDB for your support, and helping me educate my readers about what is going on in the API space.

I spun out a separate research area for API deployment, from my core API management research back in 2012 when companies were regularly asking me which of the API management providers they should be using to publish new APIs. At the time, none of them would help you actually publish your APIs, and there just wasn’t enough conversations going on around the subject. When I give talks which include my section on API deployment, some people still scratch their heads thinking there really isn’t that many options on the table–they deploy APIs wherever they’ve been deploying their APIs. However, in a cloud-driven world, the opportunities for how and where we can deploy our APIs are increasing, and the savvy teams are getting more versatile in how they get things done.

Supporting multi-cloud is something all API service providers should be supporting. I was reviewing the approach to pricing from my friends and partners over at SlashDB, and I noticed as part of their pricing tier that they have “deployment” as one of the options. Allowing for deployment of their database to API solution on Debian, RedHat, VMWare, VirtualBox, Docker, Vagrant, Amazon, Azure, as well as custom solutions at the enterprise tiers. Focusing on the needs of a diverse range of enterprise customers, while also paying attention to where the API deployment conversation has been shifting for some time with Amazon, Docker, and the other platforms that are dominating the IT landscape.

API service providers should be supporting multiple cloud platforms like SlashDB does, but API providers should also be looking at their own API deployment in the context of multi-cloud as well. You may have your primary way of doing APIs now, but I’m guessing that once you begin doing APIs at scale, your approaches to deploying APIs will begin to shift. When I talk with companies, organizations, institutions, and government agencies about their API deploy practices, it is increasingly common to see different groups using different platforms, as well as multiple API gateways in operation. This is usually not due to some grand plan in place, and has happened in a more organic, and often disorganized way. Sometimes there are good reasons for using different platforms, services, and tools, and other times there is not–it is up to your API governance, and leadership teams to decide which is which.

API deployment should be about publishing APIs wherever you need them. It could because different teams prefer different platforms, tools, and services, or maybe it is a project or partner requirement that you deploy an API somewhere out of the norm. Regardless of the reasons the most seasoned teams I come across are able to roll with the punches, deploy their APIs where they need them, while still keeping in sync with overall API governance and standards practices. In my opinion, both API providers, as well as the API service providers should be multi-platform, and multi-cloud prepared. You may not be fluent, but be ready for the possibility that at some point you may need to get out of your comfort zone. Even if you aren’t actively playing with alternate platforms, services, and tools, I recommend reading and staying in tune with other approaches.

I’ve been pretty content with my hand-crafted approach to deploying APIs using Linux, Apache, MySQL, and Slim PHP API framework. It’s standardized, clean, and something that many of my clients can support. However, I’m rapidly shifting my approach to support AWS API Gateway, as well as beginning to play with different flavors my APIs that are deployable on Google and Azure. I’m looking to keep my toolbox focused, with my primary ways of reliably deploying APIs in as little time as possible. However, I’m fully aware that API deployment has become about being able to publish them wherever they are needed, whether it is one of my clients requesting it, or maybe it is just because I’m looking to deploy a specific API prototype, and tell a specific story on a platform I may not be 100% fluent in–pushing my API deployment skills beyond where they are today.