 Welcome everybody. Thanks for coming to our presentation today. Today, we're going to discuss a little bit about using VMware technology as a back end to OpenStack. The agenda for today, the first portion is going to be done by myself. We're going to go through some use cases around why you may want to use VMware in an OpenStack environment. Some of the benefits VMware brings from a technology and operations level. Then we'll go into the OpenStack and VMware integration as it stands today. And then finally, Julian will go into the developer side of the house. So we'd like to split the talk into two parts. One's more management operations technology and the second developer aspect of it. OK, so who are we? My name is Justin Giardina. I currently am the CTO at Island Internet Solutions. I've been an open source Cisco and VMware admin for many years now. I have to admit, I'm a network geek at heart. I got into networking in the 90s. And as software-defined networking and technologies like VxLan are starting to take off today, that's what interests me the most. I'm also a Cisco champion, VxBird. And I'm a member of a lot of technical advisory boards with VMware and Cisco. And my current role at Island is I'm in charge of our global cloud footprint and the operations. Walking, test. Good afternoon, everyone. My name is Julian. And I'm working at Island with Justin, but more on the development level. So I've been doing Python and Java for over 15 years now. I actually started with the Python project, which is the Zop application server back in the days, for those who remember. And I'm basically building a platform, an API, and customer-facing portal for Island Cloud. And I'll get a little bit to it in the second part of the presentation. So I'll let Justin start. OK, so a little bit about Island. We're an internet service provider. Now a cloud service provider. We've been in business for 18 years. We have seven data centers across the globe. And we've been doing virtualization and cloud solutions for about seven years now. A couple of awards that we won that we're pretty proud of. We won awards with Forrester and virtualization review around DR as a service and infrastructure as a service. And of course, we won some VMware awards around the service provider industry. OK, so the first part of the presentation, I would like to clear the air and say, we are not employed by VMware. We do not have any religious beliefs around VMware, Hyper-V, KVM, or Citrix. We are not here to argue about VMware. We're just basically here to talk about our experience over the last six years with VMware as an underlying platform and the benefits we've gained from it and where we think we can go with it with OpenStack. OK, so some of the use cases that we see with VMware. So of course, why is it interesting for somebody like Island? As I mentioned, we are a cloud provider. We offer, I don't want to say a niche, but we offer a pretty unique play in the cloud industry. We work with a lot of customers around strict MSAs, SLAs. We have to develop custom solutions for customers. We also have to deal with a very large environment. We have a global cloud footprint. We have to some kind of way make those data centers work with each other and offer global redundancy across those. And also, internal operations, staffing, and efficiency. As I said before, we've been dealing with VMware for about six years now. And to pull the plug on the VMware architecture that we have and move to another hypervisor would be pretty disastrous for us. Or it would take a long time to recover from. The second use case I think would play a lot. It plays to Island, but it would also play a lot to some of the enterprise guys in the room. It's leveraging your investment in your existing infrastructure. So if you run a VMware shop today, chances are that with the VMware integration that's out today and that's coming, you can leverage what you already have and know. And we think that's huge. And again, using existing architectures and knowledge. Although the open stack components may not plug directly into what you're running today, chances are that with a few custom tweaks, you can run an open stack environment on top of what you have. And then finally, let developers be developers. I don't want to make a developer in the room aggravated with me, but usually we don't want developers designing the architecture and the network and compute side of the house. We really want to rely on and give them a platform that they can develop against, whether that's an API or an SDK. And we let our ops team manage the operational and infrastructure side. We let our developers do the developer side. So some of the benefits about using VStream Enterprise, real quick, by a show of hands, who in the room is actually using VMware today? A lot. OK. Is anybody a developer in the house that's working with open stack that is trying to tie that into VMware? Not too many. Interesting. So unfortunately, this may be old news to some of the people that are used to VMware in the house today, but the four main things that we really enjoy working with VMware on is VMware's history, SLA, and support. VMware has a huge footprint in the data center industry. The VMware's in all the top Fortune 100 companies. And they've been around for a long time. Also, what makes sense to us is the VMware dedication to support for different verticals. So a lot of our customers are in the health care industry. Some guys might do credit card transactions online. And VMware has the certifications needed to design the backend infrastructure to support that. So if you're developing an open stack cloud, say maybe for a health care client, you can be rest assured that the backend infrastructure is capable of supporting that. Operations, this is where I think the numbers are pretty astounding. And this is based on the natural progression at VMware. And an environment like ours scale is huge. So in today's VMware environment, and we're gonna start talking about something called Virtual Center, but Virtual Center can support up to 512 compute nodes and 4,000 VMs per cluster. So you're talking about tens of thousands of certified architecture scale, and also the VM sizes in a VMware environment. Although we don't recommend these, but the numbers today are astounding. For instance, you can put almost a terabyte of memory on one VM. Diagnostics, that's a big one. So some of the talks I've been going to this week were around collecting diagnostics around open stack deployments, maybe collecting log entries and working with it with Julian, it's a lot. It's a lot to take into consideration. What's nice about the VMware platform is that they consolidate your diagnostics into one area. So vCenter does a lot of this on its own, as well as there's third-party products or third-party offerings by VMware like vCenter operations that can actually dig down deep in the infrastructure and give you visibility kind of out of the box. Performance, it's no argument that VMware's leader in the performance around the ESXi hypervisor. Also what's really unique is that all performance metrics for your VMware environment live in one place. So again, we're talking about something called virtual center. So things like disk latency, disk read IO, memory utilization, CPU utilization, that's all gathered in one central place. And there's an API to extract all that information if you're building your own portal like we are. And then finally, troubleshooting. Again, our operations team at Island, if a customer calls and says, hey, you know, my VM's running slow. I mean, there's a whole gamut of things that could be wrong. And what we like about vCenter and what we're gonna talk about vCenter operations is that it gives you a holistic view into all pieces of the infrastructure. So not only can you see VM metrics that could potentially be a problem, but you can also see underlying issues. For instance, the vCenter operations, we can plug into hardware vendors like HP, Dell, Cisco, whatever. So you can predict hardware failures or performance issues and actually see what's going on before your customer does. Next, some of the technology that we find most important as a service provider around vCenter and vSphere in general. Sorry about all the acronyms, but DRS is a great one. It's called distributed resource scheduler. That basically intelligently starts VMs on hosts that have the capacity and it can also migrate VMs in real time from hosts around your clusters. So if one host is getting to say 80, 90% CPU usage, these systems can migrate VMs across hosts with no downtime on the fly. HA is another big one. We've all ran into situations where hardware fails in VM where they call it a purple screen of death, but basically it's equivalent to a kernel panic. Whatever the reason is if your host ever fails, HA can actually put VMs on existing hosts. Yes, it requires a reboot, but it's minimal downtime. SDRS is another one. It's more along the storage side. So what storage DRS can do is if you have data stores or sand volumes that are starting to fill up on space and more VMs are trying to get onboarded via your portal, the system can intelligently move these VMs again with no downtime to other data stores that do have space. And it can also take into effect things like IO metrics and latency. So if one data store's got 10 milliseconds of latency and one has two milliseconds, the system can dynamically move stuff around for you. Working with my friends over at Rackspace, I know that some of the systems early on, it took a lot of algorithms and coding to get that kind of functionality to work. And it's not always reliable. You can rest assured that with the vCenter, this stuff's been around for years and it's been working great. And then finally, ops and login site. Ops stands for vCenter operations and login site. Basically what that is is the full suite of metrics around VMs and your hardware environment. So I think the number today is like four million, I don't know, but it's in the millions of metrics that this system connects. Again, all these metrics are presented via vCenter. So you can dig down in depth and see what's going on with your infrastructure at all times and we think that's a huge win. And then finally, VMware's contributions to the SDN stack, as you guys know or don't know, VMware acquired NYSERA. They also have their own technology called the vSwitch and the vCNS. And basically these are full layer two through layer seven virtual or software defined networks. At Island, we've been an SDN user for a number of years now, first starting with vCNS and we migrated over to something called vXLand, but we have very large scale deployments of these technologies and they work great day to day. So for the guys here, guys and girls here that are not familiar with VMware or vCenter, I'll just go over this slide very quickly. In the green box, you see a vCenter server. It is a central management point for all of your virtual machines and ESX servers. And what Julian will speak on and what I think is great for a developer is that all metrics are pulled, I'd say a high number of metrics are pulled from the vCenter API. And Julian will go through that in a second. As far as Island goes, I'm trying not to talk too much about our company, but I just wanted to talk about how we scale. We scale horizontal, we don't create huge compute clusters, but remember that this is all managed by vCenter. So as we scale horizontally with something called vXLand, we can create pods as needed as the capacity grows on these pods and then say a customer needs VMs tied to his same network that originated in pod one. Two years from now, we're in pod N. We can bring up these VMs and have them talk to each other as we scale. This is a technology that's been around at VMware for a couple of years now. Finally, how we look at things, and I think this will really play into Julian's development discussion, but when we design an Island pod, we consider all of our services that are around that pod, clients of the pod. So what I mean by that is we, over the years, we have developed a repeatable and very reliable pod infrastructure. We happen to use Cisco UCS. Of course, we're using VMware, but basically our pods, we almost consider them commodities. Everything is automated, the configurations are automated, we can plan them down in another geography very easily. The trick is to get the services that need resources from those pods to access them. So if you take a look at the slide, our DR is a service, maybe our VMware vCloud, our OpenStack or Portal, we treat those as clients all accessing the APIs we're about to talk about. So shifting gears a little bit, what is the current state of OpenStack integration with vSphere? I realize that there's one component on here that is not in here, which is Solometer and we can talk about that. But today, if you look at the top row, you have Horizon, CLI, Tools and API. Those are the traditional services that could or couldn't be public facing, that your admins, users, tenants, whatever you'd like to call them, would use to access your system. And then as far as the OpenStack components go, today Nova speaks directly with vCenter and ESXi, Neutron with NSX, and then Cinder and Glance, again with vCenter. And remember, I think you're starting to see a common thread here. Although NSX looks different, it is a component that gets installed and managed somewhat in vCenter, and the rest of these components talk directly with vCenter. So when you wanna spin up a VM in Horizon, it's actually gonna make an API call a vCenter, do the work and bring the VM online. Also, what you notice too is some of the cloud operation stuff that I talked about that makes it really nice to say, okay, well, look, I got OpenStack working, I can deploy VMs, but how do I manage this on a day-to-day basis? How can I make sure my customers get the performance that they need? And that's where these other products buy VM where come in. And we use these extensively. One other thing I forgot to mention too, about login site. Login site ties in with the vCenter operation suite, and it can be a receiver for syslog messages. So for instance, in our environment, we have all of our ESXi servers communicating with login site. Not only can we see the logs in one central place, can search on logs, can do things like that, but the vCenter operation suite is intelligent enough to decipher some of these logs. So for instance, if we get a syslog that has an issue about a scuzzy timeout, say on a storage device, we can actually get alerts from that. So to have that all in one place is really powerful. Okay, now this slide, if anybody's in the room that is working at VMware, this is, remember I wrote loosely, I italicized it, and I underlined it, and I see a lot of people taking pictures of it. So here's the disclaimer. The left-hand side is for the VMware guys. The right-hand side is for the OpenStack guys. And what I'm attempting to do is, although they're not direct hooks into these components from VMware and OpenStack, well, not all of them, I just wanted to get a VMware guys thinking to the terminology. Julian's gonna touch on this, but the first time you see VMware, it's V everything. It's confusing. At the same time, if you're a VMware guy and you see a word like Nova or Neutron, it really doesn't mean anything until you start reading about it. So what I wanted to do in this slide is if you're familiar with the VMware environment, you'll see that, okay, well, hey, I know it would VMware, SSO and inventory services. Keystone is the acceptable equivalent in OpenStack. vCenter, server, ESXi, okay, well, there is a Nova hook in that and we saw that in the other thing. So I think this is a good thing to get started if you never have seen either environment. Okay, and with that, I'll pass it over to Julian and he can give you his take on what it was like developing against VMware. Thank you, Justin. So hi, so obviously the software defined everything, API programmability is a pretty hot topic in the industry right now. So we wanted to take a look and see the technology in a developer point of view. So the big question is, okay, obviously Justin highlighted a lot of pretty strong features of VMware and the advantages you can have deploying it for the enterprise, but is it actually offering the same advantages for every developers? So first, like any developers, like programmers in the room, okay, couple, how many of you guys actually programmed the VMware API, the VMware stack? Cool, and what about the open, programming OpenStack? All right, okay, so let's take a look at it. So what is it like to actually program the VMware stack? So I started actually programming the VMware stack recently, beginning of 2013, and I come from basically the open source land. So I've been programming like open source framework, my whole career, and I was actually the first time I was touching and programming like a proprietary stack such as VMware. So that's a couple of things that are pretty interesting that I can still remember is the first impression when you're starting to dig into it and start to program it. So the first thing is that I remember the Justin slides, the last one, the acronyms. You basically see VEX, VY, VSTUFF, et cetera. You never really know what's doing what, and this is like one of the big problem because one, you have to find what exactly those products does, what's behind the acronym, and then look for documentation, for the SDK or any other kind of information. Then the other thing is that we are back in another religious debate, which is Java, Java versus, you know, something else. Python, PHP, whatever, people actually preach these days. And why it's because if you're programming VMware, you can do it obviously using Python. This is how it's used for open stack, but Java is the first class citizen in VMware. This is where you'll have awesome documentation and SDKs, et cetera. Then another thing, which is really, really visible when you actually touch it, is the non-homogeneous, the API are not homogeneous across product. Why? Well, it's because they've been acquiring different products, those products being like, tied together, and all APIs have been kind of like, been like put, but they're like different. So for instance, if you start like programming vCloud director and vSphere, you have to look at some point on how for one VM that is in vCloud director and another one in vSphere, how you can actually link them together and uniquely identify it. That's one of the most common thing that you will do at the beginning. Then of course, there's a lot of XML subtype of endpoints. So very chatty, very different from what we have nowadays with let's say newest technologies such as OpenStack, which are like REST API usually. And the drama is that there are very few developers actually interested in the developer part on open on VMware. So it's kind of like, it's really a problem because if you talk to developers right now, what do they want to do? They want to do AWS, right? We all know that. And we're hoping that they will want to do a lot of OpenStack as well. But definitely not VMware, very complicated to find. So as a result, what you have is a very specialized enterprise type of community of developers, which is nothing like what OpenStack could actually offer in that regard. And you've been at the conference for one week. I mean, you all know that developers have an awesome tooling on OpenStack. For instance, DevStack. If you're a developer, you want to do OpenStack very easy. You get DevStack, you run one command or two commands or you use an actual appliance and you can get going, hack in Python and test it out. In VMware, it's different. You have to actually, you need someone like Justin who actually knows what to set up, how to configure, tie them together, put it somewhere, put the API. It tells you where's the API endpoint. It's pretty heavy and it really requires someone with deep knowledge at the lowest level, which is like a kind of problem. Now, having said all that, it looks like pretty bad, but actually the result, if you're playing the game, if you dig into it and you're building a product, well, it's actually working great. So that's our reason why it's working great, is because the VMware stack is actually really full-featured, stable, it's robust, and you actually have awesome documentation, lots of API, and everything is actually out there. As well, the API compatibility is really great. I'm not even sure they've been ever deprecating something. And they have like pretty long recycles. We're talking for major products around one year, and it gives you some time to actually anticipate change on your custom applications. Then they have something called a beta program that allows you to actually test and get feedback, test and give feedback or report bugs on their products that will be released. So it's pretty interesting as well. So that's an example of our cloud management portal, which is built 100% against the VCloud director, vSphere, vSphere manager, leveraging the API from a Java platform. So what we do here is basically, we leverage a lot of the vSphere performance counters, so all vSphere APIs. We tie that to compute usage, then cost, it's connected to Salesforce. So we have alerts based on the actual usage, and we have, we start in introducing some cloud management features, such as starting a VM, resizing a VM, et cetera, setting networks, disk, resizing disk, et cetera. But this is just the infinity of it at the moment. So we usually provide that portal in addition to vCloud director, so that customer can actually go to vCloud director and perform the cloud management features. So having said that, we have our application working, technology, we're pretty happy at the operation level, so why are we actually looking at OpenStack, right? Well, there's like certain amount of things that we actually like about OpenStack. The first thing is that the API are open and we believe we become one of the standard cloud API in the future. So what it means is that if we talk about developer attraction, you have better chance to actually find people that will be inclined at programming our stack if we're having an OpenStack endpoint in addition to the VMR1. And there's reason for that, it's because while the rest API are really modern, they're consistent across all components, they're well documented, and it's very attractive. Now, another thing is, you know, remember, I told you we needed someone like Justin to set up the developer boxes, the sandbox, like everything, like, well, with OpenStack, developer, they don't have to worry what's running, what's the same technology, how's the network configured, is it running on an appliance, like, et cetera. This is like pretty big deal because developer don't have to worry about that, just like take the API and build the application as fast as possible. Then something that we're looking for as well is the interoperability with third-party application. So what does it mean? Let me give you an example. Let's say you want to do a queue and testing using continuous integration systems, such as Jenkins or bamboo or whatever you want. Well, if you're using AWS, you can actually download the plugin, configure the scope of parameters, click a button, and boom, you can actually deploy at AWS. Rockspace, OpenStack's gonna be the same, but if you do vCloud, you have a problem. You have to do it yourself. Meaning like you can actually do it, but you have to program the plugin, register the plugin, take care of yourself, so this is a problem. And, of course, with OpenStack, no more religious debate around Java. You just use the REST API, and you're good to go, you can choose go, or like Pascal, or basic, like whatever you want. You can just do it. So I'm not gonna say again, but because you've been hearing it a million times this week, I'm sure, the culture and community, but this is something like both Justin and I were coming from that open source world, sharing of knowledge, et cetera, so we're really excited on getting back inside that such community at the moment. So now the documentation, it's an interesting point for OpenStack. On the one hand, you have a lot of documentation. Very easy to find, very well organized. I mean, extremely good job on that side. But at the same time, when you're a developer, while they're really cycle for OpenStack, they're six months, so if you're actually developing a neutron plugin or something like that, you better be opening Python and reading the code. So don't throw stones at me, but this is kind of the reality most of the time. Why? Because the technology is moving so fast at the moment that the only way to make sure that you have an accurate information is actually sometimes to read the code. And coming from the soap world 15 years ago, it kind of reminded me a couple of past experiences. So on our side, we actually started already integrating OpenStack on top of VMware and what are the challenges that we're having? So first, there's these resource pools versus instance-based models. So in VMware, you have resource pools, which is basically a certain amount of RAM, vCPUs, disks, and in OpenStack land, you basically have instances that are pre-configured with a certain size and as a result for the customers, if you're in VMware land, you get billed by the type of VDC you're having, and if you're in an OpenStack model, you will be billed by the hour depending on an instance type. So this is something, this kind of challenging to get like a hybrid version of our cloud management portal. This is one of them. Now, there's another thing in VMware, which is really nice is the Vapp notion. So this is something that you don't have in OpenStack and this is something that we find our customer actually like a lot and use a lot. So we actually haven't really talked about it at the moment, but I just wanted to mention it because this is something that's missing, that would be missing for us if we provide some OpenStack offering. Then another thing that we are missing is a neutral plugin for VCNS. So if you saw other presentation from the VMware crew, they've been presenting NSX, which is really nice, but we have a lot of legacy deployment using VCNS at the moment, and it's important for us to be able to support those guys during the transition. So we are actually working on that. It's been a couple of time, but we're not interested in a fully VCNS compliant neutral plugin. We're just interested in a neutral plugin on our side that handles the case of vSphere, VCNS, and OpenStack deployment. So no KVM, OpenVswitch, and all that. And if you want the big challenges, I'm gonna show you that here. So sorry about the ugly schema. I did that like quickly. Just wanted to show you exactly what's happening. So on the left side, you have our portal, which is basically web application or mobile application, and we have our own API. So our own API, the proprietary, that's our own set of API. That's basically giving you access to the platform, and the platform is responsible to connect to the different API. So right now, we are leveraging vCloud API, the vShell API, and the vSphere API, behind the scene. So the portal is actually directly hitting those, and external developer customer can use our API as well, or they can use the vCloud API as well. We open them the same way. So what we would like to do is to do the same with OpenStack in the middle, having the platform actually using the OpenStack API the same way they use the VMware API. And depending on the type of deployment the customer is on, so either an OpenStack deployment or vCloud, giving access to both our API and the native OpenStack API. And if we go back, the challenge for us is migrating from our proprietary API toward the OpenStack ones. And that's something called extensions in the OpenStack API that are really nice, and that could allow us to minimize our own proprietary API, and give them access to only OpenStack ones. So what does it mean for us at the end? So we told you about all those connection plans on VMware, but there's something that we're not really interested about is the horizon front end. We'll be basically abstracting the access to OpenStack at our portal level. And we want to support and continue to support both vCloud director and OpenStack. And now the big thing that we really want to achieve is giving the ability for our customer to actually use their tool, like the developers, like SoulStack, Ubuntu, Juju, Chef, all the tools that they use with any other clothes that they don't have to write drivers for vCloud director anymore, that they can just use the native OpenStack API and the OpenSource plugin they can actually find. And I think we would be interested about contributing code and a lot of different things to the back to the community. And we've been talking with the VMware crew and we'll be happy to sing with them and see how we can actually help the mother for VCNS and possibly other things. So thank you. I'm gonna let Justin wrap up the presentation. All right, so thanks, Julian. So I guess the end all goal of this presentation was that we are a VMware provider, we are a vCloud provider and we're actually developing our OpenStack platform to work in conjunction. And again, if you remember from my diagram that we want to maintain our pod architecture something that's tried and true, could equate to your architecture as well, something that you know and run today, don't be afraid to start looking at putting OpenStack on top of it and not change the guts, I guess. VMware back in the low level integration, the same, kind of repeat of what I just said. It's all about for us keeping that operational efficiency, SLAs and things like that that we need or that our customers depend on and we feel that VMware will continually do that for us. And then as Julian mentioned too, we feel that the vCloud environment or the vCloud API that VMware provides is gaining momentum and again, we will continue to support it. But we also feel that the OpenStack offering or our OpenStack offering will give more features for developers and bring our expertise into the different verticals that we have or verticals that our customers need and allow their developers to develop against a cloud that may be PCI compliant. One thing that I just noticed is that I think I skipped a slide. So back on our talk about OpenStack integration with VMware, I think it's useful to mention two things. One is, and I don't know if anybody here attended the talks yesterday by the VMware team and the different distros, but be aware that VMware announced four distribution supports for all the VMware integration. And yesterday, Red Hat, Suza, Morantis and Ubuntu all showed what they do to integrate VMware pretty systematically. So what I mean by that is maybe you can bring up a VMware, I'm sorry, an OpenStack setup on the distro of choice and then some of these guys actually had a wizard. So you open up a webpage, you type in your vCenter IP, you type in your NSX IP and you click Go and the stuff works. Another thing that VMware does that I'm not sure if anybody is aware of is VMware has a website called communities.vmware.com and they have an OpenStack section. What the VMware team, what the OpenStack team at VMware does is they create something called Ovova and basically it's an OVA appliance that has OpenStack configured from top to bottom on it. You configure a couple of settings like what DV switch you're gonna use, which vCenter IP username password and things like that and you can get up and running with OpenStack within five minutes. So you do need to have vCenter, you do need to have a couple of things configured but the documentation's very easy to read. And sorry, I forgot to mention that. So finally, thanks for coming to our presentation today. My contact and Julien's contact's up there. It seems like a mantra that every presentation I see the companies talk about that they're hiring. Alas, Island is hiring as well. Looking for VMware and developers that were interested around OpenStack and VMware. Also I put a link, a tiny URL link to this presentation. It's online now if we went too fast or skipped over something that you'd like to see. It's online. And then finally, what I think's very helpful, I see people taking pictures but this is online too. Everything I talked about today from a product perspective in the corresponding developer information about it is in my last two helpful links slide. Again, it's online but I feel that that would be very helpful for everybody because I looked at, like I said, I've been using VMware for a while now, I'm familiar with the terminology but when Julien came on board, he was going crazy with all the V stuff I said and it's actually hard to navigate VMware site to find this. So we created this simple link structure so that you guys could get to it very easy. Thanks a lot. Thank you.