Abstracting public clouds down to common services

The advanced features of public cloud providers’ native services offer clear benefits. Most enterprises now exploit cloud-native patterns in developing new applications, even in the augmentation of migrated applications. However, most enterprises would like to minimize lock-in to specific cloud service providers. Guess what? When you leverage a cloud provider’s native services, those services are not transportable across clouds.

This makes it obvious why containers have become a megatrend.

IT typically considers containers a good idea because everyone is using them, and it’s good to follow the crowd that’s also creating a development ecosystem. Also, containers can scale by using cluster managers and orchestration services, such as Kubernetes. 

Finally, containers are a nifty way to abstract the applications away from the underlying native services, which make the applications more portable from cloud to cloud. Also, containers make it less important to consider the features and functions of specific public clouds than when applications are not abstracted.

So, what’s the downside to containers?

There’s the obvious fact that containers themselves, including all the goodies in the container ecosystem (orchestration, security, storage, etc.), are becoming a common platform that runs across public clouds. Today’s developers and application architects no longer think in terms of storage and compute services from a specific cloud provider. Instead, they consider storage and compute services in general as abstracted notions that can be translated into specific native services using containers that address these resources as common services and are treated the same across clouds. 

To the application and to the developer, native services are now common services that operate independently of the public cloud platform the application leverages. The specific value that public cloud providers offer does not really matter anymore unless performance issues or outages occur. Thus, the public cloud provider becomes a common, commoditized utility service. 

We’ve seen parts of this movie before. Public cloud services brokers promised to find and utilize the best and least expensive cloud services among the different providers. However, you still had to leverage these services using the native API or interface offered by that provider. 

What’s different is that most of what a cloud service is, including the interface, management, and operations, is abstracted into a set of common approaches and services that operate across cloud providers. This could make cloud services largely the same in terms of what developers and the actual applications see. Moreover, this could extend to other native services such as security, governance, observability, data storage, etc. It all becomes a set of abstractions where the cloud brand may not even be known. 

Although some of these capabilities exist now, most container developers are very aware of what cloud or clouds they use. However, the idea of abstraction to remove both the conceptual and real dependencies on cloud providers may make its way into more and more cloud development. 

Certainly, if the underlying cloud services become commoditized, containerization makes the investment in applications that much more valuable. Moreover, the cost of application development and deployment should fall with containerization, given that abstracted services can be mixed and matched. 

Where does this leave public cloud providers? Businesses will leverage services using a provider’s native interface or via an interface that can translate native services to abstracted common services, either through containers or other mechanisms. In either scenario, the providers make money. I view this as a win/win.