Background and Motivation

Cloud vendor lock-in problem has been heatedly discussed in recent years, and there is a clear reason: it prevents deploying the software to a different cloud vendor without threatening the process and infrastructure efficacy, and gets in a way of optimizing cost management. Having the ability to switch software to a different cloud vendor creates numerous benefits:

1. It helps to reduce DevOp cost and cloud vendor cost;

2. It allows to choose a vendor based on service functionality, quality, performance, and feature richness;

3. It facilitates the use & deployment of Nested Customer Requests (in-house customer requirements of a specific (and different) vendor).

Vendor Lock-in Problem and the Main Reasons It’s Rarely Solved

While most companies are aware of solving (or avoiding) vendor lock issues, few take actual measures to do so in design, and even less - in implementation.

The main reason for that lies in the complexity of the task: mastering one cloud vendor is a tedious work while mastering multiple cloud vendors increases the difficulty exponentially.

It is also related to the nature of modern software development which became more agile and quick. Today’s development teams are required to deliver microservices way faster than in the past. This creates the “quick and dirty” culture with short-term benefits and mid/long-term drawbacks.

When it comes to cloud infrastructure automation and CI/CD, this approach leads to vendor lock alongside many security, scalability, and high availability problems. In the diagram below one can see the level of vendor lock as a function of the invested time.

How Can We Reduce the Vendor Lock Level?

There a few aspects to consider when opting for cloud microservices automation by decreasing the vendor lock. These aspects form three main layers to be addressed autonomously with the following steps:

Lock-In Prevention Action Plan

The first step to mitigate is to acknowledge the problem and start investing time and effort in a proper design on all three layers. The application and data layer are tightly related with the business logic hence they must be designed and implemented by each company. However the Cloud infrastructure and the related Devops stack is not unique to a specific company and follows industry best practices. Therefore an external automation service can be used With Simloud, you’ll get a “quick and neat” approach to cloud automation and integration. How so?

• Using Simloud can reduce time and reduce cost of DevOps process flow when creating a cloud-agnostic infrastructure

• Simloud service is designed to avoid the cloud vendor lock. It automatically creates cloud infrastructure in your cloud account (on AWS, GCP, Azure, etc) such that migration to a different cloud vendor is easy and automatic (for the cloud infrastructure level)

• It ensures complete CI/CD (Kubernetes, frontend, serverless) and offers centralized monitoring and centralized logging features.

Conclusion

While the common behavior of startups and SMBs to start with a “quick and dirty” approach often makes sense, it creates a technical debt that makes it very expensive and/or non-practical to migrate to a different cloud vendor. The cloud vendor’s market strategy is hardly predictable and depends on various factors, so creating an autonomous infrastructure that will allow an effortless transition to a different cloud vendor if need be is a basis for avoiding many technical difficulties in the long run.