 Or why don't you stand by the pool and then I'll stand here and I'll run your slides, and then you run my slides. OK. Good morning. I'm here. We are here to talk about multi-layer open stack clouds as provided by Ceras for KVH. So my name is Caleb Crane. Oh, doesn't have my name. Anyway, my name is Caleb Crane, which you can't see there. I'm a software development at KVH. And my presentation partner is Sigluft. He's the CTO and co-founder of Ceras. A little bit of a brief introduction to KVH. We are a managed services and cloud provider and network provider within AsiaPak. We have 22 financial exchanges. We have more than 140 data centers and 2,200 customers. We recently merged with our sister company, Colt. And we now provide connectivity throughout Europe and even the US. And all of these numbers have since increased. So our customers are now over 40,000. Brief history of KVH. We started in 1999. We were founded by Fidelity Investments. We laid our first set of fiber in the ground in 99 in Tokyo. And in 2002, we launched our data center services. With our first data center, we've quickly expanded out to have many more. In 2004, we started managed IT services. And then in 2010, I was part of the team that launched cloud services at KVH. So we provided bare metal servers, firewalls, load balancers, virtual servers, all that kind of stuff. And we provided in using automated tools. And then in 2012, we started to expand both in Asia and in Europe. And we did the Europe expansion by providing services through Colt. So KVH provides the typical cloud services to our customers. We provide them with private hosted clouds. We do that with either VMware or with OpenStack. We give them the standard services they expect, storage, security, all of that kind of stuff. But more and more, we hear our customers saying that they want to be able to also connect their private clouds with public clouds, like Amazon and SoftLayer. They want to have a single unified interface for that access. They want to have connectivity between those clouds. And we think that the best way to do that is to bet on OpenStack. We think that OpenStack is the horse that's winning the race and going to keep on winning. And we think that by providing our customers with the OpenStack API and interface, they can more easily use other third party tools that interact with OpenStack and whatnot. We've turned to our friends at SIRAS to help us provide that. And with that SIG, we'll talk in more detail about the SIRAS solution. Great. Thanks, Caleb. So my name's SIGluft. I'm the CTO of SIRAS. We've been working with KVH for over a year now. And we'll be launching our products together. SIRAS provides a platform we call Cloudscape. It's essentially an overlay cloud that sits on top of a variety of clouds. So conceptually, we have this circle here where we're showing Cloudscape as an OpenStack platform that allows enterprise customers to create and define data centers or virtual data centers using OpenStack, but deploy them on different types of cloud footprints. So in this particular illustration, we have VMware and OpenStack representing the offering, a private offering from KVH. And of course, Amazon soft layer being public offerings. So KVH using our platform is able to reach all of these clouds. But more importantly, or equally importantly, is as you start to deploy data centers in a variety of locations, connectivity starts to become an issue as well. And so we've done a few things with OpenStack to reach into the DCI layer so that a project that maybe is deployed in a VMware site in one location and an Amazon in another location can be connected using a DCI mechanism that is tenant to tenant, not just data center to data center. And we'll give some examples on that in a minute. Want to go to the next slide? This picture here, everybody should recognize it's just standard OpenStack framework here. Probably the main things I just wanted to call out were that when you're looking at OpenStack, OpenStack, of course, is very powerful because you can bring a lot of vendor hardware into the picture. But ultimately, it's about deploying an application and compute storage networking. As well as once you've deployed, you want to be able to monitor and see how your applications are running. So hopefully nothing exciting to anybody here. Pretty standard. If you go to the next slide. The problem started to arise when you started thinking about a distributed footprint. Whether it's all OpenStack, where OpenStack is doing a lot of good things, but even in a more hybrid environment where people actually want to go to some of the public clouds, things start to get a little bit more challenging and even more so if you think about what's in the middle. Currently, OpenStack has very little concept of multiple sites or what's between those multiple sites. And so we look at this problem. We believe very heavily in OpenStack, but we look at this problem and we see that there are challenges in the current status quo. So if we go to the next slide. So what CRS has done is we've built a, essentially, an OpenStack platform that sits on top of a variety of clouds. We treat all clouds as we call them under clouds. And these clouds can include OpenStack. They can include VMWare and a number of the public clouds. And what we do is we actually run a full stateful OpenStack. And where typical OpenStack will develop plugins for hardware, we have what we call undercloud drivers. So you can see up here that under each project, under each component of OpenStack, instead of having a physical driver, we actually have what we call an undercloud driver. So we can map a Nova sender request into whatever the cloud underneath us has. In doing so, we have a common API model that is exposed to the northbound. The user can pick and choose which clouds projects go into. And in the middle, what we show is another extension, which is we refer to it as Neutron WAN. We'd like to propose it into the OpenStack community. And this allows us to manage the connectivity between the two projects or multiple projects. But at the end of the day, a user of a CRS platform or soon the KVH offering will be able to leverage a hybrid cloud whereby they can have their projects distributed in various footprints. But it's all visualized and seen as OpenStack. So if you want to just do one animation. So when we look at this, there's a couple of just quick comments to make. One is what this does to the end user is it allows the end user to separate the concerns of the IT department, the person paying the bill to come in and use KVH's footprint and say, I would like to have access to these private and public clouds. And I'll pay the bill for it if you do the next step. But the consumers of that IT department may be interested in using a number of variety of tools. And because we are OpenStack, none of these tools are precluded from running on top of our system. So if you just do one more. So a DevOps department can come in, can use the tools of choice, can drop it onto this footprint. But it will be scoped to the footprint that the IT department has dictated or decided is appropriate for that enterprise. So we bring an element of governance into the picture and then that becomes something that KVH in turn can offer to their customers. So why don't we go ahead and we're going to show a bit of a demo here. And what we have right now is we've made a few changes here to Horizon. But our platform, again, being OpenStack, we've tied it into Horizon. I'm just going to call out a few things up here. We've introduced the extra tab here we call MetaCloud. And what we have under here is a few tabs, a map view. And this gives us a view of all the physical data centers that are at the disposal of the tenant. We can also see on the right-hand side, we've already pre-created five different projects on five different under-clouds. Some are public, some are private. OpenStack-based, VMware-based, SoftLayer site, and two Amazon sites. And we're going to focus on the VMware and the Amazon sites. So right now, we're going to pull up the VMware project. So it takes a second. So right now, we have a Solometer View. There's one security group. We're going to go to the topology, and we see a very empty topology here. Now, by pulling up, we have a little demo tab, which kicks off a single heat script. And what we're going to see now is that heat script is going to bring up a set of sugar CRM instances. We're going to bring up three of them. And as these come up, what's happening is we're actually spinning these up inside a vCenter environment. But it's all visible through here. So if we go on, we're going to hop over to AWS. So you can see up at the top there, we're changing from the type V, and we're going to change over to an Amazon site in Tokyo. And here in Amazon, you always have the VPC subnetwork always there. And we're going to kick off the same heat script. No change, nothing. It all looks like open stack. And we're going to spin up the same footprint here. And now what you see here is the same three instances coming up inside Amazon. We pull it over to the next piece. We can go over to that Amazon undercloud, and we can actually watch these projects coming up, or these instances coming up. And you can see here, there's three. The four terminated above are from a previous run of the demo. And now we come back to our open stack, and we see the exact same instances up and running here. So now we're going to click into standard instance view inside open stack. Sorry, here's the completed running on Amazon. And we go back. And here is how we see the world inside our open stack. So there's a full, stateful representation inside our open stack that is mapped down to the Amazon undercloud, and likewise for the VMware footprint. And we do things like auditing. So we will check to see that what we believe or know to be correct is, in fact, mapped below. We can do corrective action and so on and so forth. If you want to go on. So we're going to go back to the VMware instance. And I'll take a second. So we see the three different instances now are up and running, and we'll go to the instance view. And once again, we have the same footprint running inside VMware. There's a private and a public address assigned to each of these servers. We can, I think we're pulling back to AWS. What we're going to show you here now is, again, common view, same heat script created it. The addresses are different, of course. And we're going to just enter these addresses here. And what we'll see in a second is, lo and behold, here's the sugar CRM up and running. So this is inside Amazon. So fundamentally, we've created one footprint that is now connecting, sorry, is now deployed in two different clouds. The end users, as far as they're concerned, are talking to OpenStack. They did select which cloud they wanted to go to. And now we have both clouds up and running. And so the next thing we're going to do is we're going to connect those two clouds. We mentioned that there was this WAN project, Neutron WAN. And so we're going to show how we connect these two different projects together. So we have to go to the administrative role. So neither project owns the network. They're both, they're effectively three different projects. And here's the administrator. There's only one security group. There's no resources applied. And what we do here is we create two projects. We are going to go first in and we select the type V, or the VMware footprint, and we're going to connect the private network. So we're going to bridge over a connection, private to private, so 10 100 to a 10 100. And we go over to Tokyo. And again, we do the same. And in a second, what will actually happen is we will drop two VMs on either side in each of these projects. Those VMs will actually represent an edge point and will connect. Ultimately, this will run through KVH's network and will even orchestrate direct connect and their network. In this particular case, we're just doing a tunnel. But now we will see popping up here in just a second. So what we've got here right now is the physical AWS site connected to the physical private data center inside, I'm not going to say the name, between those two data centers. So VMware tenant through a DCI to an AWS tenant. The two sites are now both connected. So we've basically shown all the major components. This is what will be offered now by KVH through their service offering. We just wanted to show two screenshots or actually four screenshots just to give you a little bit of a view. As Caleb mentioned, they have always offered services such as load balancing and firewall and so on. So what we've done is we've extended our platform and we handled firewall. So you can define firewall and it will be deployed. This is a perimeter firewall. It will be deployed in all of the under clouds that we support. So AWS, we have to do some funky stuff for going from VPC to VPC. So it's all done with ACLs. On VMware, we're orchestrating a Viata firewall. And in OpenStack, we have both a vanilla and one based on MiDucura. And soft layers, again, based on Viata. But what effectively happens is, if you go to the next slide, is in Horizon or in the APIs of OpenStack, it's just standard firewall as a service. So what we expose to the outside world is one firewall as a service API. And so you can have in an IT department, you can have a security expert who defines the firewall policy and it can be deployed on any of the under clouds, one definition. And then just real quickly, the network topology slide again here is showing the load balancer. So in this case, we did spin up three instances of a sugar CRM. Of course, the reason you want to have that is because it's behind a load balancer. And again, we support load balancer. If you just go to the next slide, we're able to, again, have a single definition. So here we have a round robin. It's all mapping into private networks. Comes in through a public network of the load balancer and gets sprayed across the various servers. So this is a use case that KVH's customers have been asking for. And so we focused on making sure we had this. But more interesting things that we're developing now is on top of this platform, we can now create independent projects, which would be a distributed load balancer or a global load balancer. And you can have multiple projects sprayed across different data centers. And effectively have a resiliency model or a scale out model all orchestrated through the same building blocks. So that's the end of our presentation. Hopefully it all ties together. And if you have any questions, we'd be happy to answer them. OK. Well, thank you, everybody. And I hope you enjoy your time at OpenStack.