Revisiting Technology Lock-In in the Cloud
Note: This article is originally published by CIO Advisor APAC.
When starting a cloud journey, many CIOs rightfully look to a set of IT principles in guiding their implementation. One commonly used IT principle is avoiding technology lock-in. There are many reasons why this is a good principle to uphold. Relying too much on one single vendor, for example, is very risky because you typically don't have control over the vendor's product direction and company health. However, committing to a single technology or vendor is not always heresy, depending on where you are in your cloud journey.
Agility
There are many goals for moving to the cloud, and agility is arguably at the top for most companies. Agility in execution requires simplicity which is much easier to achieve through uniformity and standardization of technology.
Serverless technology is an example that captures this problem. On the one hand, deploying your workload as serverless would allow you to focus on your application and help you be more agile. On the other hand, building your application for a proprietary serverless technology would lock you to the cloud service provider's ecosystem. If you come to this scenario, assess whether committing to the ecosystem would give enough competitive advantage, that sacrificing technology independence is worth the cost.
Operational risks
Let's look at an example in application monitoring, which is basic hygiene for your IT operations. Most cloud service providers offer an in-house tool for monitoring, and if you have adopted AWS, you would be using Amazon CloudWatch. In most cases, CloudWatch just works with little or no setup. The trade-off, of course, is that it doesn't work outside of AWS.
If you're operating a multi-cloud environment, your IT operational tools must work across different clouds. This usually means that you must stand-up some cloud-agnostic tools on your own. For example, instead of standardizing on CloudWatch, you might set up a Syslog server. Besides the additional effort, this requirement would make your IT architecture more complex and introduce more “points of failure,” which would increase your operational risks.
Cost considerations
Another IT principle to consider is the total cost of operations. Let's look at the cost implications using the examples I provided above.
Depending on the type of your application, a serverless implementation could be more economical compared to a traditional Infrastructure-as-a-Service model. With the pay-per-use charging model and no infrastructure to manage, using serverless technology may end up saving you money.
Standardizing your monitoring on a cloud-specific solution like CloudWatch will most likely give you lower costs compared to implementing a cross-cloud solution. Using managed service solutions may also allow you to reduce your people costs.
Another benefit from standardizing on one cloud is simpler training for your staff. And finally, consolidating all your workloads may entitle you to a volume discount from your cloud service provider.
Conclusion
While avoiding technology lock-in is undoubtedly a good principle to uphold, you should consider all IT principles holistically. There are cases where committing to a single technology or cloud vendor makes sense. Perhaps you are just starting your journey and would like to “dip your toes” in the cloud so you can quickly learn the technology. Maybe you are an SME business with limited IT resources, and willing to accept lock-in for letting the cloud service provider handle all your infrastructure operations. Or perhaps you are under an aggressive schedule and need to build and launch your product quickly.
As with all business decisions, you must understand the benefits to be gained from the costs you pay. Technology lock-in can be acceptable if the benefits are justified. If you decide to accept the risks from technology lock-in, be sure to review them again in the future and assess whether they are still acceptable to your business. Technology lock-ins should be considered as “IT architecture debts”. Debts must eventually be paid, but you need to find the right time to do it.