It was literally a Power Point of everything that was wrong with the work we had done. I looked at it and it was all true. I’m, “Yes, that’s true. Here’s how we’re doing that.” “Yes, that’s true. This is really big.” “Yes, that’s true. You want to help?”
The fact that I was upfront about it and didn’t keep things to myself, I was very open, changed the dialogue and they ultimately came in and did a lot of collaborative work with us.
That’s I think the story with OpenSource. That’s how it should work. But, and here’s the big but. Corporations are very nervous about that, right? I don’t want my employer’s reputation tarnished because somebody had a bad experience with it.
That fear can drive you to get into these big release cycles and polish things and not expose yourself to feedback and criticism. That is something the ends up being really hard.
Art Fewell: I had a conversation earlier that threw me sideways and I’m curious about your take on it. We’re in the lines of … What are the implications of docker to OpenStack? On one hand docker will work with OpenStack and accommodate each other. OpenStack was conceived before containerization got really big. If we had built up a ground up system …
Rob Hirschfeld: There are people aiming missiles at your house right now for saying that by the way. That’s okay. Containers are old as dirt, frankly.
Art Fewell: Yes. Yeah, the primitives have been there in the Linux Kernel since … For what? Over a decade or something, right?
Rob Hirschfeld: Since before virtualization, yes. Why docker, why now? Frankly, OpenStack was doing containers as an alternate for virtualization in the first stage. That was a really early plugin, but Docker is different and actually there are two elements, there’s docker itself and then there’s Docker as a proxy for this broader new fleet of container management infrastructure.
The thing that’s amazing to me is that’s really been coming along for quite a while. The platform as a service, Cloud Foundries and OpenShifts and Herokus. They’ve been using containers for a long time. The hosting providers have been using virtual private servers which were really containers forever.
They’d offer a tremendous and very real advantage over virtualization for a couple of reasons. One is higher IO performance. Just better performance overall, it gets you closer to bare metal performance ‘cause you’re not adding a second OS and a whole another set of drivers and all that.
The real reason why I think containerization is a very big threat to virtualized clouds is because of over subscription. When you have a workload that’s not doing anything in a containerized workload it just disappears, it just is gone. The RAM can page you out of memory.
Art Fewell: Yeah, very ephemoral stuff, right?
Rob Hirschfeld: Right. The container itself is still there, if your workload comes and goes the container is there to take the workload.
There’s a different issue with volume that comes up. You can’t really over subscribe virtualized servers very much. You can maybe do 1.5, maybe 2 times the amount of RAM on that server. If you start getting beyond that the whole system starts to fall apart.
With containers you can sell that same piece of hardware 10 times or more and really pack in the workloads and so you get better performance and over subscription and so the utilization of the infrastructure goes way up.
It’s a very compelling story to run containerized infrastructure. Even on virtualized workloads, although I think ultimately we’re going to see people are going to scratch their head about running 100% containerized workloads on top of 100% virtualized workloads. You’re not getting real benefit, but I’m a bare metal automation guy. From my perspective everybody is moving down to bare metal.
Art Fewell: One of the things I think I’m curious about is … You have OAM and a management orchestration stack around my virtual machines as that will start to become able to take in containers as well. What about bare metal? Will the container world maybe start to take things that we thought, “Hey, this belongs in bare metal.” and say, “Well, container is close enough to where we could have it.” If we have an OAM for containers will that allow us to put applications that might be bare metal applications so we could have a common OAM around virtualized and bare metal environments? Could OpenStack potentially be that vehicle?
Rob Hirschfeld: I really see the DevOps phenomena which to me is about automating workloads and being able to recreate environments with scripts and code. That is really the mega trend for what you’re describing. It doesn’t matter where I run it. I could run it in VMs or containers or on bare metal. If I’ve automated the deployment, I’ve automated the deployment.
The trend I see is that mega trend of automating the deployments and having better control in the software development and deployment life cycle, that is opening up a whole new world of how we operate infrastructure.
What we really want to do and what my goal is is not to have to pick and choose winners but to let people be flexible. You might be able to say, “All right, I’m going to test it in containers on a developer desktop or laptop.” they’re going to use containers. They’re going to go to a test environment, probably on VMs and then you’re going to go to a cloud and do a scale or a pilot in the cloud and then you might come back and do whatever you want, bare metal containers, VMs in production.
The point is once you’ve got that automated workload and you’ve created the portability by automating then you can choose what the right environment is. You might look at it and say, “You know what? I need 10 machines to run this.” It doesn’t make sense to me to virtualize them. I’m just going to put it on bare metal because I know the workload.
You might say, “You know what? I have an existing Cloud Foundry environment, I’ll push it there.” “I have an existing OpenStack environment, I’ll push it there.” I think that there are some people who believe OpenStack is going to be the data center operating system.
I’m not as much of a believer in that OpenStack eats the data center phenomena. There definitely are people who are pushing that. I see OpenStack in the core stuff being a very good IS platform and I see there are a whole bunch of ecosystem projects that run with OpenStack or on top of OpenStack and those will also come up, but, and Hadoop is Hadoop, right? Ceph is Ceph. There are all these block storage systems, there’s Cloud Foundry. At a certain scale it makes sense to just run those systems, especially storage ones on the metal.
I think that that’s going to be the right answer with this is work to what’s simple to the work you need. One thing I know is that people are going to be needing a lot more capacity, racking a lot more capacity and consuming more both public and private.
Art Fewell: You made a great point there. I think some key strategic advice I think from you there, if I could take it as advice is perhaps not to be overly concerned with the little details initially. From my perspective you’re sitting here and you’re running a traditional environment, as an enterprise, medium, average enterprise consumer. You’ve been needing to move towards private cloud technology of some sort for a while. You probably shouldn’t be there waiting to see, “Should I wait to start to do this until docker containers are all completely ready?”
If we have the ability to click that button and with self-service, launch a new service, whether that’s virtual machines or containers, whatever it may be, it’s all a step that’s heading the right direction, right?
Rob Hirschfeld: Let me give you the Rob Hirschfeld answer for a recommendation. A patented formula. First thing is automate. I’ve talked to people a lot about getting ready for OpenStack and what they should do. The bottom line is before you even invest in these technologies, automating your workloads and deployments is a huge component for being successful with that.
A lot of people think they’re just going to take OpenStack and replace VMware. The reality is they really need to spend some time doing their DevOps automation and cleaning their house before they just move their workloads. It’s not going to solve those problems. What I would suggest from there is that’s step number one. Get your house in order.
The second one is the broader context in the docker conversation is not containers, it’s actually service architectures - what people are calling phantom micro services or micro services. What we’re really seeing from an application architecture is that people are starting to decompose their applications. It’s just service oriented architecture but they’re decomposing their applications and then they are treating them as individual components and capabilities and then automating against that.
When you take that approach, it allows you to scale better, it allows you to be much more resilient and decouple the components in your application. Those two things, that’s the starting point.
People get very focused on, “Should I use docker? Should I use OpenStack? Should I use …” Those are important infrastructure decisions, but they’re secondary to automating your workloads. That’s really where you create the portability. That’s where you mitigate against the risk.
The challenge of delaying those decisions, this is one of the things that, to me, gets implied by your question is, “Oh, I can’t make my decision right now. I’m going to not decide.” With public cloud available, not deciding and not making some forward motion translates into people driving you. That was two years ago, the big story was really IT department is getting end-run by public cloud, which still happens.
To some extent OpenStack would help with that. OpenStack cluster would let you give somebody access to public-cloud like infrastructure. As long as they’re automating it as they go to public cloud, you’re okay. If somebody is doing manual setups in Amazon and not doing the automation, that’s where I’d get scared.
Art Fewell: If you are a consumer of cloud services it enables you start seeing your job differently which I think is important to a DevOps mentality. ‘My job is not to take this server and install some software on it. My job is to make sure that the service that I’m creating here delivers a good experience. The best experience possible and the best economic way.’ Maybe that is for me to build myself or maybe I look into it and find out hosted works better.
That’s the responsibility I as an employee have to my business. You realize, In that view point, I can become a lot more important to my company than I could have thinking my job was to go and install an operating system on this machine, right? A change in paradigm.
Rob Hirschfeld: Yeah, doing repetitive work like that is … The challenge is you’re going to be replaced by a robot if that’s what you’re doing.
Funny anecdote, I was hearing from the company that does a lot of work with Chinese data centers. In China, labor is super cheap. They’re not doing manual installs anymore. It’s come to the point where they must automate the installs because even though they have labor that effectively costs nothing, it’s not fast enough or accurate enough. It’s not repeatable enough. They are investing in automation.
When I was first dealing with Asian companies where they have very inexpensive labor, it was very hard to sell automated solutions because they were, “We just have a team of 10 guys per rack who babysit the rack.” Not quite that, but on that scale. We’re getting to a point where it’s just not an option anymore.
When you look at those problems and helping people survive for that, it really is a question of getting out of your own way. It’s worth mentioning this thing called Jevon’s paradox. If you haven’t heard of it.
Jevon’s paradox says that the easier it is to consume and the less expensive something is to consume the more people consume. When cars improve their fuel efficiency people actually drive more and consume more gas. IT is definitely in that. The more an IT organization makes it easier to consume IT the more … You literally work yourself ... The more you automate the more you make those things, actual more work you’re creating for yourself.
Art Fewell: We’ve talked a lot about OpenStack and how OpenStack governance and things that are changing and you touched on a little bit about OpenStack networking. I’m curious, we’ve had NOVA Networking and we have Neutron. One of the initial challenges with Neutron versus NOVA Networking is that you couldn’t have redundancy in your network nodes, right?
I’m curious, what do you see is the key challenges and the key things that are happening from that networking perspective from your perspective?
Rob Hirschfeld: Networking has been a real challenge and I think that we’re not done. I think that we’ve made a lot of progress, things have been moving really fast for networking. If you look at the major plays in OpenStack networking, I’d be very direct about this. They are almost replacing OpenStack networking.
Open Contrails and MidoNet, two of the big OpenStack Neutron plugins effectively replace most of the plugins. People are not sure if you can use open vSwitch and create a scalable OpenStack architecture. I think it’s just going to take time.
Art Fewell: And open vSwitch has just announced just with the past week that they’re going to try to take OVS into a full & complete framework.