Screaming in the Cloud - Making Multi-Cloud Waves with Betty Junod

Episode Date: November 3, 2021

About Betty Betty Junod is the Senior Director of Multi-Cloud Solutions at VMware helping organizations along their journey to cloud. This is her second time at VMware, having previously led product marketing for end user computing products.  Prior to VMware she held marketing leadership roles at Docker and solo.io in following the evolution of technology abstractions from virtualization, containers, to service mesh. She likes to hang out at the intersection of open source, distributed systems, and enterprise infrastructure software. @bettyjunod  Links:Twitter: https://twitter.com/BettyJunodVmware.com/cloud: https://vmware.com/cloud

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. You know how Git works, right? Sort of. Kind of. Not really.

Please ask someone else. That's all of us. Git is how we build things, and Netlify is one of the best ways I've found to build those things quickly for the web. Netlify's Git-based workflows mean that you don't have to play slap and tickle with integrating arcane nonsense and webhooks, which are themselves about as well understood as Git. Give them a try and see what folks ranging from my fake Twitter for pets startup to global Fortune 2000 companies are raving about. If you end up talking

to them, because you don't have to, they get why self-service is important, but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y dot com. This episode is sponsored in part by our friends at Vulture, spelled V-U-L-T-R, because they're all about helping save money, including on things like, you know, vowels. So what they do is they are a cloud provider

that provides surprisingly high-performance cloud compute at a price that, well, sure, they claim it is better than AWS's pricing. And when they say that, they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently

elastic and open. They can mean the same thing sometimes. They have had over a million users. Deployments take less than 60 seconds across 12 pre-selected operating systems. Or if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes,

except maybe Amazon, who stubbornly insists on having something of the scale all on their own. But you don't have to take my word for it with an exclusive offer for you. Sign up today for free and receive $100 in credits to kick the tires and see for yourself. Get started at vulture.com slash morning brief. That's v-u-l-t-r dot com slash morning brief. Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I like to poke fun at a variety of different things, and that can range from technologies

or approaches like multi-cloud, and that includes business functions like marketing, and sometimes it extends even to companies like VMware. My guest today is the Senior Director of Multi-Cloud Solutions at VMware. So I'm basically spoiled for choice. Betty Janod, thank you so much for taking the time to speak with me today and tolerate what is no doubt going to be an interesting episode one way or the other. Hey, Corey, thanks for having me. I've been a longtime follower and I'm so happy to be here. And good to know that I'm kind of like the ultimate cross section of all the things that you can get snarky about. The only thing that's going to make that even better is if you

tell me, oh yeah, and I moonlight on a contract gig by naming AWS services. And then I just won't even know where to go, but I'll assume they have to generate those custom names in-house. Yes. Yes. I think they do those there. I may comment on it after the fact. So periodically, I am, let's call it miscategorized, in my position on multi-cloud, which is that it's a worst practice that when you're designing something from scratch, you should almost certainly not be embracing unless you're targeting a very specific corner case. And I stand by that. But what that has been interpreted as by the industry in many cases, because people lack nuance when you express your opinions in tweet-sized format, who knew, as me saying multi-cloud bad.

Maybe, maybe not. I'm not interested in assigning value judgment to it. But the reality is, is that there are an awful lot of multi-cloud deployments out there. And yes, some of them started off as we're going to migrate from one to the other, and then people gave up and called it multi-cloud. But it is nuanced.

VMware is a company that's been around for a long time. It has reinvented itself in a few different ways, different periods of its evolution. VMware is a company that's been around for a long time. It has reinvented itself in a few different ways, different periods of its evolution, and it's still highly relevant. What is the multi-cloud solutions group over at VMware? What do you folks do exactly? Yeah, and so I will start by multi-cloud.

We're really taking it from a position of meeting the customer where they are. So we know that if anything, the only thing that's a given in our industry is that there will be something new in the next six months, next year. And the whole idea of multi-cloud from our perspective is giving customers the optionality. So don't make it so that it's a closed thing for them. But if they decide, it's not that like they're going to start, hey, I'm going to go to cloud. So day one, I'm going to go all in on every cloud out there like that. That doesn't make sense. Right. But they all gave me such generous free credit offers. When I founded my startup, I feel obligated to at this point. I mean, you can definitely create

