• Tweet
• Email

• Tweet
• Email

I started my career in late 90s selling Microsoft Application Platform that included the servers and the developer tools. One of the most common customer objections that I used to handle was “vendor lock-in”. Every time I pitched MS SQL Server or Visual Basic, the immediate concern from the customers was getting locked into the Microsoft platform.

A decade later, “Vendor lock-in” still remains a hurdle that the technical sales rep has to go through. But the landscape has changed significantly. Now the vendor lock-in argument has shifted to the Cloud. I often hear lock-in in the context of Amazon Web Services. AWS competitors use the lock-in factor to create FUD among the customers with a hope to increase their sales prospects. But how much of this is a real concern? Should businesses be really worried about getting locked into one platform?

In my opinion, every technology decision involves some level of lock-in. My Hyundai car came with an in built MP3 player that makes it difficult for me to upgrade to a better audio player. For a long time, I lived with a HTC phone that had a proprietary headphone socket that prevented me from plugging in the powerful Bose headset into it. All of us tolerate certain level of lock-in across the devices and technologies that we use.

Vendor lock-in can be avoided to a large extent in the IT world. But, it is a huge trade off between performance and portability. Let’s consider the example of Microsoft SQL Server as the database. Like most of the enterprises databases, SQL Server comes with a lot of built-in optimizations that can be exploited for enhanced performance. To leverage these optimizations, one has to encapsulate the business logic in the stored procedures written in T-SQL, which is a native SQL variant used by MS SQL Server. This gives the database developers and the DBAs a chance to extract the best possible performance from SQL Server. So, what’s the trade off here? This makes it extremely hard to move the data tier to Oracle or DB2 at a later point. Migrating the schema may be easier but not the business logic and the extended stored procedures that are written to take advantage of the native SQL Server capabilities. The developers could have chosen not to exploit these features and to comply with ANSI SQL standards that are common across any relational database. They could achieve it by moving the business logic to the client and use the DB only for persistence. But that would seriously limit the performance of the application. So, it is clearly performance or portability!

AWS offers most of the services that are required to build Internet scale applications. Static content can be off-loaded to Amazon S3, which will reduce the burden on the web server. It can further be cached across the edge locations by leveraging Amazon CloudFront. The session management can be moved to Amazon ElastiCache to achieve better scale of the web tier. Data that gets written once but read more often can be persisted to Amazon DynamoDB. All these services are exposed through REST API that is very proprietary to AWS. The moment you start consuming these APIs in your application, it is extremely hard to move to other Cloud platforms. The fact is that most of these services have alternatives that will not lock you down to AWS. For example, you can setup a Memcached server to manage in-memory objects and session data in the place of Amazon ElastiCache. You can setup and configure a MongoDB or Cassandra cluster to handle the non-transactional data without depending on Amazon DynamoDB. You can deploy HAProxy instead of relying on Elastic Load Balancer of AWS. That will make your application independent of the underlying Cloud infrastructure. You can then move the whole deployment that consists of a couple of dozen VMs to another Cloud. But, remember you are going to take control of the infrastructure and need to handle the failover and high availability all by yourself.

The implications are very similar to the tight integration with the database server that we discussed earlier. If you need performance and productivity, you will have to come to terms with the proprietary features of the platform. If you want to avoid vendor lock-in and insist on portability, then you got to sacrifice the power and performance offered by the platform.

So, is it performance or portability? You decide!

- Janakiram MSV, Chief Editor, CloudStory.in

• Anonymous

  Very well written article.

  Lately , we have been questioning ourselves too about this whole concept of “Vendor lock-in”. In our case it is AWS. I somehow feel that a system should be architected independent of a vendor rather than being totally dependent on the Vendor specific implementation

• http://proteans.wordpress.com/ Gsvasan

  After being Microsoft techie for more than a decade, currently I make use of ubuntu/linux/debian to perform my software development and use language PHP and java. I avoid vendor lock-in while I get portability and do not sacrifice power and performance.

  I feel developers would become more mature by learning how to take control of the infrastructure and the ways to handle the failover and high availability all by themself. Once they learn, possibly there need take control on continuous basis.

• http://www.mrinalwadhwa.com/ Mrinal Wadhwa

  Hi Janakiram,

  This is an interesting discussion.

  Buy into a lock-in or avoid it? — is a strategic business concern which shouldn’t be taken lightly [1, 2]. As you mentioned, lock-ins exist in all competitive environments, not just in the technology landscape [3]. The word “lock-in” may have become a cliché in the IT industry — the open source movements have used it to campaign for decades — but that does not reduce the importance of each such choice and the impact it can have on your business.

  Either of the two options, choosing to lock yourself in or choosing to stay vendor neutral, could prove profitable for your business.

  Locking into AWS, for example, can reduce development and short-term maintenance costs. It allows for a faster time-to-market and requires a lower level of skill to operate etc.

  Staying vendor neutral, is more flexible, gives you control, can reduce long term costs, lead to better application runtime performance and higher availability etc. But, requires higher level of skill to develop and operate, has higher upfront development costs etc.

  This is a complex decision, choose wisely.

  To your point on performance+productivity vs. portability. I would not club performance and productivity together. Both are separate levers. Buying into AWS improves developer productivity, but application runtime performance is a separate lever. If you have the right skills, tools like haproxy, memcached etc. can be tuned to serve your application’s needs better than their amazon hosted equivalents.

  With regards,
  Mrinal

  • http://www.janakiramm.net/ Jani

    Agree with you Mrinal! Productivity and Performance are independent but go together in most of the cases. AWS may not be an appropriate scenario for that but if you consider Windows Azure + .NET + Visual Studio, it offers a combination of perf and productivity. Same is the case with Google App Engine. That prompts me to write one more article. 

    Thanks for the detailed explanation and keep reading our articles

    • Vibha

       Janaki and Mrinal,
      Thank you for putting things in perspective.
      However, if one has to go online in a week’s time with limited resources I guess choice is obvious…one will opt for performance and a provider who has services seamlessly integrated like AWS.