Building Cloud Agnostic Applications

Vendor lock-in can be a pain. Imagine you've written an application to work against one cloud provider and now you'd like to migrate to another one. I've seen cases where the engineering and development work to make the change would cost more than any savings of running on the new provider.

Then there are those cases where you might want to migrate to or from a private cloud. Or, efficiently develop locally without a cloud system installed.

There's a way to design applications so that switching providers isn't such a hassle.

Deferring Important Decisions

When "Uncle Bob" Martin regularly describes clean architecture he notes,

A good architecture allows you to defer critical decisions, it doesn’t force you to defer them. However, if you can defer them, it means you have lots of flexibility.

Odds are you're building an application to run in "the cloud" rather that a specific cloud. I'm assuming you don't work for Amazon, Google, Microsoft, or one of the other cloud providers. Most cloud developers don't. Given this assumption, an application shouldn't assume a particular cloud and tightly couple to it. It's a decision that can be deferred in the architecture.

Use An Interface

Start with a well defined interface describing what you want to do. For example, an interface to save data.

interface SaveMyData {

    function save(array $data); 
}

When creating the interface don't copy the API to the cloud library you are using. Don't tightly couple to that API as it could change in a future version or there may be a time to move away from it.

On the interface only describe the functionality you need. It's easy to start describing all the features the initial implementation you have in mind can do. Describing everything will give you more software to write and maintain without providing something useful to the application. Add more features as the application needs them.

Note, when if comes to crafting interfaces consider using the interface segregation principle.

Create An Implementation

The next step is to create an implementation of the interface. For something like saving data I would likely create two implementations. One to save data to the cloud I'm using and a second one to save data locally. The option to save data locally would enable me to work on the application without interacting with the cloud itself.

This is where the ability to avoid vendor lock-in happens. When the time comes to switch cloud providers simply create and test another implementation of the interface using the new cloud provider. It's a far simpler switch.

Dependency Injection

How would you pass the appropriate implementation around an application? A common way to do that is with dependency injection. Using dependency injection the implementation can even be part of the configuration for the application.

Dependency injection is common enough there are already best practices for implementing it in most programming languages and frameworks.