Sapsiwai - Fotolia

Learn from past mistakes to avoid Amazon lock-in

Oracle, IBM and Microsoft all generated past worries of vendor lock-in. That same concern exists with AWS. Don't let history repeat itself in your enterprise.

The majority of IT decision-makers believe that vendor lock-in prevents their companies from maximizing the business value of public cloud. IT leadership often chooses not to move applications to the public cloud because they believe investing in just one cloud provider will hinder flexibility.

Several studies reinforce this conclusion, stating that the overwhelming market dominance of public cloud players, like AWS, is negative for the industry. Even when using core services, such as Amazon Elastic Compute Cloud and Amazon Simple Storage Service, IT professionals averse to Amazon lock-in tend to stay away from application-specific services, such as databases and application development platforms. The fear is that the cloud will control all aspects of that platform going forward, and limit flexibility.

But we've seen this movie before. Enterprises had the same concerns years ago when they were looking to move to Oracle, IBM and Microsoft, among others. The core concern is the same: If an enterprise moves to a database or proprietary OS platform, will it be locked into that platform long term? While traditional enterprise vendors attempted to provide a reassuring answer for that concern, no one wanted to hear the true answer: You choose a technology, you're locked in.

Vendor lock-in makes the cost of moving technology prohibitive. Oracle is a strong example of this, but IBM, Microsoft and others have the same issues, more or less. If an enterprise elected to move a database to Oracle or created a net new database, then significant cost and pain are the tradeoffs of moving to another database.

Those headaches can be worse if an enterprise uses native -- and thus proprietary -- features, such as stored procedures and triggers written in Oracle's native language or native APIs. But why buy any technology unless you exploit all features to get the most value out of it? Unfortunately, those features can provide a short-term benefit, but can deepen the lock-in.

Even decades later with the cloud, there still is no truly open technology. For instance, cloud providers offer database technology that has a tendency to use proprietary features, such as APIs and models, which can be expensive to port to other clouds when the data needs to move. While there are open technologies that are cheaper and less proprietary, most enterprises have not made the leap because of the cost and risks involved with making the move.

In some cases, enterprises have to run their traditional data and application development platforms in the cloud, such as Oracle running on AWS or within the Oracle Cloud. They continue to pay expensive licensing fees.

Apply past lessons to avoid Amazon lock-in

So, what lessons can IT professionals learn from the locked-in enterprise software days of yore? And how can they apply that knowledge to avoid Amazon lock-in?

First, always have an egress plan. Once an enterprise moves to a cloud-native database on a public cloud, it needs to know how to get off that technology. It doesn't matter if it's moving to an open technology or closed, both have their lock-in downsides. An exit plan will not necessarily lower Amazon lock-in risk, but it lessens the financial and organizational commitment to a particular vendor.

Second, try to pick cloud-based platforms that enable users to eventually leave. For example, reputable cloud-based database providers will have processes and tools in place to move to other platforms with very little cost and risk.

Finally, don't use proprietary features -- if they can be avoided. While those native APIs are tempting, they won't work on other cloud platforms. Always build applications as if they are going to move tomorrow, because perhaps they will.

Next Steps

Businesses of all types go all-in with AWS

AWS lock-in is among IT's biggest cloud fears

Customers want harmony between AWS and Oracle

Dig Deeper on AWS Services for integration and middleware