While Cloud technology offers various advantages, vendor lock-in can be a concern for most businesses dealing with big data. Here’s how the impact of potential vendor lock-in can be reduced within the cloud environment.

By now, most modern businesses know the benefits of Cloud computing and are dealing with Cloud technologies in one way or another. However, despite the many positives that cloud technology can offer, there are several concerns over vendor lock-in when it comes to leveraging the cloud offerings.

So, what is vendor lock-in within the cloud environment? And why would anyone concern about it, especially when there are multiple benefits of not maintaining a private cloud?

In the Cloud context, ‘Vendor lock-in’ is when a customer tied to a technology and cannot easily move to another vendor without incurring significant cost and having compliance and other legal constraints. This can potentially put a business under risk.

These concerns stem from various risks that a business faces when it uses cloud services from specific provider. For instance, what if the cloud provider goes out of business? What if there is a change in the cloud provider’s service/platform that does not meet the application requirements of the business? What if cost advantage is impacted as the business has already locked in to a vendor? What if government policies about services and data changes abruptly? All these can jolt a business or impact them negatively.

These risks are magnified manifold when it comes to Big Data, where businesses have to face challenges of not only application compatibility but also with respect to data transfer and associated costs. Since Big Data involves large volumes of data, the costs of securing and auditing could be even higher than application transfer costs.

In addition to the above two issues, one needs to think about infrastructure and deployment migrations as well. From the engineering standpoint, a few steps can be taken to mitigate these risks. If we can focus on the following traditional areas of the Cloud, the vendor-lock can be planned and executed better, if not completely avoided.

Moreover, while opting for various strategies to avoid vendor lock-in, businesses need to keep in mind the aspects of portability and standard processes for inter-operability. Essentially, it boils down to balancing and designing systems to leverage advantages of cloud provided services and avoid vendor lock where its critical to business.

In the course of a few blogs, I would be discussing a few pointers and approaches on how businesses can streamline the use of Cloud technologies and reduce potential risks. These may not be solidified solutions per se, but will explore ways to avoid issues such as vendor lock-in. The idea is to minimize the lock-in as much as possible, and there may be cases where vendor specific technologies/managed services may provide operational advantages over those of self-managed techniques. However, we need compare both these options to get maximum benefit from the Cloud.

Let’s start by categorizing the approaches to avoid vendor lock-in, into the following broad areas:

1. Infrastructure as Service
2. Platform as Service
3. Software as Service

Infrastructure as Service:

Applications need to be designed in such a way that apps treat infrastructure as service and plan DevOPs accordingly. Infrastructure can be used as a service layer by:

1. Using container technology wherever possible so that you can rebuild and deploy anywhere
2. Building your own standardized/hardened/customized OS from ISO images. By having your own base image with appropriate monitoring and other artifacts pre-installed, machine images of specific cloud can be built from these ISOs
3. Disabling auto-updates of OS to have control on what goes in and what goes out of kernels
4. Planning security aspects instead of depending on Cloud provided. These two aspects can be complimentary to each other. For example, you could harden your hardware, right from IP tables to routing rules, tighten proxies and have your own load balancing concepts than vendor provided ones
5. Instating your own DNS and time sync services if needed

Platform as a Service:

Platform can be used as a service by developing service discoverability that’s agnostic to site and vendor. This can be done by taking the following steps:

1. Using company domain names or fixed IPs to avoid frequent changes to external DNS (if it cannot be avoided altogether)
2. Using VPN tunnels from premises to access internal IPs provided by vendor. Please take care not to use elastic/public IPs to access them. This way internal DNS or host file mapping can be used across vendors to access services internally
3. Securing your software by proxies and firewalls
4. Using your own or open source monitoring systems. You might want to limit vendor provided monitoring to infrastructure and have application monitoring to your own to avoid rebuilding and managing vendor specific monitoring
5. Designing private sub-nets of cloud in such a way that they are extension of your own corporate network. Additionally, you could devise a strategy to assign proper sub-nets across cloud providers.

In my next blog, I will be discussing details of how vendor lock-in risks can be mitigated by deploying ‘Software as Service’. Watch this space for more interesting content on the subject and email us at info@clustr.co.in to share your thoughts.