>> From the Silicon Angle 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, where we're talking about storage, and SDI essentials. And of course, storage, and infrastructure, really are there for the data in the application. To help me dig into this, Rob Coventry, and Steve Kenniston, thank you so much, gentlemen. >> Thanks, Stu. >> Alright, so, yeah, when we talk about one of the only constant in the industry, Steve, you said in one of our other interviews, is change. The role of all of this infrastructure stuff is to run your applications, and of course the application's, you know, 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, 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 kinda want to reset the definition of what we mean with, when we say cloud, 'cause 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 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 gotta evolve, and support that, just as like we did with virtualization. >> Yeah, absolutely. You know, when we did it, in the industry, we spent so much time arguing over definitions, and we went, "Hybrid, public, multi, composable, "composite, everything like that." Well, you know, 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 can they get more out of data? The whole wave of big data that we were well into, and the next wave of AI, is all data at the center of it. >> Yeah, I think, I like the way Rob kind of positioned this. We've, we talked about, you hear a lot of folks talk about cloud. You know, 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'd be data, or whether it'd 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 that you want to be able to deliver on, 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. >> Yeah, applications are changing a lot. You used to say, the era of shrink-wrapped software is mostly over now. It's, talk a lot about microservices now, and when I'm building things, you mention functions, which catch into functions, and services, and serverless. You know, a whole new area that's changing. What's needed for this world, you look at it, you've got, you know, 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 on that spectrum, and where your customers... >> 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, you know, it, I was sharing with Steve last week, you know, we're modernizing our house, because we built the house back in '01, it was golden oak, it was gold handles everywhere, and so now we're getting rid of all the gold, we're painting all the golden 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, 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 that it's completely virtualized, it's automated, it's policy-driven, it's orchestrated, it's got all those types of cloudy-like, you know, 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, and let me poke at one thing, because you said, you know, virtualized, and I think you don't mean just a hyper-visor, but we have things like containerization, you know, bare metal's back, you know, it's so funny, what's old is new again. Remember, it was like, "Oh, we're gonna 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, depending on how you're doing it. >> Great point. I mean, not everybody understands the distinction, right, between containers and VMs, right. 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 were kinda 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, just take two of our product. We'd take Spectrum Protect if you take Spectrum Protect Plus, right. Spectrum Protect, you know, 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. Any time you have to do anything to that code, like I want it to support X, all ten million lines of code need to kinda make sure it's adaptable to that thing, and it needs to be able to lift and shift. And 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 in a service, 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, um, now I want to ask you a question, Stu. Because I tend to think the analysts, as well as kinda 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 gotta kinda 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 CubeCon, going to my second year of doing serverless comps, so, look, yeah, serverless functions, as a service, we're still in the early adopter phase. Some cool startups out there, I'm excited to talk to real customers that are doing some cool things. But even I asked Andy Jassy if, you know, the CEO of AWS, he had made some comment, you know, if we had said a couple 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 Lambda 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 on this yet." So, look, we understand, what could be done today, and what can't, when we talk servers? Containers, containers are doing phenomenal, we're now, containers have been around over a decade, you know, Google's been talking for many years of how many billions of containers they spin up and down. But, I've talked to much smaller companies than, you know, the Googles and Yahoos 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. You know, 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 talked to, you brought up virtualization, it's like, oh. It's, you know, we watched this wave from the last 15 years of virtualization, it's just for basic, we don't even think about, sure there's environments that aren't virtualized for a certain reason, if it's containers. But, you know, when you've seen 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're talking of 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, you know, no sequel, my sequel, you know, cool applications. So, it's a spectrum as we've been talking about, Steve, but, um, 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's tough. APIs, we haven't talked about yet, though, is a critical piece into this. As worry about, okay, we're just gonna have API sprawl just like we have with every other thing in IT. >> I definitely want to get to API, but one more, just one more piece of color. When you're at these conferences, and the users are there, listening to the folks, but 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 infrastructure? I'm trying to 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 the stuff is cloud-native, right, I mean, or can be cloud-native. >> Yeah, and the nice thing about containers is, it just lives on top of Linux, so, you know, if I've got the skillset, 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 gonna have stuff in my data center, yeah, of course. Am I gonna 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 an okay, what about my application, "my configuration, and what I did?" When I use Salesforce, I don't need to worry about it. I can pull up on any device, well, the mobile is 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's 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 gonna get any slower. And this platform enables that speed of change. >> So, the one thing, those of us that live through the virtualization wave, 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 had, like three years ago, went into a conference, someone is like, "It's so much faster than virtualization, "it's this and this and this." And I got off, I'm like, "Hey, uh, "we've all got the wounds, and, y'know. "You know, less hair, now that we've gone through a decade "fixing all of these issues, what about this?" Docker did a great service to 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 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, state is still something we need to worry about. >> That said, you know we've made a big investment in our ability for a block storage, and by the way, all of our file storage offerings, to be able to work with both Kubernetes and OpenShift, so, those are two of the predominant, prevalent container-based systems out there. So, I think that, at least it gives that ability to attach anything that needs persistence to our storage. >> 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 the infrastructure comes, team's set in, okay, I've got the building specs, give me a million bucks and 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 gotta 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? >> Well, that's this, 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 OpenShifts, 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 run across an 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 for me. >> I was gonna say, 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, and granted in a larger companies. And it typically comes across in a chart that shows, not the number of people are changing, but the skillset in 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 gonna be doing that much administration. So, what I want are capabilities, well, first of all I need to program the infrastructure, so that it is programmatic, to either the application, connect through API so maybe I have a chef or puppet doing dev-ops, 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 there. 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 gonna get. That's the infrastructure developer, who sent, 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, it's very similar, as you said, and it makes a lot of sense to me. Because, for sure, chef puppet, been hearing lots of people talk, 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's 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's made up of three things. People, process, and technology. And the people are evolving just as fast as the infrastructure needs to evolve. 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. It's gotta be constant, and that's how that skillset is changing. >> Okay, so, is that, what's that infrastructure developer's role in helping with the app modernization? How do I figure out, you know, 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 of sort of thing, and figuring out which applications in my stack today, I can refactor, which makes sense to build out of microservices, you know, 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? 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 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 I look at my application portfolio, it can be a little bit daunting, so what sort of things should 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 gotta have a software to find infrastructure to be able to do any of this. And basically what that software to find 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 are either through command-line interfaces or rust interfaces, such that it can be orchestrated, and then you take advantage of all those all 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-defining capabilities that I think is different than the rest of the marketplace. >> Yeah, I mentioned it earlier, but I think I'll close on it too, is, you know, lots of customers, gotta modernize the platform, and that really sets you up to be able to modernize the application. Alright, Rob and Steve, thanks so much for joining us, helping us walk through the data, and the applications. Alright, thank you so much, I'm Stu Miniman, and, appreciate you watching theCUBE.

