 Thank you for coming to join us for the Great Expectations panel. We're going to get started. Everybody's here. Thanks for your patience while we get everybody mic'd up. I'm fine. I'll stand. I think everybody can hear me. So we've got a great panel. The topic we've called the Great Expectations, the New Enterprise Stack, and we're really focusing on the evolution of OpenStack as an enterprise platform. We've got some folks here representing the provider side of things, the vendor side of things, the end user side of things, customer side of things. We really wanted to start off a topic about a discussion about OpenStack and how it's delivering on enterprise expectations, and highlight a couple of key areas. Everybody on the panel has kind of talked with their teams about the key areas where OpenStack can improve or address enterprise requirements more effectively. The things that we should put on the community's radar. So real quickly, we want to run through and introduce everybody. Starting here on the end, we have Mark Mule, who was just on stage at a great job monitoring the panel for the keynotes from Comcast. Jesse Proudman from Bluebox, the CTO and co-founder or founder of Bluebox. Cebu from Cebu El Marju from eBay, Chief Engineer of Cloud. Devinanda van der Veen from HP, Master Technologist and PTL for Ironic on the technical committee as well. Dave McCrory from Basho CTO there. And then Benny from Revello, the co-founder, chairman and president of Revello Systems and finally Jared Ray from CenturyLink Cloud, the CTO there. One of the founders of Tier 3. So to start off guys, we just wanted to check with you on the panel. The panel wanted to really get a sense for who's in the audience. And could you just give us a sense for who in the audience is a technical person from the dev side of things? How many devs do we have in the audience here? And then from the end user operator side, someone running a cloud. And then finally from the service provider side. Any other category you'd like to represent, just raise your hand so we have a little sense. Great. Thanks a lot to the 3ROM Cloud done category. Great. Thank you very much. So right off the bat, we had a lot of conversations over the past few weeks. Guys had a lot of fun last night talking through some of the topics at dinner. We're talking about what enterprise expectations are for OpenStack and we wanted to spend a few minutes talking about very simply what are enterprise application workloads and how are they different from the kind of other workloads that are out there that are becoming much more popular and prominent in the environments that we're managing with OpenStack. Can you talk a little bit about what an enterprise application workload attribute list looks like? Maybe you could start us off, Mark. Sure. Happy to. Mark Meale with Comcast. Thanks for having us and thanks to the developers in the audience for putting together this great product. We depend on it and we thank you for all the great work. Now we have a lot of volume. There you go. I personally feel like the workload shouldn't be that different but reality is when you get in front of a developer, the developer has lots of things to think about. And unfortunately at least for me, in my experience with enterprise applications, a lot of the development happens outside of Comcast. And so that means that we're dealing with third-party vendors that certify a vertically integrated stack of things that in many cases go all the way down to specific releases of kernel and that bothers me to no end. So working with the third-party ecosystem, the developers outside of our four walls of Comcast is probably the single biggest requirement and the single biggest impediment for us to get our stuff onto OpenStack. Thanks Mark. Benny, you guys spent a lot of time thinking about workload portability at Revello. Maybe you could talk a little bit about how you evaluate and consider an enterprise set of requirements for applications and workloads. So the way we see the current enterprise application, like you're calling them, all built this way. So the application itself is very closely connected to the hardware and it's an optimization of almost the point function. When you're talking about the cloud, there is a clear separation between the infrastructure and the application itself. It's not clear when you're developing the application where you're going to run it. This is not the situation right now. And because of that, customers are running into many issues like the first question they would ask, what about the performance? What about SLA? You want to be able to separate those when you are providing an answer to them. One trivial example, I think everybody here that was running recently on a cloud like Amazon experience, they basically because of security had to pitch the virtual machine, their iPvisor, sorry. And because of that, they brought the entire service down. They didn't bring it to on time. They did it over a few days. But this is something that Enterprise will never tolerate. You can always raise your end to the IT and say, well, you cannot bring it down because there is a big business running here. In Amazon and some of the other public cloud provider, you'll get an email, read the instructions, how you build the application for the cloud. So this is something that Enterprise is not used to today. There's no one app, there's no one platform for all apps these days. And Jared, you guys build a pretty robust Enterprise-grade platform over at CenturyLink Cloud. Can you talk a little bit about the customer expectations for Enterprise? You've been doing Enterprise Cloud for some time now. What's your take? We right now service thousands of customers, mostly in the Enterprise space. When we talk to our customers today, it's mostly on two big things. What we call traditional Enterprise software stack, which is normally a software vendor basically provided something and it traditionally is used to a bare metal configuration. It's made that way. And a lot of the Enterprise software, and we've been working with our customers on this, stop saying Enterprise software because if you actually look at how technology has changed because of cloud, if you look at it now that's not Enterprise software. That's just a very legacy architecture model that they actually built. A lot of our customers are now moving to a more Enterprise model where they don't care if a cloud goes offline. It's fine. They don't care if VMs go offline. They're able to stay up. That's one of the big things that we've seen. Right now about 85% of our workload still today require high SLA. And so it's at least four nines plus. They can't have blips even on networks. We're actually having a lot of traditional vendors now saying that they came and handle a seven-second blip on a network. So we have a model completely to that. And that is extremely hard. Especially when you start going into an open stack architecture or something that's a little bit more fan-out model. What are you seeing in terms of diversity of workloads and diversity of platforms that Enterprise is expecting you to support? What do you guys support at Centrelink Cloud? Huge split. We see a massive amount. A lot of back office is now traditionally moving to us, which is surprising. There were clouds doing web-based applications, things like that. We have a ton of back office moving to us. A lot of them just want to get out of their data centers. This year alone at Centrelink, we have 57 data centers. Our customers have moved out of 20 data centers of their own. Just basically porting into our cloud. So it's a massive change for them. And it's really a question of what the application owners do. If you have an application owner that thinks in a cloudy way, it's much easier to get them onto open stack, as opposed to if you have an application owner that, as Jared was saying, sort of keeps the traditional vertically integrated, tightly coupled data layers with middleware and web tiers and so on, that aren't easily separable, then they're going to stay in an Enterprise data center for a long, long time. But if you've got people that think about sort of the pets versus cattle mentality and you're on the cattle side, it's much easier to migrate them into open stack. How much of that do you think is rooted in the legacy of Windows as a platform and applications that are built on Windows versus applications that are being architected on Linux today? Yeah, I think we see it across all the different environments. If, I don't want to pick on the Microsoft gang too much, but that was the beginning of a lot of IT for a lot of companies. And that legacy has sort of, it has a long arm of the law. And that legacy has been carried forward and forward and forward into Linux architectures, whether it just doesn't matter, the platform doesn't matter so much. It's whether the team around that platform has thought through what it takes to get into a scale out architecture versus a scale up architecture. Yeah, and I would even say even more to the fact that like clustering, traditional clustering, it's a joke in the cloud. Most of the time it doesn't even work. So even on a Windows cluster, when they say use clustering services, Microsoft doesn't even recommend that anymore. The other thing that we hear from our legacy customers or traditional enterprise customers are this idea of licensing. You know, right now, today, it is extremely hard sometimes to license software and port it to the cloud, which is ridiculous. I mean, why would anybody care? Thanks, Jared. Sibu, if we come over your way, the kind of next area that we all thought was a very interesting topic is around how workloads are allocated. So we talked a little bit about what these workloads are, what these applications are, the attributes of enterprise workload. In your environment at eBay, could you talk a little bit about the kind of evolution of the last few years and how that's changed the way that you allocate workloads to certain platforms and perhaps touch on the idea or the topic of which workloads end up where and which workloads have stayed where they were or migrated over to where you are now? So the transformation that we see at eBay is quite common. We started the first generation cloud where the force was operating front end deployment from the moment you ready to push code, go through stages of deployment across data centers to bring it up live in a few minutes. That was the awesome thing we did. People were happy. But today, if I look at it, it just happens to be one of the use cases. It's all about heterogeneity. People do all kinds of weird things with cloud today. Once you put a malleable infrastructure infrastructure that they can code, and tweak things put together and people come up with all sorts of use cases today. Like I've come across developers that do 400 node Docker cluster for some CI workloads. I don't know how they had the APIs to do that, what they need to do. The traditional platforms, how do you cluster all kinds of things happening on the cloud today and it happened just because there's an API to code it. That turned out to be the most important part of our project. Subbu, could you talk a little bit about the... Bring it up, keep it going, maintain 4, 9s, 5, 9s of time. That's always hard to move. Unless you are able to get all the building blocks from the cloud infrastructure to be able to manage those at scale, the pets won't go away. If we get just a bit more specific now guys, if we go down a level deeper now so we haven't talked at all about VMware versus OpenStack versus other things that are clearly emerging. So what specifically starts to end up on OpenStack and Jared and Jesse, you guys have different audiences you're targeting. Are there workloads that you're not going after? Given the nature of the two platforms that you're running, can we start digging down a little bit deeper into the OpenStack, VMware and other options discussion a little bit more? If I could, we're also beginning to see specialized clouds forming, where it's a single API but this cloud might be better suited for tests, this cloud might be better suited for databases etc. Vertical clouds. Yes, absolutely. Are you guys not targeting certain workloads Jesse? Yeah, I think it's a great question. So on the VMware side, and this goes back to kind of the COBOL point, it doesn't make sense, with the customers that we work with that are most often SMEs, it doesn't make sense to lift and shift a VMware workload, it's working, it's operable. What we find is our customers want a cloud technology with a well-defined API that they can put adjacent to what's running today, and use that as a way to build that next-generation technology integrated with what's operating now. But this notion of moving workloads, we just don't see that that planning out in reality. I couldn't agree more. To Dave's point, there's a question before you ask yourself, are you going to move to OpenStack? It's a question of is it even worth touching? We want to expend our resources in a very deliberate way. We have the same 40-year-old billing system issues that lots of companies do in our position, and we're never going to touch them. As Dave said, it's not about laziness, it's not because people don't want to design new systems in the right way, it's because it just doesn't make sense. Then I think you can get to the question of where should things run? For us, there are workloads that are harder to get to run on OpenStack than other workloads, but I don't think there are workloads that you cannot run on OpenStack. We run latency-sensitive voice applications on top of the OpenStack infrastructure, and it works great. It's a scale-out architecture, and when we have a problem, and the voice conferencing system that we use goes down, there's another instance of it that is already running, and we're load balancing between the two of them. It's not an issue if you've built the application correctly. If we can stick with you for just a second, Mark, because I think there's an interesting segue that we talked about. We wanted to cover some other areas here. If you have a user in your community of users at Comcast who's very familiar, comfortable with VMware, or a dyed-in-the-wool enterprise user, maybe not as familiar with an SOA environment, or the quote-unquote environment, are there certain expectations that they have of OpenStack right now? They're coming into the OpenStack environment saying, I can't do what I need to do in my quote-unquote mindset right now. Again, I'm not trying to generalize too much here, but I want to get a sense for the reactions you're seeing of your kinds of users in your community inside Comcast. What are their expectations when they come into OpenStack? I have one favorite one, and I'll sort of model myself after Jesse here, and then I'll throw the grenade and let somebody else react to it. Oracle, I think, is the big hairy thing that everybody... When I first came to Comcast seven years ago every single database it felt like, I'm not sure this is actually true, but every database felt like it was an Oracle database. It was the tool for storing any piece of data at the company, and unwinding that to my earlier point about developers was tough. And now as we have successfully unwounded in some places, trying to migrate work onto any virtualized infrastructure, but especially onto OpenStack has been tough to do with Oracle. One thing that I would probably comment on just legacy environments at CenturyLink, it's a 85-year-old company, so if you want something old, they have it. It's amazing. We were acquired in November, so we're about a year old, which is inside the company, and one thing that we've seen very powerful is even in that old of company, they have I think they said up to 18,000 VMs that they just run internally. And it's spread across the board, some of it's for network virtualization, a lot of it's for internal core back office stuff. And what we've learned from the customers is when they come and talk to us about how to port something over, they already have it virtualized. It really comes down to SLAs, it comes down to what their expectations are of that VM and how it's being maintained. And there's a lot of things that they're not going to move. CenturyLink has eight different billing systems on the back end. They did a lot of acquisitions over the last decade, and some of them they plan on getting rid of, but realistically moving those is extremely hard to do and very inefficient. And so they would rather port all 18,000 VMs over basically almost lift and shift where it does become something easy for them. But there's a lot of applications they're going to keep on bare metal for a while until even us, which is pretty high grade. Please. I'm not sure if this is working. Go right ahead and speak up. This is a small room. I see a lot of professional customers looking at pets have the hardest to move, with Oracle being the architectural example of that. So seeing that a push or desire for that both enterprise or legacy customers have everything old and need to drag that along. Why isn't OpenStack supporting more of the legacy kind of stuff that we need to drag along? That's exactly what we're talking about. Spot on. Is there anything that they don't find in OpenStack that they're expecting? Why isn't OpenStack able to do what I needed to do for this particular workload? Are we trying to stretch the philosophy of OpenStack too far to make it do pets things that it wasn't designed to do? I want to contradict that point. I want to contradict that point. I think it is not as an operator of OpenStack for the last two plus years. I don't think it is the responsibility of OpenStack to evolve itself to deal with pets better. I think we have to move towards cattle. What I want OpenStack to give me as an operator is enough building blocks so that I can influence the change from pets to cattle. Today I'm not able to do that as much as I would like to. I need to get out of OpenStack. This is exactly where we need to land. We've got to get through everybody in this amazing panel and simply you nail it. If we want to get right to the last question, we can't do everything. We've got to have at least two minutes for everybody to talk through some of the ideas they had. If you're looking ahead over the next year and then out to 2020, what are the key things that you would change about where we're focusing right now and the kind of specific attributes of the product roadmap quote-unquote for OpenStack that you'd focus on that would make OpenStack more attractive to VMware users, OpenStack more attractive to enterprise users. Characterize it however you like. I'm trying to not get into VMware versus OpenStack or anything like that. It's more about the nature of a dynamable enterprise user who's looking at OpenStack, trying to figure out how to use it more effectively. What would attract more enterprises to use OpenStack more effectively from your perspective? Just a meta comment to start with. We had this identity thing a year or so ago where we were all worried about OpenStack's identity relative to AWS. I don't want the new identity crisis for OpenStack to be how are we relative to VMware or any other product provider. I think we need to evolve on our own, as Cebu said. I think for me the single biggest set of, well maybe I'll list a couple things and I won't limit myself to single, but stability at scale. There's stability when you have tens of VMs. There's stability when you have hundreds of VMs. There's stability when you have thousands or tens of thousands of VMs. Most of our deployments today are in the several hundreds of VMs in terms of size and we are having stability issues. When we're moving hundreds of gigabits worth of data through the OpenStack cloud one instance of it, we see stability issues. We cannot take our core businesses and run it on top of an infrastructure that has stability issues at few hundreds of VMs and a few hundred worth of gigabits. We have infrastructures that I'm responsible for at Comcast that move tens of terabits per second that I would love to use OpenStack to orchestrate the data center for. There's no chance I would think about doing that until we get stability and scalability under control. We do it by hand. It's all the classic bare metal stuff. Pixie boot and ChefPuppet. I don't think it doesn't get to that level of scale. When we're moving 10 plus terabits on a platform on an infrastructure we don't virtualize that infrastructure today. The VMware infrastructure at Comcast just to maybe answer your question a little bit to the side is many multiples larger than the OpenStack-based infrastructure. It probably doesn't do very network-intensive loads. It does somewhat network-intensive loads like maybe tens of gigabits as opposed to single gigabits that we're doing mainly on OpenStack today. Jesse, where would you focus our energy over the next year and the big hairy audacious goal for 2020 on the five-year horizon to attract more enterprise workloads? So again I think that the key here is to change the conversation from how do we move enterprise workloads to talk about how do we how do we sit next to adjacent to enterprise workloads and be that platform for next-generation applications. Stability is obviously a challenge you're hearing in the keynotes. You can stand up on OpenStack Cloud today and run a pretty consistent set of commands to make it fall over like it just happens. And I think the challenge there is that you've got this huge open-source set of developers with a very wide range of experiences working on distributed systems and you've got developers who aren't operators. And so I think the foundation has and continues to do a very good job or a better job getting the operator's voice integrated into the project itself but stability, I mean it's really it's stability. How do you define what core is and get that core rock solid so that we can stop hearing these stories of people who stood up clouds and abandoned the project because they didn't work? I would just want to echo that to what CommonJC made. Define a core, make it solid, keep it long-term. So I would say the pretty much the same thing that Jesse said. OpenStack really needs a solid and scalable, both solid at a small scale an individual VM that's workload has to be able to be kept up for five nines even if the machine has to go under maintenance we need to be able to port that workload around seamlessly and at a very large scale tens of thousands of VMs also be stable but we also need an ecosystem of platforms on top of that and so right now that's one of the problems that we're tackling. Services market, not market but developer market, ecosystem. Also one point just to bring up sort of stepping out OpenStack we've talked a lot about diversification I see it as an abstraction layer there's already work being done to abstract physical layers of infrastructure within OpenStack so that might be one of the next steps I can dig it for you if you want. Thank you very much Devinanda. So I agree that it has to become more stable to be usable especially at scale that's the only way that trust is going to end up being built for the really what becomes the early and late majority to adopt OpenStack in the enterprise I think that's going to take time but I think it's very much needed my view is though if we go to the 2020 view that it's really about services and other things that really today you see in the few legitimate players that are in the platform as a service space I see those capabilities being the things that need to be bubbled up and that's what needs to be tightly integrated and living on top of OpenStack for the benefits to be there the other point I would make would be the one thing that could get people to move all of those legacy applications over sooner is in ease of moving them and the push for them to get away from the Oracle tax and if you look at the ever increasing licenses if you can move away from that the cost differential over two to three years might be enough for you to rewrite that application and make the move if you could make that easier on developers and for enterprises in an easier business case then I think you'd see more rapid adoption Thanks Dave So in our work at the Rovello we are comparing the stability, SLA and performance of several clouds not only OpenStack clouds including the other ones and I can tell you the situation there is sometimes better but it's not like it's completely the pet's environment where everything is stable and everything is great my conclusion from that is that running infrastructure at that scale it's complicated and one of the ways to deal with this I think some of the previous talk here is to focus on the core saying things this is not what we do or we don't do this thing is a great value in general in product marketing or product management to say yes we are doing this is the core, this is what we are doing and this is what we are not doing strategy, somebody smarter than me said it is the things that we don't do so saying that we don't do a few things and focus on the things that we do and what we are doing really good is what will get us there just to finish I'll give you from my previous life in communication when it compared the evolution of TDM to IP IP became very cheap but it became something very simple oversubscribed where there are many deficiencies in the core itself of the IP and it's being handled in the perimeters so things that the core doesn't do are being propagated to perimeters in our case it will be to the orchestration tool to the application things around it so focusing on the things outside of OpenStack, outside of VMware a lot of buzz about containers Kubernetes, Mezos, CoreOS again this is about competing and attracting workloads regardless of the enterprise discussion we've been having but again how do we make OpenStack more attractive vis-a-vis the attributes of CoreOS and Kubernetes and Mezos how do you see the two or three of these circles being together and the diversity of the environment continuing to proliferate as it's going on how does OpenStack remain an attractive workload platform and attract things with these other things emerging? once again I see OpenStack as an abstraction layer those fit in just fine under the abstraction layer the details of how the NOVA abstraction layer might be used for containers need to be worked out but again containerization, virtualization bare metal, common abstraction layer for it different vertical clouds to provide different functionality for different needs I don't do this debate a lot I mean we have these alternatives today and what is the right thing to do for a company for an operator I think today as they have said before OpenStack is not cloud so is VMware is not cloud cloud is a service that you put together providing all the building blocks and if you look at Mezos, Kubernetes and all these things are giving me patterns commoditize the patterns that I need to do for efficiency for example I can run 1000 CI jobs with over a pool of 100 VMs I can do that in Mezos that's a pattern I need the building blocks which is provided by the cloud as a layer of abstraction underneath the layer cake I see that as a layer cake with stuff building on top of each other yeah I think one of the things OpenStack has done very well particularly in the last last year or so is it's become sort of the standard open cloud API and so you look at tools like all the DevOps tools Chef, Puppet, Ansible they all speak to OpenStack you look at cloud management platforms they all speak to OpenStack and so now we've got this defined thing that people are writing their their technologies to speak with that's really powerful so as we look at adding new technologies adding support for Docker the fact is we've got our language defined and the abstraction piece holds a lot of weight Any other thoughts guys? Thanks a lot this was fantastic thanks for the discussion guys really appreciate it