Recently I was sitting in a vendor presentation at a technical conference and I was reminded of how confusing it can be to know which type of IT service (ITaaS, IaaS, SaaS, PaaS, XaaS, etc.) to use. To make matters worse, the definition of these types of services continues to evolve. For example, IaaS today looks more like PaaS a couple of years ago. When you factor in the topic of “lock-in” you have an even more difficult decision on your hands.
To avoid lock-in, should you own and run our own infrastructure? Does your solution really need a PaaS? Can you accomplish the business objective with a SaaS offering? Do you pick one partner or several? Is some lock-in acceptable based on the service you are providing?
Taking a new look at lock-in
The term lock-in almost always has a negative connotation, but we intentionally choose lock-in in many areas of our personal lives. For example, I may be “locked-in” to a neighborhood due to a lease, mortgage or just the difficulty of moving. We are locked-in to service plans. We are locked-in to the stuff we own. The list goes on. In reality, lock-in as an intentional decision, based on tangible benefits. This does not make lock-in good or bad, but acceptable. Now, if you are locked-in to something you did not choose and, especially if there is no value or benefit, then that would be bad lock-in.
It can be the same thought process for choosing IT services, which can come in many forms. You can be locked-in to a specific service type, architecture, code level, vendor, etc. Regardless of where, there is always some level of lock-in.
So, what should the thought process look like when choosing an IT service and how do you choose acceptable lock-in? In my opinion, the maturity of what you are building should help guide your selection.
For example, if your solution is providing a service where time to market is critical, then you may benefit from an offering that provides more than just CPU, RAM, and storage. You will want the leading-edge functionality (instead of the lowest common denominator). You should pick a single public cloud platform and run right behind their release roadmap, leveraging the innovation as they create it.
In this approach, the benefits of utilizing a platform that cranks out hundreds of new features are well worth the lock-in. However, it also requires that you have the skills and the organizational structure that allows you to quickly learn and utilize these new features, as well as the wisdom on how best to control your cost along the way, since you will not be in a position to play one provider off another.
If your solution is a “cloud mature application,” meaning is was developed to run on a public cloud using commoditized CPU, RAM and storage, then you will probably benefit from a cloud management platform / cloud broker / next-gen PaaS service that provides a single interface and a lesser degree of lock-in. This approach allows you to shop cost and diversify your environment, but is assumes your organization has the skills for developing and running all the services required for that application instead of relying on an outside service.
Most companies can benefit from several approaches, since they have applications at different stages of their lifecycles. Companies that try to standardize one approach for everything will probably experience less than optimal results. As such, companies should look at each case individually and determine which IT service best gives them a competitive advantage while also matching their internal skill set.