The True Cost of Being Cloud-Agnostic
Let’s talk about the real cost of cloud computing, and by that I don’t mean hourly pricing models, network charges, and licencing implications.
I want to talk about opportunity cost, explore factors like speed to market, how effective our development teams can be, and the operational overheads involved in our technology choices.
The famous Allan Denot once said...
“If you believe in the cloud, you can't be agnostic.”
...and by famous I mean in DevOps/Sydney, and by once I mean January 2019.
I believe in the cloud! When I make that statement, it doesn't mean I promote "only using the services that are available in all clouds" or "building all of your own services from scratch so they work identically in each cloud".
I'm a firm believer in using the right tool for the right job, and the right cloud or clouds for your project, program or organisation. I'm a cloud believer and I don't have a vested interest in any one cloud.
There are many ways "the cloud" can make your life easier. If you're looking for a simple way to store and retrieve files, and you're okay with it taking a few seconds, not a few milliseconds, AWS S3 is a great option. AWS RDS is an ideal way to use the relational database that you know and love without having to be hands-on with installation, upgrades, and replication. Are you a Microsoft shop? It's hard to pass up Azure for services like hosted Active Directory. Do you only care about writing code? Google App Engine is an amazing service for Planet-Scale web services with all of the infrastructure managed for you.
But what about the other definition of being cloud-agnostic? What about the dream of many organisations that we keep hearing so much about in the industry…
Cloud-agnosticism is great! No vendor lock-in, more customisation, but wait. Think of all those tightly integrated managed services you're leaving behind.
If you read the article by by Maish Saidel-Keesing called "Cloud-Agnostic: Friend or Foe?" this provides some great insights into this topic.
Trying to be cloud-agnostic may lead you to "only use features that are available in all clouds", which is the lowest common denominator, or "deploy in such a way that we can switch a given workload to any cloud in minutes depending on the hourly price of a given service", which I've not yet seen an organisation achieve.
The scary path I’ve seen too many organisations follow is the idea that we should build as much of the system as possible in-house to avoid any sort of lock-in.
The avoidance of cloud vendor products or even third party SaaS products for fear of being locked-in has been a common theme with the organisations I've worked with. I've never found the right way to describe the flaw with this way of thinking until I came across the following article which compared cloud provider lock-in to databases:
“If we choose to use Oracle as the database for a given application, we don’t usually also build the application on SQL Server to make sure we aren’t locked in to Oracle. We don’t do so simply because we believe that the costs of having two alternative databases for the same application will outweigh the benefits in risk management.”
"Switching Costs and Lock-In" is a great AWS blog that explains the difference between switching-costs vs lock-in.
If cloud-agnostic is the "wrong strategy", what is the right one?
It would be foolish of me to prescribe a magic bullet for your cloud journey. Having a well thought out application migration strategy and a shared vision for the future of your application architecture should be a key part of your strategy. If I only had a few minutes to set you on the right path I'd ask you to consider the following:
- Containers - these are a great way to make your application code portable. From AWS ECS/EKS and Fargate for fully managed containers, to Google's App Engine which allows you to bring your own container and let Google worry about the rest
- Managed Database Services - Managing databases is hard, using a cloud vendor’s managed database services could save you time and money, and allow you to focus on your core business. Switching later doesn't have to be difficult. In fact, AWS has services to help you move data between different databases called AWS Database Migration Service.
- Operational Overhead - Evaluate new services and new projects with a view to minimise operational overhead for your teams and focus on what makes your business unique (i.e. solving your customer's problems by releasing products/software/services that meet gaps in the market). Everything else is a distraction.
- Continuous Improvement - Consider methodologies such as Lean, Agile and DevOps, all with common themes of continuous improvement, and what you can do to improve your CI/CD process (i.e Define, Develop, Version, Build, Assure, Store, Provision, Deploy). Ultimately the cloud, your infrastructure and any platform you may "build, manage or buy" is there to service your applications so they can be deployed and run somewhere.
Some of the most successful projects I've had the pleasure of being part of have taken advantage of the hard work of cloud or SaaS providers. They help organisations save time, and allow them to get things done right the first time.
Cloud native, serverless and SaaS are some of the most powerful ways to add value to a DevOps/ cloud transformation, outside of the people-part of the transformation. Services like RDS, S3, Google App Engine, Buildkite, Github, and Slack are among my favourite technical accelerators to help drive success in organisations.
Is missed opportunity the real cost?
At this point you may still be asking yourself, what’s the true cost of being cloud-agnostic? Is it cheaper, or more expensive than the alternative? The cost I’m referring isn’t directly related to your profit and loss statement. In fact, the true cost of trying to be cloud-agnostic can be missed opportunity and revenue, stifling innovation, project delays, and missing out on a selection of some of the most useful services the cloud has to offer.
So here I stand, a Cloud Believer using the "best of breed" way of thinking and continuous improvement to help you get the most out of the cloud. After all if you believe in the cloud, you can't be agnostic.