 The Computer Museum in the heart of Silicon Valley, extracting the signal from the noise. It's theCUBE covering OpenStack Silicon Valley 2015, brought to you by Morantis. Now your host, Jeff Frick. Hey, welcome back, Jeff Frick here. We're at OpenStack Silicon Valley 2015. It's the second year of this show. It's here at the Computer History Museum in Mountain View, California. Big buzz, we were here last year for the initial one. It was a one-day show, a lot of good activity, a lot of people got purchased, and it was an interesting kind of time for the industry. But it's grown up a little bit, it's a little bit bigger, and now it's two-day shows. So we'll be here all day. We were at OpenSack Seattle last week. We'll be at VMware next week, so it's all about cloud right now. So we're really excited for our next guest, Adrian Otto, Distinguished Architect at Rackspace. Welcome. Hi, thank you. So it's always great to get distinguished architects, fellows, guys that are smart, and it's great that there's companies that don't necessarily say you got to be on a management track or a VP or a GM or whatever, but really let smart guys be smart guys and dive into this. You've been at Rackspace since the beginning, and a lot of people don't know that Rackspace was really at the very beginning of this OpenSack movement. We, yeah, we were actually co-founders back in 2010. We got together with NASA and created OpenSack. And since then, we've watched it grow. It's now over 27,000 members in the foundation, 523 member organizations in 167 countries. So it's beyond our wildest dreams successful. Yeah, absolutely. Now really the conversations continues to evolve. A lot of the early pioneers have been absorbed into some of the bigger companies. Now we're getting a new generation of innovative companies that are attacking new parts of the problems. And the conversation continues to move to production, production, production, production workload. So what's some of the things that you guys are working on? Well, we've just announced that we're offering support not only on OpenSack clouds, but now on Azure. And so the thing that defines Rackspace is its service to its customers. And that's what they really, really care about. And in the Microsoft space, customers really love the Azure cloud and we wanted to have a great answer for them. So now we're offering fanatical support as a managed service on top of Azure. And this took some criticism that we, for some reason, are no longer interested in OpenSack, which is the farthest thing from the truth. We're co-founders, we're market share leaders, we're in the Gartner Magic Quadrant for Managed Cloud, the leader there. And we've just started a partnership with Intel called the OpenSack Innovation Center, which is an Intel Center of Excellence to be based in our headquarters in San Antonio, Texas. And these are hundreds of developers that are going to be working exclusively on Upstream OpenSack together as a community to make OpenSack better. Yeah, we just had Alex Friedlidon, Intel obviously led the latest investment in Mirantis, a $100 million investment, which had a lot more than just a check that goes into that partnership. So talk about your experience with Intel and again, another very concrete data point into Intel's investment in OpenSack is really a part of core infrastructure going forward. Well, it's interesting that both Rackspace and Intel are OpenSack participants who are not building proprietary distributions of OpenSack, right? We're both very committed to OpenSack as a community and about not forking code and about contributing everything upstream in a way that's visible and is inclusive of a community rather than following proprietary pursuits. Right, and really jumping in with both feet in terms of seeing OpenSource and OpenSack specifically, but OpenSource generally as a just tremendous and unstoppable innovation driver. Yeah, and this is more than just some developers working together. It's also an investment from Intel into OpenSack in the form of two enormous test clusters. The largest test cluster ever put together for OpenSack, it's two 1,000 node clusters each installed in separate regions. And the reason why we're creating this is to really press the limits for making OpenSack appropriate in terms of scalability, making it more manageable and making it more reliable. And when do those things come online? Those will be coming online in the next six months or so. Okay, awesome. So I want to come back to the Azure, to your Azure comment because the general consensus now is that there's kind of five big cloud platforms, right? There's the three big public ones with Azure and AWS and Google Cloud Platform and then there's OpenSack and then there's VMware. When you say that you guys support Azure, what does that mean? Is that you've got some segment of their cloud in your data centers? Does it mean you're like doing kind of a direct connect into their infrastructure for people that and you're managing that as part of their overall cloud strategy? What exactly does that mean? So it's directly on Microsoft's infrastructure and we're providing the customer experience on top of that infrastructure. So our expertise, right? Our monitoring, our capabilities, bringing the promise of supported solution to the customer, right? We were already doing this on our own clouds. We've already kind of figured out how to do this. And Microsoft has great technical capability. So we're combining those things together. It talk about from the customer perspective, your experience with dealing with customers about kind of what they want. Do they really care at the end of the day where this thing is running, how it's running, who's running it? I mean, at the end of the day, it's about the application and the application performance and getting their job done. How have you seen kind of attitudes evolve around cloud and how the discussion has evolved since you've been involved for a very long time? Great question. Well, it really depends on what kind of buyer they are. Okay, so if they're an infrastructure buyer, they know exactly how they want to do it and exactly what type of cloud is going to suit their needs. And they'll go there to buy it. And what are the main drivers? What are the main drivers that are going to send that buyer a particular way, one way or the other? It really depends what their sensitivities are. If they're pursuing a technology leadership and they're a Microsoft shop, they're going to be gravitated toward Azure. If they're an infrastructure buyer and they're all about low cost, they may be picking another choice. They might like Amazon, they might like DigitalOcean, they might like one of these other choices that are kind of not super service or super technology, but just more accessible to them from a cost perspective. Whereas if somebody wants a premium support experience, then they're going to come to Rackspace for that. And now it's not only just running on our infrastructure, but you can choose the premium experience not only on our infrastructure, but on whatever infrastructure you want. That's the vision. And talk about how the conversation changed. There was a great slide in the general session this morning, I think it was a gentleman from Direct TV that said, if you come to me with a new project, if you come with me to a new app, it's got to be cloud. And if it's not, then you're going to ask me to requisition your box. And guess what? It might be a slow and painful process. So again, talk about how that discussion of cloud is changing inside the customer that's no longer or less maybe so, is it secure? Kind of do I buy this as an infrastructure? Now it's really moving to the why isn't it on the cloud? I found that to be pretty interesting. Yeah, I mean, thinking of your applications as cloud native, if you're building them new, it's perfectly appropriate that you build them as a cloud native application, leverage cloud technology, leverage container technology. But if you're trying to adapt an application that already exists, putting it somewhere in the cloud might or might not make a whole lot of sense. Right, right. Okay, so this logic, this policy of cloud first really applies to the software that we're building now and tomorrow. Right, right. And then there's this thing containers, right? We heard talker con a couple of weeks ago, containers are all the rage right now. Talk about kind of the impact now of the whole containerization movement. You know, they've been around for a while. They're very popular now. And how that combined with OpenStack is adding kind of a new level of flexibility and agility and deployment options that didn't exist before. Yeah, absolutely, so containers are now a movement. You can safely say that OpenStack is a movement and containers are also now a movement. It's not just a piece of open source. It's not just a community. It is truly something larger. And it's extremely exciting, right? Running your application in containers is categorically solving problems with packaging and distribution of software. It's categorically addressing efficiencies in how that software is run and managed. It allows a level of agility that we just can't, we can't even approach even with cloud technologies. So it's extremely compelling. And there needs to be a way for you to sort out how are you going to best leverage the container technology for your needs. And a lot of people are scratching their heads right now because there's so many things they're moving so quickly. It's really hard to choose what do I do? And so the idea here with Project Magnum which is now officially part of OpenStack is to make a comprehensive containers experience for OpenStack cloud operators. So you can produce a containers as a service experience for customers in a way that leverages the prevailing technologies as they develop. We've got support for Kubernetes. We've got support for Apache Mesos now which is brand new. We've recently added support for Docker Swarm. So depending on what your style of orchestration is, and I'll get into this in just a minute, I want you to ask me about the difference between imperative and declarative orchestration. Why people would care? Why would they prefer Kubernetes or why would they prefer a Swarm? You don't need to choose. You choose OpenStack as your infrastructure as a service. You can choose Magnum as the way that you provide containers as a service and now you provide your end users some choice. Do they want to run Kubernetes? Do they want to run a Swarm? Do they want to run a Mesos cluster? And you can make all of those available concurrently if you want. So that and the ability to do this in a multi-tenant way, right? In a way that has this isolation between neighboring tenants where there's no fear that they're going to be running the same container on the same kernel without adequate security isolation between them, right? This is a big issue. If you just say take Docker off the shelf and say I'm going to use this as my container as a service solution, what you're going to end up with most likely is two different, very different applications running on the same host that may be hostile to each other. And the only thing that's separating those containers from each other is the Linux syscall interface, which is something like 380 or so system calls. That is a really difficult attack surface to secure. If you know what you're doing, it's possible, but it's hard. If you don't know what you're doing, it's almost impossible. So using OpenStack Magnum is a way to organize your orchestration system and your containers in a way that is very straightforward and very safe. So if you trust a hypervisor to be a security barrier between two tenants on the same host, then you can trust Magnum to be, again, a multi-tenant solution that would allow you to have the same level of isolation with your container solution as well. Right, because at the end of the day you want the orchestration method that best fits the application. That's right. And the workload. So Kubernetes is an example of a declarative system. What that means is you give it a description of the outcome that you want. And it's the system's responsibility to carry out some process to get you to that outcome. You don't specify the process, you specify the result. All right. That's declarative. And the advantage of declarative systems is that they're very simple to interface with. Right? You chuck in a YAML file, you get out a result. Super easy, right? But the problem with a declarative system like that is that all of the complexity is in the system itself. Now to start contrast to this is an imperative system where the complexity is not in the system. The system is actually rather stupid. It just follows instructions. And the complexity is in the instruction set that you provide. You actually give it literally the process to follow. Okay, so if you want to highly customize what the process is, you might really prefer an imperative approach rather than a declarative approach. So you've got the control. That's right, you have the control and you don't have to do software development in order to change the behavior of the system. So that's why these different systems exist and why they're designed in these different ways is because they appeal to different needs, right? Kubernetes makes a whole lot of sense for mainstream. I don't need a whole lot of access into the system to make extensive customizations. Whereas with the Docker swarm approach, it really is you have full control over basically everything and you can customize exactly what happens when you push the button. Awesome, well thank you for that explanation. Appreciate it and really at the end of the day it's about running workloads. It's about having horses for horses but still being able to do it in a multi-tenant open source structure. Yes. And I look forward to getting an update on the 2000 clusters here next time we see. So thanks for stopping by. Thank you. Absolutely, so Adrian Otto, distinguished architect at Rackspace, stopping by theCUBE at Open Stack Silicon Valley. We're going wall-to-wall Wednesday, Thursday. You're watching theCUBE. We'll be back with our next guest after this short break.