How much of a dependency do you make on a cloud provider when using proprietary tools and services? Is this dependence worth it?
Author: Dominik Keusch
When setting up a cloud-native solution, the first step is to decide to what extent you want to use the proprietary functionalities of the cloud provider. Modern applications consist of a multitude of different components: In addition to the actual development, solutions are needed for configuring, orchestrating, monitoring and logging the application. You need storage, databases, messaging or streaming services, security and network functionality, runtime environments and much more. The modern cloud providers offer their own integrated solutions within their ecosystem to fulfill the functions of these additional components.
The advantages of such an ecosystem are mainly based on the factors speed, compatibility and simplicity.
Cloud services can be brought to life with little effort. They can be easily configured in a web interface or provisioned via automated scripts.
In addition, the services are designed to fit together perfectly - it just works! This agile, seamless interaction can be a gigantic innovation driver.
The ease with which the complex services interact is fascinating and whets the appetite for more. The cloud providers spare no effort to actively enhance the convenience of the ecosystem. The functionalities are well documented, there are numerous code examples provided in all possible programming languages.
In addition, we offer our own conferences, attractive certification offers, webinars, online courses, etc. One quickly feels comfortable within an ecosystem.
This feeling of well-being, this ease in rolling out an innovative product within a very short time, comes at a high price. The more the benefits of these seamlessly integrated components are enjoyed, the greater the dependence on this provider.
The glue with which the application is «held together» only works within the ecosystem. If you are not careful, the entire architecture will be geared to this provider and portability will no longer be guaranteed.
What are the options for reducing dependence on a single provider and increasing portability?
You choose a provider-neutral architecture from the start and build your tech stack from services of your choice. This allows you to benefit from the great advantage of flexibility. You can choose the best solution for each subtask from the wide range of services on offer or you can replace a component more easily in the future.
The Cloud Native Foundation offers a good overview of the available components. As part of the non-profit Linux Foundation, the CNCF aims to provide an overview of the open source projects within the Cloud Native Landscape and to promote cooperation between the projects.
The advantages of portability do not come for nothing. It requires an active architectural decision to take this path. The choice of services is complex, because projects develop rapidly and compatibility is not self-evident despite dockers and cubernets.
It takes a lot of engineering effort to make everything work seamlessly together - assuming the necessary expertise. In support cases, it is not possible to turn to a single responsible contact person. This further increases complexity.
Both cloud-native approaches presented have advantages and disadvantages. So what is the best way to decide? It's not a question of right or wrong, but of weighing up and consciously dealing with the issue. Consider the following questions, for example:
Conclusion: Both approaches to cloud-native development presented here have advantages and disadvantages. Depending on the application, one must weigh them up carefully and decide which factors to rely on. The decision is by no means a black-and-white one, and there is a broad spectrum between the extremes. In addition, it is essential that your company gains its own experience and experiences, for example in the context of a proof of concept and in real life, what the corresponding decision feels like. Fail fast - learn fast!