While there are plenty of cases in life where vendor loyalty is rewarding, cloud services do not fall under this category.
Full dependence on any one vendor is a dangerous thing as you're trusting that it will be around forever or is impervious to a security breach. If you're locked in with a single vendor and they decide to double the price, migrating to another vendor would be an extremely laborious process, which is why many companies avoid it and end up footing the bill. On top of that, the more you start to rely on their custom-made, managed services, the more lock-in you are committing to and the harder it will be to migrate.
Take Walmart for example, a public rival of Amazon. The retail giant maintains cloud infrastructure with AWS, which poses the concern that Amazon could either steal its IP or sabotage its business. A definite conflict of interest and a great example of the perils of vendor lock-in.
Vendor lock-in is the biggest driving force behind the cloud-agnostic approach, which means companies are able to switch cloud providers with minimal disruption. Most of the time this can be accomplished through the use of an abstraction layer to simplify the process of porting applications to or from various cloud platforms. The idea is to remove the complexity of working with multiple cloud vendors while creating software with enough commonality to ensure that migrating becomes an easier process.
[Ready to leverage nearshore software development teams? Let's talk!]
At PSL, we have been heavily testing this approach, and while it's still fairly experimental, we expect the demand for cloud-agnostic solutions to continue to grow. During our exploratory phase, we've uncovered some solid advice for companies looking to reduce cloud vendor buy-in and get the most from a cloud-agnostic approach.
For most companies, the base-layer services from Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP) are going to be just fine. However, you still have to be sure you are choosing the right vendor in the first place.
When assessing cloud vendors, companies should first make sure that the vendor's services align with the target market of their product, their overall strategic vision, and any budgetary constraints. There are also security, compliance, and regulatory considerations to make, for instance, while one vendor might have data centers in the right countries, others might not.
Base-layer services such as compute storage, networking, and access management all look alike at the large vendors. However, the services change when you drill down into the more specific, opinionated services. These are services that are built around the opinion of a vendor and force the user to build services in the designated format ie: kinesis as Amazon's response to Apache Kafka. Even though AWS might come up with new opinionated services faster than its competitors, you still might be left with less control in some situations.
You should look at providers' development practices because they might have unique rules for how they build and maintain each individual service. Others will have a consistent approach to everything, but they could take longer to release services, so it's important to weigh the pros and cons.
[RELEVANT READING | Cloud Security in Offshore Software Development Projects]
The best cloud services have robust communities of software professionals behind them. Look at the provider's size and the developer community that supports it. With new services, in particular, it can be difficult to be among the first people to adopt it—no one wants to be a guinea pig. Communities tend to develop after a short period of time once engineers begin to embrace certain services and comment on its implementation and design. So, don't jump on new services before you know if it's a service that aligns with your objectives. It's a good idea to have a capability adoption strategy in place at your organization to help guide the selection, implementation and dissemination of new services, technologies, frameworks, etc.
If a company wants to go multi-cloud, one of the most important things to do internally is to evaluate the services you are using and understand how opinionated those services are. In other words, which services have been designed in such a way that developers need to follow unavoidable assumptions when building software for a vendor-specific cloud.
While the most preferred approach is to use the least amount of cloud services possible (i.e. just use base layer services), we recommend replacing opinionated services with open-source agnostic ones (Jenkins, Apache Kafka, etc).
For every opinionated cloud service, there is an industry-standard, agnostic alternative. For instance, if you're already working with Amazon, you could go to AWS for a Simple Queue Service, but that would lock you into that vendor. Instead, explore open-source versions of message queues like ActiveMQ. Another example is Apache Kafka, which is an open-source, industry-standard data streaming alternative to AWS Kinesis.
Again, reducing vendor lock-in is the aim of the game, so try to think of the base-layer services as a common pool of resources and then build on top of that with more agnostic tooling solutions.
We're continuing to strengthen our capabilities in multi-cloud through partnerships and building out our internal services to become fully multi-cloud, with the goal of being able to seamlessly migrate from one cloud to another. Once our expertise and tools are mature enough, our clients will be the first to see the benefits of zero vendor lock-in.
If any companies are interested in learning with us and being early adopters of the cloud-agnostic approach, let's connect!