Multicloud and Agnosticity challenge

Why a cloud native strategy ?

Of the organizations using cloud services, more than 75% indicate they have a cloud-first strategy (Gartner). A strong cloud strategy influences all aspects of application development. It’s important for enterprises to use a cloud-first approach for app architecture, practices, tools, and the team.

Some best practices for a cloud-centric approach include:

• Avoid vendor-specific services for easy lift.
• Automate as much as possible — including VPC, infrastructure, build, test, deployment, etc.
• Keep up-to-date on cloud platforms (e.g., products, APIs) and update as needed.
• Treat infrastructure as code.
• Use a CI/CD pipeline to transmit updates to multiple cloud systems at once.
• Create abstraction layers to isolate vendor-specific code from core functions.

Being cloud-first may not be enough. There are significant risks that could cause a cloud project to blow up. What could go wrong?

• The cloud supplier shutters. While it is unlikely for the big 3 to abandon operations, when partnering with small or newly established vendors there is a risk for continuity of their service or offering.
• The contract with your current cloud provider ends and you decide to switch providers for cost or feature benefit.
• The cloud provider doesn’t meet the requirements for a new business initiative or geography.
• Having too tight dependencies on vendor-specific services may make migration too painful.

In a recent Gartner survey of public cloud users, 81% of respondents said they are working with two or more providers. The dominance of megavendors in the public cloud services market is behind the main reason that enterprise buyers choose multiple cloud providers, says Michael Warrilow, VP Analyst, Gartner.

“Most organizations adopt a multicloud strategy out of a desire to avoid vendor lock-in or to take advantage of best-of-breed solutions,” he says. “We expect that most large organizations will continue to willfully pursue this approach.”

Multicloud computing decisions usually rest on three considerations:

1. Sourcing: The desire to increase agility and avoid or minimize vendor lock-in. The decision may be driven by a variety of factors, including availability, performance, data sovereignty, regulatory requirements and labor costs.
2. Architecture: Modern applications are, by design, created in a more modular style. They can span multiple cloud providers or consume services from multiple clouds.
3. Governance: To ensure operational control, enterprises want to unify administration and monitoring of their IT systems. They want to standardize policies, procedures and processes and share some tools — especially those that enable cost governance and optimization — across multiple cloud providers.

The difference between cloud platforms is vast. To prepare for these situations, we need to go beyond cloud-centric and be cloud-agnostic. There are many reasons we may need to migrate or expand from one cloud provider to another. Being cloud-agnostic is a way to add flexibility, speed, and reduce costs.

Cloud Agnostic approach is the key to your organisation saving Time, Money & Headache

With 81% of enterprises that use public cloud facilities using multiple providers, a cloud agnostic development strategy is becoming a necessity. Applications and infrastructure simply has to be compatible across public, and private, clouds if practical levels of flexibility are to be built in.

As described in the previous section, even for those organisations that currently use only one public cloud provider, cloud agnostic development is the only way to insure themselves against the future headache and expense that vendor lock-in might become. If infrastructure and app architecture and development is not cloud agnostic, potential future decisions to move to a multi-cloud footing, or simply change one provider to another, become limited and complex.

In the next sections, we will explore:

1. The benefits of a cloud agnostic approach
2. Cloud agnostic strategies and technologies

Benefits of a cloud agnostic approach

Flexibility

A cloud agnostic strategy takes the flexibility inherent in the use of public cloud facilities up another level. If workloads and applications are built to run within any public cloud, preferences can be set to switch them between different providers based on their performance and cost efficiency in the context of dynamic factors like geography and the strengths and offerings of different providers. Or if one provider experiences temporary technical issues.

Being cloud agnostic offers a level of flexibility which improves cost efficiencies even more than simply using the public cloud. Especially for organisations with high workloads, even incremental differences in cost can add up to significant sums. And for many digitally enabled organisations, incremental gains in performance and insurance against technical problems on the provider-side is as much of an incentive to becoming cloud agnostic as cost efficiencies.

Avoiding Vendor Lock-In

A Bain & Company report found that 22% of companies that use public cloud facilities see the risk of vendor lock-in as one of their biggest concerns. The term vendor lock-in refers to an over reliance on the products or services of a particular vendor. That leaves the organisation vulnerable to prices being raised, changes to or the discontinuation of particular offerings or even, in the worst case scenario, operations being halted.

The vendor lock-in can present many risks:

• Vendors can change their product or offerings, shifting focus to a new technology or different business needs, so they no longer align with your expectations.
• If the quality of service declines or does not meet your expectations over time, you may be stuck with it due to the legal commitments or your dependency on that specific service building your vendor lock-in.
• Any vendor can significantly change their price for the service or you can get an attractive deal from a different cloud provider.
• Finally, vendors can go out of business. And while this is an unlikely situation for the big 3, let’s remember the case of public cloud data storage provider Nirvanix, which went out of business back in 2013, giving their clients only two weeks to move their data

This means that even for organisations that only use one public cloud provider because their service currently meets their needs on pricing, performance, functionalities, capabilities and reliability, it is important to build applications and infrastructure in a way that allows for an easy switch if circumstances change.

Reliability

Spreading systems and workloads across more than one cloud platform avoids the risk of redundancy and downtime if one encounters problems.

Cloud agnostic strategies and technologies

Being cloud-agnostic is about being able to build & deploy applications, which can run on any cloud platforms. You can take two approaches to be cloud agnostics, do not depend on any SaaS service of a particular provider or cautiously select the services while architecting the platform. We decided to pursue the second option

