‘Ante Up’ by Keenan Constance, Unsplash

If a service can’t be provisioned and managed via an API, it’s not a Cloud service.

Avg Reading Time: 90s

Some vendors market their hosted offerings as ‘Cloud services’ without APIs, but this is misleading, at best. From What is a Cloud?:

A Cloud is a set of managed computing services backed by vast resources, billed in small increments , and made available via API.

If a service isn’t available via API, you can’t interact with it in the new technological and economic model of the Cloud where you depend on setting-up, reconfiguring, and tearing down resources quickly, on-demand via code.

There’s a ton of reasons where you might want to do this, but here are the most important:

  • refining and polishing the provider’s generic building block into a shape that fits my specific requirements by developing and testing an infrastructure code module that wraps that service in a robust, standard configuration for an important set of use cases
  • development and automated delivery of applications that rely on the service, typically as provided by the refined, custom building block

The high-touch provisioning and management approach may work for hosted offerings for some people. This can extend Enterprise DBA teams’ services that are still using manual processes. I even understand that it’s better than the alternative of running it yourself.


An offering without an API doesn’t work for ‘Cloud Natives’ nor the DBA teams trying to adopt more scalable and robust delivery via automation.

Ante-up to the Cloud game by making your service available via API. Then make it easier to adopt by adding support to Terraform and publishing SDKs for common infrastructure management languages like Go, Python, and Ruby.

Providers, please make it possible, then easy, to adopt your service with automation. Until then, your service isn’t even on the menu of Cloud service options. For 3 years, I’ve been checking the list of Terraform providers for MongoDB, RedisLabs, and Elastic offerings, but AWS services end up with the design win. Pretty much by default.

Adopters, beware of signing contracts before confirming that ‘Cloud’ service has the elements you need to accelerate your delivery process. Avoid shutting adopting service dependencies that hinder adoption of continuous integration and delivery.