Q
Problem solve Get help with specific problems with your technologies, process and projects.

How to avoid cloud lock-ins

Avoiding cloud lock-ins with both the technology and provider is a concern for businesses interested in cloud computing.

Lock-in is my group's worry about cloud. We see the danger with cloud computing of history repeating itself due to proprietary software. If my company moves to a SaaS app and integrates our other apps with that app, for example, aren't we locked in just as we were with a mainframe or client-server app in the past? Is there a way to use cloud and not fall into that trap?

Any concerns about a possibility to be locked-in into the Software as aService (SaaS) is quite reasonable. So, let us apply our experience from the past to avoid unnecessary locking-in. We have to deal with two types of locking: a) with the technology; b) with the provider of technology.

If you work in or use certain technology, you cannot avoid being locked-in into it to some degree. For example, if you need to use a database, the only choice you have is to be agnostic in your application to a particular database implementation, e.g., from Oracle or Microsoft. If you implement SOA, you cannot avoid locking-in into a client-server model because SOA service operates in a client-server model only. A similar situation is with cloud computing and, in particular, with SaaS. 

SaaS(SaaS), according to Webopedia, “is a software delivery method that provides access to software and its functions remotely as a Web-based service” (I assume that your question is not about Storage as a Service).Therefore, we have to watch for a locking-in into either the “method that provides access to software” or the software/application itself. However, recall that we are supposed to deal with service, which means that we may behave as a service consumer (as it is defined in the service-oriented ecosystem).

In particular, a service consumer has all rights to require a service provider to provide the service under the following conditions – the service must deliver:

  1. what the consumer wants (not what is available);
  2. when the consumer wants it;
  3. where the consumer wants it;
  4. under compliance rules set by the consumer;
  5. under security protection that is in line with the consumer’ policies;
  6. under ‘business continuity’ rules set by the consumer.

All listed conditions are the articles to be articulated in the contract with the service provider. If a service-candidate does not meet these requirements, it is probably not right for you.

Does this look like a locking-in? A fundamental difference between application-oriented and service-oriented approach is in that the service is for you while with applications – you are for them; they dictate what, when, where and how you should use them.

So, dealing with SaaS, you have to have your own definition of what do you want and how you want it. You have to set the governance (policies and procedures) around using any service first. Then, you have to conduct a service provider evaluation procedure with all related RFI/RFP, reviews, live POC/demos and sign-off. All these will help you to show who has control in the relationship with the service providers, as well as to find who really wants to service you.

It is a totally different case if you might need to use SaaS as an occasional application for a stand-alone short-term task. For example, you have to model a possible outcome of a solution and you need significant computational resources and algorithmic expertise to run a Monte-Carlo statistic calculations. You might be able to find a cloud provider with this capability and I do not think that you have to be so cautious about meeting all of my 6 conditions listed above in this case. However, you are not concerned about locking-in in this case either, I guess.

The last element of this quiz is how to avoid locking-in into the delivery method. Best practices of service-oriented ecosystem implementation teach us that for a consumer to be independent from the interaction protocols with the service, the communication channel offered by the service should not be used directly. This means that the consumer has to create own Proxy/Delegate/Adapter for each communication channel. The power of such an adapter is that it shields the consumer from all possible services and, thus, the consumer can change service providers in the most painless manner if and when needed. Moreover, if an ability to change the provider is a publicly known policy of the consumers, each chosen service provider will change its behaviour and think twice before doing any harm to you, including accidental or deliberate locking-in. 

Overall, thanks to the service nature of SaaS, we have a relatively reliable mechanism for avoiding being locked-in with any particular service and/or service provider. This mechanism includes: proper governance, clear definition of consumer needs, “consumer market” type of behavior and a technical shielding from the technology locks in a communication channel.

This was last published in June 2012

Dig Deeper on Cloud service agreements

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchAWS

TheServerSide.com

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

DevOpsAgenda

Close