6 Oct 17

    A few tips on how to avoid cloud lockin


    Avoiding lockin by cloud providers means that you need to go into any migration with your eyes wide-open. A (single) cloud provider is not going to be able to meet all your needs, and they will not do it ALL for you, you still have some (and in some scenarios a lot of) responsibility. But knowing what is a commodity will help, and truly thinking about what you and your applications really need will go a long way to you making the most out of your cloud pounds.

    After visiting IPEXPO in London this week it appears that enterprises are beginning to realise that choosing a cloud provider is not a choice at all, in fact the more (and longer) you keep your options open the more flexibility and bargaining power you retain. The fundamental shift is that the application you are moving is not ‘the application’ it is the sum of its parts, or its technical capabilities.

    • To choose a single cloud provider is to falsely limit this choice to only the capabilities that that provider is able to give you
    • To choose a capability that is only available from one provider is to actually limit your options and potentially case some pain later in your product lifecycle.

    The former is likely chosen to reduce the amount of (re-)training in the enterprise. Yet to be proven but I suspect that this is a false economy, and you would recover more money in being able to switch providers than it would cost to cross-skill staff.

    I saw a plethora of companies that are able to act as a single console that are able to deploy to multiple cloud vendors, they have obviously looked at Terraform and seen an opportunity for me too. But this works only for commoditised offerings.

    VMs are VMs

    IaaS VMs are mostly equivalent across vendors, keeping your options open here is obviously a good choice as Michael Porter said: (paraphrasing) where there is perfect competition and products are essentially the same (commoditised) then consumers will choose based on price alone.

    Providers will attempt to differentiate as much as they can, it is YOUR job to define what exactly you are looking for, engineering your commodity. Don’t just choose a list from your favourite vendor and everything on that list that is not provided by a competitor is a bad thing. Define your selection requirements clearly and up front.

    But I think we all know that transitioning existing applications to the cloud in their current form is not necessarily the right choice

    Server Functions/Server-less/PaaS

    Clearly, you cannot run RedShift in Azure, or the newly announced Visual Studio Code in AWS, BUT;

    1. There is nothing stopping you from having part of your structure in Azure and others in AWS, as well as perhaps some legacy elements on premise. Modern components are exposed via APis that are easily consumable over HTTP(s)
    2. Or you can define the ’capability’ you need rather than the tools you choose. This frees you up a little since options can be accommodated in the design of your application, though it would be a little more work. It does however require a fairly deep understanding of all the offerings that the cloud providers provide
    3. You can choose offerings from marketplaces where the marketplace offering owner has an equivalent offering in competitive platforms.

    Containers are containers

    Containers are almost a perfect commodity, since they are reliant only on images that are external to (though may reside on) the cloud providers platform. Refactoring your applications to use containers whether as microservices or macro services (dirty containers) will make your applications far more portable between cloud providers, and your internal IT if you should so choose.

    Most cloud providers and all of the big players have a container service as part of their offer and it then, once more it becomes a price game. GOOD NEWS FOR YOU!

    More on the things that you might also want out of your cloud provider in an upcoming post


    Insert Image