We got a basic understanding of what is Cloud Foundry in the first blog post.

Did SAP just grabbed Cloud Foundry and put its logo on it? Of course not. We have a very powerful database called HANA and a whole set of tools were already in place and being used by devs out there. This was about combining existing capabilities and porting the already powerful onto the more scalable and multi-cloudable. Some of the Cloud Foundry characteristics were not adopted and the proper SAP adaptations were performed.

Let’s drop the buzzwords and understand this mashup:

What are Multi Target Applications?

This sounds like one of the (many) cases of fancy names for something simple. You’ll tell me if this applies later…

Typically, an enterprise application will access the database and have coding to add business logics to the data (or share data to another system, or nag a user for action, or insert more data, etc). This application is normally defined by somebody, coded and unit tested by someone (else), validated as a part of a bigger picture and finally moved to a productive environment. We call this lifecycle, right?

More technically, we have a user interface, we have some logics and then we have the database.

The some logics part is not as innocent: A fullstack coder friend of mine used to talk about “the backend of the frontend” and “the backend at the back”. In other words, you could even have business logics in two different places: the coding feeding the UI and the logics embedded in the database modelling. Different components (layers), same lifecycle:

In our new architecture, each of these layers can be mapped to a different box in the XS Advanced architecture diagram (presentation layer at UI5, backend logics to Node.js or Java and the modelling and database at the base).

I’ll let you add the arrows mentally for this one:

First, let us respond to the original question. A Multi Target Application is an application whose runtimes are provided by the different boxes or components but only serves a business purpose if those components are held together through its lifecycle.

(I hope you can produce your own definition and tell me if the name is just fancy)

For example, you will develop a piece in UI5, another piece in Node.js and a CDS view that taps the database. Each of these could even be created by different developers or executed separately but they would make no sense unless they are treated as a single business application on its way to the productive environment.

 Let’s go deeper into the technical level…

In the XS Classic approach, each of these “boxes” would have run all of the different applications in copies of the same (JavaScript) virtual machine, against a connection to a schema in the database administered by the applications. That is, a single operating system process eventually catered for all of the runtime needs of each of our different coding masterpieces. You could sometimes see the XS Engine process sweating…

The monolithic process serving all VMs

In the new approach, for the logics piece in Java or Node.js, a “copy” of the box (call it runtime) is created and bound to a specific application. Even the database binds a dedicated instance of itself to a single application in the shape of a container (note that I am not using the word “copy” for the database… that would be huge).

This way, our business application will get its own piece of Node.js runtime with everything it needs to execute its code as a separate operating system process. Something more like this:

Those copies of the runtime are called “microservices“… the name is not as fancy, but I can assure you it’s a bit tricky.

We can take a deeper look into this architecture and its implementation in the next blog post

Let’s stay in touch on Twitter or on LinkedIn !