 Hello, hi, my name is Dave LeClaire. I'm from Stratus Technologies. Glad to see you all here today. Before I start, I want to do a brief little bit of housekeeping. As you're sitting down, you may see that there's a piece of paper on your chair. You can either hand this in or pass in your business card. And we're going to be doing a drawing later for a Sonos Play 3. You can stop by our booth later on today to see if you've won. So we're here to talk about the Stratus Cloud solution. So Stratus is an availability solutions company. For over 30 years, Stratus has actually been solving availability challenges for our customer's most mission critical applications. Traditionally, the company was founded as a fault tolerant hardware company. And many of the most critical applications and processes for credit card processing, power generation, security, many of the things that you rely on every single day run through our hardware fault tolerant systems. We've been an innovator and a leader in availability for many years, however. Several years ago, we innovated and created the industry's first software fault tolerant solution. This is a piece of software that runs on commodity hardware servers and creates a highly available or fault tolerant pair of systems to run business support and admission critical applications. We've recently revved this product and launched it as a product called Stratus Everrun Enterprise. And it's based on the KVM hypervisor. When we came time to look at cloud, we thought it was time to innovate again. We looked at what others were doing with cloud and taking some of the existing clustering capabilities, such as Pacemaker, and creating highly available clouds. And we thought we would be able to do the same thing with our software, HA and fault tolerant solutions. But looking at cloud and the elastic nature of cloud and all the things that you can do with the evolution of OpenStack, we thought it was time to actually innovate again and create the next generation of availability solution. So we started where many other people started, where they actually went to create a highly available cloud solution. But we wanted to go beyond simply protecting from hardware failure, beyond simply building a more resilient control plane and providing a fault tolerant workload hypervisor. We thought that operating in a cloud environment with the agility and elasticity and flexibility, there were things that we would be able to do if we actually took advantage of that environment and create an availability solution for the next 10 years. So what we've actually created is a software-defined availability solution. Software-defined availability takes a holistic view of availability. It actually looks at not only the infrastructure, but your applications as well. And through intelligent orchestration and resource tagging, we're able to actually match workloads to the appropriate resource in the infrastructure to make sure that your SLAs for availability are met. This allows us to do some things that we haven't been able to do before. We can now create availability zones that are dynamic in nature, allowing you to move workloads in between them. You can actually have applications that may be fault tolerant, but they're only fault tolerant at near the end of a fiscal year. The rest of the year, they really only need to be accessible. So we can create environments that allow us to move between general purpose and fault tolerant zone seamlessly. However, as we looked at building an intelligent orchestration engine, we also realized that not only we were solving a problem for availability, we were also solving an intelligent orchestration for other types of challenges in cloud. We can solve compliance challenges. We can solve application dependency challenges, security challenges. We can actually tag resources and make sure that your workload is always running where you want it to run in the environment. There's a lot of pieces that go into this solution. We really would like you to come by our booth, actually take a closer look. For the next few minutes, though, I'm going to ask Ed Brennan, who's responsible for our cloud engineering, to walk through a few use cases of our cloud solution. All right. Thanks, Dave. So that's a good and a PowerPoint presentation. How does it look in action? So what we've done is we've actually taken the availability engine and placed it into our Stratus Cloud Management platform. So what we would start with is taking and associating a fault tolerant hypervisor, for example, to an application. So if I take a look at my hyperviruses that I have available to me, I can see I have a mission-critical hypervisor that's sitting in my environment. And it happens to be this hypervisor here which has tags such as mission-critical, standard, and KVM, for example. So now what I would need to do is create a deployment package that takes advantage of that availability engine. So if I take a look at my deployment packages in the environment, I would enter through my service catalog. And these will bring up all the applications that I currently have running in the environment. And I can create an application package. That application package can now exist in the environment of multiple instances. So we can do a OpenStack Summit name. We can select a category of the application, be it operating system, be it database. We can put another tag on here like a compliance tag, for example. So if it needs to be just in your data center, I can just select the Europe data center. I can create a name for the deployment package itself. Then I would go through and I would create that as a recommended package for my users of the service catalog. And then I would add different images to that package. So maybe the first one would be this Syros image. And I can add storage volumes to it. I can select the different availability levels that it might need. Maybe it's a mission-critical instance. And maybe it, too, has other characteristics that it needs, be it high performance, be it a KVM hypervisor. There we go. My touchpad doesn't seem to be working, so I could save that. And then I can add another image to this and make it an application image. So now it's an Apache image, for example. And I can select different pieces for this, whether it be a large instance, whether it be a small instance. I can add the storage volumes here, too. I can add the different tags for the mission-criticality. Or I can make this just a commodity instance. Because this is an Apache server, maybe it's stateless. I can then go in, I can save that. And now I can create my actual deployment package. Once I've created my deployment package, my users are, it's as simple as going in now and saying, I want to go in and I want to add an application to my environment. So instead of selecting off a whole bunch of glance images in the size of those images, they can go in here very easily and find a deployment package that they want. And in that deployment package, they can tell us about that deployment package, whether they want to have it mission-critical, whether they want to have a standard performance, whether they want to have it on a KVM hypervisor. And based upon those things, I've got a recommended package, for example, that comes up. Once I have that recommended package, they can go in and tell us a little bit more about their deployment. They can name their new deployment. They can tell us about any of the other, maybe it's going into a development environment, or maybe it's a production environment, or maybe it's disaster recovery. And they can add the number of instances they want to do, and the number of deployments they want to do this. I want to do two or three or four deployments. And we've actually associated that to a chargeback as well. They would go in here and figure out how much is going to cost per year for this kind of a deployment for them to run. Once they've done that, they would just go off and deploy this package, and this would go off, and then spin up all the instances needed for this application to be available to them with all the configurations it requires. And then they can go in and take a look at their dashboard so they can look at all of their environments. But more importantly, take a look at all of their applications that might be at risk within their environment, whether they have an availability risk, whether they have some sort of a serious risk to it, and what that risk might be. They can go in and take a look at the advisories. Maybe they're running out of capacity on some of their nodes, and their availability will be at risk at some time. So now they're going to go in and be able to see that in this environment and actually be able to take action on those things. They can go in to their dashboard and take a look at the statistics of their applications that they have, maybe those applications and look at their utilization statistics. And I can go in and go through by tenant, or by availability, or by application and group them in any way I want. And then on my summary page, I can look at my dashboard and then the utilization statistics for my dashboard, and grouped by availability levels that I've selected, I can take a look at how I'm doing for my network bandwidth, for my storage bandwidth, my IAPs in the environment, and take a look at how these things are doing and from a health perspective for availability and see when I might need to add more bandwidth to the environment. So you can see I've got a very summarized view of everything that's going on the environment and the capacities that are currently happening for those applications. Okay, well, I want to thank you for coming out and taking a listen to us. Any questions? We'll be doing more detailed demos of the booth, E41. Love to have you stop by and take a look. Thank you. Do you want... Yeah, folks, we'll just pass those cards to the center. Ed is in the center aisle. I think he's going to collect them and we'll be doing the drawing shortly. We can stop by our booth in a few minutes and see who won.