 Yeah, the microphones are here. Let's start first. All right. Well, good morning. These are the early folks who came down for the coffee, obviously. Thank you for joining us. My name is Greg Nierman. My full-time job is I'm a technology evangelist for Hitachi Data Systems. But I also host a podcast called Speaking in Tech every week on the register. And this session and this panel is going to be available for download for the subscribers to the podcast this week. So we've got a great panel here. We've got lots of great questions. We're going to start off with some introductions here. Caroline, why don't you start us off? Of course, it starts off with you. Hi, I'm Caroline McCrory. I'm VP of Business Development and Product at Cloudsoft. We do application blueprints. I'm Jesse Proudman, founder and CTO of Blue Box. We do private cloud as a service, both hosted and on-premises. My name is Kenneth Hoy. I am the business development manager at OpenStack Solutions at EMC. Hi, this is Manju Ramanathapura. I work for Hitachi Data Systems. I work in the Office of Technology and Planning. Among the things, I help planning the strategy work for all things open source, including OpenStack. Jan Holzer, redhead. I do a lot of technology strategy for the infrastructure side and a lot of customer engagements bringing feedback back into our R&D organization. That's great. Boris Retsky is going to be joining us. He's probably going to be fashionably late. That's great. He's kind of a diva anyway. So I want to start off just by showing hands how many folks are using containers in production in an OpenStack environment? One, two, three. That's fantastic. We'll probably nail you with a thousand questions then. But the topic for this is, are containers a threat to OpenStack? It's kind of a rhetorical question because I think generally we know that they're compatible and they work together. But I think most people are interested in about use cases and applications for containers with an OpenStack. Anybody on the panel can start. What have you seen from a production use of containers in OpenStack environments? Boris. Boris, hey! I told everybody you were a diva, Boris. Fashionably late. Okay. So I'm Boris Ransky. I'm a co-founder, chief marketing officer at Mirantis. And Mirantis is the largest independent provider of OpenStack products and services. Good? All right. We've got the commercial out of the way. All right. Boris, I'm going to ask you, what are you seeing in production environments, the use of containers? We did it. We just showed hands here. Three people raised their hands on actually using containers with OpenStack. How prevalent is it right now and what are you seeing? Well, I think there's multiple ways that you can use containers, right? So if the question is whether we see people running containers on bare metal in production environments, there is a small sliver of use cases where, indeed, people are doing that. But from my standpoint, I think the biggest value of containers and by containers, I mean Docker specifically, is that it's a very good package of application dependencies and the values and portability. Therefore, running Docker inside a virtual machine is something we have seen pretty commonly. Right. Let me just ask from an application perspective, what kind of applications do you see running within containers? We would agree. There's a lot of different use cases and there are some good use cases for containers. There are some use cases that were just constructed basically today. I think for applications, clearly, what we see is it's a great way to package application, finally moving towards a more unified way to package applications, because today everybody uses their own mechanism, not portable, et cetera. I think for the application itself, obviously, everybody is driving towards microservice type architectures and that's ideal for containers. One good question, does it make sense to repackage an enterprise app into a container? Probably less likely in many cases or less useful in many cases. But ultimately, the goal should be to create much, much smaller entity, get the portability and all that and the agility in terms of scaling, et cetera. But yeah, we see a huge value in terms of this, but there's a huge... What about actual applications? So what we see today is the classic sort of web tier type infrastructure. For example, a lot of newly developed applications clearly actually built with containering in mind. I don't think we have really seen any use case in terms of deployments for repackaging an enterprise app. When we talk to ISVs, they all look at containerization as a way to rearchitecture their current applications, for example. I just want to before we pass it down, I'll remind everybody if you've got a question, please feel free to come up to the microphone and we'll get you at any time throughout this session. Mind you, go ahead. So Greg, I think one thing what we want to do is to first level set what is a container, right? There's really the actual container which is the Linux jail for people who've been doing the Cherute Jail environment for a long time, right? One side of the container conversation. The other side is actually the ecosystem that's building on top of container which is like, you know, Mezos, Kubernetes, these type of technologies, Omega, Borg, all those things, right? I think that, you know, when you look at the container adoption, people constantly mix the two pieces. The way I see is, you know, you look at the actual container which is really providing a level of virtualization without having to take the virtualization hit, right? There is a specific set of use cases where it's really applicable. Google was doing it before even the virtualization became big, right? And Twitter lives on it, Facebook likes to do that, so these type of large players it perfectly makes sense to not take the hit of the hypervisor attacks, right? And their application tends to be homogeneous. Is it a performance or is it a cost issue or is it both? It's both, I think. That's the, you know, like cost definitely there is a big factor when you start adding the hypervisor license, that's a big cost, right? Right. And there is definitely some performance hit as well. You know, the people who worked on container they can talk about, you know, the user space and the kernel space, right? If you're on the user space your performance is lower compared to if you're running something at the kernel level. And now you have an alternate option which is like the, you know, kernel loadable modules, you can dynamically load the modules into kernel and then still get the performance benefit, right? Now we're talking about all the geek level low level stuff, right? But the net is there is definitely performance benefit. If you really start hardening your container to meet a specific demand, you can really get performance benefit, right? But the thing is with the, you know when I look at OpenStack virtual machine is really not going anywhere, right? Today there's so many other benefits that virtual machine brings in terms of abstracting your entire ecosystem around your application. And there's like hundreds and hundreds of you know, applications that enterprises today run. Not everybody is a Google or an eBay or an Amazon, right? So if you look from their perspective, virtual machine really fits into their needs, enterprise needs. So the other aspect I was talking from a container is really the whole movement around Kubernetes and Apache Mesos, those type of things, right? If you look from that perspective, I think there is a real synergy between OpenStack and container, container conversation provided you're talking in the context of Kubernetes, for instance, or Apache Mesos. Right. There, you know your conversation is more around cluster management, how do you manage your applications, how do you deploy your application in a large-scale environment, right? And that's a problem we are trying to solve in OpenStack as well. OpenStack has kind of done a fantastic job with the core components like Cinder, Nova, Neutron, Neutron people questions, so I'll leave that. Yeah, I know. So, you know, if you look at the core components of OpenStack, there is tremendous value that OpenStack brings to the table. But as you go higher up the layer, people like to use Murano, people like to use, you know, Triple O, people like to use Puppet, people like to use Chef, people like to use Ansible, there's like whole bunch of things, tools that are coming up that makes your life easy in terms of deployment management. And then Kubernetes sits on top of it, or Mesos sits on top of it in terms of being able to manage your clusters, being able to manage your application. So, you know, to go back to your question, is container really a threat for OpenStack? If you look at container as a whole ecosystem, there is a clear synergy between OpenStack and container. If you look at just the container as a virtualization layer, yeah, I mean, there is an overlap, you could run container inside OpenStack as well. So, it's again, really not a threat there. I want to get to, we've got somebody at the microphone, I want to give him an opportunity to ask the question. Thanks, Manju. Thank you. Give us your name and title, serial number. Hi, my name is Boyd Hemphill. I'm here. Hey. So, Docker is a bit unique in the sense that there is a Docker daemon, which is unusual for many of the other container technologies. That Docker daemon looks an awful lot like a replacement for a hypervisor. So, while that may not be a threat in the context of the conversation to OpenStack, it certainly seems like a need to evolve. Do you guys have any views on the idea that the Docker daemon could replace KVM or Zen in some way, in some meaningful way that would enable a more efficient use, a more powerful use of Docker containers specifically. What's that like, Kevin? I agree that for certain use cases, containers are actually more efficient than VMs. I think that's if you want to get maximum utilization of hardware in your service, containers are probably the better way to go because you can pack much more. The whole idea where the containers, especially today, can replace VMs, I think it's actually a non-starter because until you can tell me that a Docker container can handle networking, can handle full isolation and security, and can do persistent storage, right? You can't replace a VM. So, I think that's not to say it won't advance in some of those areas, but I don't see that happening certainly in the next couple of years. So, I was going to say we've been running a public cloud based on containers since 2007. I think their phenomenal set of technology that cloud itself runs on OpenVZ containers. It's more than just performance. It's more than machine efficiency. It's around machine boot time. It's around ease of administration. It's around portability and migration of those of the data itself. The reality is that Docker with OpenStack you can already do it. We have that built into our product. OpenStack is capable of that today, but there are questions around Docker itself and not necessarily around pieces it doesn't provide like yes, the networking pieces are not where we want them to be and the storage pieces aren't where we want them to be. They all get solved. It's the security pieces that I think are the big concern right now particularly in multi-tenant or shared environments it's a question that hasn't been answered yet. So, in the interim I think running containers in VMs makes sense. We do that. We have production workloads our CI workloads running containers on OpenStack today. Once that security question is solved I think that opens up a whole new door of opportunity for OpenStack itself. Guys we've got another question here. So far it sounds like everyone is saying that containers are a threat to OpenStack so I was wondering what made you guys decide to talk about this? What was the little reason that you thought that it might be? That was actually my idea to do that and I'm a marketing guy and I know very well that when you put containers in OpenStack and one headline a lot of people show up so that's one side of the point semi-jokingly but I think that in reality there is an element of truth that there is a number of use cases where containers are better than a VM and there is also a lot of truth around the fact that OpenStack has historically been really VM centric and a lot of kind of architectural decisions in OpenStack has been made around actually solving the problem of how to manage a VM so there is an element of threat which I think is good for everybody to go ahead and openly discuss. I think everybody generally views it as part of the evolution for OpenStack, right? Yeah, actually I wouldn't say it takes a little controversial aspect here but I think in the long term containers can be a threat to OpenStack because if you really would envision people really start moving towards micro-service-based architectures where the services itself are self-sustaining self-healing, etc. there would be much less need for complicated complex underlying infrastructure possibly because you just have immutable infrastructure underneath but that's far out but I think it's a good point that hopefully gets all of us into gear to actually address a lot of the issues around OpenStack and the exploration of OpenStack environments, life-cycle management, all those things which are really important which we still all struggle today with. Today as you know, as has been mentioned many times almost a PhD to operate a cloud for example and stitch it together. But yeah, no I think there's certainly a long-term threat not in the short or mid-term but I think Boris is absolutely right in terms of there are different use cases for all of those different implementations being it VMs, being it VMs with Docker being it Docker on bare metal for example which is all great, it gives you a lot of choice and opportunity to experiment as well. Great, so yeah, that's why we're here. Next question. Hi, Chris Ferris, CTO for OpenCloud at IBM so I think from a technology perspective we've already demonstrated we can run Docker or any other kind of containers inside OpenStack Cloud Foundry, whatever. But I think the thing that's missing here from a threat perspective is from a community aspect. You know, I think that the real threat is to OpenStack the community, not so much OpenStack the technology. The technology will evolve but unless we engage OpenStack Cloud Foundry Docker and sort out how we all collaborate and communicate and integrate our capabilities together then there is a real possibility that OpenStack would sort of fall by the wayside What do you see as the challenge today? What are the barriers? Well, I don't think that there are necessarily any barriers. I think what we do need to do though is get those communities engaged with each other. A little bit more directly. Any feedback? I actually agree with that quite a bit. When we get into conferences that we are here today everybody gets down into the weeds and then they actually forget that we need mass and the only way we get mass is if we all actually want to collaborate with each other and drop the religious discussions about the technology and actually figure out what problems it is that we all collectively want to solve between like as Chris said, the Cloud Foundry Foundation OpenStack and all the communities and actually get together to solve it. I personally am seeing a lot of people wanting to use containers as if it will just replace their VMs and they can get away from VMware licensing. Just because you can start using containers doesn't mean that you should. There are applications that have specific behaviors that you cannot just throw into a container and like some of my panelists have already said it will be a while before the containers are mature enough to deal with some of those sort of workloads but it's an interesting time. It's definitely an interesting time. I actually talked to two different customers in recent weeks that basically have one gig size container images. One gig. One of them said, my boss said we need to go to containers so he took the whole thing and moved into a container and then he said, I don't know why but it's really slow. It's not as fast as they keep telling me it is. So the point being there is real use cases that fit for containers and there are use cases that are not and I think we one of the things we need to do as a community especially when we roll out a project like Magnum is we have a community that has a tendency to jump on whatever is the latest and coolest thing so everyone is going to go wow, Magnum is out let's do all containers only. I think we need to do a better job of saying hey, this is the applications that fit, workloads that fit containers and these are the workloads that fit VMs and the two should be living alongside each other along with bare metal. Very good. Next question. Hi, I'm Patrick Riley, CEO of Kismatic the Kubernetes company that is not Google yet. My question is when we talk about containers we're really talking about the Linux kernel and the features that it provides I mean Docker did nothing but come up with scripts to help you manage that easier. So how do we as companies put pressure on companies like Intel companies like Docker to make the Linux kernel better and to solve some of these security issues and actually make the technology not as a viable alternative to virtualization but as a good parallel effort. I wonder if customer demand is not going to call for that. That's the thing, I think it's really funny we were in OpenStack meeting yesterday there was a conversation something similar to this how do we put pressure for people to do the right thing for Neutron that was sort of like one of the conversation and general consensus actually was this is a community at the end of the day it works more like democracy you can't really put pressure you need to let the customers and the opportunities drive the innovation right. So I don't know if you can really say you know I want to go and Intel double down and invest their money in improving the security if you tell that to Intel I'm not sure if Intel folks are here they're going to say what's in it for me right so is there a customer demand it goes back to that. I think it's also really important characteristic here like the rise of Docker and the popularity of containers has happened so much faster than almost any other technology I can think of recently and all of those vendors know these are issues like every release that comes out of Docker has some security oriented thing they're working towards it but we're just talking and working in such a condensed time frame that it's easy to kind of take potshots when the reality is we just need to give the community time to fix those issues. Great. Do we have another question? No I wasn't here to put in a plug but since he mentioned how can you press on Intel one thing that I do want to say is I work at Intel we do have something called... You guys should talk. We did just release Clear Containers which is part of our Clear Linux for Intel architecture which does use virtualization technology to run containers this was released just last week it's something that people should look at because using virtualization technology does provide that level of security so check that one out. Good. Very good. Do we have another question? I'm going to go back to applications for a second. I tried to pin it down here I think one of the natural questions if we look at potentially low latency applications like SAP HANA and others how are those impacted by containers or are we going back to use cases where HANA may not be a good fit for containers? I can't speak for HANA but I can speak for another use case similar to that. We are incubating a solution around how do we speed up the data transfer like that traditional van accelerator but how do you use that type of technology for today's world where you have a distributed deployment of your application and there is constant conversation happening between your data centers and we have a technology in Hitachi data systems that's focused on TCP acceleration this is a perfect example where container absolutely makes sense you want to take every bit of juice out of your infrastructure it makes perfect sense for us to run at the lowest level at the Linux kernel level this type of technology all it's doing is taking the packet speeding it up maybe compressing it optimizing the packets and pushing it through your pipe that's all it's doing in those type of applications where you have a single purpose and it absolutely makes sense this is the type of example where I am seeing container will probably get more traction as opposed to enterprise application that has to interact with three or four different components and maybe three or four different vendors it's much more simple Jesse you talked before about how you guys have been using containers since 2007 give us some real world application examples and maybe even some of the challenges that you had running that within an open stack environment that platform doesn't run inside of open stack that's outside of open stack and from a workload perspective that was the infrastructure that our customers were operating on top of for everything for web apps, for business apps their infrastructure that power their businesses the biggest challenges we experienced there was really focused on workloads that were requiring kernel hooks so like VoIP was a big challenge, things that tried to actually load kernel drivers don't and didn't work for us and that continues to be a problem but we are seeing more and more applications not need those six anymore that the calls are being moved into user space in many areas well since this is an open stack conference one of the potential challenges with running containers within an open stack environment so I think from my perspective the biggest problem so as an operator one of the biggest problems with open stack today is debugging failure and then you add another layer on top with containers and it just makes that even harder so like the demo yesterday the Kubernetes demo across rack space in google I get 500, great now how do you go figure out what's actually causing that abstraction built on layers of abstraction that actually tracking down and resolving those issues becomes very very difficult and sort of figuring out a structure from a logging perspective to help carry messages through and trace messages through I think it's going to be really critical I think that the biggest part one of the biggest problem right now is is monitoring right because if you're doing containers right you know as you're not stuffing an entire oracle database into a container and saying I'm done if you're using services architecture if I have 200 to 2000 of these containers which make up and you know 200 make up a single app another 300 make up a different example how do you monitor that in such a way that you're actually monitoring the entire application and not just pieces of it and then trying to and then trying to figure out where the problem is yourself that's impossible so we need better tools to do that open stack needs to be able to do that in the containers or leverage communities that are building those tools Yeah, no I would agree that I think it just multiplies the challenge we have already today with open stack where we use that it's scary to debug 50 log files from 50 different services with containers we suddenly as Ken said we suddenly have like multiple hundreds of small containers make up just a single app and then you run hundreds of apps possibly so yeah the whole orchestration how do you actually create blueprints for applications into consistent deployments repeatable deployments and I think we all will see a lot of deployments who may not just only be say an open stack but maybe across different infrastructures for example then it's certainly a big challenge for all of us again how do you operationalize how do you proper top troubleshooting for example I think the good thing is from the container side as earlier for security not only all of us working really hard setting sort of containers to a place where they are more secure I think performance wise we feel pretty confident today we've done a lot of testing they do very well I would say for the large majority of workloads we are looking at but there's always some very specialized low latency Telco is always a great example around NFV for example but as Jesse it takes time it gets there but we are moving much much faster we talked about the six months ago we already had containers that's really used in production from your how Red Hat does this are there reference architectures are there when a customer is first engaging with you about leveraging containers what's the road map look like is every environment unique and a snowflake a special snowflake that requires unique hands on attention or are there templates that can be leveraged to make that smoother absolutely we want to avoid creating all these in world snowflakes because then it becomes unsustainable to manage them and to support them etc and also for the customer it becomes impossible even just to collaborate with other customers if everybody has just their own unique snowflake then we end up in everybody has their own proprietary infrastructure at some point which really doesn't help so what are the tools you're using to provide guidance around that so I think from a reference architectures we do have reference architectures application deployments Docker is really early for this today Docker is more applicable to a lot of the new development we are moving on the company side we are moving for example to containerize all of our middleware portfolio where it makes sense for example to deliver these capabilities as services and then push them out either as virtualized as Docker whatever it might be for example so we do create this reference we try to guide customers through and think of Docker it's much more educational exercise as Ken said Caroline and others is to explain to them where it actually makes sense to look at Docker rather than just blindly go I want to wrap up my HANA into Docker yeah they heard about containers and they got to have a container shiny object and every gravitates towards it so thanks for mentioning blueprints there so for those of you who may or may not know Cloudsoft is actually based on the Apache Brooklyn project we are one of the largest contributors to it and it is an open source project we also have Clocker which we've used and we're working very closely with Docker to fix a lot of the networking and things like that and also applying blueprints to Docker containers that want to go on clouds that are heterogeneous so we don't actually care which type of cloud you want to use and so the biggest issue that I've been seeing is a lot of people now there's so many areas so many layers of abstraction that we're getting more and more calls for people who just want to go look I just need a blueprint for my app and I want to be able to move it from place to place so how do I actually do that because in the weeds discussions are great but like Jesse said so many things are also now coming up into user space and so there's more demand for actually making things easier to consume and also for those of us who have been in tech for a long time things are very different now you can get a blueprint from anyone basically you've got to get help you can fork someone's code and you can start to do stuff but how it actually works the way you wanted to changes so if you can actually build different blueprints for other people to take on the same workloads that you've done I think it saves a lot of us a lot of time and it helps us also understand that enterprises need to operate differently and how we can make that easier for them to use the new technologies Boris I imagine you're fielding tons of questions around containers how much of it is this kind of response to the hype and how much of it is from they see the value for their application or for their environment to leverage that it's kind of a loaded question I know I wanted to comment first because I think we started on the threat of some of the problems in OpenStack in terms of making it more container friendly and then we've evolved into somewhere else so I wanted to comment on the first part so the two very obvious kind of gaps that I see one is around networking as everybody already mentioned so container networking is quite a bit of a different beast than what Neutron was originally built for today so a lot of it has to be refactored and redone if we want to use still Neutron for effectively doing network management for container world the other one is the scheduler because if you look at NovaScheduler NovaScheduler is built around scheduling VMs and the biggest value of actually managing the container is actually having these monitoring hooks and being aware of certain behavioral patterns of the micro services or applications that are wrapped into container and manage the cluster based on those behavioral patterns and naturally when you have a scheduler that only thinks in terms of VMs and can monitor EVM and the VM is busy lets move this VM somewhere else that kind of kills a lot of the native value that bare metal containers bring so now going to your question that was about what people are asking I'm sure you're getting lots of questions about containers but how many of those are really kind of informed interest to deploy containers in their environments with a specific mission, specific purpose where it really adds value we don't get so much questions about containers to be honest but again going back to the question of definition of containers nobody comes and asks us how do we use Docker with OpenStack that question doesn't come up but there's a lot of questions around using Messos with OpenStack or using Kubernetes with OpenStack or using Cloud Foundry with OpenStack and from our vantage point we see containers more as manifest themselves as platform as a service and this is kind of my also kind of notion that there's been a lot of hype around Docker and the value is primarily around it as a package but the long term view on kind of containers is that the key path to monetization and the key value is actually container orchestration and this is where everybody's going now and container orchestration is really nothing more than platform as a service and we have a bunch of different players now evolving and approaching this from different angles so historically we've had Cloud Foundry in the space because their own container standard Warden, only their approach to kind of pushing the benefits of container was never revolving around container as a packaging engine from the beginning outright started saying that the value is actually using containers a higher value of abstraction so that developers can actually operate whole microservices or applications everybody knows Cloud Foundry as a platform as a service so Docker came around and Docker built this super cool thing that makes it very easy for developers to package application dependencies in the container and they've written this wave and they've kind of conquered the container standard so to speak and now they've conquered that standard and they're like okay well we need to figure out a way to make money doesn't look like Docker Hub it's a very old mine for us so let's start going Docker swarm another direction going up towards the container orchestration so all of these movements ultimately and Google Kubernetes is there also so that's also ultimately moving in the same direction so all those movements are kind of converging into paths so to answer your question when end users come to us typically those end users are not developers those end users line of business owners or VPs of infrastructure type of people and they don't necessarily ask a question how do I use Docker how do I increase agility how do I make my developers more productive so it's all about platform as a service which ties back to containers if anybody else we're going to be wrapping up here in the next five minutes if anybody else has any final questions that's actually the real question the question shouldn't be is containers the threat to open snack it should be our containers creating a new type of paths structure paths versus unstructured paths and one of the things I've actually said on Twitter before the ironic thing is if you guys know Docker actually came out of technology that .cloud used to build their public paths ironically the way things are going they'll be building a private path so the question really is do we want is there a future where open stack together with Kubernetes and Docker will be used to create a loosely coupled paths where you can basically treat everything like Lego pieces, put them together and then make your developer workflow work that's great we had just a few minutes left we're going to wrap up so we can just go quickly down the line for some final thoughts go ahead Baju so I was just going to add to that what you said when you look at container conversation people are talking about the actual container and all this ecosystem of Kubernetes Apache Mesos I think having this type of conversations help clarify what are we really talking about and people who literally read Dilbert as opposed to seeing the sarcasm in it we need to clear the air with those guys and I think to what Boris said what's evolving is OpenStack will provide the core components of how do you have a standard way of communicating to infrastructure and the upper layer we are adding a lot of projects in OpenStack but there are also initiatives from Cloud Foundry Kubernetes, Apache Mesos there are a lot of other things going on outside of OpenStack I think we are in a good time now and may the best solution win I think about a year and a half back we were on a panel we were discussing about what's the best way of productizing OpenStack distros are bad whole bunch of things Private Cloud is the way to go there is no such thing as Private Cloud and now we are at a different phase I think in about a year or two years down the line a clear winner will emerge and we will see what's going on and what's going on in the orchestration layer could be a flavor of Mesos, Kubernetes and something else and Murano on OpenStack I think that's the transition I see happening in OpenStack we need to move a lot just for quick thoughts Kelly so plugging for Kismatic how it also relates to containers regardless of whether it's what your underlying IS is please do go to our GitHub in Brooklyn Central and we also have the clocker project and I would love to hear more thoughts on different applications that all of you are working on through our GitHub repo Thank you I think the closing thought for me is all of us in this room we know what containers are we know what Docker is and we're still dealing with people that are trying to figure out how to use OpenStack and the value prop for OpenStack itself let alone containers on top and container orchestration and Mesos and Kubernetes there's so much complexity here that it's going to be a very long time before we're able to really penetrate the hearts and minds of IT and aggregate it's early and I think it's right there's plenty of time to sort of figure out what role each piece of technology has in the final solution I'm sure we can bounce it down toward the edge here as we wrap up