by • January 12, 2023
About a decade ago, cloud computing became the norm in enterprise IT deployments. Infrastructure as a Service (IaaS) and Integrated Platform as a Service (iPaaS) vendors were fiercely competing to deliver the private and public cloud products that would power the next generation of app development, processing, storage, and networking. And since APIs are at the heart of cloud computing, the race was on to deliver the API that developers and sysadmins would most favor.
The Cloud API War had begun.
Since then, the marketplace has chosen the winners and the losers. The war may have quieted down, but it’s more important than ever for a cloud service to offer an efficient API. Here’s a look back at the Cloud API War and how it shaped how data is managed today.
Sign up for our free 14 day hosted trial to learn how.
From the beginning of the public internet, tech reporters and analysts envisioned something similar to what we call “the cloud” today: a network of applications, data, and other digital resources available anywhere, from any device, as a service.
Of course, a few things had to happen before the cloud became a reality. First and foremost, the costs of broadband internet and mass storage had to come down. Mobile computing had to become widely adopted, which finally happened with the advent of smartphones and the shift from monolithic, single-purpose applications to mobile apps.
Suddenly, the infrastructure and the software were in place to make cloud computing the new norm. And the glue holding it all together, both then and now, is the web service API.
Web service APIs enable the sharing of data across platforms, allow developers to build new functionality, and provide an efficient way for platform management. The Cloud API War started when IaaS and iPaaS vendors raced to offer comprehensive cloud computing solutions to the enterprise with the most robust and easy-to-use API.
Early on in the Cloud API War, the OpenStack platform gained a lot of traction in the marketplace with some notable deployments.
OpenStack was started as a joint effort between the cloud-hosting giant Rackspace and NASA. By 2012, the nonprofit OpenStack Foundation was formed to take over management. By providing a compute engine, network connectivity as a service, block storage, identity management, metadata services, and much more, OpenStack was one of the first enterprise platforms for managing cloud deployments.
Beyond NASA, OpenStack has been used by other government organizations in the U.S. and worldwide, along with a long list of major global tech companies. As an open-source project, it attracted major corporations as sponsors. And since it could be installed on-premise, it proved popular with enterprises that weren’t ready to move their IT strategy to the public cloud all at once.
Businesses easing their way into the cloud also appreciated that OpenStack is not tied to one particular vendor. Other cloud providers in the API War at the time included Azure, which was seen as a very Microsoft-centric service, and Amazon Web Services. Since AWS was not established as the developer-focused service it is today, it didn’t initially gain widespread enterprise adoption. Sysadmins and CIOs were concerned about vendor lock-in via proprietary interfaces that could potentially not integrate between public and private clouds.
OpenStack and other sophisticated cloud services made it easy to allocate new cloud infrastructure with the click of a mouse. But over time, a lack of developer-facing services began to be seen as a problem.
Developers had to spend months or even years building RESTful interfaces to access the databases and other assets that were just provisioned. This started to feel like a trip from the cutting edge of cloud computing back in time to the old-fashioned LAMP stack.
OpenStack also had a large codebase with many optional modules. No two deployments were the same, and with many contributors to the open-source project, supporting a unique installation often fell on in-house system administrators. If the OpenStack Foundation had core priorities at the time, they were operations activities like virtual machine deployments, storage, and networking.
While system administrators can easily switch between services at the IaaS and iPaaS levels, this is more difficult for client developers. This is a much larger ecosystem with very diverse application requirements, software frameworks, and development environments. Developer-facing services, accessible via API, are widely used throughout modern applications.
Some vendors took note of developer frustrations and began to look for more effective ways to lock customers into proprietary interfaces. Tech observers and journalists noted a move up the stack from ubiquitous commodities to targeted products that command a higher profit margin and raise switching costs.
An opportunity for the next victory in the Cloud API War opened up. The market was looking for a product that didn’t have the large overhead of OpenStack — one with more developer focus.
The Google Cloud team announced Kubernetes in 2014 as a publicly available offshoot of their Borg cluster manager.
In 2021, Linux vendor SUSE discontinued its OpenStack-based cloud management offerings in favor of its Kubernetes-based products and services. Industry watchers took this announcement as proof that Kubernetes was the new winner in the Cloud API War.
As a container orchestration system, it’s not immediately apparent that Kubernetes is even in the same product category as OpenStack. And while you could make the case that they’re not in the same class, the success of Kubernetes is a sign of how fluid a technology “war” can really be.
Kubernetes caught the attention of companies during a wave of mass public cloud deployments by focusing on the emerging cloud technology at the time — containers. The rapid adoption of Docker and the container ecosystem occurred simultaneously as the rise of microservices, microapps, and other developer practices powered by web service APIs.
The “building block” approach of Kubernetes and web services directly appealed to developers in a way that OpenStack never could. A Kubernetes environment features several that developers use to customize microservices and integrate them with other services. In the end, it didn’t matter that Kubernetes wasn’t developed as a direct competitor to OpenStack. It found favor by fitting into modern API-focused ecosystems.
Kubernetes is also much easier to install and maintain. It’s available in certified distributions from the Cloud Native Computing Foundation, providing a level of support that the much larger OpenStack ecosystem can’t match. And because it has a modular approach focused on containers, Kubernetes can be built on top of any public cloud, easing concerns about vendor lock-in.
If there was a lesson for enterprise customers and cloud developers to learn from the Cloud API War, it’s to be prepared. Although there will always be vendors, products, and development methodologies on top at any given time, things change.
You can expect some cloud platform vendors to put forward various developer-facing services in an attempt to lock customers into proprietary interfaces. Other vendors might decline to pursue this strategy, but they risk losing developer mindshare without a compelling product. The danger for enterprise customers is that switching costs will rise, reducing flexibility and increasing the cost of application deployments.
Another lesson from the Cloud API War is that proprietary interfaces will reduce the compatibility between public, private, and hybrid cloud installations.
Many early adopters of public and private cloud solutions also found that their systems had grown too large to manage. Updates were challenging to apply, and the industry had no significant consensus regarding addressing issues. These are the growing pains that companies go through when they’re the first to adopt new technologies and development methods.
But in the Cloud API landscape today, it doesn’t have to be that way. The DreamFactory API management platform can be installed on any server, in the cloud, or on-premises. Or you can use our proven iPaaS service. We provide a comprehensive set of secure developer-facing services that expose all of the backed SQL databases, NoSQL databases, and file storage systems.
Developer applications can easily be moved between clouds or from the cloud to the data center. Individual databases and backend systems are also abstracted, providing an additional layer of flexibility. And since DreamFactory is an open-source software package, proprietary lock-in is not dangerous. It’s the one tool for all your API management needs.
To find out how a dedicated API management platform will always work for you, no matter who’s winning the Cloud API War, register for your free 14-day trial today!
Automatic APIs With PostgREST for PostgreSQL
As a seasoned content moderator with a keen eye for detail and a passion for upholding the highest standards of quality and integrity in all of their work, Spencer Nguyen brings a professional yet empathetic approach to every task.
Join the DreamFactory newsletter list.