your account, log in, play around, get familiar with the console, but going from zero to being like fully operationalized team to like run production workloads, right? With the same kind of SLAs you had before across all three clouds, like what, within a week is not feasible for like people getting trained up and actually doing that. Our position is that meeting customers where they are and knowing that they may change their mind or something new will come up, a new service, and they really want to use a new service from, let's say, GCP or AWS, and want to bring that with an application they already have or build a new app somewhere, we want to help enable that choice. And whether that choice applies to taking an existing app that's been running in their data center, probably on vSphere, to a new place, or building new stuff with containers, Kubernetes, serverless, whatever. So it's all just about helping them actually take advantage of those technologies.

So what's interesting to me about your multi-cloud group, for lack of a better term, is that a bunch of things fall under its umbrella. I believe Bitnami does, or as I insist on calling it, Bitnami. I believe that SaltStack, which I wrote a little bit of once upon a time,

which tells me you folks did no due diligence whatsoever because everything I've ever written is molten garbage. And to be clear, SaltStack, which I wrote a little bit of once upon a time, which tells me you folks did no due diligence whatsoever because everything I've ever written is molten garbage. And to be clear, SaltStack is good. Just the parts that I wrote are almost certainly terrible because have you met me? I'll make a note. Yeah. You have Wavefront, you have CloudHealth, you have a bunch of other things in the portfolio. And yeah, all of those things do work across multiple clouds, but there's nothing that makes using any of those things a particularly bad idea, even if you're all in on one cloud provider too. So it's a portfolio

that applies to a whole bunch of different places from your perspective, but it can be used regardless of where folks stand ideologically. Yes. So this goes back to the whole idea that like we meet the customers where they are and help them do what they want to do. So with that, making sure these technologies that we have work on all the clouds, whether that be in the data center or the different vendors, so that if a customer wants to just use one or two or three, it's fine. That part's up to them. The challenge I run into is that maybe this is a Twitter bubble problem, but unfortunately, having talked to a whole bunch of folks in different contexts, I know it isn't. There's almost this idea that you have to be incredibly dogmatic about a particular technology

that you're into. I joke periodically about the Rust evangelism strike force, where their entire job is talking about using Rust. Their primary IDE is PowerPoint because they're giving talks all the time about it rather than writing code. And Ray, that's a bit of an exaggeration, but there are the idea of a technology purist who is taking things must be this way, well past a point of being reasonable and disregarding the reality that, yeah, the world is messy in a way that architectural diagrams never are. Yeah, the architectural diagrams are always 2D, right? Back to that PowerPoint slide. How can I make pretty boxes? And then I just redraw a line because something new came out.

But like you and I have been in this industry for a long time, there's always something new, right? And I think that's where the dogmatism gets problematic because if you say like, we're only going to do containers this way, you know, I could see like Swarm and Kubernetes, we're all in on AWS and we're going to use all the things from AWS in this only this way. Things are generational. And so the idea that you want to face a reality and say that there is a little bit of everything and then it's kind of like, how do you help them with a part of that? As a vendor, it could be like, I'm going to help with a part of it, or I'm going to help kind of address certain eras of it. That's where I think it gets really bad to be super dogmatic because it closes you off to possibly something new and amazing, new thinking, different ways to solve the same problem.

That's the problem. Let's do our own devices. Most of us who are building things, especially for random ideas, yeah, there's a whole modern paradigm of how I can build these things, but I'm going to shortcut to the thing I know best, which may very well be architectures

that I was using 15 years ago, maybe tools that I was using 15 years ago. There's a reason that Vim is still as popular as it is. Would I recommend it to someone who's a new user? Absolutely not. It's user hostile. But back in my days of being a grumpy sysadmin, you learned VI because it was on everything

you could get into, and you never knew in what environment you were going to be encountering stuff. These days, you aren't logging into remote systems to manage them in most cases. And when it happens, it's a rarity and a bug. The world changes. Different approaches change.

But you have to almost reinvent your entire philosophy on how things work and what your career trajectory looks like. And you have to give up aspects of what you've considered to be part of your identity and embrace something new. It was hard for me to accept that, for example, Docker and the wave of containerization that was rolling out was effectively displacing the world that I was deep in of configuration management with Puppet and with Salt. And the world changes. I said, okay, now I'll work on cloud. And if something else happens and mainframes are coming back again instead, well, I'm probably not going to sit here

railing against the tide. It would be ridiculous to do that from my perspective, but I definitely understand the temptation to fight against it. You know, we spend so much time learning parts of our craft. So it's hard to say like, I'm now not going to be an expert in my thing. And I have to admit that something else is might be better. And I have to be a newbie again. Like that can be scary for someone who's, you know, spent a lot of time to be really well-versed in a specific technology. It's funny that you bring up the whole like Docker and Puppet config management.