While there is no right or wrong way to adopt the cloud agnostic strategy, there’s a number of proven practices to consider.

• Microservices architecture
• Containerizing your application
• Compare cloud platforms & choose the right services
• Automate-first mentality
• OpenSource as much as possible
• Ensure good development behaviors and best practices.

1. Microservices architecture

Microservices architecture structures an application as a collection of services that are broken into small units, each serving a specific business function and interacting with each other. Applications, especially if intended as cloud agnostic, are easier to both build and maintain when broken down into more manageable microservice units. Microservices are:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

Unlike monolithic architecture, the microservice architecture allows for the rapid, frequent and reliable delivery of large, complex applications. It also far easier for organisation to introduce changes or additions to its technology stack within a microservices environment.

We recommend to follow the below principles for building services.

• Follow the twelve-factor app methodology
• All services to follow The Bezos Mandate or The API manifesto

2. Containerizing your application

Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of the target environment.

Docker has changed the way we build, package and deploy our application. Now, no more statements like But, it works on my machine If it runs on Docker, it will run everywhere. Container technology existed before Docker, but Docker just made it easier to use and distribute.

3. Go for container orchestration

While containerization provides benefits on its own, it wouldn’t be nearly as valuable, as with container orchestration engines. These runtime platforms allow you to run, coordinate, and manage the lifecycle of containerized workloads. For a cloud agnostic deployment, there should be no binding between the workloads and the underlying cloud infrastructure, and the best way is to run your containerized workloads on a cloud-agnostic container orchestration platform.

There are quite a few mature and popular platforms that can run containerized workloads on different kinds of infrastructure and the most known one is Kubernetes, which became an industry standard over the last couple of years.

Originally developed by Google, Kubernetes is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. In fact, Kubernetes has established itself as the defacto standard for container orchestration and is the flagship project of the Cloud Native Computing Foundation (CNCF), backed by key players like Google, AWS, Microsoft, IBM, Intel, Cisco, and Red Hat.

Kubernetes is cloud agnostic, it runs on Amazon Web Services (AWS), Microsoft Azure, and the Google Cloud Platform (GCP), and you can also run it on-premise. You can move workloads without having to redesign your applications or completely rethink your infrastructure — which lets you to standardize on a platform and avoid vendor lock-in.

4. Automate-first mentality

Cloud agnostic strategy can increase the workload on DevOps engineers, so you should focus on the automate-first approach. Your infrastructure should be easily scalable with little to no manual effort. The same principle should be applied to CI/CD pipelines. There’s a great amount of tools that help users set up CI/CD processes. Some of them are open-source like Spinnaker and Jenkings, while others are commercial tools, e.g. Bamboo or CircleCI.

You should also automate services deployment and provisioning by using IaC tools: Every cloud vendor has its own mechanism of running infrastructure templates; however, the vendor-specific syntax of each tool makes it much harder to switch from one provider to another. To solve this approach in a cloud-agnostic way, several 3rd party tools allow you to script your infrastructure on most leading cloud providers, giving you an abstraction layer to the underlying IaaS.

Because of scope and complexity, there are not too many tools that can support IaC in cloud-agnostic setups: Cloud Foundry BOSH, Red Hat Ansible, and Hashicorp Terraform, which is most popular in cloud-agnostic IaC setups. Terraform provides you with APIs to work with each of the leading public cloud providers and many on-prem virtualization platforms.

5. Ensure good development behaviors and best practices.

Provide the team with a set of tools for building, storing, deploying artifacts, and managing configuration. Code should be part of every step of build/deploy/configuration. With these guardrails in place:

• Migrate the smallest, most isolated components (e.g. Node.js APIs, UI).
• Transform heavier, legacy components gradually.
• Transmit changes from one system to another.
• Break it to fix it: You may need to invest in some refactoring to become cloud-agnostic.

7. Opensource

Using open source technologies means that you can work on any cloud platform and move from one cloud to another with minimum problems if pricing, offerings and performance change.

6. Compare cloud platforms & choose the right services

The decision of choosing services from many cloud providers should not be done lightly. There are many options to choose from with a variety of considerations that impact whether your cloud becomes a thunderstorm.

There is no clear such thing as the best choice for the cloud. Cloud platforms are not identical when it comes to the services they offer. Requirements change.

Focus on shared industry standards vs. a specific provider. It’s worth repeating…avoiding vendor lock-in is critical. Favor flexibility without sacrificing the build or abstract proprietary services.

Also, select services & frameworks which are common among multiple cloud platforms. Write the applications to use the service based on the cloud provider.

Common challenges

Some say that “Cloud agnostic architecture is a myth,” or that “If you believe in the cloud (and its speed), you can’t be agnostic as it forces you to use the lowest common denominator of all cloud services”. The chart below shows the spectrum of available options:

In this case, cloud native means that we take advantage of a given cloud provider’s strengths (i.e. better performance, better scalability, or lower costs).

Overall, the more you invest in agnostic architecture upfront, the less it’s going to cost you to switch cloud services. However, at the same time, more complex and agnostic design will decrease productivity and slow down your delivery process. Architects are challenged to find a satisfactory optimum — a solution that’s as agnostic as possible, but which also respects the agreed time and budget scope. How can this be achieved? Well, for example, you can consider switching costs as suggested by Mark Schwartz, an Enterprise Strategist at AWS. He encourages businesses to consider:

1. The cost of leaving a cloud provider

2. The probability of the above taking place

3. The cost of mitigating cloud switch risk

Another challenge of cloud agnosticity is that the company will need a team of developers who are capable of working on multiple clouds. This includes managing and operating on different infrastructures.