Multicloud and hybrid cloud are emerging cloud computing trends which describe the use of multiple cloud providers or a mixture of cloud providers and own infrastructure capabilities. These trends hint at a change in paradigm in the cloud business - a shrinking dependency on providers.
Historically, AWS (Amazon Web Services) has been the biggest player in the market. As early as 2006 the company launched its most prominent cloud offerings (S3, EC2). This provided AWS an enormous head start over its competitors. The largest competitor, Microsoft’s cloud offering Azure, started public operations roughly 6 years later. Today, AWS still has the largest market share, but it is decreasing.
The term vendor lock-in describes the situation, where a customer is dependent on a provider because of the high costs of switching to a competitor. Traditionally, this has been a prominent problem in the cloud business. Every cloud provider has its own set of tool offerings, all of which are similar and have largely overlapping functionality, but cannot be easily transferred to another provider. Developers often specialize in one cloud provider and there is no “export-import” button to support the provider switch.
Then why is the AWS market share decreasing these days?
The vendor lock-in explains why AWS could sit comfortably on their first mover advantage for many years but others are slowly catching up. This could be primarily due to another trend: An abstraction of the implementation from the underlying services.
There are different products of cloud computing suppliers which differ in their level of infrastructure abstraction and services offered.
On-premises describes software which runs directly on the servers which are managed, maintained, and supervised by the company developing the software. This provides the highest customization to the setup but has major drawbacks. Hence, the company needs devops personnel for maintaining the server and taking care of the infrastructure and faces high initial investment costs. This additional overhead is costly, as businesses want to focus on their core activities, developing and providing solutions. For special use cases where rigorous data protection requirements are involved, on premise might be a suitable solution. However, most of the time this is not what companies want nowadays.
IaaS (Infrastructure as a Service)
IaaS describes the provisioning of compute, network, and storage resources on a flexible basis. Companies in the need of resources can book and deploy them flexibly without having to buy and maintain the underlying hardware. This provides flexibility and can reduce costs. There is no need for detailed disaster recovery plans as this is outsourced to the infrastructure provider.
CaaS helps by providing tools to easily manage applications which are encapsulated into a container. Containerization allows apps to run in a controlled environment that is always exactly as described.
PaaS (Platform as a Service)
PaaS extends on the services provisioned by IaaS and additionally includes tools to manage, develop and launch applications on top. This way, coding time can be reduced and the application management (scaling, monitoring, …) can be supported.
FaaS (Function as a Service)
FaaS is the easiest and quickest way to ship code. The developer just needs to provide the code to the FaaS-supplier and everything else is taken care of. This way, time-to-market can be drastically reduced and new versions are deployed quickly.
More and more tools and offerings emerge to provide developers with a convenient and fast way to provision infrastructure for applications. Developers switch to a “define requirements once and forget about it”-mentality. This way, they can focus on their core business without having to worry about anything else.
If the infrastructure and environment is defined in a standardized format in code, switching cloud providers is also easy. You may need minor tweaks in the configuration but that is all. No lengthy setup in the user interface is needed. If the whole application runs inside a container and no external services are needed, IaC might not be needed at all. Developers just hand their containers to the cloud provider and let them handle the provisioning. No additional setup is required.
A shrinking cloud dependency implies less risk when planning to implement cloud solutions. A viable path for a transitioning from an on-demand or an old cloud provider to a new cloud provider could involve the following steps:
1. Containerization of the application
2. Defining (previously used) infrastructure demands in code using Terraform
3. Testing the configuration in the old environment
4. Testing the configuration in the environment of the new cloud provider
5. Switching the production environment to the new cloud provider
Switching to cloud or switching cloud providers was previously a large and complex project that could take months or even years of planning and execution. Nowadays, this transition is a lot easier, however a thought out plan is still essential.
OMMAX can help you to draft a battle plan that fits your needs and helps you make it happen. Reach out to us to discuss your requirements!
I would like to speak to an expert in: