29 Aug 10 on Tech Episode 008: Wes Higbee – Are VMs Dead?
In the last episode, we talked with David Klee (@kleegeek) about experiences with moving to the cloud. At the end of the show, I posed the question of whether the considerations we were discussing applied only to VM-based architectures in the cloud or to all aspects of cloud use. On this episode, our special guest is Wes Higbee, who is a consultant and Pluralsight author. We discussed the future of VMs, how other architectures such as containerization and serverless computing are affecting our use of VMs moving forward. Spoiler: No! VMs aren’t dead!
- Wes regularly posts interesting blogs at www.weshigbee.com
- He’s got a full page of really nice Pluralsight courses
The show notes are available below the player if you’d rather read than listen! Also, be sure to subscribe to the show in your favorite podcast tool – the show is available on iTunes, Google Play, or Stitcher!
This week at VMworld 2016, we’ll be recording three special episodes of 10 on Tech recapping the day’s developments, so keep an eye out for those! They’ll be on our VMworld coverage page as they’re available.
|James Green:||Hey everybody, welcome to another episode of 10 on Tech. I’m James Green, your host, and today my guest is Wes Higbee. Wes is a Pluralsight author. He’s got a lot of really interesting courses out there. He’s recently just done one on Consul, and has some more coming out in the near future, so look for him over there. Also you can go over to his website at weshigbee.com. You can get his blog there and see some interviews that he’s done, and that kind of thing. Wes, thank you for being on and welcome to the show.|
|Wes Higbee:||Hey, glad to be here, thanks for having me.|
|James Green:||In the last episode of 10 on Tech, I was talking with David Klee and we talked about customers’ experiences moving to the Cloud, or deciding whether it was economical or operationally viable for them to move to the Cloud. One of the questions I posed at the end was, “Is that only in the case where we’re talking about VMs?,” because there’s a lot of different architectures that are becoming more popular, and at some point here, may start to eclipse virtual machines as the preferred deployment method, maybe, I don’t know.|
|I’d like to get your thoughts on that, but the question I had was: do the same sentiments and experiences about moving to the Cloud, and the economics of that, apply when we’re not talking about VMs? Let’s talk about where the future of VMs is going in light of things like containerization and serverless architectures. You’re a consultant, Wes, I imagine you see quite a bit of customers mulling this stuff over. What do you see in regards to virtual machines versus other architectures?|
|Wes Higbee:||Absolutely, so back up to your question. Moving to the Cloud, yes, you have the same problems no matter what architecture you have. There is this tendency to assume that we need to move to the Cloud regardless of the reasons. That’s something that should be … people should step back and make sure that when they move to the Cloud, that they actually have a reason for it. Otherwise, you’re just going to have the same problems you’ve had on premise, in the Cloud. That applies whether you’re talking about containers or VMs. What I think is interesting about new architectures like containers specifically … one of the things I help people with is just avoiding some emotional blind spots they have with technology. One blind spot I see is we have a tendency to relate technologies like VMs and containers. They both involve virtualization, and so that’s a good starting point to understand the benefits of containers, but in the process, it’s tempting to then just assume that containers are a wholesale replacement of VMs, for example. Like we won’t have a need for VMs in 5 or 10 years, something like that, as the assumption, because containers are just so much faster.|
|That’s where the analogy stops, and unfortunately people don’t stop with the analogy, they keep going with it. It’s important to stop and look at what’s unique about some of these other architectures. You mentioned basically not having a server as another architecture, and just storing your data in … I assume … some type of database is what you’re referring to, that’s provided to you as a service. Again, that’s a whole new dimension, a whole new architecture to look at. Each of these different architectures we’re talking about has its own potential benefits, and we should step back and understand these things individually. When it comes to containers, one of the differences you’ll see, that while it’s faster perhaps to start up a container, the value of a container is not exactly the same as the value of a VM. For example, I see containers … this is just my own personal opinion … I see them more beneficial in terms of the ability to distribute applications across platforms, almost like a cross-platform app store … I see that as a bigger benefit than just a replacement for VM virtualization.|
|James Green:||Sure. The title of our talk today is Are VMs Dead. I think I heard you answer the question already.|
|Wes Higbee:||I would say, “No”, and the reason for that is there are great use cases for a VM, until we can … If we step back and talk about a container, we’re really talking about … I like to refer to it this way … as statically compiling the OS or the kernel into our application. If you think about it that way, it’s a great analogy actually, so let’s step back to just dynamically linking a library into an application; into an EXE, for example. With dynamic linking, we then have problems when we deploy and we have software that relies on the same library, so we have static compilation of an application, which just bundles up the libraries, basically. That can remove some of the pain we have with dependency management. DLL hell is something we’re all familiar with.|
|If you take that same analogy a step further here with containers, we’re really talking about … so we have this EXE that has the library statically complied in. What if we statically compile in the OS or the kernel as well, and that’s really what we’re shipping with the container now? That just opens up some big benefits here to do some new things, but at the end of the day we still have the need for different operating systems, so I run a Mac here at home. I also have Windows machines. People use a variety of technologies on their desktops and their servers. As long as we have this myriad of OSs, we can’t get rid of the virtualization necessary to be able to run other types of operating systems, so if I was to run a Windows machine on my Mac, I’m not going to be doing that with straight containers alone, because the kernel or the OS is different, so I need something for that. There’s this nice balance point where we’re going to see VMs used for some things and we’re going to see containers used for others, and whatever other architectures evolve over time, we’ll see those as well.|
|James Green:||One thing I’m curious about is over time, we’ll see this change, but right now there’s also the issue of that applications that might be considered maybe a word as potentially offensive as ‘legacy’ at this point … there are a lot of applications out there that just need to be run in a VM. They’re not going to run in a container, right?|
|James Green:||That’s going to change over time and more things will be capable of running in a container-based architecture, but one of the things I’m curious about is are there applications that will not, and what is the reason for that? Are there applications that just … they’re never going to work in a container, it needs to be run in a virtual machine, straight on the virtual machine, for some reason?|
|Wes Higbee:||Sure. A couple of things first off, it’s important … we all have a tendency to say, “The newer version of technology, containers, right now, right? It’s the new hot thing.” Surpasses the old versions, so now VMs are legacy. I don’t think we should be talking about VMs as legacy at all, because again, there is a complement. We already have use cases right now where we don’t even have Windows containers yet, so if you have an app on Windows, you can’t even run it in a container yet. Eventually we might have Windows containers, but that doesn’t mean that everything is going to move into a container. Certainly a lot of stuff can run in a container, but if an app is working fine and you aren’t making changes to it or the changes you’re making aren’t going to benefit from containerization, then why containerize it? Leave it alone and leave it have its own process, and leave that be, is my take on that, until you have some value to add in containerizing an existing application instead of a legacy application. Let’s call it that way.|
|James Green:||Right, so I hear you cutting through the hype and saying there are really good use cases for containers, but containers another necessarily an evolution over virtual machines, and virtual machines are not now irrelevant because containers are the sexy thing to do. There’s really good reasons to just run a virtual machine. I also heard a little bit of, “If it ain’t broke, don’t fix it.” Right?|
|James Green:||There’s a lot of cases where a virtual machine is working fine and, as you said, you’re not going to see a lot of benefit from trying to put it in a container just because of the way that it’s built, so why do that?|
|Wes Higbee:||Yup. Let me step back, though. Something I think that’s neat … and I’m excited about containers in general … because we’re going to see things happen with VMs that we’ve never been really able to do. We’ve been able to do it, we just haven’t done it yet. With containers, I’m seeing this just neat idea around the idea of just packaging up software, make the process easy, distributing it, bundling a couple of layers that the are involved in building up an image, so that everything is there. That’s the same thing we have with VMs, with VM images as well, though it’s a layered process, it’s a little more efficient.|
|We are seeing the abstraction of running of containers, just like we have the abstraction of running VMs on hypervisors, we have the containerization daemon, if you will, Docker for example, having the capability to be able to restart a container that fails, so we’re taking all these problems in software development, and we’re taking them out of the application itself. With containers, we’re really starting to see these abstracted well and removed well, to the point that they can provide some serious benefits. We also have the ability now to easily scan images for vulnerabilities, and we can know about vulnerabilities in layers. We can sign images so that we know the entire thing, OS and all, is verified by the person that produced it. Security-wise, we can start to build on top of the security of base image layers, but all these things can be done with VMs as well.|
|All these things will be doable with whatever comes after containers. These are common problems we face with distributing software, and I just like that they’re abstracted well now with containers. We need to start looking at how we can apply these same nice abstractions back to containers, and a great use case of this or a great example of this is schedulers are now becoming more agnostic. Nomad, for example, is a scheduler that not only schedules containers, like Docker Swarm does, but it can also schedule VMs, and it could schedule just a raw process as well. Whatever comes next, we’ll be able to schedule it, and we always have these same problems in scheduling software, packaging, distribution, restarting, running, verifying, scanning, security.|
|All these things come back up again, and if we now have a way to think abstractly about these regardless of the technology, VM, container, whatever it might be, we’ll have systems that can handle whatever comes next really subtly. Maybe to tie this back to your initial question about moving between on-prem and the Cloud, if we can get to the point where we have schedulers that are very agnostic about what the unit of work is, it’s very easy then for us to have dumb infrastructure that could execute a VM, or could execute a container, or whatever it might be, and the dumb infrastructure could span on-premises to the Cloud, to multiple Clouds, and it will not matter to us at the end of the day, and it would be very easy to set up and very easy to move things around. That’s where that benefit is coming in, it’s to also improve how things with VMs work, just from what we’ve learned with containers.|
|James Green:||Sure. Very interesting perspective. Thank you, Wes, for being on the show. We’re out of time, but if you want to hear more really interesting stuff about this and other topics related to this, from Wes, make sure to check out his Pluralsight courses. You can just search his name over there to find those, or go to www.weshigbee.com and you can find him there as well. Thank you very much, Wes.|
|Wes Higbee:||Hey, thanks for having me. Glad to be here.|