 Hi there, folks. Well, welcome to the craziest presentation that you will see all summit long. This started with kind of a fun set of possibly recreational beverages and giggles about how challenging it is to explain open stack to non-technical people. And being the least technical person in the room, I'm a very good guinea pig for testing these analogies. So first of all, we wanted to just introduce ourselves. I'm Heidi Joy Trethaway with the OpenStack Foundation. And as part of my day job of senior marketing manager, I run the user survey. I work with a product work group and work on stuff like the marketing side of the Newton software release. Tyler, what do you do? Sure, my name is Tyler Britton. I work for IBM on the Bluemix Private Cloud, our managed open stack service. Hi, I'm Shamatha Her. I'm at IBM. I'm an offering manager, which is a product manager. And in the community, I work in the product working group, enterprise work group, and the operators' tax team. Cool. So we're going to try to take you through nine key questions and some cool analogies to go with them. And the first one is just, what is OpenStack, Tyler? Sure, so this is something we hear a lot of confusion about, especially when you're comparing OpenStack to other technologies. And they'll be like, oh, this is just like this. It's the same thing. And they see OpenStack as this one big blob of technology that does everything, whereas it's much more kind of plug and play. So the best analogy we saw here is food. So OpenStack test is the grub hub of technology. So it's that middle cloud layer, and then you're plugging in whatever underneath. So just like grub hub, I can go online and order from a bunch of different restaurants, and I can choose different restaurants, and they bring it to me. I don't have to deal with the restaurants directly. Grub Hub takes care of that for me. That's what OpenStack does with the underlying technology. So if you choose, for example, KVM as your hypervisor, or VMware, or Zen, or Hyper-V, OpenStack's that in-between layer. So I'm just calling up OpenStack and asking for, say, an instance, and then it's going and getting it from, say, KVM and bringing it back to me. It's the same way Grub Hub is going and ordering ribs. They're going to the rib restaurant, picking them up, and bringing them to me at my house. I really liked how you were explaining this to me as the important thing to know is that OpenStack isn't the food. It isn't the kitchen. It's the orchestration of bringing the thing that you want to you. Absolutely. I mean, I think that's the power of it. It's so pluggable. So whichever components that make sense for your environment, so if you want to use NSX or open virtual networking, or no matter what you want, OpenStack makes that connection for you. So yeah, I think a lot of times people make the assumption of OpenStack contains all those things automatically where they don't. There may be most commonly used stuff, like burgers may be the number one thing on Grub Hub, but you can still get all those other options. And just like Grub Hub, I mean, I think another powerful thing here is if you're using Grub Hub, as Grub Hub gets new restaurants, their menu expands, and you can order those things as well. And OpenStack is the same thing. As more drivers come online, you get the benefit of orchestrating and controlling more things behind the scenes. Absolutely. I think you see it the most in Cinder of all places where there's just constantly new drivers for new storage companies, new technologies that you can then integrate into your OpenStack environment. And speaking of ways you can use OpenStack, we asked, what are the different ways you can use OpenStack? Because there are all of these different service providers that are helping people to use OpenStack, and we thought a good analogy here was coffee. This idea that there are maybe three different ways that you can get to yourself to a venti latte in the morning. For example, you can go straight into Starbucks and order the half-calf, extra hot, no foam, skinny, venti, caramel latte, and get exactly what you want provided by this barista. And that's a bit like Managed Cloud. You give them all of your specifications and presto. You are receiving this thing tailored exactly to your needs. If you look at distributions or distros, as we call them, that's a little bit more like having your own curry. You have certain packaged options. And it's something that you can really manage on your own. But at the same time, you have a limited set of choices. And yet those sets of choices are nicely packaged for you, nicely tested for you. Makes it a lot easier for you to deploy. Or you can freeform it. Do the DIY version. Download the code yourself. Do all the packaging and all of the testing by yourself. Or in the case of coffee, roast your own beans. Grind your own beans. Go milk your own cows, if you like, for your latte. And serve up your perfectly French pressed roast. Yeah, I love this analogy because it covers the trade-offs as you move across the spectrum. From this side is the easiest, but also the most restrictive to the most freeform, but the most difficult. So then it's finding what makes the most sense for your particular tastes. All right, well, Shamile, let's talk a little bit about the big tent. Because that's definitely something that people have a lot of questions about. That comes up pretty often, actually. And so the best way we thought about how to describe the big tent was we started thinking about tents. And that actually led us to think about a farmer's market, for example. So if you look at the big tents, in the big tents there's a set of criteria that as long as you're adhered to the open stack for opens, you can become a part of a big tent. Much like a farmer's market, anyone can pay the fee and set up a booth and a table. And as long as there's meeting certain guidelines about where they can put signage, how much signage can they put, how much real estate they have, they're good. And you can sell your goods at the market. Likewise, there's also a notion of when you go to a farmer's market, generally over time, there might be booths or stalls that are more popular than others. And over time, the farm markets become known because of those things, whether it's honey or whether it's a certain produce stall. But because of that, over time, they become the attraction to the farmer's market, in a sense. And because of that, the farmer's market in return will give them preferential placements. So when people walk in, they're right there. They might give them expanded real estate. So that way they can accommodate the huge crowd that they have. And that's how we look at the core services as well. Where in the big tent, everything is officially an open stack project. We still have a set of services that are more popular and widely adopted based on the user survey that we consider the core services of open stack. And so that's how, over time, they're all welcome. But some of them do get better placement or become more popular as they become more popular. They get better placement. Or in our case, they become a core service, more or less. The interesting thing is also to draw a contrast to what the old process used to be like here. So before we had the big tent and where everything was an official project that met the four opens, we had the integrated and release cycle, which basically, a project started and it would be an incubated project. And it would then apply to become integrated. And there was actually a graduation checklist, like literally about 15, 20 things. Are there people using it? Is a team diverse? Do you have multiple companies contributing to it? And in this analogy, that would be like your supermarket, where basically you have to work with a buyer. Once you work with a buyer, you negotiate which shelf you get in product placement. And by the way, as you're more popular and you sell more or you negotiate better rates because of volume, you get better placement to where you're in the middle versus the bottom or the top of the shelf itself. Those are great market systems for analogies. Let's talk a little bit about office space. What are virtual machines, containers, bare metal? What's the difference between them, Tyler? Yeah, this has gotten even more confusing lately, is before it was like, well we have bare metal and we do virtual machines, that's fine. Then we put the containers on top and it's pretty straightforward. But now we're getting the, we're putting containers on the bottom and then virtual machines on top of that. And then we may put containers on top of that. So it gets pretty confusing. So what we found was we think a office building or office space is the best kind of analogy for that. So your bare metal is like your whole building. So if your company needs an entire office building, you're generally either buying it or signing a really long lease, but they're building it exactly to your specifications. How many bathrooms you want on each floor, break rooms, what they look like, how the whole setup is, especially if you're building it from scratch, you have architects in there and they're building exactly as you want. So you're generally making a pretty big commitment, but you have the entire control of that space. And that's as close as you can get to just getting a bare metal server, whether you're using Ironic or what have you. Then the virtual machine that we think is more like an office suite. So you still have control over your space. It's a smaller space. Generally the commitment is as long either because you're taking a space out of a building and you're sharing that, there's other suites in that building of other companies. So now you still get to have some control. So you have your own bathrooms and your own break rooms and things like that. You'll have some control over how your space is set up, but they're still within the confines of the building. So they may say, oh, this corner space includes two bathrooms and this is what you get, even if you want four of them. That's what that space comes with. So you still have those and that's like an equivalent of a VM, you have virtual hardware. So here's your virtual NIC, here's your virtual disk. So you have the feeling like you're in your own building, but there's still some restrictions on that. And then the container, the best is the rented office space. So the reguses and stuff of the world where you can get an office for as short as a day or hours where the core services, if you will, are pre-built. So you have the bathrooms are where they are, the break rooms are where they are, all that stuff is set up that way and you just get your individual office space. So just like a container, if they're running on Linux, you can, your container could be Alpine Linux, even though you're running on Ubuntu and things like that, but you don't get to change the underlying pieces. You're just sharing the CPU and RAM and things like that, whereas the underlying disk and network that's just controlled by the VM or bare metal server that you're running on. So it's kind of that same continuum of as you get kind of the more granular and it's also in general, a shorter lifespan. So usually you're buying a physical server, you're keeping it for three or four years, a virtual machine generally, some period less than that and then containers could be minutes or hours. Yeah, and they're more configurable or the bare metal or the virtual machine, being more configurable as well as having the longer lifespan. And it's also about, this now is where it works in multiple ways where there's also the sharing of resources, right? Where you have your receptionist, for example, in a Regis-type model, in a container model, you're sharing resources, so you're kind of using the kernel and building on top of it. With a virtual machine, everyone has their own office and everyone has their own receptionist still. There's still some contention for resources there, but a container really sharing all of them at that level and then bare metal, as long as you can fit it in your building, you're good. Exactly. Yeah, love it. Shamile, do you talk about interoperability, please? Yeah, absolutely. So interoperability, and specifically what I wanna talk about is explaining interoperability in the OpenStack way of what we do with interoperability. And so the best way to think of interoperability in OpenStack is to think about plug standards or power outlet standards effectively. So in this case, the OpenStack API is really much like a plug. And so you have standards defined here. And the cool thing about that is once you define the interface, it doesn't matter whether I'm plugging in a toaster, a laptop or anything, I can plug in because they're all using the same interface and it also doesn't matter whether I'm plugging that laptop or toaster into my office or my home or maybe hotel, wherever. And this plays out really well because in the OpenStack plan, you can think of your applications, cloud-native applications or just applications in general that you're developing and running as being the utility or whether it's a fridge or a toaster, that's what you're really building. And you're relying on the power outlet or the API interface in this case to be standardized to where you can build an app that will fit it. And as long as your app fits that interface, you're good. And then likewise, that the house or the office could be considered different OpenStack clouds in this case. So I can develop an application, I can use a standard-defined interface that's been tested for interoperability in these different things, like an inspector will come in and make sure that you're adhering to standards that are set. And once that's done, you can use your application or your appliance in any place that uses that standard. Yeah, I mean, you could even extend it even further if you can get a power inverter in your car and plug your blender in, your Margaritaville blender. Okay. In the tailgating or something like that. Well, it's just, we've seen that code other places where, hey, there's not really OpenStack behind it, but people have even built these kind of API converters. And it's just that's the key thing from the application's perspective. As long as the plug looks like a normal plug when you go to plug it in and it works the way, it provides the power and follows the spec, then you're good to go. Implementation is less important. Like the chord size doesn't matter at that point. What matters is the plug at the end of the day. Yeah, awesome. Well, one of my biggest problems is where to park my Porsche. Pause for laughter. The way that I'm learning about the difference between block storage and object storage is if I were to actually have this problem of where to park my Porsche. And the options that I have are on a block storage basis, I could rent a storage unit. And then that becomes mine all mine. I can put my Porsche in there. If I decide to get a Winnebago instead, I need to go get a bigger storage unit. I can also take my Porsche out and then I still have this block storage space, this rented storage unit that I'm gonna have to pay for whether I store anything in it or not. Now, the other way to do it is with object storage. It's effectively like handing the keys of my imagined Porsche to a valet. He gives me a ticket and then I'm off on my merry way. When I want my Porsche back, I say here is my ticket. This is kind of the code for where you have stored my object. And he brings it back to me. Now, we're talking about how this analogy works and also kind of where it breaks down. And I like the point that in object storage, if the valet runs off with my car, not only is he going to store it, but he's also going to make a couple of copies of it so that if it gets a door ding, when I get my car back, I get the one without the door ding, which is a very interesting way of doing it. So, what would you add to this? Yeah, I think, I mean, I'd be interested to see if the ability to quickly 3D print cars, the first use case was backup cars of high-end cars at valets. Yeah. But no, I think that's the main piece is the unit of measure, right? So in this case, in object storage, it's the car. It's the object. Yes, whereas when you go to a storage unit place, you're not saying, I need spot for a Porsche. You're saying, they're like, these are the sizes. I need a block of storage. And you're like, here's, we have a 10 by 20. Will that work for you? Yeah. Or all we have left is the 20 by 40s for an RV. You're like, well, that's the only one you have. So I'll get that so that it doesn't matter how much you consume, you're paying for that whole thing. And the other thing here is another difference is just like when you had the keys to the valet, he gave you a number, right? And you don't care where your car's parked. It's their responsibility once it's there. And you just have to provide that number to get it back. Whereas in your storage unit, if you have to remember what number your car's parked in, if they all look the same and you forget which storage number your car was in, you're not gonna get it back. So you have to know a more specific path of where your car is stored versus in the valet. You just have to know, here's my number that you gave me when I gave you my keys. Yeah, you're responsible for the locations of everything in the block. So even your Porsche has snow tires and they're buried in the back. You better know where they are in your storage unit. You need to know what's in your storage unit. Please, put a Porsche in my storage unit. I would appreciate that. Well, let's talk about how networking works in the cloud. Yeah, so this is often a very confusing spot. Supposed to be once you get into overlay networks and micro segmentation and all these type of things. So the best way we can wrap around it was mail, which mail is actually a very classic networking analogy, right? So they're like, oh, the IP address is the address and kind of working through. So how does overlay networking work into that? So with physical networking, you write your letter, you put it in, the envelope has the two in the from, just like your packet does, and you hand it to the mailman, which in this case you're handing it to the router, the closest router, and it goes from there. That still applies to how our physical networking is happening. Software defined networking is where you bring into more of the inter-office mail kind of on top. So if you've ever worked in a big enough office where you have an inter-office mail setup, I think it's less common now with email and all that good stuff. But you'd have these fancy manila envelopes where you just put someone's name on it. So Heidi Joy, and I'd put the stuff in it and I'd hand it to my internal mail person who would then take it from there. Now, Heidi Joy actually worked in a different office. She's on the west coast, I'm on the east coast. So they would take that inter-office envelope, any other ones that were going to her office, and put it all in a big external envelope with the address of the office and send it there. The mail person there would open that envelope, take out and say, oh, okay, this goes to Heidi Joy. There's these other mail pieces in here and they go there. So I don't actually know what's happening with that underlying network. In that case, I don't know it went to the post office or I don't know it went on these internet routers or how it got to her. I just know our internal mail system works by writing names on this envelope and passing it along. And that's kind of where the overlay networks come in. So overlay networks don't know about the underlying networks. You as a consumer just know about that top level network. So you know your private network of 10, 10, 0, 0. You put an IP address in there and it goes to it. You don't realize under the covers it's actually being encapsulated and sent maybe across multiple networks to get to the other side. So it's that abstraction you just don't even know about the underlying physical network. But at the same time, networking hasn't changed. You still have to write the address on the envelope to get it there and that's where physical networking is still happening underneath. So no matter how you send that, that interoffice mail, it's still at some point is going in a physical envelope and heading on its way over. Yeah, exactly. So at the end of the day, the process is still the same, but you're being abstracted from it to where you don't have to deal with it, right? You're just kind of saying it's going to Heidi Joy and then the two systems kind of. So the mailman, the actual US mail person is the physical router. My internal mail person is my virtual router that I've created, my virtual networking. So all I know is I give it to them and then they're smart enough and know how it works to hand it off to the appropriate physical router which is the actual mailman. Just make sure that my fictitious Porsche gets in that mail and I'm good. Keys in the jail to your fictitious Porsche. Nice. We had an idea for why for-profit companies have an interest in supporting OpenStack. We had this idea to talk about rail. And once we did a bit more research, we stumbled on a phenomenal comparison. So in Australia about 150 years ago, as they were building rail lines, they really only needed to build rail lines from wherever stuff was coming from or going to the ocean. And it wasn't until they started networking, literally networking their different rail lines together that they realized they had created a very, very big problem which is they had three different sizes of rail line. They had the wide gauge, the regular gauge and the narrow gauge. And so what ended up happening was by 1939 toward the beginning of a war, the three gauges were causing so much problem that they needed 1600 people to move 1.8 tons of freight across from one boxcar to the next so that the contents could continue on their merry way to get to where they were going. So it would literally be like if you were shipping from one state in Australia to me, you would put it in a boxcar, send it to the end of your line, then some people would pick it up, move it into Tyler's boxcar. He would transport it over here, they would pick it up out of my boxcar, move it in and then it would be transported to me. So they have been working for 94 years to solve this in Australia and it looks like they've finally solved the rail gauge issue. But we think that OpenStack is a lot like making a rail network system, that the underlying infrastructure, which is the standards and the infrastructure itself make everybody's, benefit everybody because we see the for-profit companies in our ecosystem as being the boxcar creators or sellers or maybe they even not only sell boxcars but they will also operate them for you. And so it's in their best interest to have one consistent standard so they don't have to make three different kinds of boxcars to go on the three different rail sizes. How else might you add to that analogy? Well, I think that's the big piece is just because the idea is like, oh, the rails, you're not directly profiting from the physical rails themselves, why would you contribute to this system and standards? But it enables everything else. So if you're a Mirantis or an IBM or SUSE, Red Hat having everyone kind of all having that same rail line, you can, it increases your scalability and also cuts down on duplicate work. Think about when you had basically three different systems. You probably had three different sets of engineers working on designs for systems for all those different ones. There's all this duplicate effort that happens. And I think that's really the big thing is cutting down on the duplicate effort brings commercial value to those companies, not just it's good for the community. And I think innovation as well, right? Like just in the railway example, it'll be connecting more cities faster because now you can have teams that go, okay, I got this route, you got this route, we're all working on it together, we're all funding it together and you can get more routes or in this case, more services possibly faster. And you're bug stomping, you repair one little piece of the rail line and that's not only gonna benefit your goods moving across the rail line, it'll benefit everybody else. But it's part of being a good citizen and maintaining the rail line. Exactly. Yeah, I think sometimes it's hard for people to make that because there's no direct connection to revenue that it's more of an indirect. But I think this is a perfect example of how in the end, everyone benefits. Whether you're making money off it or even just you're an open tech user who uses the open source code, you don't make any profit from it, you're just a consumer, you're still benefiting from these people that do make money off it, contributing and being involved. Yeah, and you benefit from it. So if you had like one of those little hand carts on the rails, you still benefit by a standard rail line, right? Yeah, you benefit from not only the size and scope of the infrastructure and how good the infrastructure is, but you also benefit from those consistent standards or costs. I think we had a question. Or the shipping container system is another option. Yeah, you're right. Because they had to standardize so that way they could fit more efficiently, fit more and yeah. Yeah, cool. Well, we've got one more and Shamile, you want to take it away, explain this. Absolutely. So when we were talking about coffee, we kind of discussed the difference, what would be called the consumption models of cloud or sorry, deployment models. This is the consumption models of cloud. And so in this case, what we thought about was, okay, coffee was good. Now let's switch over to something more interesting. It's late in the day. Yeah. So basically, you have different deployment options here or consumption options. You can have a public cloud, a private cloud or even a community cloud. And really the difference here becomes much like bars. You can, when you want to drink, you can go to a public bar and you can pay for that one drink that you want and they'll bill you for it and you're off and gone. But every time you want that drink, you're coming to the bar, you're buying that one drink and so at the end of the day, you're like, you know what, maybe I want to have my own bar or have a party that I want to host and that's where the private cloud or home bar comes into play. Where you do a little bit more investment upfront, now you're not paying for one drink anymore. You're paying for building the bar, stocking the bar and everything. But now it's yours to use whenever and with however many friends that you have that are invited. So you can have your own parties, you can have your own choice of what drinks you want in the bar and everything. And so that's like the private cloud model. But again, you're investing a little bit more upfront. And then you've got an in-between model here called community cloud or in this case, a club. So in some parts, they still have a concept of social clubs where you have to become a member and then once you're a member, you get access to the bar and you can order drinks and everything. And so community cloud is similar to that where you're taking the concept of the home bar but saying, you know what, I really want this but I don't want to go it alone in terms of investment and everything. So you chip in with a few of your pals in the neighborhood and you all put together this community cloud or a club in this case. And there you're still stocking the drinks but now you're sharing the burden of the investments but you're all benefiting from the investment as well. Yeah, I think the key about that is there's usually some common theme. So a social club that you're generally sharing some sort of, you know, if it's the VFW, it's the veterans, if it, you know, there's some overlying interest that you share and I think community cloud is the same where we see it where it's research organizations or healthcare so they have some education, they have some overlying interest that they share that makes sense for them to share a cloud. Exactly, and generally it's also a difference of, you know, if you have a public bar, for example, they'll generally stock, you know, they'll have sufficient stock. So chances are very rare that you're gonna go there and order your drink and they'll say, sorry, we don't have it. In the private cloud, you know, you can have a lot of resources but you gotta buy those resources up front. So there is a situation where if you didn't plan accordingly, someone could want that next beer and you're like, sorry, that one's gone. So they'll be more planning. Yeah, the other challenge on the public side is because you're buying per drink, you're definitely paying a lot more than when you're stocking your bar, when you work out the drinks. So you're going to the hotel bar and getting 20 euro drinks. Yay. You know, once you start drinking a lot of them, that gets pretty expensive. 10.97, but I wouldn't know. But on the other hand, if you really just want the one drink, you don't need to go to the time and expense of an entire private bar. So yeah. Yeah, you don't need to blow 10 grand to set your basement up as a bar when you want a drink a week. Although I can think of some people who would justify it. Yeah. Well, I think even private can kind of break that into two modes too. So home bar, we're talking about kind of local on-premises private cloud. There's a concept of dedicated or a hosted private cloud. And I think that's where it comes into where you can rent a room. Yeah. So like, if you go to, you know, you want to have a Super Bowl party. Go to courtyard, may I courtyard? Yeah. At the conference room. Get a VIP room at the club. And you say like, hey, we want to rent this room. You know, you have less options at your home bar. They have a set list you can choose from. But again, it's dedicated resources where the other problem with the public cloud sometimes, especially if it's a busy Friday night, you may be trying to get the bartenders attention for a while there to get your drink. Whereas in it, you're getting that, hey, this is just our group of friends and we have a private room for our event. But we don't want to blow 10 grand and we've set up a bar in someone's basement. So we want a dedicated. Some people would call that a wise investment. Yeah. Yeah, yeah. I think so. Great. Well, we have a question in the back. What kind of bar is a hybrid cloud? That's a good one. Let's see. This is a good question. Also, because we talked a lot about these analogies and where did the analogies break down? And in a lot of cases, when you take them to the logical extreme, they can break down. So what do you think it? What hybrid cloud would be the vaguest trip? Where you can get a drink in a hotel and then take it into your own private room and hang out with your friends. Oh, I like it. I like it. I mean, think about it, think about it this way as the next up. So as a hybrid cloud generally, you have some public cloud resources and you have some private cloud resources. I mean, you can do that net. I mean, I have a neighbor who has a basement bar but he still goes to the bar pretty regularly when he wants something he doesn't have in his basement or, you know, so I think it's managing those resources. Questions, what would be that abstraction layer that's kind of managing that is, that might be his wife, you know, kind of saying if we can go to the bar or not. Hey, we have a bar in the basement already. Why are we going out to the bar? And then generally, it's also, you know, whether we're talking about a workload running on two clouds or bursting where we're running on one workload and we're bursting into the other. So, well, maybe that's it. So you have your private room that you've rented but way more people show up. You ran out of drinks. And he said, hey, we're gonna have to go to the bar out there because we're all full up in here. Or we have our private party at home and then we're doing a 50th birthday bash for someone so we decide to go elsewhere for that. Okay, we have time for a couple more questions. Ooh, we are good. High fives all around. Well, there are nine analogies that we hope that you will test and also find the logical kind of points where they break down. Any final thoughts on kind of this process for us? I had a blast doing it. And it was really interesting because we started with analogies and you know, you'd pick the first thing that came to mind and then you'd start testing it and it would break down and you'd go somewhere else. But really it ended up being like a lot of these analogies that we did choose. We chose because they were so deep in terms of there were multiple dimensions that they could address. And so that was a really fun process overall. Oh yeah, absolutely. I think those were the interesting ones where you're like, it's like this, yes. And then well, what would this be? And then you're like, oh no, that doesn't work at all. What happens to my cars in the valet parking scenario, if the valet gives back my one car that has no door ding, well what does he do with these other cars that he printed on his three day printer? He crushes them and then uses those resources to build the next one. Depending on if the object storage has the security codes in place that require him to crush them. But maybe if he's a bad guy, he turns around and sells them elsewhere. Data leakage. Do I see one other question over here? Okay, well thank you very much for joining us today. Thank you. Thanks.