Ever since public clouds were introduced, organizations have increasingly adopted the great features that cloud solutions provide.
Almost infinite scalability, cost efficiency, reduced management overhead, and high flexibility are just some of the features that public clouds provide. All these can be used to gain an advantage over competitors. But as the IT industry goes, there has always been one thing that seems never to have changed over the years. It’s called vendor lock-in.
Cloud-agnostic solutions vs vendor lock-in
Vendor lock-in has been present in many forms ever since the first commercial software was introduced. Cloud providers practice vendor lock-in as well. They implement their infrastructures in such a way as to make it more difficult to migrate to their competitors. Software companies deploying their software on public cloud infrastructures such as Microsoft Azure, Google Cloud, and AWS must keep that in mind. After all, nothing’s futureproof and even the biggest companies can fail, significantly raise their prices, change licenses or do pretty much anything that can make life more difficult. To avoid this, the concept of the “cloud-agnostic” application was introduced.
Understanding the cloud-agnostic concept
Let’s face it, using public clouds is inherently cloud-native. For example, using the Terraform tool to create a single Virtual Machine in Microsoft Azure would require a cloud engineer to use a “azurerm_linux_virtual_machine” resource in his code. The same kind of VM would require an “aws_instance” resource in AWS, and “google_compute_instance” in GCP.
Keep in mind that VMs are a basic type of cloud resource. Before creating one, a cloud engineer must first create a private network, which would also need him to use different Terraform resources on each cloud platform in every case. And if that’s not enough, network infrastructures aren’t identical across cloud providers. Some cloud platforms require an engineer to explicitly specify which subnet goes to which availability zone and which VM goes to which data center, while other cloud providers simply allow the creation of a subnet, and any VM in such subnet can be in any data center. The decision of where to put the VM is made while creating it, not while creating a subnet.
This is just the tip of the iceberg.
There’s much, much more. Cloud providers differ widely from each other, which means you need a different Terraform code every time you want to set up a new infrastructure in a different public cloud. Terraform code can’t be migrated from one cloud to another…
What does it take to make an app cloud-agnostic?
Well, every app uses some standard components, such as a database, file storage, an ingress controller, and so on. At some point, cloud engineers and developers will have to decide which component they want to use. Let’s take an ingress controller as an example.
A cloud-native approach would opt for an AWS ingress controller if the application is deployed in AWS. A cloud-agnostic approach would opt for a more community-oriented controller like nginx. For storing documents, a cloud-native approach would opt for DocumentDB in AWS, while a cloud-agnostic one would go for MongoDB. But even so, these components would all have to be managed differently for any cloud provider, even those that follow the cloud-agnostic principle.
That’s because sometimes it would make sense to use some kind of cloud-managed MongoDB if the specific cloud supports it, and sometimes self-hosted MongoDB if it doesn’t. Regardless of which approach we pick here, cloud-agnostic or cloud-native, most parts of the infrastructure must be managed by us. The only difference is how much we have to manage.
So what does ‘cloud-agnostic’ mean?
To summarize the concept, in practice ‘cloud-agnostic’ means designing applications in such a way that they could run flawlessly throughout multiple cloud providers. This is achieved with open-source integrations and avoiding any cloud-native technologies.
How to benefit from cloud-agnostic solutions
The benefit that the cloud-agnostic approach brings is that minimal or no additional application code modifications will have to be made before migrating to a different cloud provider.
Using open-source community software brings flexibility, while the cloud-native approach quickly leads to vendor lock-in. The cloud-agnostic approach requires developers to write their code to avoid any cloud-native infrastructure or use any cloud-native functions in their code. It also requires cloud engineers to look for solutions available in every cloud. We can think of it as an investment in case we have to move to some other cloud provider for any reason.
Challenges and considerations in cloud-agnostic strategies
The flexibility that the cloud-agnostic approach introduces comes at a price.
First of all, one of the biggest benefits of adopting cloud platforms is shifting part of the management overhead to internal cloud provider engineering teams.
Every cloud provider has a group of people responsible for keeping certain parts of their infrastructure running. For example, there’s a dedicated team to take care of Kubernetes clusters, another dedicated team to manage backup stations, and so on. These teams manage thousands of instances, so the customer doesn’t have to do it. In some cases, these internal teams can also be beneficial to the cloud-agnostic approach, e.g., when it comes to open-source databases. All cloud providers have some service that runs Postgres, MariaDB, or other free and open-source databases. In those cases, the internal cloud team can always assist a customer when something happens, but only if the customer uses a database as a cloud service.
Unfortunately, that’s not always the case. For example, if a customer needs a Docker-swarm deployment, which would clearly be a cloud-agnostic approach, he will be quickly encouraged by the AWS sales team to go for Amazon Elastic Container Service. That service has its strong points but it’s cloud-native and not compatible with a pure Docker-swarm. So, if the customer really wants a pure Docker-swarm, he has to deploy self-managed infrastructure made of VMs just for that purpose. The entire management overhead is now shifted back to the customer. One of the biggest cloud advantages is lost, but when needed, migration to a different cloud provider is much simpler because we used cloud-agnostic technology. We can always create the same Docker-swarm cluster in any other cloud.
A small subset of technologies
The other thing that must be mentioned is that the cloud-agnostic fan is limited to a small subset of technologies to choose from. Usually, customers who decide to stay with a specific cloud provider for a long time don’t care if the technology they pick is cloud-native or cloud-agnostic. So in the end they have many more options, either agnostic or native. Sometimes a certain feature is needed while developing an application, but it’s available only in a certain technology. In those scenarios, if that feature is available only in cloud-native technology, a cloud-agnostic fan may have to rethink a bigger part of the infrastructure and modify it. Someone who doesn’t care which technology it is will just use the one that provides such a feature. End of story.
The right blend of cloud services
The last thing that is worth paying attention to is the combination of cloud services. Generally speaking, all cloud services are designed in such a way that combining and connecting them together is a straightforward task. If you don’t care about cloud agnosticism, you’ll probably develop a cloud infrastructure quickly, sometimes even with just a few clicks. On the other hand, you may have to spend several hours deploying and configuring some cloud-agnostic services on your self-managed cloud infrastructure.
Cloud-agnostic strategy vs use cases
All the abovementioned considerations may be acceptable at a certain scale and with a certain use case. A cloud architect may accept the overhead in some cases, but it will always depend on time. How much time and capacity does the cloud team in your company really have? And how much would they have to allocate when making your application cloud-agnostic? That’s the aspect you need to discuss internally.
Pros and cons of cloud-agnostic approaches
Benefits of going cloud-agnostic
Let’s start with one of the benefits we’ve already discussed in the previous section. If your application is cloud-agnostic, you can always migrate easily to a different cloud vendor. But it’s not just about public cloud vendors. It goes much further than that. Using cloud-agnostic approaches also enables you to migrate to on-prem infrastructures as well in many cases. It also helps you easily migrate to your private cloud if there’s any need for it. That consequently leads to allowing your application to be deployed easily in any of your customer’s private clouds. Developers can benefit from this flexibility as well. If they need to, they can quickly deploy the entire application on their laptops when testing new features. Customers could do exactly the same thing. They can deploy the trial application on their own to check if they like it or not. The list goes on, as always, when flexibility is introduced.
In the previous section, I’ve pointed out that most of the management overhead is shifted to the cloud customer when implementing a cloud-agnostic application. This means that the team responsible for application development will now be responsible for managing their own piece of infrastructure. This is true, but let’s look at it from a different angle. All, or at least the vast majority of, cloud-agnostic technologies are also open-source. Usually, open-source projects have a large community of users and developers constantly working on the project. Those communities are very eager to make their project popular so they will gladly answer all your questions if you know how to ask. Nowadays we have Slack, Discord, Stack Overflow, etc. applications full of discussions about the very diverse issues people have faced while using open-source software.
You can easily find those discussions and use some suggestions written there or you can ask a question yourself. If you’re using some technology which is more than a few months old and experiencing some issues, someone probably fixed it already. We should never underestimate the open-source community, as such people are highly passionate and motivated.
There is yet another positive aspect of the cloud-agnostic approach when using open-source. We do know that reducing our options for extending the technology stack just to cloud-agnostic ones can cause some refactoring or infrastructure redesign. But let’s think about the long-term outcome. Those teams that decided to use a cloud-agnostic approach will have some additional work to do while refactoring (which is always the case when refactoring), but when the reactor is done, there will be no more additional costs of licensing proprietary software. This is more of an open-source oriented approach, but a cloud-agnostic approach usually comes together with open-source.
Cons of a cloud-agnostic strategy
Despite the numerous advantages, I also need to mention the disadvantages of cloud agnosticism. You need to allocate additional time and resources to develop this strategy. You also must consider the cost of data transfers, which will be inevitable in the case of multiple clouds.
Cloud-native vs cloud-agnostic
Every case is different, and every organization must decide what makes the most sense for them. A cloud-agnostic approach is beneficial in many ways, but in some cases, a cloud-native one seems much more reasonable. Let’s highlight some features that both of those approaches introduce and what can usually be expected from either of them.
As you can see, the biggest advantage and premise of the cloud-agnostic approach is to avoid vendor lock-in, allowing the application to work in every cloud environment. This, however, comes at a cost. Only when taking the use case and the company’s long-term plans into consideration can it be decided whether it is a good idea to go that way or not.
Strategies for mitigating challenges in cloud-agnostic implementations
When developing a new application from scratch, it would be a good idea to let developers know that it’s supposed to be a cloud-agnostic one from the very beginning. Even if you’re not sure whether you’re going to adopt any cloud features at all, or if you’re going to stay with a specific cloud for a long time, it’s good practice to develop the app using this cloud-agnostic approach from the start. At this stage, it won’t make much difference to the engineers, but it will pay off later, regardless of the direction the app takes.
Using Kubernetes / containers
In case there has never been any need to adopt a cloud-agnostic approach in your application, start by adapting Kubernetes and containers. Kubernetes is a container management system and orchestrator. Adopting it brings numerous advantages, and cloud agnosticism is just one of them. When you have your application packed in containers, you don’t care where they run, because all internal dependencies are already solved. Using Kubernetes will also allow you to solve external dependencies between the application’s components. For example, the database, storage server, caching, and many more can be deployed in Kubernetes beside your application. You may decide to use cloud infrastructure for some of those components, but if they can run on Kubernetes, they can most probably work on all clouds and on-prem servers.
Well-thought-out database migration
While migrating, sooner or later you’ll have to face the most stressful challenge, namely database migration. Data stored over a long time is one of the most precious assets that the organization has. It also has to run without any downtime. There’s no ultimate solution to the migration issue. The process must be well thought out and thoroughly tested before performing in a production environment. What I’d recommend would be to take your time and investigate all the available migration tools out there. Since you’re moving to an open-source platform, you can expect many migration tools to be available over the internet. This step is crucial, so don’t rush it, and if you have any doubts, ask the community for assistance. You may be surprised by how many people have dealt with similar issues already and are able to help you.
Testing cloud-agnostic solutions
Once the entire process is done, test it. Check if your app is really cloud-agnostic on several cloud environments. For that purpose, you can have several different Terraform codes that will be able to manage an infrastructure in different cloud providers. Implement at least 3 Terraform codes for all major cloud providers and test your application on each one of them. This process can also be part of a much bigger testing pipeline. With that, you will be able to check if the app is running well, but you may also have a comparison between cloud providers. Which cloud provider is more cost-efficient? Which cloud provider needs some additional fine-tuning? And so on. And if anything happens, you are already prepared to run your production environment somewhere else.
Also read: 7 Cloud Computing Trends for 2023-2025
Want to learn more about the cloud cost savings?Read "The Total Economic ImpactTM of Microsoft Azure PaaS" free report and revamp your organization's infrastructure and boost innovation with Azure PaaS!
Is Kubernetes cloud-agnostic?
Yes, Kubernetes is an open-source container orchestration tool, which can run on any cloud platform. In fact, every major cloud provider has implemented the Kubernetes service and made it available to their customers. Keep in mind that using a cloud’s managed Kubernetes can be considered cloud-agnostic if you don’t deploy or use any cloud native tools like cloud native ingress controllers, certificate managers etc. You can keep Kubernetes running as a cloud-agnostic system, though only if its resources are also cloud-agnostic.
Is Terraform cloud-agnostic?
Terraform is software designed to manage any cloud resources, whether native or agnostic. It can run on any computer.
Is cloud-agnostic right for you?
There’s no ultimate answer to that question. Cloud engineers and application developers should make that decision together with stakeholders. All those people should take into account their capacity, skills and long-term development plans. My suggestion would be to start by asking yourself two questions: “How certain are we that we’ll want to stay with one cloud provider for a long time?” and “Do we have the required competences to plan the infrastructure’s lifecycle ahead of time?” Cloud agnosticism is about being prepared, and those two questions should bring some of that mindset. If you don’t plan wisely, you’ll run into problems sooner or later.