 Okay, I'm going to kick it off because there is a lot of material to cover. My name is Jarek Mishik, unfortunately my partner in crime Venkat couldn't make it. He's part of the GTS team, so I serviced his team and obviously he ended up going to a customer location rather than to this lovely city of Paris. So I'll be holding the torch for him and for myself. So first of all, a quick intro, I've been with IBM for 20 years, believe it or not. And for the last six years or so I've been working on cloud, which was initially called within IBM as a new enterprise data center. So let's just quickly look at the scope of this presentation here. So what I'm going to cover is basically what we did within IBM and it was a joint effort between the group that I represent, which is STG, which is the server group, and the GTS, which is our services group. And working with them, particularly the part of services which is called strategic outsourcing. So they have a lot of engagements with customers where they need to go in, stand up the entire infrastructure, set up middleware and end user applications, and then run it. So that's how they make their money. They make their money by doing this over and over and over again. And the challenge here is that whatever you do in any data center, you deal with four fundamental services or four fundamental entities and this would be what? This is compute, storage, network. What's the fourth one? Probably the most important one. Why do you need those three? Well, you typically need those three because you want to run some kind of workloads on top of that, right? Just the infrastructure itself is meaningless and useless if you don't have workloads. In other words, applications and software to be running on that particular infrastructure. So what we did is we thought about how do you actually eliminate this incredible cost inherent to standing up complex infrastructures for typical traditional applications, right? You've been probably to many sessions during this week and I attended myself some of those and everybody gets very excited for a good reason about those born on the cloud applications. It requires, however, some significant upfront investment in rewriting your code or writing a new code from scratch that would align well with this cloud paradigm where you create your software as microservices, stateless, so that they can be stood up and killed and it doesn't really matter whether 100 is running or 150. Here in this particular example, we still have a large number of customers who care about those traditional applications. But on the other hand, we want to take advantage of those latest advancements in compute science specifically in cloud so that we can deploy those applications, stand up the infrastructure and deploy those applications quickly, right? So our challenge here was to come up with a methodology that would allow us to automate the whole process, the whole shebang, so to say, right, from going to the customer location which just hardware available for us and then automating the entire process of standing up your cloud and then standing up your application-specific infrastructure including middleware and then deploying the application itself in an automated fashion, right? So the use case here was to provision that infrastructure for this multi-tier J2E app, typically a lot of our customers use those J2E applications written according to this development pattern and then be able to stand up the infrastructure and deploy the application in three or less than three simple steps. So that was our challenge. So what are the quantitative benefits that we achieve by doing this that way? So obviously improved time to value because instead of spending sometimes, believe it or not, in complex situations, we could spend a couple weeks standing up the infrastructure especially if it was heterogeneous infrastructure that included power and Intel and then having complex databases to be set up. So we can basically shrink down this time to one hour and one hour is full disclosure here, is meant as one hour from the time that you already have your cloud up and running, right? We have the automated process to stand up our cloud but that's not the subject of this particular talk. So then obviously once you have this all set up in that agile fashion, you can change your environment, add, remove workloads, autoscale those workloads pretty rapidly. And by doing that, so we also achieved quite high level of cost savings, right? In that old days, setting up this whole infrastructure, setting up your applications was very labor intensive. So we had a whole set of scripts that you can run but nevertheless there was always a human involved in going actually to the physical system, installing the operating system then running those scripts. One additional aspect of this is that all of those installations are slightly different. When we go install a well-known that I'm not supposed to say but well-known enterprise ERP system then they have a tech note which is probably like 10 pages will tell you how do you need to install your operating system for that system to work, right? So obviously somebody had to automate that and had a script but somebody need to still go and install it and it takes time. So all of this has been automated. All right, so my pitch here is really what I want to convey is that with this new approach we are basically gluing together or bridging two paradigms. There was an old paradigm going back to my four fundamental services in every data center or every computer shop which is in the old days there was a huge difference between operations and then DevOps and software deployment. Operations had their own tools, they had their own procedures, scripts and so forth that would stand up the infrastructure. So ways how you install your hardware, how you wire this, how you install your network, how you configure your network, how you install your operating system and so forth, right? That's the one discipline which was in itself pretty contained and well-defined. On the other hand you had all these DevOps people that had their own tooling and their own procedures. How once that whole infrastructure is set up how do you go and actually install those pieces of software? How do you take the stack which may be very complex and install it in a repeatable and manageable manner? So two disciplines, different tools, different things that you need to do. What I'm showing you here is with this new approach which is heat-based, open stack heat-based. I can now glue this together, I can basically bridge this gap and have one consistent set of tools, open stack and the environment of open stack and then I have one scripting language which is the heat template language, YAML that I can use to describe both my software pattern which describes my software architecture in this particular example, this J2EE. So I have multi-tier application which consists of multi-tier, each tier is a different set of again software components that needs to be stand up in a specific order. They also need to be wired together meaning that the application server needs to know where the data server resides and how do I connect to it, what are my credentials and so forth. So all of this can be now expressed in that one format. I can create one simple template that takes care of both my application patterns and my infrastructure patterns. This is something that people do not realize often times that this is now possible, it's available for you today. So the rest of my session here will be to kind of trying to convey that storyline that you can actually now take your infrastructure describing a standard fashion and take your software stack describing a standard fashion, put it all together in one set of templates and deploy it as a unit and manage this as a unit. This is a huge advantage. All right. So this is my kind of web app pattern. I simplified this so that we can handle this 40 minutes time limit, but it shows all the main components here. So first of all, I want to have a load balancer. So I want to have one IP address to which I can go and hit that IP address and get access to my app. Then you have a cluster of application servers. In our example, it's a web sphere liberty profile servers, but it could be anything else. We just use this for a lot of IBM customers. Within that application server, you have your application running. In our particular example, in this use case, it was a web customer credit application which needs to be deployed into each individual of those servers. And then you have a backend database for data persistency. The application is using JPA, so Java persistency API, to persist data in the DB2. In our case, the backend database is a DB2. So that's the storyline here. That's my web pattern. So how does this actually translate into infrastructure requirements? Well, so for the DB2, and again, that's the requirement which is based on those tech notes or specs coming from our customers, which tell you, you shall use this or that operating system because we are only certified on that or other operating system level and release. So in our case, it was Red Hat 6.5. So I needed to provision a virtual machine based on Red Hat. And I wanted to be able to connect to this machine over a private network, simple. Then I've got the liberty profile VMs, the application server VMs. And again, it needs to use the Red Hat 6.5. It needs to have access to private network. And in addition, I want to scale. And I want to use the heat autoscaling capability to scale this cluster up and down as my workload increases or decreases. In addition to that, I want to also leverage one of the features which are part of the IBM distribution of OpenStack, which is called holistic scheduler. Using this holistic scheduler, what I can do is I can improve the resiliency of my topology by specifying policy, placement policies. You'll see this in an example in a sec. But in our two expresses in a kind of using words, what I want to do is I want to spread my VMs across available availability zones. And then I want to also make sure that if one of the availability zones dies or if one of those zones dies, I lose no more than 50% of my application servers. And oh, by the way, while you edit, also make sure that within the availability zone, each of those virtual machines run on a separate host, right? So think of it for a sec. It's a pretty, pretty well-defined business policy that now, using the extensions which are provided by IBM to the Nova scheduler, I can actually implement. And how? You'll see in a second. But this is something which goes beyond your traditional scheduling in Nova, all right? But this is also driven, obviously, by our business needs. It's not something that we made up out of thin air. That's actually one of the use cases of one of our large customers who told us to do it that way, okay? And we implemented this. There is other possibilities as well. Then for the heat load balancer, right? I want to manage this group of homogeneous VMs. In our case, that's the Liberty profile VMs. I want to manage this as a pool. And then I want to also assign a floating IP that I will use to hit that application with this one single floating IP. And the load balancer is responsible for distributing, dispatching work requests to available servers. All right. So, let's talk a little bit about this topology or placement, because I think it's a unique value that we bring to the table. For those of you who are intimate with OpenStack, you probably heard about the project called GENT, G-A-N-T-T. And that's going into this direction. The difference here is that we already have it. And we work with the community to move the community into this direction, right? But just by the virtue of us having that business need expressed by multiple customers, we decided to implement this kind of a little bit ahead of curve evaluation. So in our case, let's think about an example such that I've got two availability zones. And I've got in each of those, I have several servers. Let's say that I want to deploy initially four application server instances. They run as a virtual machine. Within this virtual machine, I have obviously my liberty profile instance running. And then within that liberty profile, I've got my application running, my web credit application up and running. So I've got four copies of those. And as you can see, I've got two availability zones. So what I want to achieve is that the placement that will assure that if one of those availability zone dies, I still have 50% of my application servers up and running. And that's guaranteed here, right? All right, so think of it for a second. The mapping, right? One host running one virtual machine. Within the virtual machine, you have your application server, which in turn is running your app. So that's our topology. So this is how I actually do it. I'm not going to go into gory detail. And the chart here is more for reference. It's not probably 100% technical accurate, but it doesn't really matter here. What I want to drive home here is that we've done some enhancements to the stack to be able to provide this topology-aware schedule. And for that, we had to enhance Heat Engine itself. So we have plug-in points now in Heat Engine that allow us to call out from Heat Engine to our scheduler before anything else happens. So typically, if you know how Heat works, is Heat works basically taking your template and going resource by resource. So for example, if Heat encounters a request for a resource-of-type server, it's going to go to the Nova scheduler and say, I need a server. And the Nova scheduler will try to place it, and it succeeds, and comes back to the Heat and says, yep, I created that server for you. Server is basically equivalent to virtual machine here, right? Also not necessary. So now, and it goes one by one, so it goes top to bottom, and every time it encounters a resource-of-type server, it goes and asks Nova to create that resource. And then only after all of this happens, in sequence and successfully, your stack will change the status to stack created, which means all the resources you're requested have been created. But it's a kind of, as you know, step by step sequential process. What we do here differently is we actually take the entire Heat template. We kick it out to our ego, as we call it, the holistic scheduler, which processes this in its entirety, right? So what we do here is we actually solve, we are solving the hard NP problem, right? And we do it using a piece of technology out of IBM research, which is, if you're interested, called BSA, which stands for a bias sampling algorithm. But we basically take your entire request, and we create an allocation plan. So at the time when we finish processing this, we already know where all those resources will reside, right? And then we go back to Heat, and we say, OK, do your job. And now Heat starts doing what he does, going to Nova and saying, well, Nova, I need a VM. But Nova is now also plugged into our scheduler piece. And now a scheduler knows, oh, I've seen that request before. And oh, by the way, I actually have already an allocation for that. So here's your allocation. So this VM ends up on the very system where it needs to go to basically fulfill this request, to honor this policy that I just described, OK? So this is roughly how it works. All right, so in terms of policies, there's a number of policies that we implemented. And some of them will be implemented in the near future, with the asterisks at the bottom. But basically, we have several policies that are already there. One is what we call intra-group policy, which allows you to say, OK, so I've got a bunch of homogeneous VMs. And I want to apply an anti-ethnic policy to this homogeneous set of VMs for availability reasons. So the placement will go and spread them across nodes or availability zones or whatever. Another policy is, I want them close together. So that's your affinity policy. So we have this for intra-group. Then we have inter-group policies, which allow you to do the same, but between the groups of VMs. So for example, you have a group of web server VMs, and you have a group of application server VMs, and you want to deploy them in an anti-ethnic manner. So you can also specify that. And then finally, you have something which joins this all together. So you can have a policy which says, within that group, I want an anti-ethnicity, or affinity, and then between those two groups, I want anti-ethnicity. So there is a way how you can express this in policies. So there is a whole bunch of capabilities here, and I will just touch upon one which is implementing the scenario that I described. So for that whole thing to work, obviously you need to know what's the topology. And we describe the topology using this simple XML syntax. So when you pay attention to this sample, to this snippet, you will see that basically we define levels in the topology hierarchy. In this particular example, it's pretty simple. It's two-level. We have availability zone, and then within availability zone, we have hosts. So we define our hierarchy, and then we also define the conditions that needs to be met if you want to place your VM in a certain availability zone. And so we name those availability zones accordingly. So we're going to actually go and generate that file for you using a supplied script. If you have this type of setup, which is pretty typical for OpenStack, if you have multiple availability zones, you can just call this the script, and it will eventually create that topology file for you. But you have ability actually to go and manually create any kind of topology that reflects your particular environment. So you can, for example, be in the HPC business, high performance computing business, where you probably operate on the level of data centers, racks, and nodes. And you could express this hierarchy here as well. And that would work the same. All right. So how many of you attended the heat session on Monday by Zane and Steve, Lynn Bitter, because they were talking about this heat beyond basics, right? They were talking about what are some of the best practices for using heat templates and so forth. And they were also referring to this example that you can actually nest your templates or have a nested stack. And that makes a lot of sense in this particular example because it allows you for separations of capabilities and separations of tiers. So I have created three templates. One is a template, which is the parent template, which describes your kind of, think of it, that it describes the infrastructure requirements. So in this parent template, I describe what kind of nodes I need and then also what are the relationship between those nodes. So for example, whether I use autoscaling and for which of those nodes autoscaling is used and also load balancing and so forth. So this is infrastructure type of layer. And then going into each of the particular node types, like I have a DB2 server template and I have WLP server template, which is the Liberty profile template. Within that template, I actually scoped it so that it only deals with what refers to this particular virtual machine. So what I do inside, and you'll see code examples snippets in a second, I'll do set up this node so it can deploy the middleware, so DB2 or Liberty profile, and it can deploy the application. So that's the scoping here. OK. So here's an example of a policy annotation. And that's within the parent template. By the way, I will post the presentation as well as I already posted those templates on GitHub, so you don't have to make any pictures, but if you want, that's fine. So those examples are there for your reference, and I think it's a good teaching tool as well in terms of looking up how things are actually done and you can use some of those examples. So first of all, to make the whole policy work, we need to annotate the auto scaling group. That's the first line here that I'm referring to, which tells you that basically this auto scaling group needs to be associated with this policy. So then in the policy, you see that the policy is actually what we call custom resource type in here. So it's an IBM specific custom resource type, which implements that topology aware policy. And here what I need to do is obviously I need to define the type, but then also I specify the topology level. So I'm saying in my policy, I want to use availability zone. I want to have 50% as my percentage. So this policy is, by the way, known under resource loss per node failure. Don't blame me for this name. Blame this guy. Typically I refer to this as a spreading policy. Maybe that's easier to remember. Sorry for calling you out on that, but I had to do it. So resource loss per node failure policy means exactly what it means. So if I lose 50%, I cannot lose more than 50% of my resources. That's the policy. And this policy will be enforced at all times. And then within this, I also have another policy which tells, oh, by the way, I also want anti-affinity at a host level, which basically translates into put each of those virtual machines within the availability zone on separate hosts if possible. There's another thing here, which is worth mentioning, which is what is the mode of this policy? It can be hard or soft. What does it mean hard? Hard means that you absolutely must enforce this policy. So what's going to happen if your topology doesn't support that policy? And you guess, how are we going to behave? Well, we fail. We cannot create that stack with this policy being required as hard. So sometimes you can live with soft policy which says, OK, do your best. If you can place it according to policy, do it. But if you can't, still place it. But do your best job to spread, basically, what it means is this. So this is, again, at the infrastructure layer. All right, so there is also this whole notion of wiring stuff together. That's one of the topics that I want to cover. So how do you wire together those software components and different resources? You wire them either implicitly or explicitly. Here's an example of how you wire this implicitly, which means in our parent template, I have a reference to a DB2 server, which means, and that reference is actually, as you can see, in my autoscaling group, which is basically an autoscaling group that creates my liberty profile virtual machines. So this implicit depends on means that you cannot go and start deploying my liberty profile virtual machines until you actually go and get that attribute from the DB2 server node, which means you need to wait until I know what this IP address is, and then you can start continue with the deployment of your liberty profile. Because as you guys know in this J2EAP typical pattern, you have an application which is using your JNDI typically to use the data source, which in turn connects to the database for data persistence. So you say, OK, I cannot go and actually create that link, create that wiring between my application server and application server and my database until I actually know where this database is. So I need to wait until that deployment happens, and then after that I can go and start deploying my liberty profile. All right. So we covered pretty much the infrastructure layer. So again, we use load balancer, autoscaling, and the IBM policy topology, a word placement. So it's always good. Infrastructure is all nicely set up. So what do I do next? Well, next I'm going to use those nodes to set up the software. So on DB2 node, I need to install configure and start DB2 instance. I need to create a database. And also I need to return the host name or IP address back to hit as the pointer to where I actually deployed this DB2 instance. Then for the liberty profile, I need to wait until the DB2 deploys, then install configure and start the liberty profile. And then within the liberty profile I need to configure a default server, so like a default instance of this application server. I need to create a data source, which will be used to persist data. And I also need to set up my DB2 JCC driver because I happen to use the DB2 as my backend. So I need to go and set up this driver so I can connect from the liberty profile back to my DB2, right? And then finally I need to go ahead and install this J2E app. The J2E app luckily doesn't require a lot of things to wire this because as long as I use that GNDI name that I'm setting up here in this default server data source, then I'm going to be fine, right? My application will work. OK. And then once I deployed everything, I want to return the URL to that load balancer. OK. So hit software configuration uses two resources, right? It uses the software config and software deployment. So software config is like a wrapper, which represents your component, software component installation. Typically, it's going to contain a script which needs to execute in order to install and configure this component. But it also takes input parameters and produces output parameters that can be consumed by others, right? And then the hit deployment is actually a implementation, a instance of this software configuration. So I can have one software configuration and multiple deployments if I want, right? And what it does is this defines concrete input parameters for the specific target server. So it kind of binds this particular software configuration with its specific implementation on one of those virtual machines, right? It tells you where it needs to run, actually. And it also creates outputs. All right. So here's an example of our DB2 server YAML. And here I'm going to share with you a couple of practical examples, coding examples, that helped a lot. So first of all, what I'm using here is I'm using a script install method, right? This so-called script hook within the software config space. And what it means is that means it's going to run like a shallow script. As you know, when you run shallow script, it produces all sorts of output. So first what I need to do is I need to kind of redirect this output, because otherwise this output would end up as my output parameter. And it will produce a lot of garbage. And all I need as an output parameter here is just the IP address of this particular DB2 instance. That's all I need. So my output needs to be redirected. So everything in between happens kind of outside of the scope of this standard output device. So what I do here is I install and configure first. I install and configure Chef, because we use Chef recipes to deploy DB2. Then I'm running those Chef recipes. I'm creating my database. Then I switch back the standard output. And now I produce this IP address as it was assigned by the open stack of this DB2 instance. So when I reach that point, what happens is the software deploy resource is going to send a signal back to heat saying, I'm done with this deployment. And it will produce this particular output parameter that then can be consumed by the liberty profile. So you see this here. So once again, it goes and installs this, uses the script install method. And it also ties it to a specific database server instance. All right, so what about this liberty profile? In the liberty profile, first, you see that I actually, at the top, I define a input parameter, which is called DB2 server name. That's the server name to which I want to connect. Then you have that script which runs to set up the liberty profile. Then it's been doctored. So I removed parts of it just to fit it on the screen. But again, the templates are available on GitHub so you can look up how to actually do the entire thing. But here, what most important parts are to set up this data source using this DB2 server name as input parameter. The parameter in this example are passed as environment variables because it's using a shell script so it's a default way how you pass parameters. So then once I set up this liberty profile, I go in profile file. Then I go and use, again, Chef Recipes to install liberty. Using this JSON that I just created inline, using this JSON as an input parameter for my instance. So once this liberty profile gets up, it already knows how to connect to DB2 because your data source and your J2CC driver are all properly configured and installed. And then as an output, I produce the name of my liberty profile instance because that's where I need to install my application. And then here in this particular example, I do not say that this deployment depends on the DB2 because I already did it implicitly. Just keep it in mind for a second because there is also an explicit way how you can define dependencies. And I'm illustrating this in this example. So this is the deployment of the second software component which goes on that virtual machine, which is my application. So in the previous step, I used this software config and software deploy resources to install, configure, and set up an application server. In the context of this application server, I want to run my application. So now it's time for me to deploy the application. And I'm using the same approach here. I'm using that software config and software deploy resources, first of all, to define the script which needs to run to install that application on that particular liberty profile and then also return the output parameter. So here it's kind of easy. First of all, I go to my liberty profile instance. How do I know to which instance to go? I take it as an input parameter. Then I say, go grab that jar file or war file from my software repository. Drop it into dropping directory of liberty profile. Magic happens. Everything is now wired. And oh, by the way, in my deployment descriptor, I'm using this depends on explicit clause or parameter which tells me don't install the application until the liberty profile is installed and properly configured. That's my dependency, right? So going back just kind of a couple of steps, you see that what I did is basically wired everything together. So I wired the application to the application server and then wired the application server to the database server using those concepts here. All right. So one more topic that I want to quickly discuss, which is also important, is the concept of those tools which are required on your image for that image to actually work with the software config and software deploying resources. To cut the long story short, there is a tool which is called disk image builder which builds those images and bakes those tools into the image. So you could have an image which is already kind of ready. You can run this image and say, OK, bake it, the tool's into the image. I have a problem with this. Because in my world, most of the customers do not want to maintain multiple images. They want to just maintain one set of images which are valid across the entire spectrum of applications. If you had one image which would be like a vanilla open stack image and another image that you need for heat, that wouldn't be that good. So eventually, going back and forth, Steve Baker posted actually a way how you can delegate that tool installation process to the moment when you actually deploy the image. So you can have one image which has only cloud in it on it and it will still work with heat provided you follow that example which is given here on that link. So basically what it does, it uses a specific software config resource to get the tools on the image first and then it goes and deploys other software components. So it kind of delegates this by. So in my quick response is to bake it or not to bake it, I would always go for not to bake it. Because then you can preserve one set of images that will work for the vanilla open stack deployments and for heat deployments. And that's the result of the deployment. When you go and run that stack, you will get over the time time stamp here. So first, you will see that heat goes and creates the DB2 server. All other resources wait for it. Once the DB2 server is created, now the auto scaling groups kicks in and start create all those virtual machines with Liberty profile. Once that's done, then the entire stack has deployed. And as you can see, also the policy resource had been properly created. So you not only have a infrastructure running, but you also deploy the entire software stack and not only deploy the entire software stack, but you deploy the software stack in a way that enforces your business policy, which is no more than 50% may die at any given time. All right, I think that's it. I've got some additional material for you to look up. And I think we just exceeded our time. So thank you very much. Thank you for coming. If you have any questions, you can come up to the session up to me and we can discuss offline. Thank you.