 Hi, everybody. How's it going? It looks like people are still filtering in over here. That's good. Well, thanks for showing up. Wow, this room is packed. Jesus. Wasn't there anything else interesting going on today? Well, I'm going to talk a little bit about network virtualization and really making a case for how network virtualization works in the cloud. I'm the Chief Strategy Officer at a company called Midokora. We happen to be a network virtualization vendor, so I might have some opinions along the way. I'm going to try to keep this fairly non-bender related and just talk about this particular approach. And I might end a little bit early and just go to questions from people. It looks like it's a fairly broad audience over here with some people that are very technical and some people that are very business, so it becomes a little bit tough to put together a presentation that fits everybody, so we'll leave some space for questions afterwards. But thanks for joining. Really appreciate everybody's time today. Really, everyone in this room is going through this whole process of building in cloud. And these are things that you guys understand fairly in detail. There are a few different building blocks in terms of building in cloud. The things that when you're looking at products having to do with building cloud, especially scaling, you look for things that end up having properties of scaling that are linear. And when I say linear scaling, it's the idea of being able to add more like host in order to have more capacity rather than being able to get bigger and bigger devices and scaling up. This is a concept that seems to be fairly standard in cloud, especially because usage patterns in general are elastic. And sometimes you end up having a lot of bandwidth. I mean, sometimes there's a lot of traffic in your cloud. Sometimes you don't. Sometimes you understand how are you going to end up using your particular property. Sometimes you understand what your tenants are trying to do. Sometimes you don't understand what you're trying to do. And because of that, you end up with a situation where it's very hard to end up doing real capacity planning in the cloud. And back to the idea of elements. In terms of elements of the cloud, there are really four big pieces that end up making up what people think are their clouds. You have the open stacks. And this is cloud management fabric. I don't really need to talk to you guys what that means. Maybe in a different audience, it might make sense. You have the hypervisor part, which is really the compute part. These are really, I'd say, the two of the most popular hypervisors in the cloud at the moment. I'd say in this room, this is probably the most applicable. I think there are a couple of others, which I failed to mention, but I don't think that they really make much of a dent in this audience. There's ways to handle compute, like it says, and we talked about scaling a bit before. When you end up scaling out compute, you end up scaling it in a very linear sort of approach by adding new boxes in order to be able to handle that sort of scaling. Storage up till recently has been kind of a very interesting phenomenon where there really weren't very good options in terms of how to scale out storage. You ended up having to use big iron boxes that were EMC boxes or very large sands, and they didn't have a very good scale-out story. Projects like Ceph, projects like OpenStack Swift, Solid Fires out here in the audience, they might be here somewhere. They also have a product that ends up handling scale-out storage and Gluster does. Now there's a whole group of people that are talking about storage and trying to handle that in a scale-out way, and that's a very important thing. We have an ability to scale out compute, we have ability to scale out storage, we have this cloud management system that ends up scaling out with us as well. Really, the problem that we have today is very much a networking problem. When you end up building a network for the cloud, it's very hard, number one, a capacity plan to figure out exactly what your traffic requirements are going to be in the cloud. It also ends up, not just capacity plan, but the idea of traffic engineering and the idea of where your network hotspots are are very difficult as well, because you end up with, if you have a VM on one rack and a VM on another rack all the way on the other side of the data center, and you end up having to go through interim boxes to handle networking and of creating these hotspots in areas that doesn't make a whole lot of sense and it doesn't scale out, and you end up having these interim devices in the way that don't scale out properly. And the idea is to be able to scale out rather than scale up. Getting bigger and bigger devices is not a cost-effective sort of approach for building cloud. If you're a service provider in the audience, you know, you have a business requirement where you need to build a cloud that is competitive in price and that can compete in terms of functionality as well. And when you end up having to rely on physical gear in order to be able to make that happen, you can end up scaling out in a way that ends up having a linear pricing model either. So there's business reasons why you end up wanting to scale out rather than scale up. In terms of networking as well, let's say that there's a NAT device in your cloud and you end up using this device to handle all NAT within your cloud. Well, having to replace this device ends up introducing ideas or possibilities of service interruptions and you end up with all of these different areas within your network that also end up being almost these logical single points of failure within your system. And having to scale these up by replacing these devices dramatically increases your chances of service interruptions. And that's a pretty big problem, honestly. That's something that's not very easy to handle. The other thing is physical devices as a whole, when you end up looking at physical devices like these switches and these routers and other pieces within your network, these load balancers are out there, really aren't designed to be manipulated and configured at that high churn and micro granularity that the cloud environment has. You end up having lots of customers that are doing very micro-type config changes on these boxes and these particular devices aren't built to handle that kind of speed, that churn, that granularity. And really you run into a lot of limitations on the physical layer having to do with the network as you start building this out. This is a fairly apparent one that a lot of people in the cloud have been talking about for a long time but you have the limitations of VLANs. If you're doing a moderately sized cloud, let's say it's something that is a public-facing cloud, it's very easy to get to a tenant count or project count of over 4,096. VLANs have an upper limit limitation of 4,096 VLANs per network. Even if you're doing an internal cloud for let's say a large company or a company as a whole, it's very easy to get to the idea of where you have more than 4,000 projects on that cloud as well. The limitations of VLANs are there. If you end up looking at other networking-type technologies other than VLANs, you end up not only with that physical device configuration issue, but there are other issues that pop their head out that make it very difficult and even cumbersome to be able to scale out your cloud having to do with network isolation. I've mentioned this a little bit, but if you have a load balancer in your cloud that's servicing your users, you end up steering traffic to a device in the middle of your cloud somewhere and that device is pointed at other VMs or hosts in your cloud or maybe outside of your cloud and you're routing traffic one place to spit it out another place so you end up having these single points where you're routing traffic through in order to make that happen. The terminology for that is a traffic trombone that you're creating and this is something that also is not scalable. Anytime you introduce these points in between that traffic has to go through, it doesn't scale at the level of the cloud. When I'm talking about cloud, I'm talking about the ability to get into the thousands of hosts. Your limitation really becomes networking as you start doing this and getting to this point. The physical network as a whole is a big problem and these are the main points that I would say present in terms of physical networking and that's one aspect of it. The other aspect of it is the human cost. When you look at the up-ex expense in terms of managing a cloud and managing a network, we were talking to one provider a few months back that had something like 500 network engineers that were doing minute changes having to do with firewall rule changes, router changes, making decisions on just tiny little network things and that is for a normal organization that's not scalable but I don't even understand how it's scalable for a large telco. When you start making these choices and you start throwing people at the problem I don't think it's an actual, it doesn't make sense. The model in the cloud is how do you end up making everything lower your up-ex costs, lower your cap-ex costs, get everything down to the point where you have as little people involved in it and if you end up having to do any sort of configuration or management you could do it with the smallest amount of people as possible. So the human cost really don't scale that well within networking and networking seems to be really that last frontier. It's like that area that nobody is really messing with or well, not very many people. This company is. But not very many other people are doing things in this space and they seem to be looking at this as a physical problem which it's more than that. You end up needing to be able to handle networking in the physical space of course but we think that there's an actual better approach to this and there's a few companies that are taking a different model to this rather than manipulating physical devices in the network space and connecting them to projects like Quantum where you end up having some of these pieces being automated and the ability to handle L2 constructs and other things of that sort. The idea I think that is a bigger idea and it's an idea that our company as well as some other companies out there have is distribute the intelligence out of the network all the way to the edges. I'll get back to this page in a second but the idea is using encapsulation in order to create a virtual network. You end up using encapsulation and handling the intelligence all the way to the edge so these devices that you have at the edge use machines that you have at the edge which are x86 boxes end up receiving these encapsulated packets and being able to decapsulate them and they end up handling really the network transformations on these packets and the calculations having to do with what that virtual topology is and from the point of view of the user it looks like they end up going through a logical topology. If you look at that top piece over there from the point of view of the user they end up going through routers and switches and getting to the end house and to the VM but from the point of view of the physical network all we're doing is using the physical network as a dumb pipe as a medium to send from one to the other we handle the network intelligence at the edges and we really trick the user into making it look like they have these virtual constructs we don't require physical devices in order to be able to handle this now this is an approach that is a much more scalable approach because you don't end up with these devices in between it ends up being something that's definitely much more scalable we end up treating the physical network like they're really dumb pipes so we're removing all that intelligence which we've traditionally relied on within the middle of the network that physical part of the network and saying hey you know what we don't want the physical part of the network to handle it we're going to handle it as close to the edge as possible and handle it in an x86 gear and handle it in a way that's very scalable so we end up handling not just us but other solutions when I say we so I'm saying this group of people that are solving this problem we end up doing these network transformations making it look like this is happening requiring much less of the physical network since our products have an idea of the network topology they can also do a lot more interesting things like if there is traffic coming from one side of the network and it's destined for a VM let's say traffic's coming in from the internet it's destined for VM1 we have a rule on VM1 saying do not accept that traffic rather than putting that on the physical network at all we drop it right at the edge of the network and you can do more interesting things which we have an idea of the network topology and this concept and this idea of distributing intelligence out to the edges creating an overlay it ends up requiring less of the physical network and you don't run into the physical limitations that a network normally provides I feel bad for that dog you don't end up with these limitations you don't end up with the limitations of having to deal with the network to deal with the high churn of that you don't have to deal with the granularity because all the intelligence is pushed out to the edges and we're not requiring physical devices in between in order to be able to handle the load balancing or the NAT or any of these other sorts of concepts you don't end up with these traffic trombones you don't end up with VLAN limitations that are out there and this solves all of those problems but really the point of the talk was how to scale networking in the cloud and the big problem that distributed, overlay based network virtualization solves is it ends up letting the cloud operator as you guys be able to treat networking much like you treat compute and much like you treat storage right now it grows at a very linear scale so you only have to pay as much as you use you add more host as you need more capacity it scales out very linearly if you don't need that much capacity you can reduce the amount of hosts it's a model that's very similar to what projects like SUF and Gluster and SolidFire are doing with storage and it's a very that model is akin to how the network ends up that network model of scaling I mean that cloud model of scaling works so you almost have to take this approach in order to truly build a scalable cloud without these limitations of course there are people in the room that have built these clouds before who have not used these technologies but one thing that we're finding is providers that make this type of technology is as people are starting to build their second generation clouds they're starting to realize that this type of intelligence at the edge makes a lot of sense and they're looking at products like ours and you know furthering their investigation and their analysis of these products and seeing if this technology fits them and they're starting to realize that a year ago or so nobody had really any knowledge about network virtualization and fast forward today I think I was looking through the sketch panel there was something like eight different talks having to do with network virtualization with different vendors and that's amazing I mean that industry came out of nowhere and everyone is really now starting to say okay you know what this isn't something that just solves a problem of scale it's a more intelligent way of building your cloud as a whole and can end up being more cost effective so and I think this room is evidence that there is interest at least in trying to figure out like what the hell this thing is so it really is a different way of thinking about networking as a whole rather than thinking about these inter room devices you end up thinking about how do you end up turning your whole cloud into one big network device it's a really it's a very difficult distributed systems problem to solve and you know there are a few companies working on this and I'm sure some of these guys in our room I'm with a company called Midokora that solves this problem as you can see by that really big logo on the screen there's another company that recently got bought by another large company yeah that's probably in this room as well that has a product in this space as well and Big Switch who's also another great company is looking to solve this problem and you know I'm sure that there are other vendors that are coming this way you know there's rumors every day of new companies like Cisco and Plumgrid and there's a spin in calling it yummy I don't know if I'm pronouncing that right but you know there's a lot of people in this space that are really looking to solve this problem and I believe this is a problem that is very well suited for infrastructure as a service networking there might be other applications for that but this particular model especially because scale out is so important and the insight into the traffic is a lot less and you really need the flexibility in order to do this very well within cloud networking so that being said these are the reasons why I think that distributed overlay based network virtualization makes a lot of sense in the cloud these are really kind of the big points around it there's a lot of products that solve this problem and like I said if you guys have any questions or want to talk that's great I know that there are other vendors in the room as well so if someone comes up and asks a question and it's not about something that I can answer I'm going to go up and start talking about what you guys have to offer as well thank you thank you there's a mic right there I was thinking it's kind of hard to get away from the challenge of getting the physical topology right if you don't have the physical topology right it turns out that clever ways of rerouting traffic and all that are sort of limited they can't do very much for you but is there some more flexible design of the physical topology and how you arrange your switches and so forth which makes this virtualization easier more productive I hear a lot about the value of network virtualization but very little of it is sort of tied to what must one do at the substrate in order to make this a viable solution I think that's a really good point and I think that one really good thing about being part of a community like this is people love to share and there are people that are building these clouds and trying to figure out the best way to approach these things and one of the good things is they're finding out about this people are publishing their reference to the architecture and talking about what they're doing I expect to see a lot more of this because really there's value in sharing all that information from a product perspective at least the products that I mentioned that do distributed overlays the requirement that I've seen at least in our product and another one of these products that are there is IP connectivity so it's very important to build a robust well thought out IP fabric in order to be able to do that now that doesn't mean that these things still need there needs to be a lot of thought into it and there needs to be you need to have strong engineering talent to make sure that you've designed this thing properly but this is a very well known problem the internet is a very large IP network and I think that the capability and the skill set is out there in order to be able to handle fairly well and the idea mostly of pushing these things out to the edges really for another thing this is not completely in that question but it raises another point because you only ask for IP connectivity between host and that's all you require the physical network well that's the requirement for an engineering team everything above that space in that virtual cloud area virtual network area is something that's run more by your ops and your cloud admin team so as projects like these also come out there's going to be more of a demarcation line between who's responsible for it and how you connect in and how you don't and it took a little while for people to figure that out with the virtualization and the same guys that end up managing the physical servers that are going to be able to manage the virtual servers but over time people figure that out and I think it's going to be a bit of a culture shift because this really blurs the lines quite a bit but back to your point from the point of view of the physical network it's very important to build something that's right and I think that knowledge is definitely out there so I would say that that's an easier problem to solve I think than being able to build a network that scales out that has more that's engineered with the proper traffic patterns and all of this other details that you need to have in order to build a cloud network any other questions so if you overlaid the network so the user have to manage two networks right, the underline network and an overlaid network so and then there are so many problems with the underline network in the physical network then sometimes it's already overlaid or sometimes encapsulated then you are proposing an overlaid of the overlaid network so how do you scale managing two networks in that case this is why I think infrastructure service is a really good fit for this particular thing you automatically already have users managing their own virtual machines with firewall rules and a solution like this allows them to do a little bit more they can end up setting up virtual routers and connecting these routers together and setting up switches and connecting these switches to particular hosts and particular VMs and that sort so it gives the end user a little bit more flexibility the benefit of the integration of these products into projects like OpenStack really allow that cloud user in order to have that flexibility so if you look at that top pane over there that's managed completely by the end user you look at that bottom pane over there and that's managed by the cloud operator now there's probably going to be cloud admins and support staff and other people that are involved in your cloud that want insight into that virtual network and want to be able to manually configure that as well but really we think that the other thing is that if you do your good job and you tie these things together and you present these in a particular way to the end user a lot of this should be very transparent to the cloud operator and they should only have to be really responsible for maintaining that physical network I don't think it actually doubles their work it actually makes the work a little bit easier particularly in the idea that if you were to have the other approach to this let's say you had networking devices that were these physical devices you end up having to build a lot of integration scripts and have a whole a lot of kluji sort of ways of managing that physical network to be able to tie into something like an open stack in order to be able to handle all of that stuff programmatically it's a really big challenge and when you end up abstracting it all away and looking at a solution like this with operations like these it ends up being much less of a challenge from an operations point of view and I think the big key about that is the tight integration with projects like open stack if that integration wasn't there then yeah it would be a pain in the butt also there is you know all of these projects also have APIs on their own so even if there wasn't that particular fabric and you had your own management fabric that you were using in order to be able to do to be able to do VM creation or something like that you can tie all of these things together through these projects individual APIs to be able to do similar things as well so could you talk a little bit more about the tight integration with open stack because it seems like Quantum has the software defined networking as one option but I didn't see how your option would be better than another one with open stack I don't think it's a that's a very good question the question I think if let me repeat it right is you see other people plugging into things like Quantum you're wondering how this is any different than them using something like Quantum well Quantum only provides a certain amount at this moment at least as of Essex it only had up to Layer 2 functionality as of the last version more services are being put into Quantum there are still services that are handled by Nova Network Manager that require persistence in order to be able to handle persistence object model in order to be able to handle and so there are if you look at as of at least Essex that's L2 and then at Essex everything else though is in Nova like floating IPs, security groups all of the associated things having to do with VM creation having to tie these concept of routers together and tying bridges together and tying those to machines that happened at the initial API call things that happen really kind of outside of Quantum a bit now I think eventually all of that stuff is going to go over but integration, proper integration we believe requires integration not only with Quantum but also Nova at this moment as things move over to a different model and as Quantum becomes more fully flushed out then it might make more sense but we believe you end up having to integrate at two different points right now and I think a lot of these projects that are out there that have Quantum integration only have a certain level of functionality because they only have Quantum integration so the network is bigger than Quantum in OpenStack that helpful? any other questions? sure, do you mind if you go up to the mic? okay oh yeah not in our model I think BigSwitch actually probably can speak a little bit more about that if they're in the room over here the question is is there any intersection with OpenFlow and in our model there isn't I think in the CIRA's model I believe they use OpenFlow in order to control the OpenV switch that are on the host of these machines we don't actually do that and BigSwitch's model I can't speak of because they're not public yet so feel free to add if you want to thank you excellent I'd say it's very easy to give us a call but I would say for the vendors in here as well I mean everyone's fielding calls everyone's talking about this there are a few sites out there that are really excellent there's one site written by a blogger named Yvonne whose last name I can't pronounce called iOS Hints there's a good site to go to there's another site called Network Static there's another and that's I believe done by Martin Casado at the CIRA there's another one called Network Heresy there's another one that a blogger at Dell is at called well it's his name Brad Hedlund so there are a few different sites out there that really kind of cover this space and not just cover this space but cover mostly like intelligent data center networking thoughts and they talk about a lot of stuff they talk about overlays they talk about class fabrics they talk about open flow they talk about VRFs and the scalability model they talk about Juniper Solutions and Cisco so I think a broad education actually is very helpful just to kind of understand this as well and you know like I said earlier the type of people that's involved in this it's always been these network guys that have had a lot of depth on this and that's starting to move on up kind of to more of an application, server, admin sort of group of people so I think there's more people that are going to have to get more depth that haven't been used to it in networking and these are all really great places to start from and also I think all of our vendors that are out here have blogs of their own Big Switch is very involved in the ONF and they've done a great job in network I mean education around not just open flow but software to find networking as a whole so I'd say all of those places would be some of the first places I would kind of go to and look at and then after you have a little bit of an idea on what you're trying to do and where these fit talking to vendors is really helpful as well and you'll be armed with more information so you can call people out Any other questions? Alright, well thanks for your time guys I really appreciate it