What exactly is software-defined - CTO039

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to episode 39 of the CTO Advisor Chats. Exciting times, I got two good friends, both Josh Atwell and Mark May. We're gonna talk a little software-defined data center and recap a conversation we had during Interop in which Josh really challenged both me, Mark, Rolison and Jack Pola to really think through the definition of software-defined. We're gonna try and recapture some of that magic. First off, Josh, can you go ahead and introduce yourself? Hi, thanks Keith for having me on.

My name is Josh Atwell. I'm a developer advocate for SolidFire and I like to stir the pot. The pot was stirred. And Mark, can you go ahead and introduce yourself? Sure, I'm Mark May. I'm kind of a storage and infrastructure guy. I do lots of stuff for lots of people. All right, and some of it you will do anonymously, I heard. Sometimes, yes. All right, so it went really well because we had Josh leading the conversation and challenging us.

So we're gonna take that format. I'm gonna step back as the moderator and I'm gonna let Josh moderate the conversation. So Josh, take it away. Thanks, Keith. So it's challenging to recreate the scenario that we had because we did have this opportunity where we were together and we could really feed off one another. But the premise was, and it's a frustration that I have, how do you define what is software defined? We went through this with cloud and I think a lot of that has settled out from the marketing hive to what the reality is and what the new reality is.

And everybody likes to talk about, this is software defined and that is software defined. And in my mind, it is not. However, without leading the witness, Keith, what would you define as software defined? I'm gonna give my original definition and we'll work through the conversation. Basically, I said, software defined is when you have an API to, specifically, we're talking about the data center. I was saying a API to the data center. Yeah, a generalized abstraction of the underlying components I think is kind of where we went first.

Yep, so that's kind of where we started. Jack, he's not able to be on, but one of the things that he had mentioned was that when the infrastructure is code, it doesn't matter about the hardware, it's just software and the software can be anywhere. And my counter to that is, how is that different than the Windows operating system? Because the Windows operating system is hardware agnostic. And from my mind, when we talked about this topic, simply because something is software and it performs infrastructure tasks and it can reside on any hardware and it's indifferent as to whether it's appliance or white box does not necessarily make it software defined.

That makes it hardware agnostic, right? The software is a critical component, but that isn't necessarily something wholly unique and new and interesting and fundamentally changing the way that we operate our data centers. So how can software defined be the same as Microsoft operating system? Yeah, I struggled with that question because I thought it was a great question. I think one of the things I looked at, I initially gave my API to the data center. You said, that was a kind of a weak definition, go forward, then we evolved to marks, an extraction of the data center.

And then you, as you repeat it now, said that Windows is an extraction. So how's Windows different from software defined or is Windows software defined? And I guess we can rehash some of this conversation. It's a software defined is one of those things that when I want to use software or policy to define intent of my object or my data center, whether it's software defined storage, software defined computer, software defined networking, the ideal is to be able to use policy to define the intended configuration or the behavior of the resource that we're defining.

Everything's software defined. And that's a problem because everything is software. It doesn't exist without software. So how do we really narrow that marketing definition and get to the meat of what it actually is? Yeah, I'm with you 100%. When I look at this particular topic, software exists on everything that we run. You don't have a network switch without software on it in order to operate. And the uniqueness that becomes software defined is when we have an opportunity for the environment, the infrastructure to be programmed with policy and rules and capabilities even under certain situations.

So when we think about routing a traffic between data centers or between the cloud, when we think about the economies of certain paths based on geography or based on how much the provider is charging and based on traffic flow, being able to identify these changes in an active environment and be able to modify the path that an application takes or the behavior in the environment based on policy that has been created by humans who know what's going on and the environment through software to be able to define what that infrastructure is going to do in order to accommodate that changing need.

