My prediction for the future of Cloud Service Providers

-

While I don't claim to be as prescient as Nostradamus, I've had an idea about a major change in cloud service provider offerings for the past two years. Recently, I came across news of a collaboration between Microsoft Azure and Oracle Cloud, which gave me a sense of déjà vu. 

Hybrid-cloud and multi-cloud are gaining popularity, and companies like aviatrix are offering services and products to facilitate these options. However, multi-cloud also presents challenges, such as the complexity of enabling private communication between workloads across different providers and the additional cost of networking ingress and egress. 

I predict that major CSPs, such as Amazon and Microsoft, will recognize the demand for other providers' services and offer multi-cloud capabilities as a native feature, without the need for extensive manual configuration or third-party tools. 

I envision a future where an AWS VPC can connect to an Azure VNET in a specific subscription with just a few clicks in the AWS console, or a few lines of Terraform or CLI command. This kind of connectivity could unlock new potential in different areas of business. For example, customers could use the best of cloud offerings across different providers with far less complexity than they face today. As a customer, I could run my compute on Azure AKS, while my persistent layer uses Amazon RDS and S3, and I use GCP for machine learning and AI use-cases. 

It's difficult to say when this future will arrive, but I believe it will happen sooner or later.

Comments

Post a Comment

Popular posts from this blog

Azure CNI vs Kubenet, What are the differences between them and which one to use?

-
Image
if you have ever deployed an AKS cluster, either through the Azure Portal or CLI, there is parameter that needs to be configured related to the networking part of AKS and that is to choose the networking model between  Azure CNI and  Kubenet. ( by default it's Kubenet as of writing this post) So what's this all about? in a nutshell this parameter is related to how Nodes and Pods gets their IP addresses assigned. It\s important to understand their difference before creating the cluster since you can\t change the networking model of your cluster once it\s deployed, and you defiantly don't want to re-create and re-configure your cluster again just because of this option. Overview of Kubenet and a few things to keep in mind This is the default options if you don't explicitly change it. With this option the cluster nodes gets their IP addresses from the VNET which your AKS is deployed to. This is not a big deal since the same thing happens if you go with the second option, ...
Read more

AWS EKS vs Azure AKS - my thoughts and reflection after using both in Production

-
Image
I am lucky enough to work both with Azure AKS, and AWS EKS(EC2), and I decided to dedicate a post on my blog about the two. I have also to admit that this is the most opinionated post I have written so far. I tried to put more emphasises on their differences than to write about their similarities. Here are the three areas I comparing them:  AKS vs EKS from Cluster Management Standpoint,  AKS vs EKS from Networking Standpoint,  AKS vs EKS from Scalability Standpoint AKS vs EKS from Cluster Management Standpoint  Both AKS and EKS mange the master node (AKA Data plane) for you completely, and there isn't much difference I notice in that area between the two. However, Azure does not charge you anything for the Master node it manage and you only pay for the worker nodes, however, EKS charge you a fix price monthly for that Master node (around USD 70 dollar depending on the region) One feature I like in EKS is called Managed Node Groups . This feature automate and off...
Read more

Architecting Kubernetes for High Availability, Fault Tolerance and Business Continuity

-
Image
Kubernetes can take care of many things, and can solve many problems except the ones it doesn't know about such as region failure and  human errors. In this post I want to compare and contrast the differences between Single Cluster setup spread across multi Availability Zones that is very common vs Multi Cluster Setup Spread across different Region . Hopefully by then end of this post you have some clue about when to use which setup no matter which cloud provider you are using; be it AWS, Azure, or GCP. Single Cluster Setup: In this Setup the Kubernetes nodes and their storages are distributed across multiple Availability Zones (AZ). This model ensures the nodes are physically separated from each other and the outage in one of the AZ will not cause the entire cluster to go out of service. At the same time the communication between each node is via private connection and does not route over internet no matter which cloud provider you use. I took the following image wh...
Read more