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. 

Copyright © 2021 IDG Communications, Inc.

Source link