In my mind, that is what we are all trying to aim for. It's not just that we create software and it does cool things. It's that the software now has the ability to do things that humans would typically need to interfere and get involved or intervene, I think, and get involved or that's no longer being the case. So I guess we're getting a little bit closer to both the problem statement and kind of the definition of software-defined. And I really liked your example of network hardware.

One of the things that from the networking side we pound on and throw stuff into all the time is BGP. So why isn't BGP software-defined? It is software and it reacts to the state of links and some other stuff. What's missing from BGP to make it software-defined? I think it needs to be more dynamic, right? It can't just be set your rules and set your policies and then adjust them when you need to because you add a new link. It needs to grow and kind of make some of those decisions based upon some overarching goals that you've given it.

I think that's kind of where we start to see the difference with BGP, especially. So I guess, especially the networking guys might argue that BGP is really great. And at what point, at what type of decisions need to be included before it's software-defined? So, you know, is it link? Is it business decisions? Is it application decisions? Because not every product that has the software-defined label has those attributes or addresses those dynamic elements. Yeah, I think in my mind and the examples that I use when I talk about this, it really comes back to how the infrastructure behaves based on feedback that it receives.

So regardless of the product, regardless of the technology that we wanna lay a stamp on of software-defined, if it can't take feedback and then leverage that feedback in order to make changes to the environment and how things are structured and framed out, then it becomes a stretch in my mind for software-defined. I mean, I think that is the simplest thing. And another example you could use that I think is really interesting that even in and of itself is almost a stretch. Look at something like DRS and vSphere, you know, Distributed Resource Scheduler.

This is software that it's a small component of vSphere, yet in my mind, it's critically interesting in that it behaves when situations present itself that it has to make a decision. And it makes that decision and it executes based on feedback from the environment, whether it's an application that is running amok and things need to be rebalanced or placement is being made and the end user doesn't care where it goes. So it reaches out to the environment, looks at the environment, analyzes the environment, identifies through algorithms that are provided how the environment should behave.

Now, I think that is a very base and cursory example because even then, you know, there's this scenario where you could say, well, you know, if it's really truly software defined, it could recognize that a network may not exist in a place that would be ideal and therefore it creates the network and connects the network using NSX or some technology and then it can redistribute the workload to that location based on that. Now, then you start getting into what I think the true reality of software defined needs to be in that definition.

Well, and that's where BGP, I think, is interesting because it's not too far away from some of those things. It's already abstracting to the physical and virtual topologies. And that's why I think Juniper, they have a product where they're actually using BGP as part of its network virtualization stack. So Keith, I think your example is kind of flawed mostly because you picked BGP. No, but I think it's a great pain point because networking guys in the SDN thing with the networking guys, if you listen to packet pushers, this is like one of the most frustrating conversations for them because they've been striving for a lot of these concepts using protocols in the past.

So I think one of the things I wanted to edge on is the point that, to Josh's point, software defined isn't one thing. It isn't one system. It's kind of the, it's an architecture and it's a system design that you aim for based on those business drivers. And I think it would, I think, help bring home this conversation if we talk through kind of what's the business drivers of software defined? Why should engineers even be concerned with software defined? Yeah, I mean, I think the business drivers are really to simplify operations and reduce complexity.

Make things simpler, make things faster, make things easier. It's kind of what we're always trying to do when we do anything. And I think that's done via computer science, via abstraction. We abstract everything in computer science, from having to have to address memory directly years ago to having virtual memory, from having physical machines to having virtual machines. We love extraction in computer science to make things simpler. So what we're talking about is the ability to take the data center or even these subsystems and abstract them to a point where we're making things simpler and easier to interface with and manage.

Well, you know, I would take it even a step beyond that. I think what we're really truly trying to do at this point is being able to have the environment adapt and take care of known scenarios, situations that we know could arise, what that situation looks like and what the outcome should be, right? And this isn't artificial intelligence, right? This still requires the intelligence and the skill of a person in that discipline who understands that technology and what that situation should be and what the end result should be.

