Cloud-native development with manageable risk

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 power of the ecosystem

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. 

The alternative: Portable, provider-independent development

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. 

Balance_DKE (1).png

What is important when deciding on cloud-native architecture?

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:

  • What application development strategy do you pursue and for what reasons? Are there principles, regulatory requirements or framework conditions that need to be taken into account?
  • How dependent do I want to make myself on a cloud provider? How do you weight the factors speed vs. independence?
  • Architecture strategy of the cloud provider: Does the cloud provider use many open source technologies or does it increasingly rely on proprietary proprietary tools?
  • Which technologies / products do you already use and have know-how? 
  • What is the project setup: Which teams are available? How are the employees trained? What are the motives for switching to the cloud? 
  • Often it helps to think about the end of a cloud partnership at the beginning. This encourages architects to give more weight to the portability of their systems and applications. 
  • How have past projects been implemented, which strategies have proven to be beneficial? Whether a decision turns out well or badly depends very much on your corporate culture, your digital experience, your agility and your employees. There is no one strategy that is the right one in every case. What has not worked well in the past?

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!