One of the most contentious topics when talking about adopting Cloud Services is around Vendor Lock-in.  Most discussions revolve around how to avoid Vendor Lock-in. So, is Vendor Lock-in a myth or reality?

A History Lesson:
Before I answer this question, let's take a look at history... Vendor Lock-In is not a new concept - it has been a concern and reality for many years.  When companies make investments in hardware and, especially, in software, organizations have, over time become dependent on that vendor's technology. This is not as big a deal when it comes to hardware, although even in traditional data centers, some Vendor Lock-In occurs.  It definitely occurs with use of software.  When companies adopt a particular database or operating system, they effectively begin to lock themselves in with those technologies and therefore become dependent on those vendors. I have talked to many organizations who over time wanted to move away from Oracle DB or IBM DB2, but found the transition very difficult and costly in terms of time and resources.  This is because IT used those technologies to built IT Services.  And, in many cases, in order to move away from those services, they have to re-write existing applications.
The same happened with other technologies.  As new technologies were adopted (e.g. OS, Virtualization, etc.) they promised new capabilities, but often resulted in lock-in with a particular technology.  In case of Virtualization, for example, while the workloads themselves became portable, the overall skillsets and toolsets resulted in IT becoming locked into particular virtualization technologies.

Reality in Cloud Era:
As companies adopt Cloud Serviecs, they often think of Vendor Lock-In and ways to avoid it.  It's easy to get started with a Cloud.  All you need is an email address and a credit card. You can spin up a virtual server in seconds and start using it in minutes.  Easy! As you spend more time in a Public Cloud environment, you start taking advantage of more capabilities.
What about Vendor Lock-In? In my opinion, Vendor Lock-In is a reality - even more so than in the past.  And, it's a view that is shared by others.  I spoke with a product manager from one of the major Public Cloud Vendors and he agreed - people who think they won't get locked-in with their chosen Cloud Providers will find that their expectations aren't met. Sure, there are ways to minimize Vendor Lock-In, but at what cost?.
Should I Fear Vendor Lock-In?
Short answer is NO! Vendor Lock-In is a reality.  Let's accept it.  Let's understand it. Let's PLAN how to deal with it.
You can minimize Vendor Lock-In, but that may not be your best option.  Why? If you want to minimize Vendor Lock-In, you will need to restrict the users from consuming some of the Cloud-native capabilities, like PaaS, Code-as-a-Service or Machine Learning. 
I propose that you should not try to PREVENT Vendor-Lock-In, but rather PLAN for how to deal with Vendor Lock-In by defining end of service requirements for every Cloud-based Service. Every IT Service has an expected lifespan.  It's true that in some instances IT Services last long past their expected lifespan, but we need to treat those as exceptions, rather than a rule. In the age of Cloud, it is imperative that we define requirements for end of service life as part of the core product requirements. This will allow organizations to use the best available technologies to create a service today, but as the available capabilities of Cloud (and beyond) evolve, IT can plan to take advantage of them and properly transition to "next generations" of IT Services. Of paramount importance is making sure that you plan how to preserve any data at the end of service life.  This is true for IT-built services on Public and Private Cloud platforms as well as SaaS services.
In summary, I believe Vendor Lock-In is inevitable. It is a consequence of adopting advanced technologies available. It allows us to take advantage of the best capabilities available to help drive business advantage.  But, we need to make sure that we understand areas of lock-in and plan an exit strategy even as we prepare to create the current set of services.