>> From the SiliconANGLE media office in Boston, Massachusetts, it's theCUBE! Now, here's your host, Stu Miniman! >> Hi, I'm Stu Miniman, and you're watching theCUBE here in our Boston area studio. We're gonna be talking about storage and SDI essentials. Happy to welcome back to the program Randy Arsenault and welcome to the program for the first time Rob Coventry. Gentlemen, thanks so much for joining us. >> Thank you. >> So, on theCUBE, we've been documenting it, so many shows and so many interviews, digital transformation, how everyone's going through various changes in the industry, and we're gonna do a series of interviews here from our studio talking about what IBM's doing about transformation and enablement. So why don't we start there? Randy, we'll start with you. We've discussed many of these things with you. You're back to IBM, so give us what brought you back and what's changing at Big Blue. >> Yeah, thanks Stu, it's great to be back. So it's been an interesting, so, I came back late last year, December last year, so I've had an opportunity to kind of come into this process that Rob and his team have been working on for a while, so I kinda got dropped in midstream and it gave me sort of an interesting perspective on how things have changed, first of all, so there's been a fairly significant change in the way products are brought to market, the way we message, the way we communicate, the way we enable our sellers and partners, so it's been really interesting to kind of dive right in and get right into the meat of it. And I think Rob and his team have done a really good job of building a programmatic and systematic approach to delivering enablement and education to our sellers and our partners. So there's a whole process, a formalized process, around how we create it, how we deliver it. I'll let Rob expand on that a little bit, but from my perspective, it's been interesting to be able to participate right from the beginning in kind of adding an outside end view since I'm sort of coming at it with fresh eyes. So I think it's been a really good collaboration, working with the two teams coming together. So, the process, I think Rob and his team, again, have really perfected the engine that we use to produce these things. >> Yeah. Rob, love to get your viewpoint. I mean, industry watchers, I think back to even when I did my MBA, or when I worked on the vendor side, and as I've been an analyst, IBM's one of the companies that breaks the rules as to everything changes all the time, you have companies come and go. Living here in Massachusetts, we've seen lots of brands come and go. IBM's stalwart in the industry, so give us a little insight as to what you're working on. >> So yeah, IBM is the survivor in that dinosaur game that we seem to manage to evolve constantly. The evolution is an important aspect of it, and so one of the things that we did about a year and a half ago is we evolved our sales force and storage. We went from several different discrete roles to a single storage sales role. We knew what we had to do in that regard is to bring everybody up to speed to at least a minimum level in order to sell our entire portfolio, and what its strengths bring to the table, instead of just the product they were familiar with, that they were comfortable with, and that they had success with in the past. So one of the things that we did was, we kinda observed, how did we do transformation or education in the past? And it was predominately what I call a bottoms-up approach. Have a product, it solves a set of problems, here's how to do it, here's how to sell it, here's what it does, here's how it competes, works great in the industry. When you've got a large number of products, you cannot educate people in the right amount of time following that bottoms-up because by the time that you learn it, we'll have moved on the the next set of products and our competitors will outpace us. So what did was we said, let's take a tops-down approach and ask the question, what kind of conversations do our customers wanna have that lead into the various solutions that we're trying to sell, that'll give you an opportunity to have some credibility, solve the problems on your way in, and let the conversation dictate which product it is. So we created a set of five conversation that focused on things like dev ops, modernization, resiliency, life cycle management, you know, the kind of things that every IT department does, and then go from there, and it's worked pretty well. But one of the things that we observed was, we assumed a certain base knowledge when we put that enablement together, and we realized there's a set of terms that I think that they're lacking that we need to help them with. >> Yeah, so that was kinda my first project when I came back, was getting involved in the creation of these kinda streams and assets for this education in January, and it was delivered and it was successful and it was fairly detailed and pretty explicit, but it introduced a lot of terminology that we sort of presumed people were already familiar with, and we found out that wasn't necessarily always the case. So the real goal of this session or this series, is to kinda set the stage a little bit so we almost think of this as kind of a prequel, like this is really meant to functionally proceed what we did in January, so the goal is that once this is put together, folks will be able to go through this and then go reconsume or reintroduce themselves to the January content, and have a much better sense for what the terminology is. Hopefully we can demystify some of the buzzwords and some of the industry lingo that they're hearing from clients, and really provide a better framework in which to have the conversations that Robert was talking about. >> Yeah, it's fascinating. We talk sometimes the analogies we use is, right, are you talking in the right language? For me, I think food comes to mind. It's like okay, if I go to a foreign country and even if I don't speak the language, they can point me towards, here's the meat, here's the fish, here's the vegetable, and then I kinda know what I'd like, but it's kinda nice if you know, okay, well, Portuguese food, I'm kinda going to be looking at this, so getting some of the basic down to an understand and then participate and get deeper involved. >> And the other challenge is that a lot of the terminology that we use has become very commoditized, right? The words that every vendor in our space uses and uses and overuses, things like agility and transformation and modernization and refactoring and containerization, these are all terms that our sellers and our clients and our partners see a million times every day. So not only do we need to understand that a fairly baseline foundational level, what do those actually mean, but what do they mean specifically in the context of our solution portfolios? So as we go talk to clients, we can now translate from the very abstract sort of idea of refactoring, for instance, into a specific set of best practices and solutions that our clients can capitalize upon and use to achieve that goal. >> Rob, I have to think that we've seen this transformation from the customers too. IT is not this silo that just waits for the business to come, and well now, I can't do that, or it'll take me six months. No, IT needs to be with the business, driving the business, so your sellers need to be aligned with that and helping, is we're all in this journey together. >> No doubt about it. In fact, one of our primary goals here is the give the sellers context of, I call it the explain the hard candy shell that IT needs to look like, and don't worry about how everything inside of it works. The business looks at IT as that hard candy shell. They just wanna consume simple things like flexibility and agility, so that they can turn around and deliver the business that they need to deliver in the very competitive world that they live in, and we need to explain IT in all these terms in the context from the businessperson's perspective, and from that, then I think what it'll do is help them better use that in the context of their sales efforts. >> Yeah, and a lot of this is being driven by, so IBM every year does a sea level global survey, which is a pretty big deal for the company. So this year, 2018, first one was published recently, with a population of almost 13,000 sea level clients from around the world, so this is a pretty robust piece of research, and a lot of the findings, probably not surprisingly this year, are focused on these concepts of agility, these concepts of rapid prototyping. There's three very specific best practices that are called out: interrogate your environment, so constantly be on the lookout for opportunities, changes, threats, both from a business outside-in perspective, and also from an IT perspective in support of the business goals. Commit with frequency, so constantly be evaluating where you're investing, how you're prioritizing, where you're focusing your scarce IT resources. And experiment deliberately, so do lots of pilot programs, lots of prototypes. Introduce things like dev ops and rapid development, which by the way, IBM has done, so one of the interesting things that's changed since I was here last time is internally within the spectrum portfolio, we now have a fully agile workflow, which is one of the reasons why the portfolio was so dramatically transformed over the last five years that I was elsewhere. So I find it interesting that we're litting it internally, but we're also able to communicate that to the outside world as well. >> Excellent, I'll take a large box of ready for the future. I have no idea what it will be, and I can't ask you for for it, but I'll take three. >> Alright. >> You know, you might say that if you're a big company, but we recognize that some of the sounds very big, very large enterprise, and it may not apply to somebody that's small, and one of the things that I observed in this CXO study is I think it's applicable to no matter who you are, in the value chain of some of these very large companies, because there's a recognition that you have to operate in that orchestrated world that works with the supply chain that you're part of, and if you don't continually reinvent, continually evolve your IT to enable your business to keep pace with the expectations of that orchestrated business, then you're not going to be relevant in the future either. So we think that there's applicability here whether you're a large company or you're a small company, and one of the things that we're gonna try to do here is try to help our sellers understand that. >> Absolutely, great point is no matter whether you're big or small, everybody is being affected by a lot of these-- >> That's right. >> Stressors, it's just order of magnitude for some of them. Alright, Randy and Rob, thank you so much for helping us kick off the series. >> The best, thanks Stu. >> Looking forward into digging into much more of it. >> Thank you Stu, I appreciate it. >> Alright, and I'm Stu Miniman, thanks so much for watching theCUBE.