Standarizing the cloud

Standardizing the Cloud

It is been a while since “the cloud” as we know it today started, probably we can say the first mover on this segment was Amazon with its AWS (Amazon Web Services), coming along later Microsoft, Google, and IBM…

In the initial age, we could observe providers just offer a simple set of IaaS (Infrastructure as Service) services, the basic toolset to replicate our traditional on-premise datacenter on the cloud provider datacenter.

Services offered on the initial IaaS providers.

The Cloud services layer was pretty simple at this point, having the foundational layer, IaaS, where the majority of consumers and providers were focused and a few players on PaaS (Platform as a Service) and SaaS (Software as a Service).

At this time (around 2010-2011), the hype of the IT technology was “the cloud computing” and how to move workloads to this new “paradigm” (as media use to call it).

This has been evolving and in the last years, due to the hype of the “Cloud” and how this technology has proven to be an enabler to speed up development and innovation, the landscape changed and is crowed:

Cloud provider matrix

The diagrams above, obviously, don’t represent all providers on the game, just try to give an idea of provider’s population has evolved and will continue evolving getting more and more complex, actually today the pyramid in terms of players is inverted. This article aims to show how to get the most of this diversity by simplifying the usage and management.

**NOTE**: I’m simplifying the layers, some people would add DBaaS (Database as a Service, Business), BPaaS (Business Process as a Service), or similar.

The final target of any enterprise is to run their core application/services securely and reliable, the ones that generate revenue or help teams to generate it, and the supporting services. These landscapes of applications and services have different requirements in terms of availability, resiliency, and performance, those different services and consumption models are there to help enterprises to meet these requirements.

Enterprise’s strategy, in any industry, try to avoid dependency of their business on a single provider, as their business could crash if this provider fails to meet expectations for any reason: crash, price increase, platform not evolving … This is translated also to the Cloud segment, were the initial trend was to move to a hybrid cloud strategy, where the enterprises mixed on-premise clouds with off-premises clouds trying to cover the weakness of one with the other and vice-versa, at the same time these enterprises tried to maximize the strong points of each one.

The latest improvement of this strategy is the “Hybrid Multi-Cloud Strategy”, where companies use one or different clouds on-premises, like VMware, Hyper-V, OpenStack,… and several Public Cloud providers, like IBM Cloud, AWS, Azure,… This heterogeneous landscape is created to allow the company keeps running in case one provider or hypervisor fails (in case of on-premise clouds), and maintain the availability and performance requirements for each application or service, basically making them resilient. This hybrid landscape can also be inherited in big enterprises due to the acquisition mechanism, where several companies have to be consolidated and they use different providers. 

Well, this seems like a good strategy, but introduce some big problems:

– IT Management of very different providers

– Lack of skills on the different providers

The approach to solve this problem I like to call it “Cloud Standardization” (probably I’ve heard in another place I don’t remember). The way to achieve this standardization is by leveraging Kubernetes technology, this container orchestration platform can run on any cloud, on-premise, or off-premise, and helps to abstract from the underlying platform (public or private cloud), and let enterprises keep the focus on the core application or services development.

Kubernetes helping cloud standardization

The image above depicts how is possible to leverage the Kubernetes platform in different cloud providers, abstracting developers and other technical teams from the complexity of each cloud provider. They see each cloud provider as an endpoint where they can point deployment pipelines to deploy their cloud-native apps or endpoints to consume middleware services.

Following this strategy we can leverage another level of “microservice architecture”, having, for example, an AI app microservice that consumes a specific Artificial Intelligence service on AWS using a specific AI service just available in AWS or because it happens to suit better for that specific task, while we can also have a specific AI app microservice in IBM Cloud consuming specific AI service in IBM Cloud for the same reason.

This “cloud standardization” helps organizations to focus on their core business applications and services instead of having to spend valuable time on organizing and manage the different clouds because of the diversity of technologies on the underlying layer.

The concept of a hybrid cloud could have some flavors, like multi-cloud and a multi-cloud provider. The difference between a multi-cloud and a multi-cloud provider strategy is :

–      Multicloud provider strategy involves more than one cloud technology provider, which also implies more than one cloud instance. Cloud instances are normally in different locations.

–      Multicloud strategy involves just having multiple cloud instances of the same underlying technology or provider, like having VMware cloud on-premise, and other instance of VMware in IBM.

The K8s Manager showed in the picture is managing the different instances of the K8S clusters deployed on the different clouds. These K8s managers can manage the entire lifecycle from the instantiation of the K8s cluster on each cloud provider to the lifecycle and security of the apps deployed on top of each K8s cluster.

This is very powerful for IT teams as they can control where an app is running, choosing among different endpoints (cloud providers), and applying policies and specific RBACs to each one. These policies help to maintain the security of each deployment, automate them, and also to keep the availability and resiliency needed across the different clouds.

You can see an example of one of these K8s managers, Red Hat Advanced Cluster Management, ``.

Hope this vision helps you guys to simplify the lifecycle of the cloud deployments, leverage all cloud provider’s strong capabilities, and reduce the weak ones.

Leave a Reply

Your email address will not be published. Required fields are marked *