Cloud Lock-in May Not be What You Think

In the technology space there has always been the struggle between building a hardcore skill and being flexible enough to adapt as technology adapts. My first experience with that was Cobol (yes, I’ve been around for a while!), and since then I’ve seen in play out in client server, virtualization, storage, phone switches, and much more.

On the one hand it’s great to have people with strong skills and on the other hand it’s even more important to be agile and adaptable in your ability to create or deliver services based on the best possible solution set, not just the one you happen to have become strong in.

Are you letting a technology, service or language dictate your IT strategy?


I’m going to come right out and say it; if you’re allowing a specific technology or service to determine IT strategy for your company you are in effect creating lock in. We’ve all talked about lock in and some of us are more nervous about it than others. Personally I like to find the right balance of flexibility as it protects my ability to support my business most effectively and efficiently.

Typical lock in situations

  • We’re an Oracle shop
  • We’re an IBM shop
  • We’re an AWS shop
  • We’re a VMware shop
  • Storage 
  • Operating systems
  • Switching
  • Etc., etc..

Superficially the lock in associated with each of the above is summed up as follows; We have a big investment in a specific technology associated with X (operating our infrastructure) and as a result of that investment we’ve also made an investment in training and acquiring staff with specific skills.  The fact is, if the first choice of a solution didn’t lock you in, then the acquiring of staff who get their personal validation by being great at doing X really cemented you.

How is lock in through staff skills or resume builders changing in today’s IT?

Today it’s not uncommon for a coder to only take a job if they know they’ll be working with AWS APIs. If they don’t get that experience they don’t want the job. A few years ago that request might have been Oracle DBA or vSphere Management. This is wrong, we must stop doing this or all we’ll ever do is paint our businesses into a corner again, except we’ll do it with a new technology.

Using AWS is like choosing a server or operating system. Like a server or OS, the primary point of having AWS is that you want to be able to deliver applications. So, if using AWS is no different than using an HP server 20 years ago, why would you want to build a strategy around only HP gear? What happens when Dell or Quanta offer better and or less expensive gear is the answer “sorry, we’re only able to support HP gear”? If you find that you’re hiring staff based on the idea that they can support use of AWS (and thereby build their own careers), this could severely limit your ability to provide service flexibility or cost efficiency in the future.

The business of IT - a reality check

The business of IT is not to help some individuals develop specific skills. IT is there to enable technology based solutions that create opportunity for the business. The opportunity being created could be in operational efficiency (bottom line) or it could be in new sales (top line).  

By contrast, think about how most of us have gotten to where we are with our solution and technology choices. Our IT environment looks like a collection of stuff that would otherwise only be found at the neighborhood flea market. It doesn’t look like a strategy and it certainly doesn’t lend itself to rapid adaptation.

HR & Leadership have a big part to play


Leadership, hiring practices, technology leverage strategy, and reward systems all have an impact on how you get locked in. When you follow the path of least resistance you get locked in. When you reward staff for being the best at a specific solution type, you get locked in. When you allow those existing conditions to dictate your options for the future, you’re putting your business at risk. Life -- like IT -- isn’t about the easy choices. Most of the time the most important choices we make are the hardest ones. The path of least resistance in getting off a cliff is jumping. Let’s see how that works out for you.

What should we do?

There aren’t any easy answers, but my suggestions are as follows:

  • Reward your employees in ways that put the correct emphasis on the right message and value. If you place value on knowing VMware or AWS, then that’s what you’re going to get. If you place value on making IT innovative, agile, adaptable and cost effective then that’s what you’ll get.
  • Hire for the ability to deliver services and to leverage technology not necessarily to drill into every technology. Why do people use Nutanix or AWS in the first place? They use them because they abstract away the unproductive nuances of the underlying capabilities. They provide the Easy Button. However, you can’t (shouldn't) buy Nutanix without having a way to also leverage Google or Openstack and you can’t (shouldn’t) use AWS without a plan for being able to easily use an alternative. 
  • Build a framework of skills associated with just enough internal technical depth combined with business acumen and then leverage partners for short term opportunities to provide unique technical value. 
  • Always be thinking about “how will I actually own this?"
    • Will I be able to always attract the right staff?
    • Will this vendor continue to be benevolent after I’ve fully committed?
    • if my business or technology trends change significantly can I trust my tech to help prepare me effectively?

Lock in can be a choice and in some cases it can work, but whatever choice you make it must be made with your ability at your company in your region and your vertical to make the most of what you have. If you’re building everything yourself or stitching a bunch of open source solutions together then you better keep in mind that those skill sets are hard to acquire and the return on investment comes from real scale. If you’re putting all your eggs in one cloud basket and developing your staff to support that, what’s your ability to pivot if things don’t work out with that vendor, like maybe when they become a competitor?

Makes about as much sense as jumping off a cliff, doesn’t it?