I just had a kind of healthy discussion over Slack with some friends, some people that we know and comment about some of the newer areas of config management. And the whole idea is like, is it a new category or an evolution of? And I went back to the point that I made earlier. It's like, it's generations. We continually find new ways to solve the problem. And one thing now is like, it just all goes so much faster now. There's like a new thing every week, it seems sometimes. It is. And this is the

joy of having been in this industry for a while, toxic and broken in many ways, though it is, is that you go through enough cycles of seeing today's shiny, new, amazing thing become tomorrow's legacy garbage that we're stuck supporting, which means that, at least from my perspective, I tend to be fairly conservative with adopting new technologies with respect to things that matter. That means that I'm unlikely to wind up looking at the front page of Hacker News to pick a framework to build a banking system in, and I'm unlikely to be the first kid on my block to update to a new file system or database just because, yeah, if I break a web server, we all laugh, we make fun of the fact that it throws

an error for 10 minutes, and then things are back up and running. If I break the database, there's a terrific chance that we don't have a company anymore. So it's the mistakes will show area and understanding when to be aggressive and when to hold back as far as jumping into new technologies is always a nuanced decision. And let's be clear as well, an awful lot of VMware's customers are large companies that were founded somehow, and this is possible, before 2010. Imagine that. Did people even have businesses or lives back then? I thought we all used horse-driven carriages and whatnot. And they did not build on cloud, not because of any perception of distrust, because it functionally did not exist at the time that they were building

these things. And, oh, come on into the cloud. It's fine now. Yeah, that application is generating hundreds of millions in revenue every quarter. Maybe we treat that with a little bit of respect rather than YOLOing it into some Lambda-driven monster that's constructed out of popsicle sticks and glue. Yes. I think people forget that. And it's not that these companies don't want to go to cloud. It's like, I can't break this thing. That could be like millions of dollars lost a second. I write my weekly newsletters in a custom monstrosity of a system that has something like 30 some odd Lambda functions, a bunch of API gateways, and it's tied together with things. And periodically there are challenges with it that break as the system continues to evolve.

And that's fine. And I'm okay with using something like that as a part of my workflow, because absolute worst case, I can go back to the way that my newsletter was originally written in Google Docs, and it doesn't look anywhere near the same way, and it goes back to just a text email that starts off with, I have messed up. And that would be a better story

than most of the stuff I put out as a common basis. Similarly, yeah, durability is important. If this were a serious life-critical app, it would not just be hanging out in a single region of a single provider. It would probably be on one provider, as I've talked about, but going multi-region and having backups to a different cloud provider. But if AWS takes a significant enough outage to US West 2 in Oregon, to the point where my ridiculous system cannot function to write the newsletter, that too is a different handwritten

email that goes out that week because there's no announcement they've made that anyone's going to give the slightest toss about given the fact that it's basically cloud Armageddon. So we'll see. It's about understanding the blast radius and understanding your use case. Yep, 100%. So you've spent a fair bit of time doing interesting things in your career. This is your second outing at VMware.

And in the interim, you were at Solo.io for a bit. And before that, you were in a marketing leadership role at Docker. Let's dive in, if you will, given that you are no longer working at Docker. Let's dive in, if you will, given that you are no longer working at Docker. They recently made an announcement about a pricing model change, whereas it is free to use Docker desktop for anyone's personal projects and for small companies. But if you're a large company, which they define as 10 million in revenue a year or 250 employees,

those two things don't go alike, but okay. Then you have to wind up having a paid plan. And I will say it's a novel approach, but I'm curious to hear what you have to say about it. Well, I'd say that I saw that there was a lot of flutter about that news and it's kind of a, it doesn't matter where you draw the line in the sand for the tier, there's always going to be some pushback on it, right? So you have to draw a line somewhere. I haven't kept up with the details around the pricing models that they've implemented since I left Docker a few years ago, but monetization is a really important part for a startup. You do have to make money because there are people that you have to pay and eventually you

want to get off of, you know, raising money from VCs all the time. Docker Desktop has been something that has been a real gem from a local developer experience, right? So that has been like well-received by the community. I think there was an enterprise application for it. But when I saw that, I was like, yeah, okay, cool. They need to do something with that. And then it's always hard to see the blowback. I think sometimes with the years that we've had with Docker, it's kind of like no matter what they do, the Twitterverse and Hacker News is going to just give them a hard time. I mean, that is my honest opinion on that.

If they didn't do it and then, you know, say they didn't make the kind of revenue they needed, that would become another Twitter thread and Hacker News blow up. And if they do do it, you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage

resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free. No asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. It seems to me that Docker has been trying to figure out how to monetize for a very long time

because let's be clear here i think it is difficult to overstate just how impactful and transformative docker was to the industry i gave a talk heresy in the church of docker that listed a bunch of things that didn't get solved with docker and i expected to be torn to pieces for it instead i was invited to give it at container con one year and time, a lot of those things stopped being issues because the industry found answers to it. Now, unfortunately, some of those answers look like Kubernetes, but that's neither here nor there. But now it's, okay, so giving everything that you do that is core and central away for free is absolutely part of what drove the adoption that it saw. But goodwill from developers is not

the sort of thing that generally tends to lead to interesting revenue streams. So they had to do something. And they've tried a few different things, but haven't seemed to really pan out. Then they spun off that pesky part of their business that made money selling support contracts over to Mirantis, which was apparently looking for something now that OpenStack was no longer going to be a thing. And Kubernetes is okay, well, we'll take the Docker Enterprise stuff. Great. What do they do as far as turning this into a revenue model? There's a lot of the, I guess, noise that I tend to ignore when it comes to things like this, because angry people on Twitter or on Hacker News or other terrible cesspools on the internet are not where this is

going to be decided. What I'm interested in is what the actual large companies are going to say about it. My problem with looking at it from the outside is that it feels as if there's significant ambiguity across the board. And if there's one thing that I know about large company procurement departments, it's that they do not like ambiguity. This change takes effect in three or four months, which is underwear outside the pants superhero style speed for a lot of those companies. And suddenly for a lot of developers, they're so far removed from the procurement side of the house that they are never going to have a hope of getting that approved on a career-wide time span. And suddenly for a lot of those companies, installing and

running Docker Desktop just became a fireable offense because from the company's perspective, the sheer liability side of it, if they wind up getting subject to audit, is going to be a problem. I don't believe that Docker is going to start pulling Oracle-like audit tactics, but no procurement or risk management group in the world is going to take that on faith. So the problem is not that it's expensive, because that can be worked around. It's not that there's anything inherently wrong with their costing model. The problem is the ambiguity of people who just don't know, does this apply to me or doesn't this apply to me? And that is the thing that is the difficult, painful part. And as a result, the improvement groups and their champions

of Docker Desktop are having to spend a lot more time, energy, and thought on this than it would simply be for cutting a check because now it's a risk and org-wide and how do we audit to figure out who's installed this previously free open source thing? Now what? Yeah, I'll agree with you on that because once you start making it into like a corporate issued and a software that you have to install on the desktop, that gets a lot harder. And how do you know who's downloaded it? Like my own experience, right? I have a lockdown laptop. I can't just install whatever I want. We have a software portal, which lets me download the approved things. So it's that same kind of model. I'd be curious because it's like from a, once you start looking at from a large enterprise perspective, your developers are working on IP, right? So you don't want that on something that they've downloaded using their personal account,

because now it sits, that code is sitting with their personal account. That's using this tool that's like super productive for them. And that transition to then go to an enterprise, large enterprise and going through a procurement cycle, getting a master services agreement, that is like, that's no small feat. That's a whole motion that is different than someone swiping a credit card or just downloading something and logging in. It's similar to like what you see sometimes with like the, how many people have, you know people have signed up and paid $99 for Dropbox. And then now all of a sudden it's like, wow, we have all of Megacorp signed up. And then now someone has to sell them a plan to actually manage it and make sure it's not just sitting on all these personal drives. Well, that's what AWS's original sales motion looked a lot like.

They would come in and talk to the cto or whatnot giant companies and the cto would say great why should we pick aws for our cloud needs and the answer is oh i'm sorry you have 87 distinct accounts within your organization that we've brought up for you we're just trying to offer you some management answers and unify the billing and this would probably give you a discount as well because there is price breaks available at certain sizing it was a different conversation it's like i'm not here to sell you anything. We're already there. We're just trying to formalize a relationship. And that is a challenge. Again, I'm not trying to cast aspersions on procurement groups. I mean, I do sell enterprise consulting here at the Duckbill Group. We deal with an awful lot of

procurement groups who have processes and procedures that don't often align to the way that we do things as a 10-person, fully remote company. We do not have commercial vehicle insurance, for example, because we do not have a commercial vehicle, and that is a prerequisite to getting the insurance for one. We're unlikely to buy one to wind up satisfying some contractual requirements, so we have to go back and forth and get things like that removed. And that is the nature of the beast and we can say yes we can say no on a lot of those questionnaires but it depends or i don't know is the sort of thing that's going to cause giant red flags and derail everything but that is exactly what docker is doing now it's the well we have

a sort of sloppy weird set of habits with some of our engineers around the bring your own device to work thing so that's the enterprise thing let me be very clear here at the Duckville Group, we have a policy of issuing people company machines. We manage them very lightly just to make sure the drives are encrypted and that the screensaver comes on with a password. So if someone loses a laptop, it's just replace the hardware, not we have a data breach. Let's be clear here. We are responsible about these things. But beyond that, it's, oh, you want to have some personal thing installed on your machine or do some work on that stuff? Fine, by all means. It's a situation of we have no policy against it. We understand

this is how work happens, and we trust people to effectively be grownups. There are some things I would strongly suggest that any employee, ours or anyone else, not cross the streams on for obvious IP ownership rights and the rest. But we have those conversations with our team for a reason. It's understand the nuances of what you're doing. And we're always willing to throw hardware at people to solve these problems. Not every company's like that.

And 10 million in revenue is not necessarily a very large company. I was doing the math out for 10 million in revenue or 250 employees, assuming that there's no outside investment, which with VC is always a weird thing. It's possible barely to have a $10 million in revenue company that has 250 employees, but if they're full-time, they are damn close to a $15 an hour minimum wage. So who does it apply to? More people than you might believe.

Yeah. I'm real curious to how they're going to like, you know, like you say, if it takes place in three or four months, roll that out and how would you actually track it and true that up for people? So. Yeah. And there are tools and processes that do this, but it's also not in anyone's roadmap because people are not sitting here on their annual planning periods, which is always aspirational, but no one's planning for, oh yeah, Q3, one of our software suppliers is going to throw a real procurement wrench at us that we have to devote time, energy, resources, and budget to figure out. And then you have a problem. And by resources, I do mean resources of basically assigning work and tooling and whatnot and energy, not people.

People are humans. They are not resources. I will die on that hill. Well, you know, actually, resource-wise, the thing that's interesting is when you say supplier, if it's something that people have been able to download for free so far, it's not considered a supplier, right? So it's now they're going to go from just a thing I can use and maybe you've let your developers use to now it has to be something that goes through the official internal vetting as being a supplier. So that just, it's a whole different ballgame entirely. My last job before I started this place was a highly regulated financial institution and even grabbing things that were available for free. Well, hang on a minute because what license is it using and how is it going to potentially be incorporated?

And this stuff makes sense and it's important. Now, admittedly, I have the advantage of a number of my engineering peers in that I've been married to a corporate attorney for 11 years and have insight into that side of the world, which to be clear is all about risk mitigation, which is helpful. It is a nuanced and difficult field to, as are most things, once you get into them. And it's just the uncertainty that befuddles me a bit. I wish them well with it. Truly, I do. I think the world is better with an independent docker in it. But I question whether this is going to find success. That said, it doesn't matter what I

think. What matters is what customers say and do. And I'm really looking forward to seeing how it plays out. 100%. Same here. As someone who spent a good chunk of my life there, their mark on the industry is not to be ignored, like you said, right? With what happened with containers, but I do wish them well. There's a lot of good people over there. It's some really cool tech and I want to see a future for them. One last topic I want to get into before we wind up wrapping this episode is that you are someone who was nominated to come on the show by a couple of folks, which is always great. I'm always looking for recommendations on this. But what's odd is that you are, if we look at it and dig a little bit beneath the titles and

whatnot, you even self-describe as your history is marketing leadership positions. It is uncommon for engineering types to recommend that I talk to marketing folks. Personally, I think that is a mistake. I consider myself more of a marketer than not in some respects, but it is uncommon, which means I have to ask you, what is your philosophy of marketing? Because it very clearly is differentiated in the public eye? I'm flattered. I will say that like, and this goes to like how I hire people and how I coach teams is you have to be super curious because there's a ton of bad marketing out there where it's just kind of like, hey, we do these five things. We always do these five things, blah, blah, blah, blah, blah. But I think it's really being curious about what is the thing that you're marketing. There are people who are just focused on the function of marketing and not the thing, right? Because you're doing your marketing job in service of a thing, this new widget, this new whatever, and you got to be super

