 Tudi je tudi čas. Zdaj, sem zelo tako 40 ljudi, da so tudi 20 ljudi, da se nekaj nekaj počil. Mi je Nikolaj Volchev. Zvonim z SAP. Proste sem v 3 ročnev, v domenju KWAT, in especially in the life-cycle management part of it. So here I will talk about, first of all, distributed apps in the cloud, what are their challenges, and then would share our experience at SAP, how we actually manage such kind of apps in an easy manner. Okay. So starting with distributed applications in the cloud, what is this beast? Very abstract speaking, we have this cloud in the middle. You can imagine this is a cloud foundry deployment somewhere, on whatever, yes. Normally we have the end user of your business app, which is accessing it via one unique endpoint or graphical web user interface. But normally behind this web application or service is an interconnected graph of other subcomponents running again in the cloud or in any other cloud, bringing different aspects of this one business capability that the user actually is interested in. Normally there is this application development team, who is responsible for the development, for the testing, for the configuration updates, et cetera, of this interconnected set of applications. So this team needs to actually manage this distributed app in the cloud. So what are the challenges that we see for this application? We would start with a very simple example. It is a very common pattern that you, for instance, separate your front end from back end, develop this in the most appropriate technology for the purpose, like doing front end in Node.js, that use from user request processing, or some back end in Java, for heavy data processing, et cetera. Possibly these two apps need to evolve together because changes in the back end needs to be accordingly reflected in the UI. So we are talking here for a not that de-coupled life cycle of these apps. These apps have dependencies to a persistent service, like PostgreSQL. The front end here needs some geospatial resource, which is external to our app here, our distributed app, because it is managed by another team. It might be even deployed in another cloud, it be whatever. The Java back end might expose some this way stable API for consumption from another service. And all this is managed by our application team. So what are the challenges that we see in practice? First of all, how to develop the different components, possibly heterogeneous of our distributed app, consistently achieving some versioning between the apps and common built test run workflow, then how to model deployment specific configuration, because this is wanting, assembling your apps, but then you want to deploy them at depth, at test, at prod, possibly with different configuration for each of these deployment environments. So these have to be declared somewhere. Then possibly how to package and deliver, because in some cases you don't have to package, you might have some continuous integration to directly deploy from the source control repository. But sometimes you might want to package version possibly exposed to a marketplace, your application to be purchased by other users. Then how to deploy it via possibly one single operation, following the concrete order of deployment of these apps, because we would see that this also is important. How to update it without breaking the app, because different services might require, for instance, the UI might require first to update the backend in order to work. Possibly without downtime, there are patterns like boograin deployment introduced on the app level, but here we are talking about this distributed set of apps, so we need something on that level in order to achieve true zero downtime update. And finally, how to undepoi all these things without any leftovers on the system. So, what are the solutions that we see in practice? Many, many teams come up with these script code words actually to automate their lifecycle operations, to create different apps in certain order, to create certain services also in order to bind them, et cetera. This is really possible solution, but first of all it requires significant up-front investment and it's kind of costly to maintain in time. And actually what I'm going to propose and cover here is to offer some decorative app model, which would be interpreted by deployment tooling to actually address all these challenges. We already have this on the app level in Cloud Foundry. You can deploy app with certain configuration, bind it to services, but this doesn't cover your more complex, possibly solution that has several apps there and possibly managed services. So, I'm going to introduce here the multi-target application concept, or simply MTA. And this is first of all a spec developed at SAP and a model, decorative model, where application developer teams could actually describe the structure of their distributed app, where the different Cloud Foundry apps are mapped to entities called modules and managed services are mapped to entities called resources. So, on the left side we see our application in the Cloud Foundry runtime. Actually we map it to something decorative here. And the definition here is that this multi-target application, or MTA, is composed of different, possibly heterogeneous apps, possibly different services that we want to manage as one lifecycle management unit. We want to deploy it, to update it, possibly to do boogreen deployment with it and finally delete it with one operation. So, what such kind of a model could be good for? First of all, define explicitly the structure of our distributed app. In most cases this is not that explicit. You deploy several apps, they understand your eyes via some other means, et cetera. But having a decorative model, there could be tools that actually deploy this application automatically. And I will show that. Second, you might declare any external resources that our app depends on, either on deployment or runtime, so that tools could allocate automatically these resources and buy them for you. Even on deployment, remove these external resources. And here I'm not talking only for managed services, but this could be actually anything there. And the third good thing is to put declaratively the specifics, actually to declare the specifics for your app for deployment in different deployment context, like that in depth you want to run with wall memory, in queue you want to do some wall testing and on prod to have separate configuration. So, having this declaration, actually we can really distinguish between the stable structure of the application and volatile configuration between the different deployments. Here we can actually provide capabilities like even interactive feeling of some missing configuration on deploy time. Ok. So, the main challenge actually that we are addressing here and actually we are addressing it with putting one wife cycle around these distributed apps. So, what is this wife cycle? We want to cover the development through built and distribution of your app to the operations. So, we cover the whole spectrum here. Starting with development, this is not that different from before and actually to illustrate I've taken the prominent spring music sample for cloud foundry. Actually it is rather simple. In its classical form it contains just one spring application with persistence. But I've extended with it some news provider that you could manage not only songs and albums in the classical spring music, but you can also show some music news. I've also added some external news provider that are coming outside from our app. So, this is the thing that I as a developer want to manage. First of all, I have to create all sources in your idea of choice, whatever. And then I have to define this structure of my application. And for defining the structure we use YAML descriptor files starting with MTA deployment descriptor is the thing that you put your static content of your app, static structure. This is normally included in your Git repository. And you normally have one of it. Then you might add extension descriptors. These are kind of descriptors holding your deployment specifics. And they are merged on your static part. So, via such kind of files you can alter the configuration for depth, for plot, for test, et cetera. So, there might be different extension descriptors and they come when you deploy the app. It is normally not part of your source control, et cetera. And it is provided by the operator. So, this is my spring music enhanced spring music deployment descriptor. This is the YAML file, but just to cover the most prominent parts from it. So, we are enhancing the standard metadata offered by Qual Foundry with additional extensions. So, we are adding this spec version. As I said, the MTA is a spec. It defines what are the things I could put here in terms of elements, but it is not that important here. What's important is that I give my application, distributed application an ID so I can correlate the different parts of my app. I also give it a version so I could achieve unified versioning of the different components. Then, I define the so-called modules. Remember, these are the apps that would be created in the runtime. These have types, which correspond to the different build packs that would be used, but via the type semantic you can create additional default configuration for your app. For instance, say that your Java apps need to be run by default with 2 gigabytes of memory. This is something very useful that we see at SAP. Additionally, you add the part to the binaries. Additionally, you can configure other parameters like build pack, routes, memory instances, etc. Actually, everything that you can put in the standard manifest demo, you can put it here as well in the parameters of the app. You can also add the environment, this is yet another standard thing, but one prominent addition is that in practice we see that when you decompose your app to different parts, you normally want to do some kind of discovery between your UI and the backend and there are different ways to achieve it. Spring cloud provides something for that, but here we provide another alternative. We are not opinionated, but we have additional ways so you can expose configuration from one of the apps, which could be read and injected in the environment of other apps. Here my spring news app exposes its URL so that it is visible for other apps. You can see that we are using here some placeholder notation and these kind of placeholders with the door would be resolved on deployment time automatically by the deploy tools. So here the default URL would be resolved to whatever URL is assigned to my news application at runtime. Inject the URL of our news provider in my main web application via such kind of require section and actually it would be injected in environment variable called news URL here. I am doing a reference to it so that's it. We have URL from one app in the environment of the another that wants to talk to it. Additionally we add the resources these are our managed services. We have one Postgres managed service and we have one user provided service. Remember the user provided service our external service this external news provider. We configure them at the service label in the first case Postgres certain plan and we configure the user provided service. But something is missing here actually it's missing the URL. This is something that is not known on design time of your app. Actually this URL of this external news provider would come possibly at deployment time and might vary via different deployments of your app. So this is something that I don't want to put here because I simply don't know it. Then we have service bindings actually all of the stuff that is allowed to model for your app like routes bindings etc. All of it is supported here as well. We simply put it in a more decorative way. We might define service bindings with certain parameters for the bindings and having this static structure filled out we could prepare also some kind of deployment specific configuration. So this is an example of this extension descriptor in which I'm providing certain concrete values for instance production deployment of my app so I provide concrete values for memory, for instances and I also could configure with concrete URL my external service provider. So this is the extension file that comes on deployment time. Good, I've developed the app, prepared the sources defined these two descriptor files. One of them is mandatory, the static one the deployment descriptor, the other is optional. Then I have to build actually this is an optional step as I said some people or teams they develop and deploy directly from source but if you want to actually package and distribute your app or as I said publish it to a marketplace you might want to package it and bring it to one structure. For that we introduce the so called empty archive which is a kind of container compliant with the jar specification in essence contains my application sources it contains the sources plus the jar manifest and the deployment descriptor. Remember this is the file containing the structure of our application and it is normally contained in the archive. So this archive is then used for distribution I might send it, I might publish it somewhere et cetera I might sign it so the deployment tools could check the signatures of this archive. So how I build it actually first of all I start with defining the project structure sources et cetera and build my sources actually in the spring web application I have jar file and a Node.js application for my news provider then I could alter the empty deployment descriptor via whatever YAML editor I choose then could add the manifest YAML for the jar file this is an optional thing and could finally use a jar or a maven plugin we have such for building this structure into an empty archive this is the thing that we actually need to do so we've covered the development building come to, right now we're coming to the interesting stuff to the deploy actually this is where the challenges are experienced here so we're deploying the app to Cloud Foundry and for that we introduce the so-called Cloud Foundry deploy service the wife cycle operations of my distributed app with single operation and in the same time actually assure the completeness and consistency of our app so we have the operator using standard Cloud Foundry terminal here with one additional plugin called CF deploy with this command and the operator actually hands over here the empty archive plus the deployment specific configuration which is optional because the archive could be self-contained could contain anything there and then this actually calls the so-called Cloud Foundry deploy service backend whose purpose is to achieve your desired state of your distributed app it is a standard application running in Cloud Foundry and in order to bring your app to its desired state it implements a certain set of predefined workflows what are essentially these workflows doing they first of all are analyzing the empty archive plus your deployment specific configuration in terms of extension descriptor the deploy service is reading the current state from the Cloud Foundry environment reading directly the Cloud Controller API comparing these two and computing the delta between the current and the desired target state and actually executing only these delta operations so as a final phase I would have my desired state of the application so what are the supported operations that we have first of all deployment incremental this meaning that you might deploy your app and then update it and only the updated or changed things would be actually pushed again, restaged rewired, etc we support deployment from Git repository so you might directly put all your stuff in GitHub, just do CF deploy with Git URL and this would actually materialize your apps and services in the Cloud Foundry runtime and we also have plans for supporting deployment directly from sources, from directory we also have this important thing, boogreen deployment but not like the classical boogreen deployment but not on app level but covering these different apps that are interconnected and actually achieve our capability and we also have cross application, cross MTA configuration so I should show you how to actually expose and consume configuration from within your app but we also provide a kind of configuration mechanism that you can use between different apps here some additional we call it enterprise qualities that we provide, first of all all things are deployed deterministically with a concrete ordering that is exposed via the deployment descriptor there is for instance a resume from a failure, from multistep operation if there is something like that we implement certain version evolution policies like you might disallow downgrade of your app and finally deletion of not relevant artifacts on update or when you have just removed one app on update or the complete deployment of your app so this was the kind of boring stuff some real data our services wife on SAP cloud platform there we execute more than a thousand deploy per day we have SAP at least more than 100 such kind of distributed apps including the test ones that are used by different teams and more than 100 productive applications running in our platform and this also is actually developed, built optionally and deployed via this deployment infrastructure and one important thing it is open source from the last Friday so you can find everything with hub first of all the MTA model guide we have certain this MTA plugin for the cloud foundry CLI and our backend or work for engine that actually deploys your app with single operation and actually achieves this automation so you can look at it we can try it what are the next steps we are open source but we are also eager to contribute to the community so we already initiated some talks with for instance Dr. Max from the extensions PMC and we we expected to give in the next weeks proposal of incubation in the cloud foundation but in the meantime we are actually continuing our work for achieving additional capabilities based on this decorative model that we introduced some plant features that we have a parallel materialization of artifacts that would further reduce the overall deployment time application configuration update so you might not want to actually re-upload via cf push and restature app just some kind of configuration update we plan support for docker and with such kind of support you might imagine that will act as docker compose for cloud foundry additional interesting thing is the lifecycle hooks where you might add some custom application coding executed on different lifecycle phases of your app like on update or on delete additional secure configuration management reusing this credit hub project that is right now is getting some hype for our configuration management so having this outlook the key takeaways first of all we see a common pattern for the distributed cloud apps in cloud foundry we are coming with the MTA model actually to address these apps and build these processes from development through build to deployment actually to address them to bring these enterprise qualities and we are happy now to contribute to the foundation with that and yeah I would really appreciate that you look on this give your feedback and really drive further lifecycle management area in the cloud foundry thanks I didn't get it this is very good question right now in the open source world there is no support at SAP we have certain tooling that we might open source that as well but anyway if we we are planning to provide some support for that as well because this is really a missing thing you might use any YAML editor out in the world but yeah the assistance is a thing that we are planning to provide yeah this right now is supported on some extent first of all you can model declaratively your app this gives you the possible ordering that you might I actually didn't show an example of it because there are many things in the cloud foundry like capabilities but you can model certain cloud foundry tasks to be executed as part of your app against the application droplet as well and with the lifecycle hooks that I mentioned would be possibly the silver bullet for such kind of things that you might add some migration logic that is executed only on update or possibly do some cleanup on delete et cetera but anyway even now without these capabilities you might add this in your application coding on bootstrap et cetera things like in terms of support that are coming for this and the CF tasks right now are also available yeah this is supported in the boot green deployment that we have boot green you deploy both versions and just switch from one to the another and on MTA on this level we support it with the two different apps we would have two different sets of apps working so you might test the new version if you are not satisfied with it you might abort the process delete the new version and keep the old one but if you don't use it this zero downtime update right now you are left with the new version and actually bringing back the previous state is a feature we might add in future because right now we also have the support from the quad controller and runtime because you might at one point of time you might have two versions or contents of your application at the controller side okay, anything else? okay first of all we have an integrated web IDE so there you have this assistance for creating the MTA app adding different modules for it and you have very good assistance for compiling this descriptor then you have also an automatic build to not just simple jar file or a maven plugin for actually building this thing if you want to package it and actually something in that direction we might also bring in the open source world because right now we are open sourcing the model plus the deployment with this not so I would say convenient way for building it is not that complex but you have to do some maven configuration to build if you want to for building of the MTA actually what we defined is the structure we expect a container following the jar spec so you might use grader as well or whatever, you might compile it okay, so thank you I would be very happy to look on the GitRapples and give any feedback thanks