In my first cloud migration project, we were tasked with migrating the client’s consumer product website from AWS to their on-premise datacenter. This was for data privacy reasons, they didn’t trust amazon with their preview product data at that time. But the challenge was keeping the existing site live on AWS while we perform the migration.
So we built a chef plugin that would switch the deployment between both sites seamlessly without any downtime. The plugin development was done in two weeks. When I showcased this to the client, at the end of the sprint cycle, he asked “so you only wrote 10 lines of code in two weeks”. I was shocked and amazed. Lesson learnt: Never show code in a business showcase 🙂
Very recently I saw a similar job posted on linkedIn where the requirement was to build an adapter for 10+ cloud backends to solve a multi-cloud deployment problem. Seeing this reminded me of that project 10 years ago and got me thinking, is it really worthwhile to invest time and money in cloud agnostic tools, when you should be focused on running your business. Many SaaS companies indulge in building their own in-house cloud agnostic plugin/adapter/platform/tool to address customers hosted in a variety of clouds. This, although sounds cool and is a dream project for any engineer, often such products end up being operational overheads and end up in monoliths in themselves.
I prefer simple and clean setups, let’s face it, we have had enough tools and platforms. We don’t want another one. We don’t need cloud agnostic tools. What we need is a cloud compatible one. That way we can build cloud agnostic infrastructure designs which can be deployed in any cloud or on-premise with the technologies available.
And if you look at it carefully, every cloud provider does the same. For instance, be it AWS or GCP they use the same Postgres that PostgreSQL has launched. All they do is install, manage and provide apis for us. That’s why you will see the management part differs but the underlying software remains the same.
Every cloud is different, as they should be since they are different business entities. They only try to keep the logical topology similar(not same).
That’s why as a product builder you should focus on choosing technologies that can be supported on most cloud platforms and build a cloud agnostic architecture. That way it can be set up anywhere. This is called portability across providers.
Cloud Agnostic vs. Cloud Portability
While the concept of being cloud agnostic—designing systems to run on any cloud platform—sounds appealing, it can lead to significant overhead and complexity. Developing truly cloud-agnostic applications requires avoiding vendor-specific features and services, which can limit functionality and performance. Instead, focusing on cloud portability—ensuring applications can be moved between cloud providers with minimal friction—can be a more practical approach.
Cloud Portability: A Pragmatic Solution
Investing in cloud portability involves designing applications and infrastructure with the capability to transition smoothly between different cloud environments. This approach balances the benefits of leveraging cloud-specific features with the flexibility to switch providers if necessary. By utilising infrastructure as code (IAC) tools and adhering to best practices, organisations can achieve portability without compromising on functionality.
The Myth of the Perfect Vendor
Honestly, if the vendor is good, I don’t mind locking in. But unfortunately that’s too good to be true. Even the most reputable and reliable vendors can have outages, policy shifts, or pricing changes that negatively impact their customers. Moreover, as organisations grow and evolve, their requirements may change in ways that a single vendor cannot accommodate. Thus, placing complete trust in one vendor is not a viable long-term strategy.
For example: many startups have recently migrated from AWS to GCP for very simple pricing reasons. AWS prices at an hourly rate while GCP gives a per second pricing. Plus with longer commitments the discount offered can be as much as 30% compared to AWS. Such pricing is very lucrative for startups who are scaling and have to also achieve higher ROI.
At the same time I have seen migration from GCP to AWS for higher supportive and mature service offerings.
Transitioning from one cloud provider to another can be a daunting task, but it is entirely feasible with the right strategy and tools. While some organizations struggle with migrations for extended periods, a well-planned and executed approach can significantly reduce this timeframe. My experience in migrating a live banking system from AWS to Google Cloud Platform (GCP) in just four months exemplifies this.
The key to a successful migration lies in meticulous planning and robust IAC practices. By writing IAC correctly, organisations can define and manage infrastructure in a consistent and reproducible manner. This not only simplifies the migration process but also ensures that infrastructure can be quickly rebuilt in a new environment.
Best Practices for a Cloud Agnostic Infrastructure:
Modular Infrastructure as Code (IAC): Don’t just automate, modularise and parameterise server configurations, relationships with other servers in code. Server configuration, packages installed, relationships with other servers etc should be modelled with code to be automated, removing error prone manual steps. For example, If you are using terraform don't create one module and try to execute every resource from that. Instead create independent modules for each infra component and a separate module to provision these. These can be called module and provisioners. Here is how modules and provisioners structure for can look like.
Abstract Application Logic: Decouple application logic from vendor-specific services. Use containerisation (e.g., Docker) and orchestration (e.g., Kubernetes) to facilitate portability.
Implement CI/CD Pipeline As Code: Create version controlled CI/CD pipelines as code for provisioning infrastructure. There must be separate stages for specific tasks. For example, you can have one pipeline for creating a Kubernetes cluster with separate stages for different environments like dev, test, prod etc. Pipeline as code can be used beyond provisioning, for upgrades, patching, data migration, in short any automated task that happens in infrastructure.
Create a Centralised Command Center: One stop centralised command centre for infrastructure administration. Prevents vendor lock-in. Centralised logging, monitoring and identity management for better observability
Monitor and Test Regularly: Regularly test applications in different cloud environments to identify potential issues early. Monitoring tools can provide insights into performance and help detect anomalies. Write tests to validate functionality of each IAC module. Infrastructure must be performance tested to meet the benchmarks before going live in production.
Leverage Multi-Cloud Strategies: While not necessarily cloud-agnostic, adopting a multi-cloud strategy can provide redundancy and flexibility. Use different providers for different workloads based on their strengths.
Conclusion:
Don't Put All Your Eggs in One Basket:
Reduce Truck Factor, a.k.a Don't put all eggs in the same basket. While many reasons can drive more towards a hybrid model, this one in particular is the reason to drive an organisation from one cloud to another. This helps create a redundant/alternate network for always-on services and helps to mitigate vendor lock-in issues.
Relying solely on a single cloud vendor can be risky. Market shifts, vendor-specific issues, or unfavourable changes in pricing and policies can significantly impact business continuity. Diversifying cloud infrastructure across multiple providers can mitigate these risks and enhance resilience. However, this strategy requires careful planning and execution to avoid the pitfalls of vendor lock-in.
Avoid Vendor Lock-In:
Vendor lock-in occurs when an organisation becomes overly dependent on a single provider a.k.a vendor, making it difficult and costly to switch to another vendor. This dependency can stifle innovation, limit flexibility, and increase costs over time. While some may argue that a good vendor can justify the lock-in, the reality is often more complex. No vendor can guarantee perpetual alignment with an organisation’s evolving needs, and unforeseen circumstances can necessitate a change.
If you like this article do like 👍 and share ♻ it in your network and follow Kamalika Majumder for more.
Don’t let your best-selling product suffer due to an
unstable, vulnerable & mutable infrastructure
Thanks & regards
Kamalika Majumder
Comments