The Why and the How of Developing a Multi-Cloud Native Application

It all started with the shift in software development and the rise of virtualisation that we started thinking: Multi-Cloud, because a Multi-Cloud strategy is tightly coupled with agile practices, DevOps, microservices, and dynamic business needs and this is what is guiding enterprises and organisations today.

In a previous post (see here) we discussed the merits of a Multi-Cloud strategy, how to adopt it and transition to one. Now in this post, we will look at what it takes an application to be Multi-Cloud aware, and more specifically to be successfully run by the DECIDE Framework.

In year one of the project, Fraunhofer FOKUS worked closely with the other technical partners in the project in order to define the functionality and architecture of the DECIDE Framework’s tools and understand how these translate into requirements for a Multi-Cloud native application.

If we revisit what a Multi-Cloud native application is to DECIDE, we will find that it is one that is designed in a manner, which allows its microservices to be deployed on multiple, potentially heterogeneous clouds and still work in an integrated and transparent way for the end-users. In contrast to a traditional cloud-native application, the goal here is not to replicate and allow for redundancy by using multiple clouds, but rather distribution, agility, velocity, fast disaster recovery and the fulfilment of non-functional requirements (NFR), i.e. business needs are.

Now let us examine some of the challenges that arise when designing and operating a Multi-Cloud application:

  • The applications defined NFRs and SLAs must be respected at all times. - Resilience and portability of the components or microservices of an application; when porting processes across clouds mean time to recovery (MTTR) must be decreased, disconnected scenarios and faults have to be avoided.
  • The application's components (e.g. microservices) should work together in an integrated manner. Microservices’ endpoints must be managed and discoverable in case of switching hosts (change in location /IP addresses).
  • Just as with the portability of microservices, achieving seamless and cost-effective data migration or replication must be a given.
  • Making use of provider-specific SaaS and IaaS services should be possible, despite the intricacies of each service provider (e.g. different APIs, data storage).
  • Dynamic re-configuration of the application properties should be with no downtime.

The aforementioned challenges form the basis for all considerations when designing an application in the context of DECIDE.

In order to address these challenges, we need to look at architectural patterns. Patterns are not new in the realm of distributed computing and thus in cloud computing. Patterns are regarded as solutions or best practices for commonly occurring problems [1]. In the context of DECIDE, a pattern based design approach can also simplify and guide developers in the use of the DECIDE DevOps framework in order to avoid common pitfalls at the design time of an application.

Below you will find, a number of architectural concepts and patterns that if considered in the design time of the application, the application will become Multi-Cloud aware and the DECIDE Framework can cost-effectively (re-)deploy and re-adapt the application with minimal downtime on different CSPs.

Separation of Concern and Distribution

With separation of concern, an application becomes easily modularised and thus distributed. This allows developers to leverage the specifics and intricacies of cloud resources based on the current needs and, of course, the non-functional requirements of each individual component or microservice. Developing microservices addresses this issue and is regarded as the best choice to date.

Recommended patterns to be used:

Distributed Application Pattern

Loose Coupling Pattern

Containerized Services

Adopting a Multi-Cloud strategy emphasises the need for agility and leveraging the cloud resources based on a microservices’ individual non-functional requirements. Containerization can aid in this matter because with it building and deploying a service becomes much easier and the services can be independently deployed and scaled [2].

Furthermore, high-performance recovery is given, as containers are extremely fast to build and start. In addition to this, containers are much more cost-effective than VMs as the latter can impose a significant footprint by introducing a layer of intermediate processing [3] that ultimately can further increase costs.

Recommended patterns to be used:

Service Instance Per Container Pattern

Containersiation Pattern

External Configuration Storage

Application and application instances (i.e. microservices) in a Multi-Cloud environment need to be scaled out as well as ported from one Cloud Service Provider (CSP) to another in order to satisfy the defined NFRs.

The configuration of a Multi-Cloud application does not only lie in the functional parts but also the deployment and provisioning information for the underlying infrastructure [4] and services.

Examples of configuration elements include database connection strings, UI theme information, target CSPs, network locations, URIs or external APIs or the URIs of queues and storage used by a related set of applications [5].

Outsourcing this information avoids unnecessary redeployments associated with downtime but also avoids having instances use different configurations settings while an update is still being deployed.

These issues can be solved by moving all relevant configuration information out of the application package and into a centralized location. Advantages with this approach lie in giving easy access to deployment tools, enabling dynamic re-deployment and re-adaptation.

Recommended patterns to be used:

Managed Configuration Pattern

Service Registration and Discovery

In a traditional distributed system deployment, components communicate with one another and rely on functionality or data provided by other components. Components and services run at fixed, well-known locations (hosts and ports) and can easily call one another using HTTP/REST or some form of RPC [2]. However, in a modern Multi-Cloud and microservices -based deployment, network locations of the components are dynamic and change frequently.

This is due to the fact that dynamic IP addresses are usually assigned to containers and virtual machines alike. Furthermore, re-deployments occur frequently throughout the day due to specific NFRs that need to be met. For instance, workloads may change periodically and, thus, a suitable CSP must be found to fulfil the needed resource capacities and to keep costs down.

This results in dynamic changes in the number of service instances along with the allocation of new network locations. In order to make clients easily and seamlessly able to determine the location of the service to which they send requests, a mechanism is needed to make the services who have changed their network location, discoverable in an easy and simple manner.

This concept is not fundamentally necessary for the functioning of the DECIDE Framework but it allows for the seamless functioning of clients and services when a re-deployment takes place.

Therefore, we propose to use the following patterns when designing a Multi-Cloud native application:

Service Registry Pattern

Client-side Discovery Pattern

Server-side Discovery Pattern


For more information on architectural patterns, read:

[1] C. Fehling, F. Leymann, R. Ralph, W. Schupeck and P. Arbitter, Cloud Computing Patterns: Fundamentals to Design, Build, and Manage Cloud Applications, Springer, 2014.

[2] C. Richardson, “,” [Online]. Available: [Accessed 10 10 2017].

[3] A. E. Inc, “SOA Patterns,” [Online]. Available: [Accessed 09 10 2017].

[4] T.-F. Fortiş and N. Ferry, “Cloud Patterns,” in Model-Driven Development and Operation of Multi-Cloud Applications: The MODAClouds Approach, Springer International Publishing, 2017, pp. 107--112.

[5] “Microsoft Azure Cloud Design Patterns,” [Online]. Available: