Cloud Cuckoo Land: When Cloud Customers Get Locked In
April 01, 2016

Sven Dummer
Loggly

Back in the day when the word “cloud” was only used for those things in the sky, software typically ran on local machines sitting in local datacenters. Often, this software was licensed from a vendor on a per-seat basis. Vendors tried their best to make customers renew their license agreements, and vendor lock-in was a common phenomenon.

Such lock-in could be caused by a variety of factors: sometimes purposely caused by the vendors by making migration to competing products unnecessarily hard, sometimes caused by customers being naïve and betting too much of their software stack or infrastructure on the products of one single vendor.

Over the past decade, two factors have made it significantly easier to escape that legacy lock-in model. Free/open-source software has reached a level of maturity and adoption in almost every area of the industry, offering more and more valid alternatives to commercial products.

Secondly, the commoditization of cloud computing removed the need for companies to run their own datacenter.

A Storms A-Brewin'

Cloud providers often claim to offer the perfect escape path from legacy vendor lock-in by providing modular solutions in which customers only pay for what they use, instead of being tied into complex, long-term, per-seat licensing agreements.

However, most cloud providers (in particular the big players) have extended their portfolio over the past few years, offering a broad variety of services that go beyond computing and storage. They provide everything from load balancing and DNS, to messaging, monitoring, log management, analytics, databases, and much more.

It's very tempting for customers to replace more and more components running in their own colos with these in-cloud solutions. Why? Because they typically are easy to set up and they remove the costs of hardware ownership and datacenter footprint.

It's also an easy purchase because a contract with the cloud provider is already in place, and adding (or removing) a service is not much more than a mouse click — no need to negotiate with a sales rep over complicated long-term license agreements like it used to be with many legacy, on-premise solutions (and no need for the provider to deal with selling through fear attempts and related nuisances).

I Can See Clearly Now …

With so many advantages, it is easy to be blind to (or willingly ignore) that these services have huge lock-in potential, and many providers probably exist for exactly that reason. The more of these services a customer uses, the more difficult it is to move their application stack from one cloud provider to another, or to their own datacenter or a hybrid solution.

Whenever companies make decisions to move services to the cloud, it is worth it to thoroughly review the architecture specifically from the perspective of potential vendor lock-in. It might also be worth it to go with solutions that live and function outside of a specific vendor's cloud, even if it is less convenient and maybe more expensive. It's not unlikely that today's convenience and savings will turn into a nightmare and cost explosion tomorrow. There is no such thing as a harmless, one-vendor dependency, not even in the most comfortable and fluffiest cloud.

Sven Dummer is Senior Director of Product Marketing at Loggly.

The Latest

November 14, 2018

What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation? At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? Yet, an average company does not adhere to that logic. Why is that? ...

November 13, 2018

I'd love to see more security automation deeply integrated into the development process. Everybody knows since the 1990s that security as an afterthought just doesn't work, yet we keep doing it. The reason, I think, is because it's very hard to automate security ...

November 09, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 5, the final installment, covers deployment and production ...

November 08, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 4 is all about security ...

November 07, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 3 covers the development environment and the infrastructure ...

November 06, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 2 covers the coding process ...

November 05, 2018

Everyone talks about automating the software development lifecycle (SDLC) but the first question should be: What should you automate? With this question in mind, DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 1 starts with by-far the most popular recommendation: Testing ...

October 31, 2018

Halloween is a time for all things spooky, but not when it comes to your mobile app experience. A poor experience can not only scare off your customers but keep them away for good ...

October 30, 2018

As organizations have embraced open source, they have become polyglot — using multiple programming languages and technology stacks to accomplish software and hardware related tasks. Enterprises are caught between the benefits provided by a polyglot environment and the complexities and challenges these environments bring. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise ...

October 29, 2018

Factor 5 of the Twelve-Factor App relates more to processes and advises strictly separating the build and run stages. The emphasis is on identifying and separating each stage of app development, and encouraging automation between each so as to accelerate the process ...

Share this