 Hey, so I'm Michael A. Day. I'm the least important person in the room because we have a fantastic panel of people. We've got Nigel Cook. Nigel's an Intel fellow. He works in their software-defined infrastructure group. And generally a wicked intelligent guy. And kind of fun to party with too. We've got Martin Kiss. Martin is a healing MVP and is an OpenStack ambassador and founder of Hungarian OpenStack user group. So Martin, I've not partied yet with Martin but I look forward to the opportunity. We've got Sri Ram. Sri Ram doesn't really need an introduction so I'm not even going to introduce him. You all know Cloud Don? If you don't know Cloud Don, then you need to know Cloud Don because Sri Ram's cool. Thanks, Mike. Thank you. And he's easily embarrassed. Should I continue because it's kind of fun to watch him? No, I guess we have the entire session so that's okay. Thank you. So we're here to talk about a number of things but mainly around Cloud and the Enterprise and understanding what kind of obstacles exist in getting Cloud into the Enterprise, what kind of barriers to adoption exist. They asked me to kind of moderate the panel. I'm going to ask a few questions but these guys are super intelligent and the majority of the time should be them talking. So with that I'll shut the hell up and let things proceed. So I'll drop my mic and then let things proceed. I'll throw out one question just to get everything started. So OpenStack and the Enterprise, is this real? Is this something that we should be thinking about? What are the barriers to adoption for OpenStack and the Enterprise? So it is interesting. It is definitely real. There are challenges, obviously. We just had a talk about workloads, the applications running on OpenStack and we had a great panel yesterday, right? So what are the barriers? Traditional Enterprise applications are not Cloud-aware applications. What I mean by that is they need to be highly armed. They are mostly consistent. They are not like scaling up, scaling down kind of applications and they have high SLAs. If you look at OpenStack infrastructure, it doesn't support highly availability always, right? If you lose a VM, it doesn't wake up again by itself. So those are the barriers that Enterprises have in their mind. The other thing that's also happening is that they don't want to miss the train of OpenStack. They want to have OpenStack but the problem that they have is, okay, I need to have OpenStack but I have this old legacy application that I want to, that can I put it on OpenStack? Can I run my SAP workload on OpenStack? Or can I run the CRM application on OpenStack? I see that that's not the right way of approaching it. There are two things, right? Enterprises are not going to remain stagnant. They need to look forward, which means that you need to have new kind of applications, right? Whatever you are running, yes, you need to continue the investment there. You don't want to kill them but it is not the only type they're going to ever have later. So plan for those applications, right? And those applications will not be these static applications. Any application that gets written now or will get written in the near future is going to be cloud aware. But that's going to be, you need to have mobility for instance. No enterprise can survive without having or supporting mobile applications. They need to be social. You cannot have employees to run on all desktops anymore, right? So all these are your requirements. So think in those terms and plan for those things and OpenStack will support those applications. So that's kind of a starting point. Okay, in some way I can agree with Don. So basically the huge change here, the legacy application simply won't fit into this cloud model. And I guess this adaptation will take some time because deploying just a simple cloud won't solve all of our problems. And we need to change at organizational level. We need to change the development culture we are using. And especially we can learn a lot from the startup companies. They are using this typical DevOps culture when CISAD means have some developer knowledge and they can work together. And basically a lot of things is different in cloud. If you want to see a well-performing application, we need to build a cluster solution and stateless applications. And of course we need to do a very, very different development model. And we can learn about this typical continuous integration story, how we are developing software. It is changing because we think cloud software differently. Maybe the earliest dates will be different. Let's see the OpenStack continuous integration system as an example. We are using OpenStack to develop OpenStack. And if we want, we can do a release every day, basically, using those new tool sets. So I think it is a very early stage of our huge revolution and change of the entire IT industry. So I guess I'm the contrary point of view here, which is probably why I'm on the panel, I guess. So I have to take odds with some of these statements here. And I think OpenStack is getting towards the enterprise of private cloud. In fact, there are some distributions which are great for that. And that's been because of additions people have made into that cloud distribution, which they're now up streaming. So it will be available to everybody. But I don't buy into, hey, cloud, it's got to be stateless. It's the only thing that works. Cloud infrastructure is by nature unreliable. I don't think that's how the public cloud providers build and run their infrastructure. And I don't think that's how the enterprise private cloud should think about or run that infrastructure either. So to me, it's a matter of a cloud infrastructure delivers a certain SLA. And if you can, once you can deliver to a particular SLA, it's a little bit like driving down the highway, you can drive at 20 miles an hour, you can drive at 40 miles an hour, you can drive at 60 miles an hour. As long as you can set the speed that you want to run at, you can go different speeds, different distances. What's bad is if your car is going 20 miles an hour and then 60 and then back to 15 and then to 30, that that's unreliable. I think what we've got to get to is a reliable cloud infrastructure. And then all kinds of applications can run from stateful to stateless. So so I was just going to say that's an interesting point. I think that as we look at enterprise cloud, right, and if I may just summarize that there's this assumption that infrastructure that is cloud enabling is inherently unreliable in all cases. And anything that's taken to the extent, right, that that it's being taken in the current model, right, is is wrong, right. Public cloud providers, many public cloud providers run a tight ship. They have a great management infrastructure, they deploy good hardware, private cloud infrastructures should should learn from what they've been practicing for the last 20 years, right, which is deploy good hardware, deploy good infrastructure, deploy good management. And that resolves weakness in the cloud. I have a point to Nigel's right. So you're talking about cars, the only problem that enterprise seemed to have is car is not the only vehicle, you have multiple modes of transportation, mopeds, bikes, bicycles, anything, right. So if you have a car and you think about a car, you only you are only thinking about having a fancy car or a reliable car, you are only thinking in that pattern, right, cloud is not like that, it's going to cater to multiple ways, right. So you have a different approach here. And so so it's the it's the error of arguing by analogy, because you can always extend it. But I think, you know, the great thing about OpenStack, and in fact, this was highlighted by the keynotes this week, is that people are going to it because they want to build a tool chain on top of an open set of APIs. And then under that open set of APIs, they can have bare metal with ironic, they can have a KVM hypervisor, they can have a Docker container, they can have Hyper-V, they can have VMware, they have all that sort of choice in what they deploy on underneath, you know, a consistent and open API set. And I think that's how we need to look at OpenStack is enabling choice, both in the size of compute, but also then in the quality of service from storage and the quality of service from I totally agree with you on that point. Yeah, I agree on that. So we are not saying that you cannot move your existing application stack into OpenStack, you can definitely. But referring back to some real life examples, we were using OpenStack cloud and there was some transition periods. And for example, if we have the proper tool set to automatically launch or application stack inside the cloud using the OpenStack API, for example, one time one of the or each Republic cloud instance simply died. And it was much easier and faster to launch a new one, instead of calling the support and waiting for their resolution to bring back this instance to life. So I think this is the big deal in cloud. Oh, I think so too. Yeah, yeah. Well, you know, you think of the, the, the, the legacy application running on two bare metal servers, that first bare metal service, don't you have I got a four hour, you know, five day a week support policy, or is it eight hours, is it 24 hour with cloud? It's 30 seconds, I'm going to go back to my console and re provision. That is the benefit of cloud. So that's the benefit. Actually, that's the point that I think you are talking the other side of that one. Probably the cloud is not necessarily inefficient, or it's not necessarily failure prone. But what we are saying is that that assume failure and develop for that. So that's a better, but that's a better approach. The legacy applications are the developers, they're like pampered with highly available infrastructure, always on infrastructure. But what is reality is that it's no longer the case. I think the paradigm has changed and developed towards that. That's what is changing. Yeah, yeah. Yeah. And one, one more comment. I don't agree that public cloud is much more stable than private cloud. So Amazon, for instance, Azure, for instance, they have their downtimes, they have their outages, right? So they absolutely do. But you know, I was listening to Tim Bell talking about the joy of upgrading this opens that cloud from, you know, Havana, Iran. And what I'm saying is, you know, I think we've got a few steps to climb here. And it's definitely doable. But so to that point. If I were to ask each one of you to give me three obstacles in priority order, that you see around enterprise cloud adoption of OpenStack, what would you, what would you say those are? Oh, now he gets to go for it. I can go for it. I can go for it. That's fine. I didn't want to. Now remember, in priority order. It gives me time to think. Mine is like incorrect expectations. Second is the processes, internal processes. Third, I would say it kind of goes with the expectations, the kind of work, the approach that you're taking. So by expectation, what I mean is that you've had something going, it's been working for a decade, at least a decade, right? And you have the same expectations that this new shiny object will give you. You need to fix that one. Whether it's correct or not, I'm not here to argue whether it's correct or not. I'm just saying that it's a different set of expectations you need to have and think in those terms. And second thing is like enterprise IT, the way it operates. So anything that you want to have, you're creating an SLA, the IT will, you need a server now is going to go through an entire set of the question process. You create a ticket, it might take its own sweet time, a week, a month, depends on how fast your organization is, right? That's going to change. People, the developers expect to have a self-service. They're going to expect that one and they're going to operate on that one. What implies is that you have more agility, that's great, but it also create a lot of friction. It might seem to be a threat for your system, I mean, IT department, right? They're going to resist you naturally. And your entire way of operation, you are building any moving piece that have been operating with that expectation, they have to change. So that's a new process, right? You need to educate that. It's not that just you're going to swipe a credit card and get your system when you are done. It doesn't happen in enterprises. You need to change that one. Third thing is, again, like it goes with the expectations there. You had set of setting applications, you need to think forward, right? You don't want to spend your cycle just for thinking about porting or rewriting. Just let them go or let them run. It's okay to have two set or three set of infrastructure. But anything, like Nike's example. So they were moving their applications, they might have had their old applications. Anything moving forward, they were thinking mobile first, right? And they were thinking social first. So they were thinking in those terms and releasing their applications. Those, you can argue whether it's going to be enterprise or not. I mean, if it's being adopted by a big company, a Fortune 500 company, it might have a different usage characteristics. But like depending on the adoption or the revenue involved, like these are new set of applications, you should think in those terms. Those three are my top three careers. I think that cloud adoption into the enterprise mustn't be started by moving the business core applications into the cloud. Let give some time for the team to build up a pilot cloud solution and learn the new model there. And I was at the Linux conference in Ducado at the OpenStack booth and I met with three of the customers. And most of the questions came from that they had problems. First of all, most of the customers don't want to start a brand new IT infrastructure from scratch. They have existing network and OpenStack need to fit into this existing network. Nobody wants to buy a new device just for OpenStack. This is one point. The other thing that is very serious, that they want to upgrade their OpenStack cloud systems. And I think it requires a very special way of finding of OpenStack. So I see these problems currently that we need to run to start the cloud adoption into enterprise. So this is the first steps we need to do. Awesome. Nigel, have you had enough time to think? Well, you know, the hard thing in coming last is, you know, all the good ones are taken. So, you know... It sounds so good. No, no, no. So, you know, I mean, I do like what you said about, you know, it's about processes and people as well as technology. That was really good. And the legacy system piece is high on my list as well. So I'm going to leave those. And I'm going to give three more. But just assuming these other ones are already covered by the other speakers, right? So let me get this straight. You're piggybacking on their highly prioritized items. Yes. And giving us the rest of the list. I guess I am. Okay. All right. Just check. You can juggle them each other way you like here. But those are all very valid points there. But I think, you know, specifically if we talk about OpenStack. So assuming that you've already made the mental model that hey, we're going to do cloud and, you know, now OpenStack specifically, if I narrow my view to that, right? I think that deployment and upgrade would have to be like the number one thing that needs to be addressed in OpenStack to get real mass adoption. I would say the maintenance functions in OpenStack, the operational aspects of it, are another piece that need hardening. So particularly here, you know, I have to do some firmware maintenance on this row in my data center. How do I do that without complete chaos in my OpenStack cloud? But that's a great use case that needs to be addressed. So and then the third one then, if I've got one left, I'm going to have to reuse one here. Definitely the uptake of a legacy environment. So I've already got a data center full of my favorite hypervisor. You know, maybe it's a VMware environment. Maybe it's a Microsoft environment. What I need to be able to do is move that into the cloud versus build something separate and have to sort of migrate it in. And so I think that would be, if we had all those three, I think there would be runaway sort of uptake of OpenStack anyway. So I'll ask kind of a fluffy question. A little bit of a fluffy one because we've had a couple of really hard questions. What's your favorite project in OpenStack? Swift. Why? Sorry. I like, generally, I don't like the need for specialized hardware. So Swift is a great example of how you turn commodity hardware into a very simple set of hardware into highly-layable, highly-rend and distributed storage. So that's why it's personal. If you're asking me in a different way, I would say Neutron because of its problems or at least how we sail to those problems. Interesting. Yeah, my favorite project is not an OpenStack one. It is Seth that solves this commodity storage problem. So you're super setting. Yeah, but anyway, I love all of the OpenStack projects from Trove to Nova. Yeah. My favorite project or my favorite latest feature in OpenStack, let's say, would have to be Horizon. There was a metadata repository that was called, added into Horizon that was called Graffiti. And the idea of that project is to provide annotation of particular images and requests so that as a user requested an instance, it could be best matched to the right space in the underlying infrastructure. And that gives, that gives choice, it gives the ability to have a sort of a differentiated cloud environment. So that one wins my, at least my vote for now. Ideally, making the scheduler, giving the scheduler the ability to make informed decisions. Informed decisions, correct. Informed decisions, yeah. Can I ask you guys back? What do you think of Triple-O? You've got to answer that one. Oh no, I mean, I'm not going anywhere near that. Audience can answer that. What do you think of Triple-O? What do you guys think of Triple-O? Question for the audience. What, do you guys know about Triple-O? So Triple-O is, Triple-O is a project called OpenStack on OpenStack. And hence Triple-O. All right. And it's a deployment capability. So it allows you to install OpenStack using OpenStack. Kind of inception. Yeah, anyway, we are using OpenStack into a lot of different things because we are using OpenStack to develop OpenStack on the test. So, you're not getting an answer from the audience, I guess. Does anybody in the audience have any questions? They come down to enterprise. The bugbearer of most things is you can spin up a machine in seconds nowadays. And we all hear about your favorite projects. But the one thing that enterprise hates is the network. I'm surprised that you don't include any kind of integration and neutron and all that sort of stuff into legacy critical networking. Because I can tell you that's where most enterprise networks lose. Or let's say OpenStack loses its agility. So you've only got two legs on this chair. And I know there's a lot of work going on with the neutron. But OVS is kind of a disaster as regards enterprise networking. And there's lots of things like that. So I'm kind of surprised that that wasn't high on your list because everybody goes to the compute and the storage. So why wasn't that high on your list? Because I'll tell you that's the most unagile part of OpenStack. I mean, neutron is an interesting, the networking is an interesting space. And I think that, so when I included sort of set up in deployment, I was actually including that. And when I was calling legacy ingest, I was also including that networking component. But you're right. Networking is, you know, is a very interesting and inverted column of space in cloud. But I do think though, you know, despite some of the butchuring issues around the V-switch, that the notion of using an overlay network to build your, you know, your interconnectivity in cloud is a great direction. And is one that lets you basically overlay on top of an existing infrastructure versus, you know, having some deep point integration into the, into that existing infrastructure. So I think it's, I think it's on the right approach. There are actually, I must say, technologies from Intel, which are being upstreamed, which dramatically improved performance of the V-switch. We integrate it with DVDK, which will give you high performance and lower CPU utilization, for example. So I love the direction of the V-switch, but clearly it's, it is a, a work in progress, but great progress has been made. I want to add to that one. As a community, yes, we understand that neutron is a mess, but the community has taken good action so far and trying to get it to a good stable state. But I wouldn't call that as a, a barrier for adoption, right? You still had, until last release, right? You still have no one network working for, for your networking needs. So for example, like Rackspace Public Code users used, at least used no one network for the networking. So it is, it is not, from the operational point of view, it is not really a blocker. It is painful, but I wouldn't call out that neutron is messy, so OpenStack is not ready for adoption. There are a lot of features to that one that we, we talked about a lot of varying features, varying factors, but I would like to separate those things, right? And, but having said that, the community has really has worked well on that one, particularly that are, that are cool features that have gone into the Juno release, DVR, Distributor Virtual Reuter for Instance. Yeah, that's a great feature that is going to remove a single point of failure, making it much more scalable. So that's kind of my take on that one, how to, I personally like the way that, that the community has taken and realizing that, okay, it is messy, so we need to fix that up. You as the developers, anybody would accept that how messy it is, but we have worked on it, and we're still working on it. Yeah, yeah, basically, I think that Neutron is not about it, because it is just an obstruction layer to manage networking operations. And I think when we have some bad experience related, maybe some drivers that Neutron is using, and I think it needs some time to evolve and, and some, some basic evolution to go into the right direction. It was not designed correctly from the beginning, so it just took more time to fix it. Yeah, yeah, of course, of course. But I think it is an advantage of this open collaboration that we can fix things. Maybe it requires some time, but, but we have a very strong ecosystem inside OpenStack, and I'm sure it will be fixed, because if we want to run OpenStack clouds in the future, in a stable way, we need to solve that problem. So definitely, I mean, I'm not going to mention names, but there are distributions, which I think have this well in hand already announced and sort of pending announcement. So I think the networking, I mean, networking always is a challenge, but I think that the distributions are addressing that. And I must say, I think that the, if anything, the interest in NFV from the telco end is if anything helping to accelerate that, because those guys are pretty sensitive about their networking and are pushing requirements and are pushing the community in a direction that flows back down to the enterprise, you know, in a very positive way. Interesting. So we've got one question over here on the side. One of the complaints from Enterprise is the cadence is too fast. Six months for de-cycle, it was even mentioned on the first day keynote. So that, well, I'll ask another question. What do you think is the appropriate timeframe for back porting features into previous releases to support enterprise adoption? No. The enterprise doesn't want to adopt it, because it takes a lot of data to change them. Well, if the enterprise, so if the, I can see your point, but if the enterprise adopts ice house, for example, and there's a two-year back porting requirement, for releases, right, then they can effectively get those new features and still maintain their older version. So I guess my question is, what do you think is the right timeframe? Yeah, I think we are seeing this entire listing from a wrong point, because maybe we could focus on the future to make... Nugget of wisdom, would you give to the audience to leave? We can start with Shreve. Yeah, yeah, I know. That's one sentence. Nugget of wisdom is the most important. You know, I've watched this, the OpenStack community grow over, you know, this is my fourth or fifth summer. I mean, it's amazing about how much it's growing. It's amazing the diversity of interest is coming. And I think that this definitely is the... You're going to catch a train. This is definitely the train to catch for a cloud, both public and private. Yeah, I think OpenStack is still in these early days. And the next five years will be very exciting for each of us. And I'm sure we will solve most of the problems that we have now. And anyway, it is a fantastic moment and I enjoy every minute of it. We'll make two points. I wouldn't expect anything else from you. So, first thing that's kind of... Since we're talking about expectations. So, we have a right set of expectations is that we just succeed. As a community and as a product and for the users and the developers, everybody is having a better idea about what the right expectations are. So, go with that. If you need any help, I think you are getting help in the community. So, it's always very helpful and you get enough feedback. Second thing is like, I want to mention that we are in the inflection point, I would say, in the community. We've been there for four years and it used to be a lot of projects now. And now it's the time that big vendors start to remain, which is good for enterprise customers because they need a lot of support, which is the big, big play of the catch here. I had IBM, they're going to provide it, right? Naturally, they come with their own distribution and they understand the enterprise paying points better. So, FTE and OpenSpot, for instance, like we have enterprise pardoning, we have scale and fit with all those things, right? So, what I'm trying to say is that those vendors will give you the stability and maturity that the enterprise customers want. Having said that, it is not the end of the system. I'm seeing, I'm expecting the second way of thought as to where more innovation is going to keep happening. Like, you can expect a lot of, we kind of solved the infrastructure problem, we looked at how do we deploy it in here, right? How do we make the automation in here? So, we're kind of in a state where like we have a good answer for that. But now, next step is like, how do we make it much more secure? Can we make cool things about it? Can you try bolder things like making daughter companies and stuff like that? Those things, these big vendors might be different to crime, but that's where the second way of thought as to where it's coming. So, it's an active, equal system, it's going to keep happening like that. So, I'm very positive about the infrastructure that I'm learning. Together, we're going to learn, and together, we're going to follow that. Well, thank you very much for your time. I really appreciate it. I'm sure the audience does as well. And thank you guys for enduring the panel discussion. I hope it was worthwhile. Thank you guys. Thank you. Thank you.