curious about it. And I'll tell you that for me, it's really hard for me to market something if I'm not excited about it. I have to personally be like super excited about the tech or something happening in the industry. And it's kind of like an all in thing for me. And so in that sense, I do spend a ton of time with engineers and like end users and really understand, I really try to understand what's going on. I want to understand how the thing works. And I always ask them like, well, so I'll ask the engineers like, so, okay, this sounds really cool. You just described this new new feature, and you're super excited about it because you wrote it but like how is your end user the person you're building this for how did they do this before help me understand how did they do this before and why

is this better just really dig into it because for me i want to understand it deeply before i talk about it i think the thing is it shows a tremendous amount of respect for the builder and then to try to really be empathetic to understand what they're doing and then partner with them. I mean, this sounds so businessy the way I'm talking about this, but really be a partner with them and to like help them like make their thing really successful. I'm like the other end, like you're going to build this great thing. I'm going to make it sound like it's the best thing that's ever happened. But to do that, I really need to deeply understand what it is. And I have to care about it too. I have to care about it in the way that you care about it. I cannot effectively market or sell something that I don't believe in personally. I also,

to be clear, because you are a marketing professional, or at least far more of one than I ever was, I do not view what I do as marketing. I view it as spectacle. And it's about telling stories to people. It's about learning what the market thinks about it. And that informs product design in many respects. It's about understanding the product itself. It's about being able to use the product. And if people are listening to this and think, wait a minute, that sounds more like DevRel. I have news for you.

DevRel is marketing. They're just scared to tell you that. And I know people are going to disagree with me on that. You're wrong, but that's okay. Reasonable people can't disagree. And that's how I see it is that, okay, I'll talk to people building the service. I'll talk to people using the service, but then I'm going to build something with the service myself because until then it's all a game of who sounds the most convincing in the stories that they tell. But okay, you can tell an amazing story about something, but if it falls over when I try to use it, that, well, I'm sorry,

you're not being accurate in your descriptions of it. Mm-hmm, 100%. I hate to say like you're storytellers, but that's a big part of it, but it's kind of like you want to tell the story, so you do something so that people believe a certain thing, but that's part of a curated experience because you want them to try this thing in a certain way. Because you've designed it for something. I built a spoon. I want you to use that to like eat your soup because you can't eat soup with a fork. So then you'll have this amazing soup eating experience.

But if I build you a spoon and then not give you any directions and you start throwing it at cars, like you're going to be like, this thing sucks. So I kind of think of it in that way to your point of like, it has to actually work. It's like, but they also need to know, like, what am I supposed to use it for? The problem I've always had on some visceral level with formal marketing departments for companies is that they can say that a product that they sell is good. They can say that the product is great, or they can choose to say nothing at all about that product. But when there's a product in the market that is clearly a turd, a marketing department is never going to be able to say that, which I think erodes its authenticity in many respects. I understand the constraints behind that. Truly, I do. But it's the one

superpower I think that I bring to the table where even when I do sponsorship stuff, it's you can buy my attention but not my opinion because the authenticity of me being trusted to call them like I see them, for lack of a better term, to my mind at least, outweighs any short-term benefit from saying good things about a product that doesn't deserve them. Now, I've been wrong about things. Sure, I have also been misinformed in both directions, thinking something is great when it's not or terrible when it isn't or not understanding the use case. And I am thrilled to engage in those debates. But this is really expensive when you run it for this use case. And the answer can be,

well, it's not designed for that use case. But the answer should not be, no, it's not. I promise you, expensive is in the eye of the customer, not the person building the thing. Yes. This goes back to like, I have to believe in the thing. And I do agree. It's like not, it's not a panacea. Like you're not going to make product A and it's going to solve everything, right? But being super clear and focused on what it is good for, and then please just try it in this way, because that's what we built it for. I want to thank you for taking the time to have a, what for some people is no doubt going to perceive as a surprisingly civil conversation about things that I have loud, heated opinions about. If people want to learn more, where can they find you? Well, they can follow me on Twitter,

but I'd say go to vmware.com slash cloud for our work thing. Exactly. VMware, that's right. VM there. And we'll of course put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thanks, Corey. Betty Junod, Senior Director of Multi-Cloud Solutions at VMware. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a loud ranting comment at the end. Then, if you work for a

company that is larger than 250 people or $10 million in revenue, please also Venmo me $5. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble