The DevHops Podcast: Will Virtualization Beat Physical Reality?
Welcome to the first ever episode of the DevHops Podcast! This series will feature conversations between some of the tech industry’s best and brightest around DevOps, agile, cloud, virtualization, and the necessary culture and technology to meet constantly changing business and customers demands. This week we’re joined by F5 Principal Technical evangelist Lori MacVittie, and Skytap Galactic Head of product marketing Jason English. Let’s get started, and enjoy the show!
Noel: One thing I wanted to do to get started was to get each of your definitions of what we mean by virtualization in the sense that we’re using it today. Lori, would you like to go first?
Lori: Wow! I didn’t know that one was contentious. Usually it’s, “What does cloud mean. What does virtualization mean?”
Noel: That’s right.
Lori: That’s interesting, and actually, now that you mention it, there probably are some differences in what people call virtualization, especially as we see things like containers and Docker entering the scene.
Virtualization is abstraction. It’s abstracting the hardware so that it can be used by applications, operating systems, what have you, in a more consistent way so that you can move and not be tied to the hardware.
Ten years ago, when we tried to install an operating system, we had to have all the right drivers and all of the right updates, and we had to tweak settings and change which IRQ this COM port was on and that one was on.
It got better, but virtualization really took it another step further and said, “Don’t worry about what the underlying hardware looks like, don’t worry about where those resources are coming from. Just talk to us, and we’ll make sure that you can talk to whatever kind of hardware might be under there, and we’ll basically work out all those issues.”
Virtualization, whether it’s sitting on COTS, on an HP, or a Dell or some white box server, or even, as we start moving into the network—whether it’s sitting on a more custom piece of hardware, if it’s virtualized, it’s really about the environment that that creates. It lets you deploy multiple instances on the same hardware, but also how you can move that around from one to another without having to worry about, “Do I have all the right things in the settings on each of these different pieces of hardware?”
Noel: Absolutely. Something that we address here at Skytap is being able to add virtualization to the pre-prod area of the SDLC, and virtualizing these assets that were not just cumbersome, but also hard to come by, and then took a long time to set up. There grew a lot of contention to hang on to those, once you actually managed to get them for yourself. More than likely, on the dev and test side, you probably had been waiting for them for a really long time.
Jason: I really agree with that set of things. It’s almost like, when you’re looking at cloud now, people have almost made it synonymous with virtualization in a remote sense. I think when virtualization first came out, it was like this one-time huge hit of economic impact, replacing all this underutilized capacity in servers with something that’s far more efficiently using hardware.
As we move into cloud, we’re starting to see that the potential of virtualization is inhibited if we let ourselves let VM sprawl happen, if we let the spread of hardware affect how I’m going to use my development and test system. We need to find ways to more efficiently manage how we’re using virtual assets, just like we were with the assets in our data center.
Lori: That’s a really good point, that you don’t gain a lot of the benefits of virtualization or cloud if you treat virtual assets like you would hardware assets, as physical ones. You really have to rethink how you’re managing them, deploying them, provisioning them. Everything has to really also change in order to take advantage of that and not just end up saying, “We just have more of what we used to have.”
Jason: I agree.
Noel: Jason, one of the things that you brought up as we were discussing the topic for this talk was, since we’ve started developing and hosting virtual versions of solutions, that demand is increasing. I think it’s only natural that by expanding to the pre-production area of the SDLC, that demand is only going to dramatically increase even further.
Jason: Yeah. I would definitely say that there’s huge demand for making a cloud environment as production-like as possible. Now, kind of like the topic of this discussion, wondering where we’re going to reach the end of, “how much realism can you get to?” Can you really mirror production? It might be 99.9995 percent by the time we really get there, but we’re not there yet.
Noel: Lori, one of the reasons that I wanted to have this conversation today was, I had read the 2015 State of Application Delivery Report that F5 put out. I was initially surprised that that “availability” ended up being the number one must-have or priority for app dev teams. It was even ranked ahead of security, which initially surprised me.
But then it became clear to me that that if an application is not available to the people that are building it or to those who are using it, security isn’t really a factor, is it?
Lori: Yeah, if there’s nothing up, there’s nothing to attack, right?
Lori: There’s no place to go, there’s nothing to do. I think availability encompasses pieces of security. There are certainly different types of security attacks that are designed specifically to destroy availability.
Same thing with performance. You see it with non-technical people. If they’re trying to load a site or load a page and it’s slow—they can’t tell the difference whether it’s just really slow or if it’s down. Really poor performance can look just like unavailability, and it gets treated that way. You leave, and you never come back, or you’re angry, or you say something horrible on Twitter, and the world explodes.
I think availability is that important. If the app is not there, you can’t do business, you can’t engage, you can’t talk to people, you can’t do pretty much anything these days if it’s not available.
You’re right, that it’s surprising, because security is usually always number one for everything, whether it’s why are you not adopting, or why are you adopting, it’s always security, so to see that was surprising, but once we started thinking about it, it really makes a lot of sense.
Jason: Right. I think part of how cloud became more popular is that people started trusting it for more aspects of security. Whether it’s a managed service provider or infrastructures of service, or someone where we’re providing environments of service, you trust those providers to lift up the standards of security maybe beyond what I could even do inside my own company by having specialists, right?
Jason: As far as that service is concerned, that’s one way to look at it as why security isn’t as big a concern as availability itself. Just from our own perspective, it may be the amount of traffic, or dev/test usage has gone up at least double over the course of every four to six months, so you see a lot of distinction there.
People also don’t understand the distinction, obviously, as you work in these environments, that there’s a difference between what’s my bandwidth, and what is the performance of my actual cloud solution. They have to know what that trade-off is, so we have to take responsibility to help measure what is my bandwidth performance, just so I can at least prove that it’s the network and not the application, right?
Lori: That’s a good point, the difference between bandwidth, and throughput, and actual performance, and being able to tell whether it’s the network or the application itself, or just the application to the database, in fact. That’s usually where significant amounts of latency are introduced. There is just one poorly crafted SQL statement is just really dragging everything down, and it’s really difficult to tell sometimes. People don’t dig into it.
It’s easy for a developer. The first thing you’re going to do is point at the network. Especially in the cloud where you don’t have anything to do with it, it’s easy to just say, “Hey, it’s your fault.” More often, it’s probably something in the application or in the way that it’s communicating that’s causing this problem.
Noel: Something similar between Skytap and F5 is that we’re delivering solutions that are being developed by developers, to then be used by developers as well.
In regards to virtualization in these new technologies, is there a difference between pleasing someone who’s in development or engineering or IT, rather than looking to please maybe a non-technical end user or customer?
Jason: Yeah, there are similarities for sure. A certain level of customer service and responsiveness is expected. I think it might be higher in this space, especially dealing with IT professionals or developers, because their jobs could be on the line if things don’t work out right, or could result in some late-night or weekend war-room type activities. You definitely have a little more pressure to ensure that solutions are secure, they’re available, they’re running well, because you have a very sophisticated customer base there.
Lori: Yeah, it’s very different in the interactions too. When you’re talking to a developer, you’re trying to troubleshoot a problem. For example, you can ask developers questions, ask them to help you in ways that you could never ask a consumer to do, either because they wouldn’t have the knowledge or the capability, or you might not ask them to do that, because it might be too much.
It’s more cooperative at times with the developers, that you can actually help them. They want to give you whatever they have so that they can help you solve the problem, if there is one, and try and get it done. Because, as you say, their jobs might be on the line. They understand these things, and they’re very interested in solving it so that they can continue on. It’s a different kind of interaction, too, on the level of what you can do together, and how you collaborate to solve problems that might come up when you’re serving them.
Jason: Lori, that’s particularly interesting. One thing we’re definitely finding is that when we get customers talking to each other, you have developers or architects talking to each other, you discover a whole host of things that you really hadn’t thought about as far as use cases, or how they intend to use the products. Are you finding that out there at all?
Lori: Oh, yes. Yes, because the things they want to do, sometimes they’re fairly common and it’s easy to answer, you’ve anticipated that. Other times, you think, “I would never have thought to do that,” and you want to know why, but you also want to help. You watch them come up with this new way to do something, and it’s enlightening, not only from the perspective of, “Wow, that’s a cool thing to do,” but also from just learning how to step outside the box that you’re in and think about it from someone else’s perspective. It really helps in how you support them and the tools you provide to them, and again, how you interact with them to build out new solutions in the future.
Noel: Great stuff, both of you! I read an article on Forbes recently, and it dealt specifically with the expectations that enterprises have when moving to cloud computing. It was really interesting that these expectations were not unreasonable or surprising. They were things like improved quality, business growth, being able to scale, and getting applications to market quicker.
These expectations may not be easy to deliver, but they are deliverable. They’re what Skytap and F5 products are basically designed to deliver.
Lori: Yeah, people have some really clear expectations of a lot of new technologies that are moving to the cloud. We’re starting to ask about them in all these different spaces, not just, “Here’s what this can do for you,” but “What do you expect it to do for you,” and to really get that understanding, whether it’s to understand, “Am I explaining it correctly?” and they got it, or maybe they have completely different expectations of what this technology should bring to them.
Cloud was initially mostly about scale and cheap. Over the years, we’ve learned it isn’t about necessarily the price. That’s becoming a third or fourth, or not even in the top five. It’s really about business growth and scalability and agility. The ability to do these things quickly to reach their mobile market, all sorts of different things that have nothing to do with what the technology was originally proposed that it would do.
It’s been very interesting to watch that back and forth and see people start to respond to that by actually asking up front, “What do you expect? What do you want out of this,” and then being able to turn that around and use that to actually provide that for the customer. It’s very interesting to watch that transition happen.
Jason: I definitely agree with that. I bet expectations have never been higher, actually. Just to get back to the topic of our discussion, if something does have a physical equivalent, they expect it to have a virtual equivalent, and that’s how the market is going.
Noel: Yeah, I was just going to say, to get back to our original question of virtualization versus the physical reality, I wonder if these expectations come from reaching the maximum level of scaling, business growth, and agility that these earlier hardware solutions are able to provide, and that’s why enterprises are starting to look elsewhere.
Lori: I think it’s some of that. I think it’s some of Moore’s Law at work. Certainly, compute and processing is just outstripping everything right now. There’s a computer the size of a grain or rice, and how can you do that, right?
Lori: That’s more powerful than your mom’s mainframe, and you’re like, “Wow.” Moore’s Law has really helped us get to the point where a lot of the things that you needed, very custom-designed internal hardware architectures to do, can be matched largely by at least one or more virtual things instead.
It’s not just the growth there, because there are still large differences. I can still get a piece of hardware that a piece of software can never match. It’s more about the fact that, “Yes, but I don’t need all of that right away, and with virtualization, I can scale that. That’s that on-demand aspect. “I’m only going to have as many as I need at any one time, and I don’t have to worry about outstripping it eventually. I can just scale it up and down as much as I want, and it’s more efficient.”
I think the combination of efficiency and scale and the ease with which you can deploy these things has just made people go, “This is a much better model. This is what we want to use moving forward, because it makes more sense from a cost perspective, from a scale perspective, and from a management perspective.” It just makes things easier all around.
Jason: Yeah, and then it gets into the idea of this Lean IT, or if I’m going to address a bottleneck, maybe I’m looking at the process the wrong way. If I’m not really addressing bottlenecks and just delivering what’s needed at that particular point in the process of dev and test and delivering software to end customers.
If you look at it just as a commodity, or just as a technology, you’re going to have a problem eventually where you have some kind of inventory piling up, whether that’s hardware, or VM sprawl, or just excess capacity that you’re buying, and excess tooling that just isn’t required anymore.
Lori: Yeah, a lot of people that are still managing data centers were brought up to always oversubscribe everything, just in case. We have to unlearn, and learn a new way of doing it, to go back to the beginning of our discussion. We have to look at this differently. Otherwise, we’ll lose a lot of the benefits that we could be getting.
Noel: Lori, you mentioned still being able to get hardware that can do what software can do. What are some areas where physical systems still might have the upper hand in regard to performance, or security, or stability. And are those areas where we’re definitely seeing that upper hand shrink due to virtualization and Cloud Solutions?
Lori: I think, for the most part, you still see a lot of the core network is going to be hardware, not because it’s hardware, or because the hardware is ten times faster than you’d buy off the shelf, but because there’s an internal architecture.
We do crossbar architectures inside, and backplanes, and all sorts of interesting things inside of a network device that’s routing or switching. That’s very difficult to duplicate on a more general-purpose compu-platform. That means it’s going to get more bandwidth, more throughput, more port density, all these kinds of things. When you’re aggregating a big network, it’s really hard to do that with fifteen different pieces of hardware or fifteen different virtual things.
In the network, you’re still going to see a lot of that, not necessarily because there isn’t the power, but it’s an architectural issue. It’s just completely different. That happened in the late ’90s, when we figured out that we had to architect internally how things were switched and routed differently, because the traditional model just wasn’t keeping up, in and out, just not enough. We could not do that. It was just filling up too fast.
When you start moving into the network, and you start moving closer to the application, the closer you get, those kinds of solutions, even if they’re traditionally network solutions, are going virtual. It makes sense to do that because there is enough power to do that, and because of the application architectures and the whole model in which they’re deployed is going toward something that requires more flexibility, agility, rapidity.
It has to be fast. I have to be able to bring this up and down in a matter of hours, not take two weeks to order something and put it in place in a rack.
As you’re moving through that network, it’s getting very blurry in the middle, but closer to the application, all those things are going to be software, whether it’s caches, which were traditionally hardware, or load balancers we’re seeing moving toward completely software, all these kinds of things are going software.
They need to be very fast and very able to be in the cloud just as easily as they’re anyplace else, so that means they have to go software in order to fit that model and really be available for those applications.
Jason: Yeah. That’s part of what we do. There would be an F5 box in the network center, and then we would have virtual ones that our end customers might use all the way up until you get to that point. All of these sorts of models, you need a way to have a sandbox, or I used to always compare it to a wild west town that you walk into, and it’s just all of the fake buildings.
If you were to actually live there, you’d have to create a better scenario than that, but it’s just fine for when you’re trying to come up with ideas or innovate or deliver something quickly. We just need to decouple ourselves from depending on too much and then as we get closer to the real thing, making sure or validating as closely to that as we can.
Noel: Well, to try and start to wrap this up, are the two of you able to possibly see an end of the road for hardware at some point? Are you able to actually see an actual end to the physical reality, as we’re calling it, or are there going to be places where hardware is still going to be necessary in this field?
Lori: Well, I’ll divide it into two answers. The first one is, you always need to have hardware for resources, whether everything you’re doing is virtual or not. Even if it’s just like the whole data center floor is just like one giant circuit board, it just pops up like virtual things, that would be so awesome, but you’d still need some hardware. The resources have to come from somewhere.
The question becomes more, “Do you ever need to have custom silicone to do anything? Could we just envision a world in which everything is just running on whatever compute we could find, and it’s all virtual?” That’s possible. I think it really depends on the scale of what you’re doing and where you go. It would be interesting to get inside a very large data center or cloud and take a look and see what hardware is running where, and see what’s being used.
I think really what’s more important is not necessarily whether it’s using custom hardware here or there, but whether or not it is virtualized itself and is able to fit into that world where everything appears, at least, to be virtual, where basically, you don’t have to care whether it’s running on my hardware or Bob’s hardware. That world is definitely possible, and I think we’re going there, and I think we’re actually getting very close.
The more that we go and the further down the road into programmability and we’re using APIs, and DevOps here, and cloud, and all these things are this perfect storm of heading toward that world where nobody cares about the hardware. It’s all been abstracted up a layer so that all we’re dealing with are this virtual world, and that’s how we build everything. I think that’s where we will end up eventually.
Jason: Yeah, I think that’s a great perspective, Lori. I agree with that, and I think we’ll move more toward virtualizing processes or workflows or things that we’re trying to do, rather than the software itself, even.
Just like we have abstracted the hardware, I think software itself, or some of the development processes you could see being virtualized as well. Just like we do if we’re quickly cloning an entire environment that used to require you to do all this manual setup in scripting and batch scripts.
More of that complexity gets taken away from the developer, and then we’re going to expect them to think more in terms or innovating around what people are going to do with the technology.
Noel: Awesome. Then, just to give each of you a to talk about something that you’re currently working on or seeing in your own organizations—Is there something, Lori, that’s going on at F5 that’s impressing you the most these days?
Lori: Wow. I think the process and automation and orchestration, abstracting those kinds of things up, as Jason was just saying, pulling that up, doing more orchestration, building out platforms that are really virtualizing that aspect of doing all of this deployment and provisioning and configuration and management.
Even things like scheduling backups or maintenance windows or all these kinds of things that people have to do, nobody wants to talk about, that have to get done in order to move the business forward all the time, and being able to basically make those virtual, automate them, orchestrate them, have them running themselves.
Those kinds of things are very exciting and something that sounds weird coming from a company that’s doing services, but you’ve got to have some sort of management back there. It’s really more about orchestration and automation these days than it is just simple management and monitoring. That’s very exciting stuff.
Jason: That’s really cool. It’s hard to beat that! Since I am in a marketing role, I’m really enjoying how the discussion is advancing, getting to talk to people like Lori about this, and some of the other analysts in the space who are really seeing some interesting things happening.
It’s made it a big change from where we used to be, where we were talking about, “What’s this vendor going to do with this specific application suite,” where you could have thousands of people who basically were hanging on the next thing that particular vendor would say about their suite of applications.
Now you see the big democratization of this whole idea of what is enterprise software, and we’re still having to bring along what we had before, but what’s being developed now is a different generation, a different mindset. I think that’s what’s been exciting to me.
Noel: That’s great. Well, I think we actually managed to answer this heavily weighted question that we had at the very beginning, “Will virtualization in Cloud finally beat physical reality at its own application availability game?”
I think I can say that cloud will beat hardware—without eliminating it. Lori, like you were saying, there’s always going to be hardware, but then, Jason, like you were saying, we’re becoming less dependent on it for processes and management and monitoring.
We’ll be dependent on hardware to just stay on, to not overheat, as it’s performing all these things, but our dependency on these things to keep applications available will decrease as we shift that dependency and become reliant on virtualization.
That is all that I have today, and I really appreciate both of you taking part in this!
This was Lori MacVittie, the principal Technical Evangelist at F5, and Jason English, our galactic head of Product Marketing here at Skytap. Thank you both so much.
Jason: Thanks, Noel. Thanks, Lori.
Lori: Thanks, Noel. Thanks, Jason.
That’s going to wrap it up for the first ever episode of the Skytap DevHops Podcast! We hope you enjoyed the show, and if you have any topics that you’d like to hear discussed, or even any personalities you’d like to hear featured, let us know!