I think the difference is that now what we do, when you talk about drivers, if you're looking at balancing out based on the most efficient storage or the most efficient networking path or whatever it is that drives or reduces the cost or drives value, if we know that we can deploy out faster in this cluster versus that for this application development cycle, then we've deployed to that and nobody knows that that choice was made unless they look at the logs, right? Or to look where they were placed because it doesn't matter to them.

They don't care, right? The software has taken care of that. You know, another example I use on this is when you look at NSX and you look at virus detection, right? NSX has the ability with virus scanning software where if a virus is identified, that virtual machine can be tagged. NSX can see that tag, know that that is a machine that may be compromised and it can isolate it while the antivirus software goes in, cleans up the machine or deems that the machine can't be cleaned and determines that it should just continue to be isolated and destroyed because nuking the site from orbit is the only way to be sure, right?

And all of that can take place before a human is even aware that anything has happened, right? And it touches multiple layers and multiple components and I just, I think that is where we start seeing, you know, that the business needs and the environment needs, you know, to have that capacity. That is real, the tipping point where you get beyond marketing and like this is what the reality should be. So there, I guess here's the question, is there any validity in the software definedness of individual subsystems?

So when someone says, you know what, this is a software defined storage solution, this is a software defined networking solution, it doesn't sound like we're coming to the conclusion that that's the objective. The objective is to software define the infrastructure and however that's made up, the, and however that's interfaced, mainly through API software or whatever, the ideal is to extract away the complexity of what's consuming the data center. And that's via, and what that ends up being is all those things you said, Josh, which is the simplification and the low level activities of creating lawns, creating VLANs, going into a CLE, doing this stuff, all that stuff is automated away in the true value add stuff, the creation of applications, the setting of policy, all that is done by human.

Yeah, and I don't think we're, you know, we're not gonna get away from having humans engaged, right? Because the humans know what the business needs, humans know what the drivers are, the humans know what the guardrails should be, you know, and the interesting thing that I still hear frequently is like the strong desire for nerd knobs, right? We wanna have the knobs and we wanna be able to tweak and we wanna change this and that. And I think that what we're seeing is right now we're seeing this growth and evolution of software capabilities, as well as, you know, as a part of that, a simplification of how resources get consumed and how resources are delivered and utilized to the point where a lot of that stuff is less enticing, less necessary.

You know, we're always gonna have applications that have special needs and they're gonna need that manipulation and that high touch. But when you look at a lot of the products that are out there that talk about being software defined, you know, I still have trouble saying like, well, just because it only, you know, it can only, you know, it can exist only in software, if you will, and cares not about the hardware. I still question whether or not that is getting us to that realization, like that is truly software defined.

And I look at things like ACI and NSX, for instance, where, you know, they're software, right? They just kind of sit out there and they can be deployed in virtual machines. You know, I don't think that's the part that makes it software defined, right? Yeah, I like your point. It's a lot about getting rid of nerd knobs. And as much as we all like a good nerd knob, I think IT fundamentally, especially infrastructure, we're changing to adapt more to provide value, you know, to provide value to our customers, to our enterprise, to whoever our end user is.

So I think that's one of the biggest drivers. We have to learn to provide value and stop worrying about nerd knobs. And that's the real driver for software defined, ease of use, automation, and action. All right, so on that note, I think we'll close out the conversation and get back to Game of Thrones. But, so let's close out with closing comments. Where can folks find each one of you guys on the web? Oh, you can find me on the Twitters mostly at SensiStorage, you can find all my links there on my nice little robot dude profile.

And you can find me at Josh underscore Atwell on the Twitters, and that's the best place to find me. In fact, even, you know, my manager and other people know that that's the best way to get in touch with me. All right, and of course, you can find me at CTO Advisor on the Twitters. com. Rate us on iTunes, share us with your friends, get back to your TVs. Hopefully they have nerd knobs so you can rewind them to see Game of Thrones.

Thanks a lot, guys.