 All right, guys, we're going to start now. Just a quick disclaimer before I start off. I do get easily distracted. So if you guys are talking, I'll probably want to listen to what you're talking about. So I mean, just hop and hand over the mic to you. But we'll try to keep it short and sweet so that we have time for our Q&A at the end of the talk because I feel like the talks are like an important aspect of getting the discussion going. But the most interesting discussion happens when it turns into an interactive session. So we'll try to bear with it. Today, we're going to talk about Cloud Foundry. We'll talk about OpenStack containers, open source, essentially everything that you've been hearing about over the last couple of days, stuff that you'll be hearing about over the next few days. And we'll talk about how it all comes together in a portfolio, in a product strategy, in our Healy on Development platform product. And we also have Aaron from my team here who'll work with me. He'll give a live demo of some of the aspects of the platform that we are going to be showcasing today. I'm Manav Mishra. I head up the Healy on Development platform product team. I have been at HP. I started at HP soon after OpenStack Hong Kong last year, so roughly like 11 months. I came to HP from Google. I used to lead product management for Google Analytics, and then prior to that, as you'll see from some of the animations in my slides, I used to be at Microsoft, so I know to use PowerPoint really well. And then before that, I was an open source developer at Intel, so kind of done the tour of the industry, and I'm at HP today. See, this is what I was talking about. So before I start off, I just wanted to quickly touch upon the core themes of a developer focused product. So when I started at HP, the whole essence of what we wanted to do was to create a product for developers by developers. And the core pillars of our strategy built around what I call the 3Ds, develop, deploy, deliver. And I just want to spend 30 seconds on the slide so that the essence of this message is loud and clear to everybody, and if you have questions, we'll do a Q&A about it afterwards. So it's about developing the cloud-native applications, developing applications which run on the cloud in an easy, seamless manner. Like oftentimes, when we think of user experience and usability of a product, we tend to think consumer. We tend to think the actual user experience. But when you're building a product that's catering to developers, the user experience for developers is the developer experience. And if there is a barrier to entry for developers to start building to your platform, you're not going to attract the mind share. You're not going to attract the ecosystem, which is key to the success of any platform. So develop is a key pillar. The second one is deploy. Deployment of cloud applications. A lot of you work in enterprises. A lot of you work with enterprises. Deploying an application to the cloud in the enterprise, depending on which stage of the cloud journey the enterprise is in, can be a very tiring process, can be a process that may take several days, several weeks. And some places, my own first-hand experience, a few months for a small change to propagate all the way to the cloud. So how do we ease the deployment of applications? It's the core pillar of what we are trying to do as well. And then finally, deliver. By deliver, what we mean is we are HP. HP, that's a lot of business with enterprises. I'm not standing on a limb when I say that HP understands enterprises really, really, really well. And that's been my learnings since I joined HP. So when you're building a platform for enterprises, you need to give people a tool to deliver enterprise-grade applications. So unless your platform is enterprise-grade and supports innately the development of enterprise applications, you're requiring the enterprise or the app developer to do extra work to take an application that's been developed and make it enterprise-ready. So one of the core principles was to have an innate experience which made any application being built to the Helion developing platform be enterprise-ready from day one. It took more than 30 seconds on this one, but it's very important. So that's why I spend so much time. And cool animation, right? So I spend a lot of my time on the road talking to customers, all of you do. So everything that I'm going to talk about here should be motherhood and apple pie for all of you. You'll be like, yeah, this is exactly what we hear. Or no, maybe you're missing a few things here. So bear with me on this. If I'm missing something here, call it out when we actually do the Q&A afterwards. But the key challenges that I hear whenever I talk to enterprises, when I talk to people who run huge IT organizations, when I talk to CIOs and C-level executives in the Fortune 500 companies, HP has a presence in almost every Fortune 500 company, I think all of them, that exist today. The key things that I hear are the following. One, enterprises have one of everything. There's not a single enterprise out there which is all and on one particular vendor. Be it a hardware vendor or be it a software vendor. They have, I don't want to use the word hybrid because hybrid is such a broad term, but it's like a hybrid infrastructure. They have different hardware, different vendors, different software, different types of databases, different application development models, different frameworks. And it's kind of like a cluster. But it is also a representation of how the enterprise IT organizations have grown over the last couple of decades. So they're looking for a solution which can span the existing infrastructure. No one is going to say, OK, I'm going to burn my infrastructure down and start fresh. The Phoenix story doesn't exist in the enterprise. So any new solution that comes to be has to fit in with the existing enterprise infrastructure. The second thing is vendor lock-in. I have kind of talked about my history. I've been on both sides of vendor lock-in. I've enjoyed being in a company that loved the solution of choice and the only solution of choice. And I'm here at HP building open platforms and open source. So having been on both sides of the table, let me tell you, enterprises do not like being locked in. They want a solution which offers them flexibility, which offers them sort of like a composable stack so that they can pick and choose things that they need. And they can leave things that they don't need behind. Very important, very important. And low total cost of ownership. IT organizations, as we know today, have a huge capital spend. They are the backbone of the organization. But at the same time, they're also a cost center. So there's a lot of justification for any kind of IT capital spending. But at the same time, they're expected to drive the organization forward. So the goals are kind of in conflict of each other, but that's the job of the CIO. So when you meet a CIO, you have to keep in mind that the guy is probably doing the toughest job that exists in an enterprise today because you have two conflicting goals which are key to your success, key to the success of the organization. So they want solutions which have low total cost of ownership. So this is where apps come into play. Because apps is the atomic entity for interaction, for transaction within the enterprise. Apps are cheap to build, easy to deploy. Apps have the maximum touch point with the organization. So think of Payroll, or HR, or any of the business critical or mission critical supply chain apps, for example, being HB. We understand supply chain really well. Apps is where the transactions happen. Apps are where the IT organization touches the human beings in the enterprise. And that is where a lot of innovation happens. So everybody, at the end of the day, you can build the best infrastructure in the world. But at the end of the day, the IT organization is rated on the quality of the apps, the quality of service behind the apps that are run on that infrastructure. And the problem with apps is apps are transforming. Like when you think of the model from the late 90s, early 2000s, we had the three tiered model of app development, then we moved to the virtualized model of app development, now we are talking cloud native. So there are different models of app development which are a reflection of the technology, which was in prime at that point in time. But today's world, like all the three models coexist. And again, as I said earlier, there's no magic switch, there's no on and off switch which can make the IT organization move from the world of yesterday to the world of today. So any solution that we define, any solution that we create has to support a healthy ecosystem where the three different models of app development can coexist. And that is where developers come to play. Because when you're talking about apps, you need developers and you need enterprise developers to build those applications. But even developers have changing needs. I started, when I used to be a developer, everyone followed the waterfall model. And when I left Microsoft, they still followed the waterfall model. And we did. But that was a reflection of boxed software. Because most of the software companies were building software that was bundled in a box. And you went to a physical store, and you paid money, swiped your credit card, and you got the boxed software, and you took it home or took it to work. But that model has totally changed. The software delivery model has changed. So as a result, the waterfall model is changing. Like everyone's moving to the agile model. Things that web-scale companies do today is what every enterprise aspires to do going forward. So I live in San Francisco. So in the valley, for example, Facebook, Google, where I was for a period of time, we used to change applications multiple times a day. Google Analytics, we would add features once a week. These are not big features, but these are small features. But that's what every enterprise wants to move to. That doesn't mean every enterprise will change the application in real time, 20 times a week. But they want to have the flexibility, again, to move to that model, to have that option available to them. So that when you want to change a web page on your HR website, it's not a two-week cycle. It can be done within hours, if not hours, within minutes. So developers are key. But developers have changing needs. First, developers want to do what they have trained themselves to do, what they have a passion to do, which is to write code. Developers don't care about deploying clusters and provisioning a database service or provisioning a messaging service or figuring out how OpenStack works. Because if they do that, they can do that. Like it's not something that they cannot do, but it's taking them away from their value add to the organization. And the more time a developer spends understanding how Cloud works, the less time he or she is spending developing the application that they have been hired to develop. So very important. Second, they want more abstraction. It's a follow-up point to the first one, where it's all about APIs. At the end of the day, about 10, 15 years ago, when the RESTful API system came to be, I used to be at Microsoft when we did SOAP. Don't hold it against me, but it was important back then. But developers like abstraction. They want an API to use to do easy tasks, to do simple tasks. They want their applications to be portable and flexible. So enterprises have hybrid cloud deployments. They have public cloud, private cloud, managed clouds, depending on the scenario, depending on the kind of application they're building. They don't want to be building specific applications for each type of cloud deployment. They want to build it once. And they want to have, again, the flexibility to run the application anywhere that makes sense, depending on the scenario, depending upon the user, depending upon the data that's being transacted. And then finally, they want to use the right tool for the right job. If you ask a developer to build a highly transactional database, likely they would want to use Node. So you cannot tell a developer that, hey, I want you to build this application which has high transaction. And I want you to build it in Python. Certain things, the laws of physics, they don't line up. So you want, again, developers to have the flexibility. You want the platform that you're providing to the developer to be polyglot. You want it to support a variety of languages. And the language choice is dependent on two things. The first thing is the nature of the application that's being built, like what language, what framework suits the application being built. And the second thing is the familiarity of your developer with the language of development. You want to give people the choice of picking the language they feel best suits their needs, best suits their experience. And then this is where IT meets developers. So once these applications are developed, you want these applications to be enterprise ready. And what I mean by enterprise ready is it needs to have things like security, compliance, performance scale, availability, data sovereignty, like redundancy, like this list is endless. It goes on and on and on. So these are features that every application needs. But these are features not every application developer needs to build if the platform supports these features innately. So this ties back to the whole deliver aspect of our team. We had the three teams develop, deploy, deliver. This is where the deliver component comes to play. So we want to offer a platform to our customers, by which the developers can write out of the gate, build applications which are ready for the enterprise without having to think about things like scale and high availability or disaster recovery because you want these things to be innately provided by the platform. And open source platforms is a way of making that happen. Open source has, like you've heard this probably in five other presentations since yesterday. So I'm not going to spend a lot of time. There's a lot. And people here know open source better than anyone else in the industry. But there are pros and cons of open source. The cons of open source are things that we at HP have worked over the last decade, decade and a half, given our experience with Linux, given our experience with OpenStack. And we have used that to address the concerns that enterprises had. And as you can see, when the web came to be, a lot of the web today in the enterprise runs on open source, runs on Linux. And we have been able to move the enterprise forward, address the concerns that they've had with open source by providing support, by providing security, by building an ecosystem, and by maturing the technology, working with the enterprises. If we could do that for the web, we can surely do that with OpenStack. We can surely do that with Cloud Foundry. And that is where the Helion Cloud Platform comes to play. So Helion Cloud Platform is essentially two products. The first product is Helion OpenStack. People in this room are very familiar with that. Not going to spend a lot of time on it. We just released Helion OpenStack two weeks ago. It's built on the Juneau release. Everyone here understands HP's point of view on OpenStack. This is one of our biggest bets that we have made. This is one of the open standards that we are very passionate about. So I'm going to spend a lot more time about the development platform, because that's the product we launched the week after we launched Helion OpenStack. And that is what I'm going to cover in this presentation today. So I want to spend some time talking about the Helion development platform. And so Helion development platform has four components. The first component is what we call the application lifecycle service. The second one is the application services component. The third one is the marketplace. And the fourth one is developer experience. Again, it will all tie back to the three Ds I talked about earlier today. So let's focus quickly on the Cloud Foundry component. So a point to be noted, Helion development platform is not a Cloud Foundry distro. It uses Cloud Foundry in a very interesting and meaningful way. And it brings Cloud Foundry and OpenStack in a very interesting proposition together. So our Cloud Foundry layer is built on Cloud Foundry V2. It is a polyglot platform. It supports a variety of languages, a lot of JVM-based languages, Node, PHP, Endless. We are going to be including .NET support in it in the next few months. So we will have a truly polyglot platform for the enterprises. .NET, because a lot of people have done a service of enterprises. But when you look at enterprises today, a healthy percentage of enterprise developers are also .NET developers. And we cannot leave them behind. There's a reason .NET is prominent in the enterprise today. And any open platform, staying true to the principle of being a platform that offers customers choice, should be truly polyglot. Also included in the application lifecycle service is essentially, as the name implies, the maintenance and the management of the lifecycle of the application. This means developing the application, deploying the application, running an application, pausing an application, killing an application, stopping an application. Everything at the application layer is handled by that component. The next component is actually the most interesting part of the development platform product. It is where OpenStack meets Cloud Foundry. And what I mean by that is the development platform product also includes other meaningful OpenStack services. Sehera has an interesting example. Morano, as the higher level OpenStack services mature, they will basically come to realization in that layer. And what we have done on the Helion team is we have created an integration between Cloud Foundry and OpenStack. So Cloud Foundry ships with its own microservices. So Cloud Foundry has its own database service, for example. It's got its APIs. It's got its own service, which runs within the Cloud Foundry instance. But if you had Cloud Foundry running on vanilla OpenStack, then you were not truly leveraging the power of OpenStack at the application layer. So what we have done is we have actually plumbed the Trove APIs, the Trove service, to the Cloud Foundry database API layer through the service broker. So now any application which uses database as a service of the Cloud Foundry layer, by virtue of being written to the Helion development platform, which works on Helion OpenStack, automatically gets Trove as the database back-end. Our version of Trove, the one that we shipped 10 days ago, ships with MySQL in-box. And since Trove is a control plane-based service, any variety of database distros can easily plug into Trove through connectors. And you guys know this better than we do. So we have extensibility in the platform through Trove. We also did a lot of work on Trove to make it highly available. And we also built a disaster recovery into Trove. So as of today, our version of the development platform is the only shipping version of Trove with HA and DR built into it. We contributed the work we did back to the community. The Ptl of Trove works on Helion, works on the Helion development platform product. Staying true to our commitment to OpenStack, to the community, the work that we did with Trove is now, it's available upstream in Juneau. We plan to do similar things with messaging and other high-level services. Application services is also the layer where we see HP software services. So HP has a huge asset, a huge portfolio of software services like Vertica and Autonomy and 45. We see all of them come to realization in this layer as well. So as a developer, you have a choice between using things inbox or getting your own services or using HP software services. And that is what we want this platform to be. We see this platform as a composable platform which brings together services which are of interest to developers, which cater to developers because the target customer for this platform is the developer. The third component is the marketplace component. It's very important. So I run product management at Windows a long time ago. My learning, running a product team that worked on a platform which was the most used platform at that point in time, is that if you don't have an ecosystem, you don't have a platform. Imagine if you don't have, there have been several examples in the phone world where phones have come and they didn't have an ecosystem and that's why they went away. So the same thing applies to the cloud side of business also. If you don't have an ecosystem, if you don't have ISV partners, if you don't have platform extensions being built for you, then you don't really have a platform. You have a product that is by you, that is populated by you, and that is not open, and that doesn't offer the choice and flexibility. That is one of the founding principles of this product, by the way. So we have a marketplace built on Verano. Marketplace has two components. There are two types of elements that we see come to realization in the marketplace. The first one is what I call the add-ins and extensions marketplace. So an example would be, we ship Trove with MySQL in box. Say tomorrow an enterprise or a customer wants to use MongoDB with Trove. We don't include MongoDB for a variety of reasons, like at least we don't have it in the V1 of our product. Now through the marketplace, the enterprise can easily get MongoDB as the database of the choice working in conjunction with Trove. So that is the extension marketplace. That's the extensibility of the platform. The second aspect of the marketplace is what I call the finished apps marketplace. So now, say you are running the Helion development platform and Helion OpenStack in your enterprise, and you want a Drupal-based content management system, which one of your ISV partners has helped build and develop, and you want that to be available to your employees. So you want that to be available to your internal organizations, and how do you do that is through the apps marketplace. The last component is the most important component of the product. Because everything else is great. It makes sense if you're a technologist, if you're all about open standards and open source, you can all geek out on this stuff. But at the end of the day, we want developers to be building to our platform. And the way we do that is by focusing on developer experience. The way we do that is by making developer experience a key component of our product. And what we did for the V1, for example, we have an Eclipse plugin, which allows you to build, develop, and one-click deploy applications to a cloud of your choice. It could be a staging environment. It could be a production environment. So a developer can actually, a developer using Eclipse, can stay within the Eclipse IDE. And without leaving the IDE, it can own the whole lifecycle of the application. We have a portal for developers, we call it the Helion Developer Network, by which you can get access to all the documentation, all the APIs, sample apps, sample codes. You can interact with community, with a community building to the platform. We're working on a CI CD experience just to enable the Agile development model that enterprises care about, that web-scale companies have been doing for the last few years. And we are going to show a bit of a demo later today on it. And this is a key component. So the idea is we want to reduce the barrier to entry for developers. We want to make it as easy as possible for developers to build to this platform. We don't want developers to learn new skills or throw everything that they know and learn something totally new to build to a platform. So if you're a .NET developer, using a platform, you can actually build a .NET cloud-native application in a very easy manner. If you're a Java developer, you don't have to go learn the cloud, this magical thing called the cloud. You just have to focus on doing what you do best and just build your application to the platform using mechanisms and best practices that you have cultivated over the last decade or so. So that was the anatomy. We joined just a quick note on Cloud Foundry. I think a lot of you are familiar with this. Cloud Foundry came out of Pivotal, IBM joined Cloud Foundry after Pivotal last year, maybe roughly 18 months ago. We joined Cloud Foundry earlier this year as a Platinum Founding member. And there are seven Platinum Founding members today, as Pivotal, EMC, VMware, IBM, SAP, Rackspace, and us. And we see Cloud Foundry as the open standard of choice for enterprises, for the runtime, for the platform. And I also spoke about the work we have done in coupling Cloud Foundry to OpenStack, because otherwise what's the point? You can have two layers, not agnostic of each other, and not leveraging the capabilities and the scale and the magic of the layers underneath. And Cloud Foundry today has about 50, 60 gold, silver, Platinum members put together the foundation. We've been working on the foundation over the last few months. The foundation will be soon announced. And we're very excited about Cloud Foundry. And we're mostly excited about Cloud Foundry is because we see Cloud Foundry as a similar bet to what we did with OpenStack three plus years ago. We joined OpenStack as a Platinum Founding member. We contributed to the OpenStack community. We helped shape the direction of OpenStack in some places. We have five or six PTLs on OpenStack working on the helium products that I talked about. We want to leverage our experience, our understanding, participating in open communities, in open platforms, and open source efforts. And we want to carry that forward into the Cloud Foundry space as well. So the developing platform product, as I said, is where Cloud Foundry meets OpenStack. This is our core promise for the product. And this is something that we truly believe in. And you'll see a lot from us in the Cloud Foundry space going forward. So what do I mean by the integration between Cloud Foundry and OpenStack? What do I mean about the binding between Cloud Foundry and OpenStack? I already talked about Trove and the database APIs in the Cloud Foundry layer. That's an example. We are going to do something similar in the identity space with Keystone. The management space, you'll see a demo. What we have done is we have actually integrated the management of the Cloud Foundry cluster into the Horizon APIs so that as an IT admin who's responsible for the whole cloud, you don't have two different experiences. You can manage Cloud Foundry and OpenStack from the same portal, from the same experience. It's very consistent. It's one product. And because we see IAS and PAS as one stack, we don't see them as two different products from two different places, agnostic of each other. But there's more. So we also, dockers, containers, these are very interesting topics. Every customer I go talk to brings up docker and containers. And people keep asking me, what's our point of view on docker and containers? So what I, we are very excited about docker as a container technology. We see docker and containers as something which is necessary, but not sufficient. You can't just have a platform that only has containers and doesn't. It's totally agnostic of VMs and the virtualized environment. Because going back to my earlier point, enterprises have a lot of legacy. They have one of everything. And they want something, when they introduce something new into the infrastructure, they want something that fits in with their existing investments. Because no one's going to throw away the investments over the last decade or so and move to something totally new overnight, unless you're an enterprise which is just coming to be. So our V1 of the development platform uses docker containers as the deployment mechanism for the Cloud Foundry applications. So Cloud Foundry V2 innately supports a container technology, which is not docker. It's sort of the Pivotal's homegrown LXE-like container technology. In Cloud Foundry V3, codenamed Diego, which is going to happen sometime next year, Cloud Foundry is formally embracing docker as the container technology. A product which we shipped like 10 days ago includes docker today. So that's one of the things that in some ways are embracing docker as a container technology of choice for Cloud Foundry applications. We launched the product on the 23rd of October in San Francisco, and we also had an announcement then, which was we formally joined Kubernetes as a member. So we are working with Google and the Kubernetes community around container management. And we see Kubernetes and container management as an interesting emerging technology. And we're going to participate in it. And our first contribution to the community was a set up utility that would allow anyone to set up Kubernetes on top of Helion OpenStack. And that utility, if you want to try it out, is available on GitHub. Like, come find me after the stock, and I can point you to it. We're excited about both docker and Kubernetes. As emerging technologies, and we see them, again, being a composable platform, we see them as interesting elements of the platform going forward. So that said, I think I'm going to move to the demo now. Aaron, you're all set? Can everybody hear me? Yeah? OK. If I start mumbling, can you let me know? And monitor, for sure. Oh, yeah, yeah, I will let you know. OK. So when we talk about develop and deploy and deliver, it kind of makes sense to actually walk through it backwards. And what I mean by that is what I want to do is walk you through some of the services that we use to deliver enterprise-grade applications, talk about how they tie into the application lifecycle service, and show how we deploy in, or how we deliver and deploy applications within that service. So just a quick interjection here. So this is our live product that we just launched 10 days ago. Hopefully, the demo gods will be on our site today. They've been pretty good so far. So don't want to jinx it. But this is actually, like, the Helio Developing Platform running on our public cloud. And this is, like, live bits. There's nothing speech about it. So if it works, I appreciate it. I appreciate the demo gods. And if it doesn't, just bear with us, because it is live. And Wi-Fi has been interesting all day today. So if we have long pauses, one of this promise to do is best mind impressions. Yeah, sorry about that. I'm good at that. That's my value right. So our database service, again, is an implementation of Probe. And what we offer in the database service is the ability to create an instance, to create a master slave pair, to back an instance up, start stop instances, all the things that, as a developer, you really don't want to think about, you probably end up more time doing that stuff than you really want to. We want to provide this level of service and allow you to easily create databases within there that you could then just sort of manage as needed. So what I'm specifically talking about is within this, I'm showing you the database panel within the Horizon UI. And if I wanted to create a database, I could do it in a bunch of different ways. There's the standard create options of what size, what volume size. Right now, we support MySQL 5.5. There's also the ability to restore it from a backup that you may have scheduled with this service, as well as create a slave pair. And if you were to create a slave from a master, if you were to replicate from an instance, you would land that in a different availability zone. So out of the box, we're giving you high availability of a backing service. When we talk about the messaging service that's in beta, Cloud Foundry actually offers RabbitMQ connection, but it's a single node. It's kind of a toy connection, and it's unmanaged. What we're trying to do here is provide the essentials of a managed service. Unlike Cloud Foundry, what we actually have here is the ability to launch nodes of RabbitMQ clusters. And so the multiple, as we launch a three or a five node cluster, those are deployed across availability zones. So again, you get better availability and a higher level of management. You can also actually, one key thing about this is that Rabbit is actually integrated with Keystone. So since I created some of these clusters, my authentication into those clusters is actually built in, and I can add other people that are in Keystone as well. And just for context, Aronis Chandling is the inner IT admin right now when he's interacting with the CUI. I am. So I'm going to maybe flip a switch soon. But I wanted to actually talk about application lifecycle service. That's our implementation of Cloud Foundry. And what we've enabled within the application lifecycle service is the ability to easily instantiate Cloud Foundry clusters, easily integrate our managed services that I just walked through up into those clusters, and easily manage applications from within those clusters. I'm going to walk through all of that. So if I was to go through and create a cluster, I can actually use some of the services that I just walked through, the database service specifically at creation time. I can choose to actually create a new managed database instance, or I could actually use an existing one. So you'll see that these are the database instances that I've actually created that are highly available. So right at the bad at creation time, I actually get a database service that I can bind to that is managed. And by managing it, it's got high availability, with HA and VR related to it. That's right. That's right. If we go into one of these clusters, what we have here is a UI experience. And so the UI experience is really built around making these applications really easy to manage. What I mean by that is if we click into one of these, the first thing I can do is I can actually enable auto-scaling. So I can set a policy about when I want the instances of my application to scale in or out. And I don't have to worry about that as a developer. I don't have to pre-configure it or do some kind of scripting. It's built right into the platform itself. It can be conditional. It can be conditional, yeah. So right now what I'm doing is I'm setting the thresholds at which I would scale up and down. So I would scale down at the lower threshold, and I'd scale up at the higher threshold. And I've also set the instances that I would scale out to. I can also see the log stream of this application in real time. This is really useful if I make a mistake and things don't go well at deployment or if I just have a bug. I can also easily synchronize and collect this in a central logging service. So those are the management things that normally I'd have to stitch together and that I get for free as part of the platform. The other thing that this platform really gives me is the ability to deploy right now from my laptop up into the cloud. And that I think is really cool. That is usually the developer. All right, I've switched. I'm now the developer. And so what I've got here is a very simple application that I've written. It's very simple. Actually, it's just a bunch of files. It's a node application. It's a chat application. And if I wanted to actually push this version out, I would use our Healing Command Line tool. And this tool actually asks me a bunch of questions to guide me through the process eventually when it wakes up. So I'm going to choose to deploy from the 15 net. And what that does, what I'm doing now, what it does for me is actually basically build a domain for me. I've got a couple more default questions. I'm not buying any services. And now the deployment starts. So it's actually packaging the application up and uploading it up to the cloud. And then you can see here it's actually stopping the application out there and starting it. I can go to the app panel. And let me get up to this application, which is a different one. And you can see it deploying here. So what you're seeing is there's a bunch of deployment, I guess, housekeeping going on. I'm pulling in dependencies at real time from external. Now I'm actually instantiating the service, loading it up, making sure it runs all the way to close to success. So I want to check that. And it looks like it just finished. So if I go over here, I've got a very simple node chat application. I can be like the only person chatting in. You like to go to that part of it? Yeah, I talk a lot to myself. And the thing I noticed when I put this together this morning was that I figured that Mono wouldn't like the background because it's very particular. So I did this on purpose, to try to stay calm with it. So what I'm going to do now, actually, is make a fix, a very simple fix. I'm just going to change the backgrounds here to just sheer black. There's another one. I'm going to save it. But because I know Mono's really particular, and because I want to actually comply with our dev team's best practices, I actually want to push this up to GitHub, because I want this change to stick around. So the nice thing about the command line, the healing command line, is that I can actually tie it into CI processes. So one of the devs on our team, Fani, is built. Right here. Right here. That's right. The things go along. I've been working on who I've been looking at. Has built a CI mechanism. And I've actually added my repo in this Node Chat repo. What I'm going to do now is I'm going to actually check in that style sheet change. I'm going to push it. So what I'm doing right now is I've actually made a change. I've checked it in. And our prototype CI application is going to actually pick that up. If I go and I drill into this, you can see that it's actually starting to build. So this application that you see is actually running on the GDN development platform opposite of a public cloud. So we are using a CI-CD application to control and manage the CI-CD process for other applications where it's on the same platform. It kind of awaits the very meta. But we were like, hey, we have to build a CI-CD experience. We just have to use our own platform. We have to use our own dot food. And this is what we have up and running today. Right. So far, the demo guys have been smiling. Oh, there we are. Oh, and then there's that. Sorry about that. You can see here that we're going through the same kind of building and staging stuff that you saw on the command line. And when we actually go to the, we can see that we're deploying as well. So I'm going to refresh this screen as well. And what I've basically done is by checking in my code, I've kicked off a build chain that deploys all the way back out to the cloud. And so occasionally we get a bit of a refresh, but see if this works. There it is. So it looks like it actually got all the way through. Let's check. Yes. And the color is fixed. And just because mono is particular, I just wanted to make sure that the color was fixed in the second panel. Oops. Sorry, mono. I blew it. I'll do that offline. But just to show you that we can go through an entire check-in and deploy cycle, that it's really easy to automate how we actually deploy things. And that the platform is actually taking care of a lot of the concerns that I would normally have to either script by hand or work with a large team to get in place. And just to add to our point, the CICD experience that you're talking about today exists in a public cloud environment. Enterprise developers do not have access to that today. And OpenStack, their platform, on-premise cloud being project-cored into an integrated component of our customer base, getting this experience to our enterprise developers is a huge feature. It's a huge win for not only for Cloud Foundry, but also for OpenStack, because the way we see the helium product line come together is essentially magnifying the scale and the greatest of OpenStack at the application there. Thanks, Arun. And so the helium development platform, as I said, is diagnostic of the cloud deployment that the enterprise may have. We see that as a software stack that we work in private cloud, public cloud, managed cloud. It's open source, an open platform built on a great open standard of OpenStack and Cloud Foundry. It's available for download today. We have a community version that you can actually go download and install it. Optimize for helium OpenStack. So in order to download the platform, you'll also need the helium OpenStack layer to enable some of the greatest of code and other services we talk about. And for those in the US, we also have a free layer trial motion available for the developers. So it's a 30-day trial in log into a public cloud. You don't need to set up anything. Within five minutes, you can be up and running. And you can take it for a spin. So that's it. I'm out of at hp.com. I'm free to share with you. I'm on Twitter. And it was over there. And if you want to learn more about the product, here's a URL. I'm not going to read it. It's too long. But you guys can find out. Just search for the helium development platform. And you should reach this URL. That's it. I'm going to end with my full slide again. And I'm ready to take questions. Please. The Cloud Convery command line, CF targets and stuff. Yes, you can. It's our own helium command line. It's like helium, TLI. Oh, that would be great. They'll be like, but it supports all the commands that Cloud Convery supports. We're giving them Cloud Convery to be able to run a container. Do we have a build file? Do we have a build file? Or both? Both. Because of the container, it's seamless. As a developer, you don't provision the Docker container. We take care of it for you. So when you push an application out, we create the Docker container. When you fill in the application, we destroy the container. The container management is seamless for the developer. There's a bunch of terrible setbacks, for example. You can fill applications and liners of your choice using the bitback support.