A Super Helpful Guide to Avoiding Cloud Vendor Lock-In When Running Your Service on Cloud
Hello there, how is it going?
Welcome to 8bitmen.com
This article is a comprehensive write-up on the techniques & best practices to avoid cloud vendor lock-in when building & deploying our services on the cloud.
Vendor lock-in is something which gets unavoidable, especially when using a vendor-managed proprietary technology. But still, there are a few practices we can follow to minimize the lock-in risk as much as we can.
These practices assist us in smoothly transitioning to a different cloud service or run our service on-prem when things start to get difficult.
I’ll start the discussion with what is vendor lock-in, why is it risky? I’ll give a gist, & will continue with the best practices.
So, without any further ado.
Let’s get started.
1. What is Vendor Lock-In in Cloud Computing?
When researching on picking the right technology to design our service, there is a reason we prefer open source technologies.
Using open source gives us the freedom to write custom features, leverage the industry frameworks, tools & libraries available. Cloud services to deploy an open-source tech are easily available with competitive pricing.
But when we opt. for a custom written vendor-managed proprietary technology like a hybrid horizontally scalable SQL database with NoSQL features or a NoSQL database supporting strong consistency & transactions. Our app/code gets tightly coupled with the underlying proprietary technology.
Alright, so what are the risks of this kind of tight coupling?
2. What Are the Risks Involved with Cloud Vendor Lock-In?
At a point in future if our business faces any sort of issue with the proprietary technology be it a technical limitation or a billing issue. It’s super hard to bailout since the code is tightly coupled with the proprietary tech.
To transition to a new cloud service, we may even have to write things from scratch which may eat up quite a lot of business resources & time.
When we are locked-in we have to rely on the vendor for rolling out new features of the proprietary tech. Since the code is closed source, we cannot write any custom features. This strongly limits our ability to roll out new business features to the market at a quick pace.
Speaking of security, again it’s on the vendor if it is complying to the latest security protocols & stuff. The data might be at risk.
Well, these are a few of the downsides which come to mind right now wrt. the cloud vendor lock-in.
Now let’s talk about the techniques we can follow to completely avoid or minimize cloud vendor lock-in.
3. What Are the Best Practices We Can Follow to Avoid Cloud Vendor Lock-In?
3.1 Be Crystal Clear with the Requirements
This is one of the most important aspects we have to be thorough with when designing for the cloud. We should be crystal clear on what we want, what are the technical requirements, the deployment budget etc.
The reason for this is, the cloud vendors have so many services & contextual sub-services like monitoring, logging, analytics & the associated billing plans. It’s super hard to decide which one to pick & which one to leave. Be thorough, avoid being overwhelmed.
There might be chances that you may not even need a proprietary technology. Thus, averting the lock-in by a cent per cent.
3.2 First Open Source, then Proprietary Tech
Start looking for open source stack first, if it doesn’t fit your requirements. Then look for the proprietary tech.
I’ve already stated above why it’s a lot easy to work with open-source tech. Writing custom features, leveraging existing tools & frameworks, easy to transition to a different cloud platform hosting the same open-source tech etc.
3.3 Look into Multi-cloud Deployment | Break Down Your Architecture into Modules
A multi-cloud deployment simply means DO NOT PUT ALL YOUR EGGS IN ONE BASKET
Ideally, we should break the architecture into smaller services, microservices & deploy different services with different cloud providers. There are several upsides to this.
Familiarity with several cloud platforms. It becomes easier to transition to & fro between different platforms.
A hands-on in-depth insight into the economics of services running. Easier to make business decisions when you are aware of the pricing intricacies of the cloud.
3.5 Have A Backup Plan Right From the Start. Exit Strategy Ready in Case Things Don’t Work Out
Right from the start, we should have an exit strategy. Specifically, when working with proprietary tech.
There are times when we hit a wall wrt. a technical limitation & things become tricky. We have to roll out a new business feature, but the technical limitation just doesn’t allow us to do that. Or there is a core technology limitation, which would cost a lot to deal with.
Or what if we have a billing disagreement with the vendor?
Having an exit strategy, helps us kickstart Plan B in minimum time.
3.6 Interact with the Proprietary Tech via An Abstraction Layer
Well, this is obvious, still, I’ve added it to the list. Do not directly tightly couple the code with the vendor tech. Always write an interface for connecting with proprietary technology.
For instance, let’s say we need to connect with the vendor database. Instead of directly connecting our business layer with the vendor database. We would write an abstraction layer which would point to the database. The abstraction layer would have generic methods such as save, update, delete etc. Which would have further vendor technology-specific implementations.
The upside of using an abstraction layer is it isolates the rest of the application code from the proprietary vendor database code.
In future, in case we need to change the database, we would just have to change the implementations of the save, update, delete methods.
If it weren’t for this abstraction layer, the proprietary DB code would leak to the business layer & it would require a lot of refactoring, which is error-prone.
4. More On the Blog
Well, Guys!! This is pretty much it. Do share your views on this write-up in the comments. Do let me know if you have anything additional on the mind.
If you liked the article, share it with your folks!!
Follow 8bitmen on social media to stay notified on the new developments in software engineering, distributed systems, system design, real-life architecture space.
Our Twitter Handle
I’ll see you in the next write-up.
- Distributed Systems, Scalability & System Design #1 – Heroku Client Rate Throttling
- Zero to Software/Application Architect – Learning Track
- Java Full Stack Developer – The Complete Roadmap – Part 2 – Let’s Talk
- Java Full Stack Developer – The Complete Roadmap – Part 1 – Let’s Talk
- Best Handpicked Resources To Learn Software Architecture, Distributed Systems & System Design