 From the SiliconANGLE Media office in Boston, Massachusetts, it's theCUBE. Now, here's your host, Stu Miniman. I'm Stu Miniman and you're watching theCUBE's Boston Area Studio. We're talking about storage and SDI essentials and of course, storage and infrastructure really are there for the data and the applications to help me dig into this. Rob Coventry and Steve Kenison, thank you so much gentlemen. Thanks Stu. Thanks Stu. All right, so yeah, when we talk about one of the only constant in the industry, Steve, you said one or other interviews is change. The role of all of this infrastructure stuff is to run your applications and of course the applications, the really critical piece of everything we're doing is the data. So Rob, maybe talk to us a little bit about your viewpoint, what you're hearing from customers and help set up this conversation. Well, one of the biggest changes that's going on these days is the move towards cloud. And I often kind of want to reset the definition of what we mean with when we say cloud because it means so many different things to so many different people. To me, cloud is all about not a place, not somewhere where you're running computing while it may have started out that way when Amazon launched AWS back in, what it was it, 02 or 03 or salesforce.com and when they were running everything in the cloud. But it's really evolved more to a style of computing, distinct and different from your traditional computing. It has certain attributes. Those attributes are what distinguish cloud computing from traditional computing, more than anything. And so basically now storage has got to evolve and support that just as like we did with virtualization. Yeah, absolutely, in the industry we spend so much time arguing over definitions and wait, hybrid, public, multi, composable, composite, everything like that. Well, when I talk to customers, most of them do have a cloud strategy, but number one is the ink's still drying on what that strategy is and the pieces that make up that strategy are definitely changing over time as they grow and mature. But they absolutely know that no matter where it is their data is one of the biggest assets that they have outside of people. And therefore how can they leverage how they can get more out of data. The whole wave of big data that we were well into in the next wave of like AI is all data at the center of it. Yeah, I think I like the way Rob kind of positioned this. We've talked about, you hear a lot of folks talk about cloud and a big part of what we're trying to do is have our sellers as well as the community understand that cloud isn't a place, right? It's a thing and you've kind of alluded to what I want to do, specific types of either development or programming or provide assets to the world whether it be data or whether it be things like websites or that sort of thing. It's got to live somewhere and where that lives is becoming more cloudy. Now whether that place is on prem or it's in a cloud or it's in a remote data center someplace at the end of the day the functions, right? That you want to be able to deliver on are behave in a cloud like behavior. And I think that's becoming more the trend of what people want. And really it's the consumption model of where it lives and how you pay for it is really the bigger part of how things evolve. Applications are changing a lot. I mean, you used to say, the era of shrinkwrap software is mostly over now. It's talking a lot about microservices now and when I'm building things, you mentioned functions which gets into functions of service and serverless whole new area that's changing. What's needed for this world to look at? Most customers have hundreds if not thousands of applications. Most of those aren't ready for that brave new world of cloud native. There's usually some stuff. So maybe Rob, give us a little bit of that spectrum and where are your customers and what are they doing. So look, I think we recognize that people have the vast majority of their infrastructures running or applications are running on traditional infrastructure, right? And so they've got a couple different choices. They've either got to modernize what they've got. And the modernization is, I was sharing with Steve last week, we're modernizing our house because we built the house back in 01, it was gold and oak. It was gold handles everywhere. And so now we're getting rid of all the gold. We're getting rid of painting all the gold and oak and repainting the whole house, right? So that's a modernization. It's not a complete refurbish remodel. That's what we would refer as refactoring, right? That's a much bigger heavy duty thing. And so businesses are going to have to look at those traditional applications and decide which of them should be just simply modernized and then adapted or modernized to work with and orchestrated with that bigger cloud-like environment and which of them need to be refactored to operate with the underlying cloud infrastructure, which by the way, expectation is it's completely virtualized, it's automated, it's policy driven, it's orchestrated, it's got all those types of cloudy like pay-on-demand types of characteristics that people learned and love from AWS and from Google, but now they're getting on-prem as well. Yeah, let me poke at one thing, because even you said virtualized, I think you don't mean just a hypervisor, but things like containerization, bare metals back, it's so funny what's old is new again. I remember it was like, we're going to go 100% virtual except for containers and everything else now. So now we've got lots of flexibility into how it's deployed and there's that modernizing the platform and modernizing the applications and sometimes you do one before the other. Great point. How are you doing it? Not everybody understands the distinction between containers and VMs, but the way I look at it, containers, one of the first things that they were really trying to attack is a more efficient way to do virtualization than what we had with VMs in the past, right? And one of the things that they learned is if they break those applications into smaller functional microservices, then they get another benefit and that is continuous development. That's critical to the flexibility and agility that the business needs to be able to constantly evolve those applications. And the third factor is what I call asynchronous scale. So each little function can consume however much memory, storage and compute that it needs independent of all the other functions in there. Whereas when it was operating as a monolithic application, the traditional approach, well, you kind of were stuck with however much the largest footprint was required. Now you get a lot more efficiency out of it. You get a lot more availability and you get continuous development. That's what you get out of containerization. And if you bring that up even one more step now, right? And I like to use this analogy when I'm presenting to clients and maybe this is helpful is if you look at our two, just take two of our product, we take Spectrum Protect, you take Spectrum Protect Plus, right? Spectrum Protect, 25 years in the industry, number two in the world, everything, right? Millions of lines of code, might even be tens of millions of lines of code. Anytime you have to do anything to that code like I want it to support X, all 10 million lines of code need to kind of make sure it's adaptable to that thing and needs to be able to lift and shift and you talked to, we were talking about agile development, which we do now, but you were also talking about the release trains and all that stuff, right? And what ends up going in and out versus look at Spectrum Protect Plus, built on an agile development, built on microservices. I want to put it in a service, I want to plug, I can just grab that service and plug it in pretty easily. I don't have to kind of drag all that code kicking and screaming so to speak along with it. But now I want to ask you a question, Stu, because I tend to think the analysts as well as kind of the thought leaders in any company that are trying to think about helping sellers sell and that sort of thing, we're about 12 to 18 months ahead of the customer. We have to be because we got to kind of see what's out there. What are you hearing around this containerization, refactoring, I think we have an opinion, it'd be interesting to hear an outside view of what you think is happening. Sure, Steve, and in the last few years I spent a lot of time going to the cloud shows, I go to KubeCon, going to my second year of doing serverless comps. So look, serverless functions as a service, we're still in the early adopter phase. Some cool startups out there. I'm excited, you've talked to real customers that are doing some cool things. But even I asked Andy Jassy of the CEO of AWS, he had made some comment, if we had said a couple of years ago, if Amazon was built today, it would be built on AWS and he had made this, if Amazon was built today, it would be built on like Lambda and serverless. And I was like, come on, really? He's like, well, no, I mean, what I mean is that's the direction we're going, but no, we're not there yet because we can't run one of the biggest global companies in the world on this yet. So look, we understand what can be done today and when we talk serverless containers, containers are doing phenomenal. We're now, containers have been around over a decade. Google's been talking for many years how many billions of containers they spin up and down, but I've talked to much smaller companies than the Googles and Yahoo's of the world that like containers are moving in that environment. I'm not sure we've completely crossed the chasm to the majority, but most people have heard of Docker. They're starting to play with these things. Companies like IBM and everyone else have lots of offerings that leverage and use containers because a lot of these things, it just gets baked in under the hood. When you talk to, you brought up virtualization. It's like, oh, it's, we watched this wave from the last 15 years of virtualization, it's just pervasive. We don't even think about, sure there's environments that aren't virtualized for certain reason if it's containers, but when you see Microsoft get up on stage and talk about how they've embraced Linux and a lot of the reason that they've embraced Linux is to do more with containers, that's there. So containerization is going strong, but when you talk to the spectrum of applications, yeah, we're still early because the long pole in the tent, at least customers like to, it's those applications. If I've been running a company for 20 years and I have my database that keeps everything running, making a change is really hard. If I'm a brand new application, oh, I'm doing some cool, no SQL, my SQL, cool applications. So it's a spectrum as you've said, as we've been talking about, Steve, but yeah, the progress is definitely happening faster than it ever has, but you take those applications, there's a lot of them that I need to either start with a lift and shift and then talk about refactoring things because making change in the application stuff. APIs we haven't talked about yet though. There's a critical piece into this is worry about, okay, we're just going to have API sprawl just like we have with every other thing in IT. I definitely want to get to API. One more, just one more piece of color. When you're at these conferences and the users are there listening to the folks, the one more piece of color is, do they have applications run the business? But it has to sit on top of something, so there's the infrastructure piece. What are the questions around refactoring and containerization that happen around infrastructures? I'm trying to think about how to get from A to B. What do I think about the underlying infrastructure or is that even a conversation? Because a lot of this stuff is cloud native, right? I mean, well, it can be cloud native. Yeah, and the nice thing about containers is it just lives on top of Linux, so if I've got skill set and I understand that, it's relatively easy to move up that way. Yeah, for a lot of the developers, when they say the nice thing, if I do containers, if I do Kubernetes, I really don't care, the answer is yes. Am I going to have stuff in my data center? Yeah, of course. Am I going to do stuff in the public cloud? Yes, and that's if I can have the same Linux image. We've been talking for years about how much of the stack do I need to make sure is the same both places to make it work, because that was always the last mile of okay, it's tested, my vendor said it's good, but I get it, okay, what about my application and my configuration and what I did? You know, when I use Salesforce, I don't need to worry about it. I can pull up on any device, well, the mobile's a little bit different than the browser, but for the most part, I'm anywhere in the world or I work for any company, it's relatively the same look and feel. So a little bit long answer on this, but when it comes to containers, what we've been trying to do and what I found really interesting is the Nirvana has always been, I don't want to worry about what's underneath the stack. And when I said, I mentioned the cool new thing, serverless. The reason for that is the business with containers gets that continuous development and continuous availability and scalability all in that infrastructure. The infrastructure enables that, right? So in my mind, the reason people want to do it is they know the speed of change in their business is never going to get any slower. And this platform enables that speed of change. So the one thing, those of us that live through the virtualization way. Virtualization, great. I don't need to worry about what server or how many servers or anything. Yeah, but the storage and networking stuff, oh, wait, that kind of all broke? And we spent a decade fixing that. And trust me, when containerization first went, I like three years ago went to a conference, somebody, it's like, it's so much faster than virtualization. It's this and this and this. And I got up, I'm like, hey, we've all got the wounds and, you know, you know, less hair now that we've gone through a decade fixing all of these issues. What about this? So, you know, Docker did a great service in the industry, helped make containers available broadly and have done a lot. I'd say networking is a little bit further along than storages. Most of the things, you know, we talk serverless, it's mostly stateless today when we talk containers. Okay, where's my repository on the side that I do things so, you know, state is still something we need to worry about. So, you know, yeah. That said, you know, we've made a big investment in our ability for our block storage and by the way, all of our file storage offerings to be able to work with both Kubernetes and OpenShift. So, you know, those are two of the predominant prevalent container-based systems out there. So I think that at least it gives kind of that ability to attach anything that needs persistence to our store. So what I'd love to get your perspective on because we talk about, boy, these changes that are happening on the infrastructure side. For a while it used to be, okay, business needs a new application. Let's go build a temple for it. So the business people says app and then infrastructure comes, team said in, okay, I got the building specs, give me a million bucks in 18 months and now I'll build it. Well today, you don't have as much money, you don't have as much time, but that relationship between infrastructure and application, they've got to be working so much closer. So how do they, you know, when I'm building this, who is that that builds it and how do they work even closer? We can talk about the infrastructure developer, I guess, too, because really this is the role that kind of is an evolution from what maybe was in the past, a storage administrator, right? It's somebody who is setting up a set of policies and templates and classes of storage that abstracts the physical from the logical so that the application developer who is going into Kubernetes or into OpenShift says, I need a class B usage for storage that has backed up and maybe replicated. Or I need a class C that is backup replicated and highly available. And the storage administrator in that case is setting up those templates and just simply making sure that he's monitoring all this so that when the additional demand comes, he just plugs it in and starts to continue to add more. Okay, so I've talked a lot to developers, I haven't went across infrastructure developer before as a term, so where do they come from? What's their skill set? Maybe help flesh that out a little bit. Go ahead. I was just saying, I think in a number of customer presentations I've given over the course of this last year, it's come up a number of times. So I think, granted in the larger companies, and it typically comes across in a chart that shows not the number of people are changing, but the skill set and the different organizations I have are changing. So today where I spend a lot of time doing administration, five years from now, I'm not going to be doing that much administration. So what I want are capabilities, well, first of all, I need to program the infrastructure so that it's programmatic to either the application, connect through APIs. So maybe I have a chef or puppet doing DevOps. But when I make that call as a developer in the company to chef or puppet because I want this, to Rob's point, everything underneath that. It's orchestrated underneath it. There's a set of policies that are set that says, this is how much compute, how much network, what kind of storage you're going to get. That's the infrastructure developer who set using APIs that are in the infrastructure and at the higher level platforms like Kubernetes and OpenShift that basically allow that developer that just says, I need some of that, I need some of that. The experience is not a lot different than what they get with Amazon Web Services or Google App Server. It's a similar kind of experience, but you can do this on-premises now. Yeah, and yeah, it's very similar, as you said, and it makes a lot of sense to me because for sure, chef, puppet, Ansible been hearing lots of people talking. That's the people. It's like, you're not configuring LUNs anymore. I don't need to do all the old masking and all the configurations. The network people, it's like, no, you've got a different job and it shifted. That whole vision of infrastructure as code is starting to come to fruition. And we talk a lot, or at least I do, right around IT and technology and infrastructure is made up of three things. People, process, and technology. And the people are evolving just as fast as the infrastructure needs to evolve, right? So tomorrow, I want to be building a programmatic infrastructure today so that my people can be focused on, like you said, where is the future? I don't know, but I constantly need to be thinking like the analysts think. I need to be 12 to 18 months ahead of the company so that I can continuously evolve that infrastructure and help them get there. But I don't disrupt the flow of the people that need access to the data or the applications or that sort of thing, right? It's got to be constant, right? And that's how that skill set is changing. Okay, so what's that infrastructure developer's role in helping with the app modernization? How do I figure out, what do I just build new? What do I move over? How do I start pulling things apart? Yeah, I think it definitely starts by looking at the different applications that they have. I think you made a good example where, okay, so now I want to modernize as much as I can and now I want to start drilling into by taking a break, gaining some knowledge and some insights about containerization and APIs and that sort of thing and figuring out which applications in my stack today I can refactor, which makes sense to build out of microservices, refactor into microservices and that sort of thing. Start doing that, get that done and then start looking at ahead of that, what's next, right? So getting that infrastructure programmed and plumbed ready so that anyone who needs to access it can, so it's more hands off. Think of the younger generation coming into technology today, right? I want to use my iPhone, I want to do this. I want that piece of storage. I want it to be a click of a button. I, as an infrastructure developer, need to help set that up and make that happen so that as we move forward, I'm doing other net new things. Would you agree? Absolutely, absolutely. So at the end of the day, those guys are basically taking advantage of those large pool of services, whether it be storage, networking or computing, creating APIs or leveraging APIs in that infrastructure and wiring it up so that the end user developers can go and access them at will without waiting. Yeah, last thing I want to ask in this segment is, you know, change is tough and when you look at my application portfolio, it could be a little bit daunting. So what sort of things that they be doing to make sure that they're ready for the modernization, the transformation, to get along that journey a little bit faster? Well, the first thing is, is that you've got to have a software-defined infrastructure to be able to do any of this. And basically what that software-defined infrastructure has is has a number of attributes, the first of which is an actual separation between the physical and the software. It has policies. It has the ability to APIs that allow you to control that, that you're either through command line interfaces or rest interfaces such that it can be orchestrated and then you take advantage of all those policies such that you can automate it, monitor it and manage it centrally. That is the base definition of software-defined infrastructure and we've had it with CPUs for a long time. We've had it with networking. People have been doing network separation of software and hardware and it's really IBM that is unique in this business that has a set of software-defined capabilities that I think is different than the rest of the marketplace. Yeah, I mentioned earlier, but I think I'll close on it too, is lots of customers has got to modernize the platform and that really sets you up to be able to modernize the applications on top. That's right. All right. Rob and Steve, thanks so much for joining us. Thank you. So helping us walk through the data and the applications. Thanks, Stu. All right, thank you so much. I'm Stu Miniman and appreciate you watching theCUBE.