How to Accelerate Deployment of Distributed Cloud Applications

Introduction: Problem

Typically, a cloud application consists of at least a couple of different components, and most of the time these are written in different languages. This, of course, gives us a lot — rapid development of new features, using an appropriate language for the proper purpose, agility, resilience, and so on and so forth.

However, this also raises a lot of questions with regard to the app lifecycle, doesn’t it? For example: can we reliably update complex multi-lingual apps? Can we do that from Git? What about using the blue-green deployment strategy? How can we move the application from our testing environment to the productive one?

Usually, every dev team tackles these issues by creating its own automated scripts and processes, so that manual work is minimized and no downtime is needed. Some platforms provide ready solutions, such as Docker Compose and Helm.

Our Approach

In SAP Cloud Platform we use the open source MultiApps project, which has been proposed to the Cloud Foundry community as an incubating project. MultiApps enables you to package all of your software archives with the same lifecycle into one bundle called a Multi-Target Application (MTA) and deploy it as a single entity. This provides you with the consistency you need and even more — a declarative approach for describing your dependencies.

You can tune-up an MTA to take care of the deployment and timing order of your application’s components; also, it can delete any non-relevant artifacts from your new version. MTAs provide you with a ton of enterprise qualities such as version evolution policies, logging and auditability, recoverability of multistep operations, and much more.

All one should do in a Multi-Target Application is define a deployment descriptor (in the format of a yaml file) and pack it together with deployment artifacts. In that very same file, one can describe the whole application and its dependencies.

In an MTA, the different components of the application are described as “modules” and all external dependencies are called “resources.”

How to use it

Open our GitHub repository and follow the instructions there.

Technical Overview

A bit more info for the different segments of that diagram:

Operator is responsible for 2nd Day operations like initial deployment, updates, etc. It is the one in charge of releasing to production.
CI/CD pipeline is another way to integrate regular application updates, where each code commit is built, validated, and assembled with the other app parts and finally deployed to production.
CF CLI plugin is the CLI client for performing MTA operations like deploy, update, etc. with a “single click.”
MultiApps is the server app, responsible for bringing the cloud app to its desired state. This is done by analyzing the current state and executing on top of it the minimal set of incremental changes towards the desired state.
PostgreSQL is used for process state persistence as the MTA deployments are multi-step operations with the possibility to resume or retry any failed step. This also provides high availability qualities for the deployments.
File Storage is used for temporary storage of the MTA artifacts like archive and deployment specific configurations.
Cloud Controller is the brain in the Cloud Foundry platform. MTA deploy service backend is mainly “talking” to the Controller to bring the cloud app to its desired state.