Locked In

I've worked with many different clients who are either on the verge of moving to the cloud, or who are in the cloud and are terrified that they will be "locked in" to a particular provider. A lot of these same clients have spent months or years just coming to the core decision to move to the cloud, let alone trying to implement solutions there. These fears usually rise up once an SDK is mentioned, and most often its always developers voicing these concerns. My experience has taught me these fears stem from the same problem: current lock in. A lot of these clients have been on-premises for as long as most of the developers have been at the company. Anyone having to deal with on-premises procurement processes of new hardware can attest to the pain points. It often takes months to secure new hardware, if the budget even allows it. Other clients have already been in the "cloud", in the sense they use a managed provider to host all their infrastructure. This is nice from an SLA standpoint (if they hold up), but often the same problems of procurement are still there (and budgets as well). This fear of being held hostage then carries over to the new cloud provider. Now that you're so close to being free, why would you want to lock yourself into another cage!?

Docker & OpenShift

The solution that almost always creeps to the top is either Docker and/or OpenShift (or something similar). Let me start off by saying, I think Docker & OpenShift are great offerings. They solve a lot of problems and ease a lot of workloads for developing and deploying applications. However, I've spent a great deal of time using server-less technologies like AWS Lambda and Azure Functions. From this view point, Docker still seems like a lot of overhead, so I am a bit biased! However, even when using something like Docker, you will still find it hard to avoid interacting with specific SDKs and services from your cloud provider. For instance, OpenShift has a blog post on how to Configure an AWS S3 Bucket Store for OpenShift. In that post they speak to using the AWS SDK.....lock in. Now if we look at using some of the other services that AWS and Azure offer like storage, queues, etc, you'll quickly find that you can't easily avoid working directly with the cloud provider. It can be done, but it adds work and complexity.

Don't Lose All the Perks

Moving to the cloud is more about just great pricing, availability, and rapid infrastructure building. All of that stuff is great, but its also about opening your enterprise up to an amazing set of tools, some of which you've never had on-premises. When you embrace a cloud provider and all they offer, you can truly gain advances like you never have before. I'm a huge fan of anything PaaS. The main reason for this is everything is managed. I no longer have to think about maintaining servers, patching, updates, scaling, etc. For instance, with Azure App Service you simply just pick your hosting plan and deploy your application. You can choose how and when it scales, how much performance you want, and even deploy multiple versions. You don't even need to tell it what language your app is written in, just upload it. The minute you can take out managing servers, your teams responsible for developing/deploying/managing applications have so much more time for more important things. I've seen companies that have completely embraced their provider and broken down walls to developing new applications and services for their customers. It's truly an amazing thing.

Architect Differently

When moving to the cloud you already have to start embracing a different way to architecting your solutions. Mainly this is around the concept of architect and develop it to fail. Any application should be designed so it can fail gracefully. Adding to this, you should also start to think about how to architect your solutions to be cloud agnostic. As with a Docker/OpenShift approach this can be difficult, but I feel its much easier. The main points are as follows and some you should already be doing anyway:

  • Keep Core Business Logic Isolated - This would include any code that performs business logic and does not need to interact with any external service including: databases, APIs, cloud services, etc. This is code that can be easily deployed to any cloud provider with little to no changes.
  • Keep Cloud Specific Code Isolated - This is any code that needs to interact with the cloud providers services, think storage, queues, messaging, etc. This code would include references to SDKs and contain configs with API URLs etc. The idea here is that this code should be fairly lightweight and have strict single responsibility. In this way, you can keep a copy of the code specific for each provider and deploy it only to those providers. Keeping the same namespaces or file names in place ensures you can easily do this during deployment.
  • Keep the Databases the Same - If you're using MySQL for your app in AWS, ensure you're using MySQL for that app in Azure. With this in mind, all you will need to do is update your connection strings.

These are just a few examples of how you can mitigate these concerns and is by no means encompassing. There are a lot of opportunities for easing the pain points if you want to deploy an application across multiple providers, you just need to start thinking differently.

Don't Fear Vendor Lock In

At the end of the day, you should not fear vendor lock in with a cloud provider. You should embrace all that the provider offers, but think about how you architect your solutions. Try to mitigate lock in by designing your applications with moving in mind, and adhering to strict single responsibility. I also encourage clients to look at working with multiple providers, not to avoid lock in, but to be sure you have access to all that the cloud offers. AWS and Azure are constantly trying to one up each other, so you may find a service available at one and not the other. Don't limit yourself!