 Okay, I'm Troy Topnik. You may remember me from such products as ActiveState Staccato and Helian Staccato, but I'm here to talk about Suzy Cloud application platform now, and more importantly, Suzy Cloud Foundry. And I want to tie on to some of Dr. Max's comments about making a thousand flowers grow because we're going to show our renewed commitment to making innovation happen upstream in Cloud Foundry. So if you may have heard, Suzy is building a Cloud Foundry distribution, and one of the things that should be pretty obvious from Suzy being a Linux vendor, that we can't really build that on someone else's OS. So we are in fact going to build it on Suzy Linux. And we have a factory first model in our development of Suzy Linux. That means we have an open source distribution called OpenSusa. OpenSusa Tumbleweed feeds into both Suzy Linux Enterprise and OpenSusa Leap. And so our upstream work is going to happen and is happening. We've got a pair working on this now, getting stem cells and stacks committed upstream so that anyone can use this. So our upstream work you will see arriving will be built on OpenSusa, and our productized work will be shipping on Suzy Linux Enterprise. Same code. There's a certain process by which we can support the Suzy Linux Enterprise much more deeply. So let's talk about where that actually goes. In a Cloud Foundry implementation, you run all the Cloud Foundry roles on stem cells, on Bosch stem cells. And for as long as I can remember, well forever, Cloud Foundry has always run on Ubuntu. Initially on Lucid and then on trusty, starting around 2014. But now, you can, starting very, very soon, you'll be able to use OpenSusa 42.3 Bosch stem cells to run Cloud Foundry. So that's the base layer. That is the layer that runs the Cloud Foundry roles. But there's also another place where the operating system is important. And we make a change there, too. Or we don't make a change. We make an addition. The concept of stacks in Cloud Foundry is extremely powerful. It comes from a notion that was also around in Heroku. And it's kind of a shame that we haven't seen this used more. We saw it used a little bit in Windows native DEAs. But this is a place where OpenSusa shows up as well. So very conveniently, the build pack design makes it easy for us to use the same build pack to work on multiple stacks. This is something that is different from how it was in the Windows DEA and the Windows stack. But we've found a way to, and it was a way that was baked into Cloud Foundry so that a single build pack, if it's packaged with the binaries for both stacks, it can work equally well on both. So you just have to build binaries and you have to build a lot of binaries because there are a lot of build packs and each of those build packs has a number of language versions in it. So we're going to build all those binaries. Sousa can do this because we've got a lot of practice building packages. We build a lot of them. We've got a lot of different versions of Sousa Linux Enterprise and we have to be able to produce certifiable builds from exactly the right sources over very, very, very many versions of different packages and very, very many versions of Sousa Linux. And our open build system actually packages in more than just the RPM formats that we traditionally use. So we can also produce Debian packages. We can also produce Tar Balls. We can produce a lot of things for a lot of different platforms. And this is another thing that's very interesting. We can start using stacks and we can start using our build system to expand the choices in platforms that people have, the choices in architectures that people have. So we're going to be building lots of binaries for our own distribution anyway. I'd like to offer that we would be able to help upstream with taking some of this load, which I know is quite significant off the build pack team, or helping use our expertise in building these packages for building all the binaries that are required for all of the build packs. Another choice in what we have done and a sort of less expected choice for some people is that we've chosen to deploy Cloud Foundry on Kubernetes. We are big fans of Kubernetes. We think it's an excellent scheduler. We've done this before some of us came from a team at HPE and we made a containerized version of Cloud Foundry there. So we've essentially done this twice now. And we're getting pretty good at running Cloud Foundry on Kubernetes. So to that end, we're going to be releasing a product built on a containerized Cloud Foundry distribution called SCF. We're aiming for this to be a certified distribution. And it's going to be built from upstream Bosch releases. So we do use Bosch. We use it to build the distribution. Bosch releases are built on SUSE Linux Enterprise, which run on Kubernetes. CAS platform is our implementation of Kubernetes, but you can run on others. There's no engineering reason why it doesn't. We've demonstrated that at a few different places. And we're using Helm, Kubernetes Helm for the lifecycle management. This is for the deployment of SUSE Cloud Foundry and for the upgrade and maintenance of it as well. And just to sort of conclude, the history of this type of innovation has not been always very smooth. So I started out at ActiveState Staccato and we had a very early fork from the open source project in 2011. And we did a lot of really interesting work there. But because it was not a completely open process and because there was a lot of stuff that was held back, we were finding very difficult to donate that work back upstream to get that stuff, those innovations, which we were all very proud of. It just didn't mesh with the other upstream work that was happening at the time. With HPE Helm Staccato, there was certainly a will to move closer to upstream. We had a certified CF distribution. We open sourced several projects that were associated with that. But again, not everything was available upstream to the upstream contributors in a way that they could actually make those innovations, bring those innovations in that could be shared by everyone. With SUSE, we have a mandate to work in the open all the time. So with SCF, SUSE Cloud Foundry, Stratos UI, the CF Universal Service Broker and FISILE, we would like to get all of this stuff as upstream as we can either through the extensions project or directly upstream. And I can say that SUSE has a surprising commitment to open source because when a number of us joined in March, we had a great concern that we wanted to see a lot of our innovations going upstream. And we approached, I can't remember if it was the president of engineering or the CEO, and we said, if we have a good reason for something to be open sourced, can we make sure it's open sourced? And we were told very plainly, unless you have a very good reason for something not to be open sourced, it's going to be open sourced. So with that, I'd like to reiterate Dr. Max's statement that we should make a thousand flowers go, and please help us innovate on this platform.