 From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hey, welcome back everybody. Jeff Frick here with theCUBE, coming to you from our Palo Alto Studios today for a CUBE Conversation. I'm really excited to have our next guest on. You see him all over on social, very active community member. And we haven't had him on for a little while, so I'm psyched to have him on. He's Bobby Allen. He is a tech and cloud evangelist. Bobby, how you doing? I'm good, Jeff. How are you? Good. So I've just had the obligatory check-in, so you're getting through this madness of COVID and family's good, everything's good. Yep, everybody's good. I've got a teen and a tween. They haven't driven us crazy yet. So, so far everybody's healthy and everybody's good. Good, good. So let's jump into it, Bobby. People talk about cloud as being, there's a lot of great benefits to cloud, kind of cost savings and agility and more importantly really as a driver of innovation, which I think most people are kind of late to the party there. They think really more on cost savings versus innovation. But now it's been around, you know, AWS has been around kind of, kind of broke open the door in terms of public cloud and then there was everything as a public cloud and not goes a public cloud. And then we have hybrid cloud and we have multi-cloud and now things are kind of settling down. So when you talk to people about cloud, how should they think about the reality of it once they kind of leave the trade show and they're getting back to their desk and they actually have to start implementing some things. So, great question, Jeff, first of all, thank you for giving me that opportunity to answer that. This is how I think about cloud. So we often talk about cloud in terms of gym memberships, right? Like going to the cloud is like buying a gym membership. I actually argue that the cloud is actually more like weights. If you apply weights to good form, you're going to get stronger. If you apply weights to bad form, you're going to hurt yourself. And what we found is that a lot of these companies, Jeff, are applying cloud and automation to things that really didn't make a lot of sense. And so they're wasting more money. They're getting more frustrated and they're wondering why cloud was not this magic bullet that just solved everything. It didn't fix world peace and global hunger and now they're worse off than they were before. There are a couple of reasons I can go into about that but hopefully that answers the question at first. We're training the wrong way, Jeff. We're adding weight to things that don't make sense and will hurt ourselves. So is it just they pick the wrong application or are they operating it in a way as they operated it when it was on-prem? Because the thing I always think of, which is interesting, right, is everybody always talks about spinning up capacity, right? Spin up capacity, you're running a promotion on the Super Bowl and you're going to have a bunch of people hitting your coupon, but they never talk about spinning it down. And I went to a really interesting presentation one time where a guy talked about their application. He's like, we like when you turn it off. When you turn off our application, we're not making any money, but it tells that you know kind of how to operate this thing which is turn it on, but don't forget to turn it off. And I think, you know, we had a situation on one of our little applications that we left open and let something run and ended up with a bill that we weren't necessarily anticipating, not because we did anything wrong, but we just didn't do the right thing, which was to turn off that particular service when we didn't need it. So what's the wrong weight, what's the wrong exercise? Why are people screwing this up? So I think the problem, Jeff, is actually more upstream. So my personal mantra for 2020 has been, tech is the easy part, data and behavior are the hard parts. And I think you nailed it, right? If cloud is only about what you need to buy, not what you need to change, then you're going to be woefully disappointed with the results. And so when I'm saying go upstream, what I'm finding is, missed expectations, Jeff, sink more projects than bad code broken APIs or large bills. The thing that we're missing is, we're thinking that technology replaces the need to have a conversation. So for example, when we say we want to do something better in the cloud, what does better actually mean? So let's talk about food for a second. Hopefully I don't make your people hungry because it's around lunchtime. But if we think about cloud applications like a recipe, are we trying to make a mediocre recipe better or make a good recipe at scale, right? Because if you take a nasty recipe and scale it out, you're just going to go broke faster. So really the question is, which problem are we trying to solve? What is the issue that we're really wrestling with? And so we need to have a better vocabulary, more descriptive conversations. And so let me give you one that I often talk to customers about, right? We talk about technical debt a lot of times. And technical debt, Jeff, in my opinion, is being used as a misnomer. So there are kind of different sorts of debt that I see often in the C-suite. So there's technical debt where I don't like what we're running. There's data debt where I don't know what we're running and there's brain debt where I don't know what we want. And Jeff, I would argue that a lot of things that are masquerading is technical debt in the C-suite are really brain debt. I haven't figured out what we want to do. I haven't thought about what we're willing and able to change. And so that's why the cloud is a disappointment because we haven't figured out what we want for lunch. So it's a classic, like people process technology program, you know, problem. And we hear about it all the time, right? And everyone loves to focus on the technology. I haven't heard it really explained that well but that's what you're saying. It's like, we'll just jump to that part so we don't have to actually ask the hard questions, right? And the thing that makes me think of it when you talk about that is kind of like the whole data aggregation problem and all the big data adventures when half the time people don't know what data is where. So even just going through the exercise of cataloging, finding, organizing, cleansing, all that kind of stuff, before you really start to think about what can you do with a big data project? You got to get the baseline down before you can get into the fancy stuff. Sounds kind of like what you're talking about. You nailed it, Jeff. And I'm actually going to piggyback on something you said. This is actually the problem that I think we're wrestling with in cloud and in life. Here it is, right? I'm going to put a fine point in it for the listeners. We are struggling, Jeff, with how to evaluate better versus different. And so what cloud is done, more importantly, cloud has shortened the amount of time that we're willing to spend on something before we just start over again. And so the question that we wrestle with is do I need to do the same thing a little bit differently? Do I need to tweak it? Or is there something better that's come along where I need to throw everything away, start all over again and wipe the slate clean? And so here's what ends up happening, right? The challenge that we have building on that is how we choose, Jeff, is more important than what we choose. Because a lot of us are making choices, but we're not developing a framework to choose in a world where different things are pushed at us really every day and every night, right? Amazon and Azure are changing literally thousands of things every night. And if I feel like there's something new out there, I have to understand, is this noise or is this something I pay attention to? Is this a science for a project or is this something that helps my value? If you don't have a way to choose, Jeff, every new option is going to just lead to more confusion and more decommission. Right, well, I mean, you've raised a really interesting point, which is how do CIOs keep up with all this stuff? I mean, how do they possibly keep the lights on, run digital transformation, kind of keep up with the Lord knows how many changes, like you said, get made to Amazon every single day. I mean, the feature set when Andy stands on stage at Reinvent and lists all the services, I think he's using like a two and a half point font on a 200 foot video screen. I mean, there's so much there. So how do you help people take a step back from it's like driving a car with headlights through snow at night. He's just like, how do you help people take a step back and be a little bit more thoughtful, a little bit more intentional, a little bit more circumspect to lay a good foundation, which is going to be what the rest of the house is built on. If you don't have it, it's going to crumble. If you have it, then at least you have a chance of success. How do you help guide them and get out of that snowstorm? So I'm going to give you a new acronym, Jeff, but I think it starts with humility. It starts with us admitting that we don't have this all figured out yet. I often tell a lot of customers, cloud is at best a teenager to just learn how to drive. And cloud, similar to teenagers, the ability of what it can do is kind of been conflict with what it can comprehend in terms of unintended consequences. And so if cloud is changing all the time, let's not talk about, we crushed it, we nailed it, we knocked it out of the park. Let's raise our hand and say, you know what? I humbly need some help because here's what we do, Jeff. In this industry, we throw around acronyms in terms all the time. IaaS, PAS, SAS, VDAS, VBAS, whatever. I'm going to introduce the term CAS, but that's not containers as a service, Jeff. I think what we're getting is confusion as a service. There's so many things that are changing that people are overwhelmed, but because we want to act so much like we're crushing it on social media, we really need to say, I need help. I can't do this in a spreadsheet anymore. Please, are there solutions out there that can help me automate some of this stuff so that I'm not a victim of my own ignorance? So humility, right? Embrace other people that have solved some of this problem before. Somebody has solved this problem. There are companies out there that are taking in the data, that are automating the decision-making, and that can help you, right? Bring people in, bring in outside help. Right. Well, the other piece you just talked on is automation and it goes back to your earlier comment about scale. Bad things at scale are not good. So if you don't get things dialed in now and you start applying automation and you start applying machine speed, then things can get really squirrelly, really quick. So that's even another kind of danger zone coming ahead, start to plan and make sure you've got your stuff organized or now you're going to automate it at machine speed, IoT, 5G, and really run things ragged super quickly. Jeff, I agree 100% with that. I want to go back to something you talked about before. People process technology, I want to tweak that. I think we really need to evolve into people process product or people process problem. It's got to go back to what am I creating or what am I solving that's helping somebody? And the technology is something that I will use or not if that helps me meet that outcome. But as technologists, Jeff, a lot of us are getting lazy. I want to play with Kubernetes. I want to play with containers. I want to play with serverless. I want to play with IoT. Who is that actually solving a problem for? Is what we've got to come back to because if I'm not doing that, the less you submit that I'm playing with this, but I'm not really making something better for a customer or adding more value to the business. So again, what are your tips and tricks? Because things are not going to get less complicated, right? As we talked about Amazon's rolling out new services all the time. Google is really starting, Google cloud is really starting to rage. Obviously Satya has done an amazing job with Microsoft and then there's Oracle cloud and IBM cloud and all these secondary clouds, Equinix. And that acceleration is only going up. So how do you encourage people, coach people, tell people to make sure that they're taking a step back and being organized and thoughtful and not just racing ahead at the next bright shiny object? So great question again, Jeff. I think people have to have to be careful that just because you're here about something a lot doesn't mean it's proven at scale. Social media is dangerous in the sense that we think that we hear something a hundred times and it means that it's polished. And I think that as enterprises and as businesses, go with something that's proven but dip a toe in the water if you're not sure about it. So maybe you're experimenting with some things in DevTest. But here's some practical tips that I'll give. Three things, right? I recommend that people typically start here with cloud strategy, the three D's of data or what I recommend people begin with. Don't begin with the widgets, the shiny objects, begin with data storage, begin with data transport and begin with data organization. We know that data is the life log of the enterprise, that's what all of us are focused on right now. Data is collected from watches, from websites, from things like self-driving cars eventually. So how's my data going to be stored? Because that's the most important part of likely what we're doing as a corporation. How is it going to be transported? Am I okay with spending X amount of dollars on egress? Do I have legacy issues? And then when it comes to data organization, databases, data warehouses, data lakes, I would start with my philosophy, Jeff, on how I plan to leverage that information across any of the multi or hybrid providers that I plan to spin up. Because if I start with the data, that connects me better to the customer. How am I going to leverage this data to make something better for them? And then any venue, honestly, Jeff, that I choose to execute in, will have tools and utilities and packages that I can leverage to make something better for someone. The piece you didn't mention though was the application. So where does the application sit? You still start with the data foundationally and then go to the application or? Yes. But are most of the initiatives driven kind of at the application level layer? They are, they are. And I'm glad you mentioned that. So practically speaking, let me go down a level to double click on stuff. When people want to be cloud native, right? Because we don't want to run servers. We don't want to run boxes. We don't even really want to do VMs anymore. One thing that I recommend that I believe is high reward and low risk is that people strongly consider adopting database as a service. And this is the reason why. It gives us a format to go to something that's cloud native and doesn't have to be totally rewritten. So the juice is worth the squeeze there because I'm reducing labor, I'm reducing maintenance, I'm reducing cycles, the DBAs and people like that have to do, but I'm not paying to refactor an application. Where we struggle, Jeff, and maybe this is another topic, we really struggle with the value of applications. And because we don't know the value of an app, we're using the cost of an app as a proxy. And so if you don't know the value of something, you're always going to be at risk of over or under improving it. This is why I like database as a service. I can be more nimble, I can reduce labor and I'm not rewriting an application and spending more to rewrite it than the app is worth. If I totally refactor, if I totally replatform, the cost may outstrip the value. DBAs is almost always a slam dunk because I'm going to reduce manual things that my people are doing that freeze them up to focus more on customers and evolve in the app. That's what I see pretty consistent in the enterprise. That is really scary, that statement that you said that people don't necessarily know the value of the app and using cost as a proxy is not good. We had, I had Bill Schmozzel on recently and he did a study on trying to figure out the value of data versus the value of an app. And he did some research at UCSF and what they did is they basically said the value of the data is dependent on the business process that you can improve or the business project that you want to do. You make an estimate as to what the ROI in that process is and then you basically see if it's worthwhile to do and the case in point was running a promotion at Chipotle because Bill loves Chipotle. But he had a real concrete way that if we can increase sales at the target stores by 10% or we can increase the average ticket by 20 cents or we can increase the average number of items ordered by 0.5 or whatever. So, you know, real firm metrics that tie back to real numbers that tie back the value that you can make an assessment of that project and that project is enabled by data. So it's, I hope people are doing that for applications because cost is not the way, not the way to figure out value. The challenge that we have Jeff when we look at a lot of the things in the cloud there's a big difference between if I have big C customer, someone who's literally pulling out a wallet or a credit card to pay for my service or product versus little C customers like internally. If I'm paying for a streaming service and the cost of the streaming service goes up the value of that's likely also going up because I'm serving more big C customers. If the cost of a password reset manager goes up an internal application that nobody was likely paying for and that's really the dilemma that a lot of folks have in the enterprise, Jeff am I going to take something that has limited value like a password application and put it in a place that can have unlimited spend? Now, if I'm a Netflix or Disney plus if my spend is going up my value is going up because I'm serving more big C people that are going to pull out their credit card and give me money. So a lot of the struggle is when we drill down into this in the enterprise is the people that have the little C customers that don't have anybody paying them because they're trying to understand this is like funny money in our houses, Jeff my kids are teenagers. If I was just to charge them, right for room and board or for dinner they don't have any money. So the value of what they think about my cooking on the weekend, right? It's hard to put a value on that because they're not paying me. But if I had a food truck it's easy to put a value on that are people buying it or not. So again, the challenges between internal external customers and that's when you get any things like charge back and show back. We need a model to understand is this something that you're tolerating or something that you're actually choosing and are you willing to spend money on? Yeah. And it's a complicated issue, right? Because the other thing is you take this conversation over to the security space which I always find fascinating because investing in security is kind of like investing in insurance and you can't use all your money to ensure everything 100% or else you just why would you even do it? But you have to have some and it's not a real clear ROI but the potential downside is pretty huge. So it's this kind of balancing act as you said it's not really clean as to what the true value of that is unless you tie it back to some specific event like a breach, some type of pens getting stolen, et cetera. So these are not hard questions but it's funny cause they're not technology questions, right? They're business value questions and they're priority questions and they're trade-off questions. That's the other thing, right? You don't have infinite resources so even if you solve the model here you need to solve it within a portfolio of challenges, opportunities to then as you said, kind of rank order, where do you spend that next marginal dollar? Cause it really can have a very huge difference on the return. I think if I was gonna give maybe a final piece of advice to the audience, Jeff it would be to not confuse planning and analysis. That's something that I've talked about before. There's a big difference between those two things and I often use the analogy of tax planning versus tax preparation. Jeff, when we collect our receipts and our W-2s and 10.99s and go to our CPA at the beginning of the next year we can't call that tax planning. That's tax preparation. It's already kind of done and dusted as long as you don't mess it up it's pretty much a four long conclusion. And the enterprise is doing a lot of analysis and a lot of preparation but really we need to do more planning. We need to look at the tools and the companies that are helping assimilate and plan for the future that's coming because then when we're talking about it, right? When you're sitting with your CPA and you're saying what if I do this with my retirement or 401K or real estate assets when they can talk to you about what might happen, right? You're not in crisis, it's not a fire drill it's not a dumpster fire. You can have a very easy conversation around the pros and cons of that. So I think that's one thing we really have to embrace is press ahead, talk to those consultants and those solution providers. Is this really planning or is this just analysis? Is this looking backwards or is it really looking forward and giving me some insight into the things that are coming so that I feel smarter going into the next season? And the opportunity to make a change before you hit December 31st. I mean, I think it's a really great analogy. Well, Bobby, a lot of great stuff squeezed in in a few short minutes. It's super fun to catch up and I just love all your analogies and your stories because at the end of the day it is about people and it's about priorities and it's about business. It's not about the technology. So thank you so much for sharing your insight. Thank you, Jeff. Thanks for having me. Oh, absolutely. All right. He's Bobby Allen. I'm Jeff Rick. You're watching theCUBE from our Palo Alto studios. Thanks for watching. We'll see you next time.