Screaming in the Cloud

Insightful conversation. Less snark.

Dot Divider
Every Wednesday, listen to host Corey Quinn interview domain experts in the world of Cloud Computing discuss AWS, GCP, Azure, Oracle Cloud, and why businesses are coming to think about the Cloud.
Screaming in the Cloud Hero
Cloud Cost Management Starter Kit
Screaming in the Cloud
05.14.2021
17 Minutes
Transcript

Corey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.

Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.


Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure because I mean, who doesn’t love to complain about AWS? I feel like that’s always a good thing that we can talk about, no matter the topic. Today, we’re going to be talking about the ‘cloud cost management starter kit.’ So, the starter kit seems to be a big fad that’s going around. If you’re listening to this episode, you’re probably thinking, “It’s already done. It’s over.”


But I still want to talk about it. I think that this is a really relevant topic because I think a lot of companies are trying to get started, get their hands started in cloud cost management. So, I think this would be a great thing for us to talk about: what’s in our cloud cost management starter kit?


Amy: And it really will help answer that question that I get asked a lot on: what is even a cloud economist, and what do you do?

Jesse: Yeah, I mean, given the current timeframe, I haven’t gone to any parties recently to talk about what I do, but I do feel like anytime I try to explain to somebody what I do, there’s always that moment of, “Okay. Yes, I work with computers, and we’ll just leave it at that.”


Amy: It’s easier to just think about it as we look at receipts, and we kind of figure things out. But when you try to get into the nuts and bolts of it, it’s a very esoteric idea that we’re trying to explain. And no, I don’t know why this is a real job. And yet it is.

Jesse: This is one of the things that always fascinates me. I absolutely love the work that I do, and I definitely think that it is important work that needs to be done for any organization, to work on their cloud cost management best practices, but it also boggles my mind that AWS, Azure, GCP, haven’t figured out how to bake this in more clearly and easily to all of their workflows and all their services. It still boggles my mind that this is something that exists as—

Amy: As a thing we have to do.

Jesse: As a thing we have to do. Yeah, absolutely.


Amy: Well, the good news is, they’re going to change their practices once every six weeks, and we’ll have a new thing to figure it out. [laugh].

Jesse: [laugh]. So, let’s get started with the first item on our cloud cost management starter kit. This one is something that Amy is definitely passionate about; I am definitely passionate about, as well. Amy, what is it?

Amy: Turn on your CUR. Turn on your CUr. If you don’t know what it is, just Google AWS CUR. Turn it on. It will save you a headache, and it will save anyone you bring in to help you [laugh] [unintelligible 00:02:59] a huge headache. And it keeps us from having to yell at people, even though that’s the thing that if you pay us to do it, we will totally do it for you.

Jesse: If you take nothing away from this episode, go check out the AWS Cost and Usage Report—otherwise known as CUR—turn it on for your accounts, ideally enable it in Parquet format because that’s going to allow you to get all that sweet, sweet data in an optimized manner, living in your S3 bucket. It is a godsend. It gives you all the data from Cost Explorer, and then some. It allows you to do all sorts of really interesting business intelligence analytics on your billing data. It’s absolutely fantastic.


Amy: It’s like getting all of those juicy infrastructure metrics, except getting that with a dollar sign attached to it so you know what you actually doing with that money.


Jesse: Yeah, this definitely is, like, the first step towards doing any kind of showback models, or chargeback models, or even unit economics to figuring out where your spend is going. The Cost and Usage Report is going to be a huge first step in that direction.


Amy: Now, the reason why we yell at people about this—or at least I do—is because AWS will only show you the data from the time that it is turned on. They do have it for historical periods, but if you enable it at a specific point, all of your reports are going to start there. So, if you’re looking to do forecasting, or you want to be able to know what your usage is going to be looking like from this point on, turn it on as early as possible.

Jesse: Absolutely. If you are listening to this now and you don’t have the CUR enabled, definitely go pause this episode, enable it now, and come back and listen to the rest of the episode because the sooner you have the CUR enabled, the sooner you’ll be able to get those sweet, sweet metrics for all of your—

Amy: And it’s free.

Jesse: [laugh]. Yeah, that’s even the more important part. It’s free. There’s going to be a little bit of data storage costs if you send this data to S3, but overall, the amount of money that you spend on that storage is going to be optimized because you’re saving that CUR data in Parquet format. It’s absolutely worthwhile.

All right, so number two; the second item on our cloud cost management starter kit, is getting to know your AWS account manager and account team. This one, I feel like a lot of people don’t actually know that they have an AWS account manager. But let me tell you now: if you have an AWS account, you have an AWS account manager. Even if they haven’t reached out to you before they do exist, you have access to them, and you should absolutely start building a rapport with them.

Amy: Anytime you are paying for a support plan, you also have an account manager. This isn’t just true for AWS; I would be very surprised for any service that charged you for support but did not give you an account manager.

Jesse: So, for those of you who aren’t familiar with your account manager, they are generally somebody who will be able to help you navigate some of the more complex parts of AWS, especially when you have any kind of questions about your bill or about technical things using AWS. They will help you navigate those resources and make sure that your questions are getting to the teams that can actually answer them, and then make sure that those questions are actually getting answered. They are the best champion for you within AWS.

If you have more than a certain threshold of spend on AWS, if you’re paying for enterprise support, you likely also have a dedicated technical account manager as well, who will be basically your point person for any technical questions. They are a great resource for any technical questions, making sure that your technical questions are answered, making sure that any concerns that you have are addressed, and that they get to the right teams. They can give you some guidance on possibly how to set up new features, new architecture within AWS. They can give you some great, great guidance about the best ways to use AWS to accomplish whatever your use case is. So, in the cases where you’ve got a dedicated technical account manager as well, get to know them because again, they are going to be your champion. They are here to help you. Both your account manager and your technical account manager want to make sure that you are happy with AWS and continue to use AWS.

Amy: And the thing to know about the account manager is, like, if you ever run into that situation where, oh, something was left on erroneously and we ended up with a spike, or this is how I was understanding the service to work and it didn’t work that way, and now I have some weird spend, but I turned it off immediately, if you ever want to get a refund or a credit or anything, these are the people to talk to; they’re the ones who are going to help you out.

Jesse: Yeah, that’s a great point. It’s like, whenever you call into any kind of customer support center, if you treat the person who answers the phone with kindness, they are generally more likely to help you solve your problem, or generally more likely to go out of their way to help you solve your problem. Whereas if you just call in and yell at them, they have no interest in helping you. So—

Amy: You’ll never see that refund.

Jesse: Exactly. So, the more that you can create that rapport with your account manager—and your technical account manager if you have one—the better chances that they will fight for you internally to go above and beyond to make sure that you can get a refund if you accidentally left something running, or make sure that any billing issues are taken care of extremely fast because they ultimately have already built that rapport with you. They care about you and the way that you care about them and the way that you care about continuing to use AWS.

Amy: There’s another note about the technical managers where if you are very open with them on what your architecture plans are—“We’re going to move into this type of EKS deployment. This is the kind of traffic we think we’re going to run, and we think it’s going to be shaped this way”—they’ll help you out and build that in most efficient way possible because they also don’t want the resources out there either being overutilized or just being run poorly. They’ll help you out in trying to figure out the best way of building that. They’ll also—if AWS launches a new program and you spent a lot of money on AWS, maybe there’s a preview program that they think will help you solve a very edge case kind of issue that you didn’t think you had before.

Jesse: Absolutely.

Amy: Yeah. So, it’s a great way to get these paths and get these relationships because it helps both parties out.

Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.

Jesse: So, the third item on our cloud cost management starter kit is identifying all of your contracts. Now, I know you’re probably thinking, “Well, wait. I’ve just got my AWS bill, what else should I be thinking about?” There’s other contracts that you might have with AWS. Now, you as the engineer may not know this, but there may be other agreements that your company has entered into with AWS: you might have an enterprise discount program agreement, you might have a private pricing addendum agreement, you might have an acceleration program—migration program—agreement. There’s multiple different contracts that your company might have with AWS, and you definitely want to make sure that you know about all of them.

Amy: If you’re ever in charge of an architecture, you’re going to want to know not just what your costs are at the end of the day, but also what they are before all your discounts because those discounts can maybe camouflage a heavy usage if you’re also getting that usage covered by refunds and discounts.

Jesse: Absolutely, totally agreed. Yeah, it’s really, really important to understand, not just your net spend at the end of the day, but your actual usage spend. And that’s a big one that I think a lot of people don’t think about regularly and is definitely important to think about when you’re looking at cloud cost management best practices and understanding how much your architecture is actually costing you on a team-by-team or product-by-product basis.

Amy: Also, make sure if you’re doing reservations that you know when those reservations and savings plans ent—

Jesse: Yes.

Amy: —because you don’t want to have to answer the question, “Why did all of your costs go up when you actually have made no changes in your infrastructure?”

Jesse: Yeah. Half the battle here is knowing that these contracts and reservations exist; the other half of the battle is knowing when they expire so that you can start having proactive conversations with teams about their usage patterns to make sure that they’re actually fully utilizing the reservations, and fully utilizing these discounts, and that they’re going to continue utilizing those discounts, continue utilizing those reservations so that you could ultimately end up purchasing the right reservations going forward, or ultimately end up renegotiating at the correct discount amount or commitment amount so that you are getting the best discount for how much money you’re actually spending.

So, the last item on our cloud cost management starter kit is thinking about the non-technical parts of projects. Amy, when you think about the non-technical parts of projects, what do you think about?

Amy: Non-technical always makes you think of people and process. So, this would be the leadership making the decisions on what those cost initiatives are. Maybe they want to push this down to the team lead level: it would include that. Or maybe they want to push it down to the engineering level, or the individual contributor level. There are some companies that are small enough that an engineer can be completely cognizant and responsible for the spend that they make.

Jesse: Yeah. I think that this is a really, really critical item to include in our starter kit because leadership needs to be bought into and back whatever work is being done, whatever cloud cost management work is being done. But also teams need to be empowered to make the changes that they want to make, make the changes that will ultimately provide those cloud cost management optimization opportunities and better cost visibility across teams. So, does everybody know what their teams are empowered to do, what their teams are capable of? Does everybody know what their teams are responsible for on the flip side? Do they ultimately know that they are responsible for managing their own spend, or do they think that the spend belongs to somebody else? Also, do they understand which resources are part of their budget or part of their spend?

Amy: It’s the idea that ownership of—whether it’s a bill, whether it’s a resource—comes down to communication, and level setting. Do we know who owns this? Do we know who’s paying for it? Do they know the information in the same way? Is there someone who’s outside who can figure out this information for themselves? Just making sure that it’s done in a clear enough way that everyone knows what’s going on.

Jesse: Absolutely. Well, that will do it for us this week. Those are our four main items for our cloud cost management starter kits. If you’ve got questions you’d like us to answer, please go to lastweekinaws.com/QA, fill out the fields and submit your questions.

If you’ve enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review, give it a five-star rating on your podcast platform of choice and tell us, what would you put in your ideal starter kit?

Announcer: This has been a HumblePod production. Stay humble.
Play Episode
Open Sourcing GitHub with Denise Yu
Screaming in the Cloud
05.13.2021
41 Minutes
Links:
Transcript


Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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.

Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.

Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Denise Yu, who's a senior software engineer at a company that mispronounces itself as GitHub, but it's actually pronounced Jif-ub. Denise, welcome to the show.


Denise: Thanks so much for having me, Corey. I am excited to scream in some clouds with you.

Corey: Yes, and I do want to point out that Jif-ub is not accepted by the Jif-ub marketing team, and they're upset. But that's the nice thing about this being my show; they don't get to dictate the nonsense that I say. But this is not you endorsing my correct pronunciation, as an employee, in any way. Because that's not your role. You're a senior software engineer. What do you do?


Denise: So, I work on a bunch of different things. I actually originally joined GitHub back in March at the beginning of this global pandemic that we're still living through, somehow, in the year 2021. But I joined a year ago to work on a team called ‘Community and Safety.’ That team has been rolled into other teams by this point, partly because the original team did too good of a job at creating abuse prevention tools for the platform. But these days, I still work on community-facing tools, which is very exciting. 


I'm actually in a department called Communities. And our whole charter is to build tools that make life better for open-source maintainers. So that's a mission that I'm actually really excited about. I think [laugh] of all the products that I've worked on, this is one of the few that I can say I actually really want to make life better for the end-users. [laugh].

Corey: Oh, absolutely. For better or worse, GitHub—or Jif-up—has taken a central role in the open-source community. And on some level, I find it—how do I frame this—kind of weird in that we've taken this protocol that is widely decentralized, and that's its entire point. Well, what do we do about this? Oh, immediately, we're going to re-centralize it. That's the right answer. 

And it just never ceases to amuse me that that's what we have taken from it as a society. But it works. I can't argue otherwise. And I maintain—and this is a bet that I am definitely going to the wall with—that in five years or so we are going to look back at Microsoft acquiring GitHub as a transitional moment.


Denise: Yeah, I think so. I think even though the Git technology is built for resilience and distributed work, I think what GitHub as a platform has shown that the process of building software is more than just pushing lines of code. The code is the artifact of collaboration, but we still need a place to do that collaboration, which is why—I’ve been using GitHub for five or six years now, and I only realized a few years ago that things like pull requests and issues don't exist outside of GitHub. That's an abstraction that's so, so deeply baked into my idea of what it means to work collaboratively. That didn't exist until GitHub invented it, which is pretty wild.


Corey: Yeah, it's bizarre in a number of different levels. But so much of what we think is part of Git is not. It is the GitHub abstraction, but it's also something that is widely copied by all of GitHub’s competitors, in many respects. So, the line has gotten very, very blurry. And how people come to Git is also fascinating. 


I used to go to a Git training, I think in 2009, conducted by a GitHub employee—I may be misremembering the year by a few years in either direction—and it was a multi-day process, and it was complex, and I left it feeling in many ways that I had more questions than I answered. Now, I point people to a GitHub page that talks about how to use Git, and they're mostly there. So, it isn't that Git necessarily has improved as a product, it's that GitHub has made it far more accessible. And let's face it, after a few million times practicing, you get very good at explaining complicated things in simple ways.

Denise: Oh, yeah. For sure. It's not a huge surprise that internally, we use GitHub for everything. So, if you want to, I don't know, collaborate on writing a—even a new blog post, new marketing copy, or new documentation, all of that happens through GitHub. And I think that people with different levels of proficiency with command line—actually these days, you don't even need command line. You do everything through the UI, which I think is pretty neat.

Corey: Oh, it's phenomenal. And I do want to call out that I am the maintainer of an open-source project on GitHub. We know it's good because it has [28.3000 00:06:18] stars; at the time of this recording, almost 3000 forks. And what it is, is the “Open Guide to AWS” it's a big markdown document that more or less explains what all of the AWS services do. 

There are over 200 contributors, we have an online Slack community at slackhatesthe.cloud because they don't like open-source community stuff very well, and we make fun of them for it. But my point being is that even without knowing how to write a single line of code, this is more or less just a big readme that explains different aspects of what AWS is because it's incredibly hard to adjust to that. And that is every bit as much an open-source project as anything that's included in NPM, or any command line tool that you'll use in any aspect of your job.

Denise: Yeah, exactly. And I think the nice thing about editing a document like an AWS Guide, or anything else, really. A couple years ago, I would have said, “Okay, that sounds like it should be a wiki page.” Wiki pages support revisions, collaboration—or maybe a Google Doc or something. But the nice thing about putting it somewhere like GitHub, is like, well, you're already—probably all your other tools already integrate into GitHub. Like, you maybe get Slack notifications, when you have a PR requires review, or whatever it is. It's just so much easier to have everything in one place. And you also get the cool green squares for contributing. [laugh].


Corey: Oh, of course, the most important thing is fill that thing up. It’s—talking about gamification causing weird behavior patterns. Yeah, we have a GitHub workflow on this, that fires off on every pull request that looks at the entire site, and validates the thousand and some odd links are still resolving and valid because when you link to this many different sites across the internet, link rot’s a real thing, and it's depressing and sad to be able to look at this and, “Oh, that didn't work.” Now, we do have to fix some of this because it winds up, in some cases, flagging people's submitted pull requests as not being valid, but it has nothing to do with what they're submitting because I'm bad at this. But the fact that that's built in and is available for use is incredible. Every time I look at GitHub’s site, it's gotten better than the last time I looked at it.

Denise: Oh, that's so nice.


Corey: Well, can't shake the feeling that at some point, there's going to be at the proper moment, a deploy to Azure button that as soon as someone clicks, whatever they've written is suddenly running in some environment in Azure. Now, if it comes too soon, it's going to be terribly implemented, and no one's going to trust it; if it comes too late, then people will already have solved this problem in different ways, so timing is going to be critical. But that is going to be—well-executed at least—a potential sea change in how people approach Cloud and what the default environment to run something on it.

Denise: Wait, have you looked at Codespaces? Or seen the demo around that?

Corey: I was hoping you would bring those up. Back in the before times, I would travel kind of a lot. And the only computer I brought with me was my iPad.


Denise: Mm-hm. Yeah, a lot of people do this.


Corey: Oh, yeah. Trying to get a environment on an iPad, it turns out, it's not terrific. The solution that I fell back to was, well, I've been using VI for 20 years, so I'll just SSH into an instance and call it good. But there were interesting projects of varying degrees of success that would run VS Code in a instance somewhere and then just present its interface as a web page. GitHub has actually integrated this as a core offering: all right, you click a button, it spins it up, and it's there. 

Denise: Yep.

Corey: And oh, my God, is that better.

Denise: Yeah. I think it's still in limited beta. So, I think you still have to request access to it—I don't know if this will still be the case in March, but yeah, I've tried it out a couple of times, and it works really, really well. My only gripe is that I don't like to use VS Code, so I'm going to have to learn VS Code in order to use it.

Corey: I've got to say that is my single biggest barrier to adoption. I already know how to use VI, but a lot of the VS Code stuff, of you having a full featured IDE that does all of these things, is extraordinarily heavy of a lift for me. It more or less is breaking 20 years of muscle memory.

Denise: Yeah. Tons of my co-workers love VS Code and use it every day. I only know how to use RubyMine for, [laugh] like, large monolithic Ruby development. And if I'm not doing work on the monolith, I don't want to use an IDE otherwise; I want to just use VI. I'm working in a small enough codebase where I know the name of every file, then I don't want to use the IDE for it. 

The VS Code to me sits in this middle ground that I know I need to learn how to exist in that middle ground, but it requires me going off to the internet and hunting down every single plugin that I need to put onto VS Code to make it feel like RubyMine again. And that's the thing that I don't want to do.

Corey: Well, I'll take it a step further, and most of the tutorials I see about how to get up with VS Code as an IDE are JavaScript based—or YavaScript. [unintelligible 00:11:01] pronunciation once again—and my lingua franca is crappy Python. So, whenever I look for, oh, I want a VS Code tutorial for Python, the first eight pages of it are here the different ways you can do virtual environments and dependency management because that is Python. It focuses on that, and it winds up getting hung up on those implementation details before ever getting to, “Here's a reasonable Python project that someone who's not very good at Python can understand, and here's how VS Code can add value to it.” I mean, those posts exist, but they're hard to find. And it honestly makes me feel like an imposter for not knowing JavaScript.

Denise: Yeah, the feature that I use the most in a full IDE like RubyMine is command-click to go to definition. And with Ruby, you get the correct definition about 70 percent of the time, but it's still better than nothing. Because if I'm not doing that, I'm doing a full text search for the method definition, and that's like—my brain can only work with one of those two things. With VS Code, after 15 minutes of trying to find the right plug-in that does click to go to definition and failing, I was just like, this is just not worth it. Nobody should have to live through this much pain. [laugh]. I don't want to do this anymore. [laugh].


Corey: Exactly. It becomes this situation where at least when you're starting to learn something, it's breaking everything you're used to, and it feels like instead of helping you, you're fighting with it.

Denise: Yeah, this reminds me of how people talk about switching their keyboard layout to Dvorak, or whatever—

Corey: Oh, my God. I want to do that on one hand because I'm deep into the mechanical keyboard space. But on the other is, I don't really have six months to teach myself to type all over again.

Denise: Yeah, that's the thing. It's like, maybe it'll speed up my typing by, like, two percent. But I already type really fast. I think I would have extremely diminishing returns on that. But also, I don't want my brain to just not work for weeks or months. 

Corey: Oh, it is worse than that because as soon as you leave that and go on to someone else's computer—which admittedly is not nearly as frequent as it used to be when I was in help desk and desktop support—“Oh, can you type in your password on this thing?” “Absolutely not. Thank you for asking.” It's effectively having to go back and restart it over. I understand that it's more efficient, but you need a societal shift to it, not individuals doing it piecemeal.

Denise: Yeah, that's true.


Corey: So you're relatively recent, as far as hires over a Jif-ub. You joined mid-pandemic, or early pandemic, depending on how you want to slice that, and you've never been to their headquarters. What is that like?

Denise: Everyone keeps telling me how awesome HQ is like, and I’m like, “Cool.” I actually have a brick wall in my office that looks like some of the spaces in HQ, I guess, so people get super confused when I tell them that I'm in Toronto. 

Corey: Oh, yeah, I've been to HQ a bunch of times for various things. It's great. You’ve really—

Denise: Yeah.

Corey: —got to see it. I'm not helping, am I?


Denise: [laugh]. You're really not helping. I really want to go to HQ. I was meant to go to HQ in March. So, my start date was March 13th, or 14th—I can't remember—in 2020. And I was part of the first onboarding class to not get to go out to HQ because that was when the travel restrictions around COVID were finally being implemented. So I'm very sad about that.


Corey: I will say that GitHub has the advantage of a lot of other companies in that—to my understanding—they had a remarkably resilient remote culture before this all hit. Is that correct, or am I misremembering my history?

Denise: No, you're right. I think the figure was 75 percent of employees don't live within commuting distance to HQ when I first joined.

Corey: Well, not with that attitude.


Denise: [laugh]. Yeah, that's true. We just got to try harder. But I think that number is a lot higher now because we have been hiring internationally. And we've grown a lot in the last year or so that I've been here. 

Yeah, so I think we were better equipped than a lot of other companies to go full remote because it basically just was telling that 25 percent of employees, “Don't come into HQ anymore.” And giving people a little bit more office budget, I guess, to get set up fully for full time remote work. There are a lot of challenges though, especially when you join as a remote employee and you've never worked in a fully remote environment before. It took me a really, really long time to get used to the fact that Slack was my portal to everything. 


Corey: Oh, yeah. Here at the Duckbill Group, we were full remote from the beginning, just because I decided to merge my consultancy with my business partner’s ten days before he moved from across the street to Portland, Oregon. So, we at that point decided, all right, we're full remote. And we've never had a critical mass of staff in one city to the point where they're became a de facto headquarters because as soon as that happens, it changes your culture. Trying to retrofit something like full remote to a company that historically has always been face-to-face, it shatters a lot of the dynamics. So, on some level it was easy for us. On the other, it feels like we're at a bit of a disadvantage in some respects, once things return to normal. But that's a future problem, unfortunately.


Denise: Yeah, I think the biggest thing is learning to work asynchronously, which GitHub was already pretty good at. So I'm pretty used to opening a PR on Wednesday evening, for example, and not really expecting to get feedback on and until the next day, Thursday, or even Friday, especially if I needed a feedback from a different team. Actually, that's something that I've learned since joining GitHub; that wasn't something I was used to before because I've only ever worked in co-located environments before. Someone didn't review my PR in time, I would take a Nerf gun and go over to them [laugh] and gently ask them to [laugh] review my PR. But it's been very interesting. 

So, I also used to work at Pivotal, which I'm sure you've heard rumors about our kind of cultish pairing [laugh] culture. So, my default state of working was to constantly be talking to another human about what I was doing all the time. And so, suddenly joining a fully remote company in a time when we have to work a little bit more asynchronously than before because people's lives are just completely upended by this pandemic, that was a big adjustment.


Corey: So, in the before time, something else that you were effectively renowned for was not only giving conference talks yourself, but helping other people give conference talks, too. Let's talk a little bit about that because speaking at conferences was always one of my passion projects because I love the sound of my own voice, simply love it. And helping other people do that, too, was also something I was very interested in doing, but it was always hard for me to get traction around getting people to let me help them for reasons that are probably blindingly obvious to everyone except me. So, tell me about that. What's the story?

Denise: Yeah, so I have always been pretty comfortable speaking in public. I think it's something that I almost took for granted. And the reason for that is because I spent upwards of 10 years of my teenage and adult years doing competitive debate. It was traveling to debate tournaments pretty much every single weekend in college and spent a lot of time doing both structured and off-the-cuff speaking in front of large groups of people. And when I got into tech, it took me a long time to realize that not everyone is like me. I kind of had this special strand, I guess of imposter syndrome, where I think that if I know how to do a thing, then everybody else knows how to do that thing also. Which is aggressively not a correct assumption to make, ever. 


Corey: Oh, same here across the board. It's one of those I thought for a while I fit in tech because the stereotypes seem to fit me super well. It's like, yeah, “We're bad with people.” “Absolutely.” “We prefer dealing with computers to humans.” “Absolutely.” “I hate my boss.” “Absolutely.” “I'm good at programming…” “Oh… okay, never mind.” But yeah, there's a lot that I think people miss about what it takes to give a good talk. It's not technical mastery. It is an ability to tell a story.

Denise: Exactly. I think you hit the nail on the head there. And so after I realized that, okay, I am, at least at the median. I actually think I'm quite good at public speaking and telling stories about technical subject matter, and breaking things down in a way that someone without as much technical context as me can understand it. The thing that got me into doing more and more public speaking, specifically at tech conferences was, after I gave my first talk, people just kept coming up to me, basically, and being like, “Hey, I saw you talk to this conference. Do you want to come talk at this other conference that I'm running?” or whatever. I think like, once you've got a couple of larger stage conference talks under your belt, you almost don't really have to look for speaking opportunities anymore.

Corey: No, they fall into your lap. And then you have different problems such as, oh, I've been invited to speak at this conference. Let me do some checking to figure out are they a trash fire, or are they a reasonable place?

Denise: Yeah. Am I going to be the only not white guy speaking at this conference?

Corey: Am I going to be on a manel? I won't do it. Is there not a code of conduct that has actual teeth and doesn't read as a joke? I won't do it. And that stuff is way more important to me than the technical content of the talk.

Denise: For sure. For sure.

Corey: But tying it back to even the stuff that GitHub does, one of the talks that was transformative for how I approach this was a Git talk, “Terrible Ideas in Git.” And I like to teach people things by counterexample, and the first iteration of that talk would have been great if the Git maintainers themselves had been the target audience for this, but two people would have loved that and the rest of the audience would have been looking at this with what the hell are you talking about? So, I had to refactor it, and it made it a far stronger talk all the way to the point where there's jokes for everyone in there. But my favorite time giving the talk, I said that, “I now need to be able to explain Git in such a way that my mother would understand it. And that is a problematic way of framing on ageism and sexism basis in most cases, but not this time because she's sitting in the front row. Hi, mom.” That was one of my favorite speaker moments that was just, it's hard to get that one pulled off, mostly because getting my mother to fly to various parts of the world and watch me speak is a bit of a heavier lift than one expected. But here we are.

Denise: Yeah, I use a similar litmus test for my stepdad. My stepdad is not a technologist. He is a biologist by training, actually. But he asks me a lot of questions about what I do. And back when I worked at Pivotal, I had to explain cloud virtualization to him every time I went home. [laugh]. 

I don't know if it's gotten easier. With GitHub, I feel like GitHub is a little bit easier to explain to the average person than Cloud Foundry. But my bar kind of is, every time I put together a talk, do I think that my stepfather could understand the content.

Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: Increasingly, I found the best way to explain GitHub to folks who aren't familiar with it and are non-technical but work in the business space has been, “You know how Microsoft Word has track changes? Yeah, imagine that only without the copy-of-copy-of-file-final-use-this-one-date.bak.PDF.doc? Yeah, imagine that. Instead, this makes this streamlined and easy for multiple people to work on at the same time,” at which point they stare at you hungrily and say, “Oh, my God, how can I use this for my work?” And I feel like there's a breakout moment waiting for GitHub if they ever decide to focus on that part of the market because my God, is there an appetite for it?

Denise: Yeah, I think like that kind of revision driven editing, I think that's applicable to so many different domains. I've heard people experimenting with the idea for—I think, Figma does something similar for designs for visuals, but I've also heard the idea floated of this being done for, like, sound mixing, sound engineering, which I think would be super, super cool. I don't know how you could visualize that, but someone who has more knowledge of that space, I'm sure could come up with a way.


Corey: Oh, yeah, the challenge I find with stuff like that, for podcasts, for example, is GitHub gets very, very angry because Git gets very, very angry when you start doing things like checking in large uncompressed media files, and then making small changes to them, but you can't diff that so every revision for video work is, “Oh, here's another 150 gig file to put up,” and that becomes a problem.

Denise: Yeah.


Corey: Yeah, there's a lot that's neat out there. I also want to credit GitHub with fixing the state of working with Git because let's face it, Git makes everyone feel stupid at some point. The question is, is just how far along are you before that hits? And invariably, the approach was always, when you get into that territory, you wind up asking the question on some forum somewhere, and then you wind up getting a few minutes later, this giant essay where it starts out, “Well, Git is not really a version tracker, it's instead of distributed graph that”—and then you just skip down eight paragraph to the bottom where they give you the one-liner that fixes the problem. 

GitHub has fixed the result of queries for, “How do I X in Git?” And just gives you the answer outright. It's transformative, and it's one of the things that everyone takes for granted because no one really stops to think this documentation is awesome, and accessible, and answers my problem, but the result of it is, is that you just don't see people complaining about how hard Git is anymore.


Denise: Yeah, yeah. Oh, my God, Git is so hard. I think the first-time I correctly did an interactive rebase—like, I typed all the arguments correctly. I think I just got up and did a lap around the office. [laugh]. There's just all this random stuff that you have to remember when you're using—especially some people use the desktop GUIs or whatever. I always just use command line. But it took forever and I still make a ton of mistakes with it.

Corey: Oh, we all do. That's the beautiful part of it. The nice thing is, “Oh, well the nice thing about Git is that nothing ever really gets truly lost.” And you say, “Well, how do you figure?” “Oh, I copy the entire directory to a backup before I do anything.” Which is on the one hand, awful version control and, two, has saved my bacon multiple times. So, if it's stupid and it works, it's not really stupid, now is it?


Denise: It's not stupid if it works. [laugh].

Corey: So, a passion project of yours that I want to talk about has been teaching people to submit to conferences, to give talks at conferences, to convince them that yes, you can do this and you're good at it, you have a story that people want to tell, the things you find easy are not easy for everyone. ‘Give that story voice’ has been a recurring theme that you do. How has that manifested during this year of isolation?


Denise: Ohh. This year’s definitely been tough. So, usually when I do that pitch, I run workshops specifically around a certain CFP. Like I help out conference organizers in the Toronto area. Like, I did a workshop for devopsdays last year, and another one for GoCon, also meant to be last year. 


And usually it's like, okay, here's how you write a strong proposal—and I'll have the committee in the room—and be like, here's what the committee is looking for; ask these people questions about what they would choose to program. And this is how you get your talk submitted. This is how you get accepted; you need to understand who your audience is. It's a product question. It's exactly the same mindset that you need to get into when you're playing product manager, or if you're actually a product manager. 

You need to understand who your target customer or audience is, what they're looking for, and how do you give that to them on a plate. This year, it's slowed down a lot, obviously because there have been fewer conferences, so I've just had fewer opportunities to do this kind of pitch without—it feels weird telling people to write talks without there being a place to submit a talk to. But I think—I found that there still is room for content creation, even if that isn't a conference talk. So, within the company, within my networks, I do try to encourage people to write blog posts. Err on the side of writing what you've learned; if you spent a couple days doing a technical investigation and you found it interesting, write it down so other people can learn about it. 


On the conference talk front, I think the unique benefit of doing conference talks and getting up on stage is you do build a personal brand. After a little while that kind of transcends the company that you're at, granted that you're not talking about your company's products in every single talk. 

Corey: Absolutely. And a lot of companies get profoundly insecure about that. And I'm sorry; they're wrong. That is not a bad thing. Anyone who gives a talk for your company will eventually become better known than your brand for some aspects and in some areas—harder at places like GitHub than it is Twitter for Pets, but that's okay—and you have to be okay with that and have a plan for how you're going to transition them out when they outgrow the role and move somewhere else. But that's okay. And companies that are insecure about that drive me up a wall.

Denise: Yeah, there have been a few times when I went to very cloud specific conferences and talked about things that my company is working for, but other times, I've gone to just very general conferences where it was just like, let's talk about Agile, or let's talk about software, like super, super generally. And the ones who have gone to the really general conferences and talk about things that matter to me—like cross-functional collaboration, or test driven development, or whatever it is—those are the ones that I've actually managed to get people to apply to my company without even saying that we're hiring. It's a little mind blowing.

Corey: It is. People want to work with interesting people, and when you find someone who's able to tell a story that touches you on some level, which is the point of telling stories, then at some point, the idea of I'd like to work with that person on ongoing basis becomes actively compelling. People ask so well, it's not like you could hire a whole lot of people who do what you do, so hiring and recruiting is going to be a problem. It's like, well, it is but it's because it's finding the right people with the right alignment, but we have an awful lot of candidates to choose from for basically any role, just because for better or worse, I make a splash.


Denise: Yeah, exactly.

Corey: So, as people are looking to get into the space and they're new to speaking, how do you get them to a point where there's at least a certain level of confidence? I would say, “How do you get them to not be terrified?” But I’ve been speaking almost full time for years, and I'm still scared to death every time I give a talk when I start out.

Denise: Me too. I'm still terrified. I almost switch into a different persona when I go on stage, and I don't remember anything that happens. I don't know what—maybe there's psychology [laugh] around this, but I literally blank out the 40 minutes that I'm on stage. So, the most common objection that I hear about why someone doesn't want to give a talk is they'll say, “But everybody already knows about this. The thing that I want to talk about has already been talked about. There's already too much content out there. I wouldn't add anything new.” 

And for a long time, my response to that was just, I don't care. I still want to hear what you have to say, you're going to offer a fresh perspective, you're going to offer a new experience, you're going to explain something in a way that clicks for someone. Your explanation might be the one that works for them that they haven't been able to figure out by listening to anybody else. So, I historically said those things, and I still one hundred percent those things, and I still say those things to people but I actually came across something interesting on Twitter today. Someone was actually talking about fanfiction. I don't know if you’ve written or read fanfiction in the past. When I was a kid I used to—

Corey: I can neither confirm nor deny…

Denise: [laugh]. There’s varying levels of fanfiction out there. But fanfiction communities are actually incredibly collaborative places. I remember being, I don't know, like a 10 or 11-year-old and writing a lot of anime fanfiction, basically just writing myself into the Pokemon universe and things like that. And we would post these on forums. 

It'd be forums of strangers working together, and we’d post drafts. And then we would give each other feedback on those drafts. And in the end, there'd be 60 different pieces of fanfiction, roughly about the same universe, every story is a little bit different, and nobody was ever self-conscious that this had already been done. Because the whole point of fanfiction is that there's a lot of it, the value of the community is in the fact that the content is abundant. Not that every single piece of content is unique. 


So, I think a similar thing is true for content that's technical storytelling. Just because someone else has said this thing before, it doesn't matter. The fact that there's more content out there about this thing is good for the community, building a community around this thing. So, I don't know, that was something that just resonated with me a lot, and I just really liked that framing.


Corey: We have this weird perspective that the things that we know are easy, the things we don't know are hard, so once you've learned how to do something, everyone else knows it. I mean, one of my most popular Twitter threads that exploded that I didn't see coming was just me talking about random things that live in my shell config file, and what they do. It's, “Well, this is stuff everyone knows, and everyone has something like this, right?” And it got into a dissection of what these things do, and how it works, and of course, it's snarky because that's my excuse for a personality, but it also shined a light on something that I forgot, once again: not everyone knows this. A lot of the viral tweets you see going around are people noticing something that we've all seen and been ignoring because that's just the way it is, and someone makes an observation about it and, oh, yeah, that's right. That is something that everyone can relate to.

Denise: Yeah. 


Corey: People want stories.


Denise: Yeah, exactly. I think about every six months, I try to retweet—every review cycle around mid-year, end-of-year. It’s like, “Hey, just a reminder, if someone on your team has done something for you write this down. Catalog what they did, write it down, send it to them, send it to their manager, put it into their file so they can use it at review time.” And every time I talk about this, I always get a ton of engagement. 


And I have to remind myself that this is not obvious. Even if someone was told to do this at some point in the past, reminding people to be deliberate and be active about giving each other peer feedback, writing stuff down. You just can't remind people to do that enough, I think.


Corey: Yeah, it's one of those things where, “Well, I've already given that talk, so I have to give a different one.” No, you don't, I promise you, you have not given your talk to everyone in the industry, and the reason I know that is because by that point, you would see the view count on YouTube or whatnot—or the video winds up—and be flabbergasted because the industry is bigger than anyone thinks. I feel like I tell the same joke from time to time, but they always get laughs from the audience because it's new to them. My business partner and my romantic partner find it incredibly challenging, both—those are two people, incidentally—they find it incredibly irritating because, “Yes, yes, we've heard that one.” And every once a while they sit up, “Oh, Corey got a new joke.” But the rest of the world doesn't respond that way.

Denise: Yeah, exactly. So, I don't know if we've talked about this already, but that closes the loop on the whole imposter syndrome piece where—just because I think one strain of imposter syndrome is telling yourself, just because I know this thing, means everybody else must also know it. I must be the last person in the world to learn this piece of information.

Corey: There is no piece of technology, or anything even tangentially related to technology, that you couldn't do a tweet thread on and people would learn things about it. How an if-then-else loop works, for example. That is—sorry—ahh—do you see what I'm talking about? That's exactly what I mean. See, I meant to say ‘Conditional,’ and instead I said ‘Loop’ and we all trip over these things; they're all challenging, and the fact that we can still learn new things about that of, how does a flow control conditional actually work? 


What does that mean? Sure, anyone who spends their days writing code all the time is going to have some topical understanding of it, but not everyone's going to, first, be that person, or secondly, understand why that's valuable and relevant. You could do an entire conference talk on nothing more than that concept alone and it would be a dynamite talk.

Denise: Yeah, exactly. I did go through a wave of imposter syndrome around last year, or maybe—uh, I don't even know what year is it. [laugh]. A little while back, I was feeling uncertain about this talk about distributed systems that I've done a few times. And then I got a random message on Twitter from a student who told me that she had just gotten her first engineering role out of university—ever, ever—and she said, I watched your talk on distributed systems; you gave me the vocabulary to talk about this stuff in an intelligent way, and I've landed my first role as an entry level—I forget exactly what kind of engineer but—I mean software engineering—but I forget if it was like infrastructure, or app dev, I don't know. But it was like, that kind of feedback, just—that's really cool to hear.


Corey: I'm going to take it a step further and request anyone listening to this who’s seen the talk that has potentially changed the way they view things or helped them advance in their career, track down whoever gave that talk and send them a message. One of the hardest parts about being a speaker is that you very rarely get feedback. I mean, even on this podcast, I almost never get direct feedback online. People talk to me about it in person, when they run into me at a conference, in the before times. But it's not a thing where people wind up drafting an email, “Dear sir, I found your podcast to be compelling, and also you are a jackass.” I would love letters like that.


Denise: Well, I don't love letters like that, so please don't write me letters like that. [laugh].

Corey: Well, in my case, they're well-deserved. In your case, it would just be offensive.


Denise: [laugh]. But yeah, reach out to those strangers whose content you've learned from, I think it can actually make someone's day.


Corey: Absolutely. So, on the other side of that, if someone's listening to this, and they want to start giving a talk, but they don't know where to start, how to build a CFP, where to begin, where should they start? What is the next step for those people?


Denise: So there's an initiative that I, in the before times, mentored and helped organize local chapters for. It's called Global Diversity CFP—it's either Global CFP Diversity or Global Diversity CFP, I always forget—day. And even if you're not a person who has a marginalized identity, they've done a really, really great job of consolidating a bunch of resources to get first-time speakers off the ground.

Corey: And we will put a link to that in the [show notes 00:36:34], of course.


Denise: Cool. So, I recommend reading through what they have. So it's actually an event that take place on a full day; it's a little bit different this year, I think they might be running it remotely this year. But all of their content is geared for first-time speakers, and they have a lot of material that's pepping people up to take the first step. But I would say that beyond that, the best way to get started, honestly, is to just pick a topic that you care about, and just try to write a talk. 

And if you don't have a place to deliver that talk—if there's no meetup, or conference or anything coming up, you should just record yourself giving the talk to your computer, actually. This is the thing that my debate coach used to have us do in college: the best way to improve as a speaker is to record yourself speaking and watch it. It's going to be terrible the first few times because you're going to be like, “Oh, God. I look so awkward.”


Corey: Power through it. I still can't watch myself speak.

Denise: [laugh]. Like, what are my hands doing? But you can only catch those things and improve at them once you're aware that you're doing them. So, that is the fastest way to improve your presence and your speaking ability.

Corey: Yeah. I want to thank you for taking the time to speak with me and go through all these various topics today. If people want to learn more about you, where can they find you?

Denise: So, you can find me on the internet on the cursed blue website at @deniseyu21 is my handle on Twitter. My personal website is deniseyu.io because—I used to have .com but some kids stole it and squatted on it after I forgot to renew it. So I'm not deniseyu.com anymore.

Corey: Yeah, the joy of changing usernames on different platforms and the rest. I hear you.


Denise: Yeah. Yeah, probably those two places. If you want to talk about anything that I talked about on the podcast, feel free to DM me on Twitter. Please don't send me mean feedback that starts with “Dear sir,” in my Twitter DMs, but other than that, I—

Corey: Generally never a good plan for anyone.


Denise: [laugh]. No. 


Corey: Thanks so much for taking the time to speak with me. I really appreciate it.

Denise: Yeah. Thanks so much, Corey for having me on. It was a lot of fun. I feel like we covered a lot of ground. Probably too much. [laugh].


Corey: It really was. And we did. Denise Yu, senior software engineer at Jif-ub. 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 comment containing a correctly formatted Git rebase command.


Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey atscreaminginthecloud.com, or wherever fine snark is sold.


This has been a HumblePod production. Stay humble.
Play Episode
Writing the Book(s) on Amazon with Brad Stone
Screaming in the Cloud
05.11.2021
45 Minutes
About Brad
Author and Senior Executive Editor, Bloomberg Technology

Brad Stone is the author of four books, including Amazon Unbound: Jeff Bezos and the Invention of a Global Empire,published by Simon & Schuster in May 2021. It traces the transformation of Amazon into one of the largest and most feared companies of the world and the accompanying emergence of Jeff Bezos as the richest man alive. Brad is also the author of The Everything Store: Jeff Bezos and the Age of Amazon, which chronicled the foundational early years of the company and its founder. The book, a New York Times and Wall Street Journal bestseller, was translated into more than 35 languages and won the 2013 Financial Times/Goldman Sachs Business Book of the Year Award. In 2017, he also published The Upstarts: Uber, Airbnb, and the Battle for the New Silicon Valley.
Brad is Senior Executive Editor for Global Technology at Bloomberg Newswhere he oversees a team of 65 reporters and editors that covers high-tech companies, startups, cyber security and internet trends around the world. Over the last ten years, as a writer for Bloomberg Businessweek, he’s authored over two dozen cover stories on companies such as Apple, Google, Amazon, Softbank, Twitter, Facebook and the Chinese internet juggernauts Didi, Tencent and Baidu. He’s a regular contributor to Bloomberg’s technology newsletter Fully Charged, and to the daily Bloomberg TV news program, Bloomberg Technology. He was previously a San Francisco-based correspondent for The New York Times and Newsweek. A graduate of Columbia University, he is originallyfrom Cleveland, Ohio and lives in the San Francisco Bay Area with his wifeand three daughters

Links:
Transcript


Announcer: 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.



Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.


Corey: This episode is sponsored in part by VMware. Because let’s face it, the past year hasn’t been kind to our AWS bills, or honestly any cloud bills. The pandemic had a bunch of impacts: it forced us to move workloads to the cloud sooner than we would have otherwise, we saw strange patterns such as user traffic drops off but infrastructure spend doesn’t. What do you do about it? Well, the CloudLIVE 2021 virtual conference is your chance to connect with people wrestling with the same type of thing, be they practitioners, vendors in the space, leaders of thought—ahem, ahem—and get some behind the scenes look into various ways different companies are handling this. Hosted by CloudHealth by VMware on May 20, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Visit cloudlive.com/coreyto learn more and save your virtual seat today. That’s cloud L-I-V-E slash Corey. C-O-R-E-Y. Drop the E, we’re all in trouble. My thanks to VMware for sponsoring this ridiculous episode.



Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. Sometimes people tell me that I should write a book about Amazon. And that sounds awful. But to be sure, today, my guest is Brad Stone, someone who has written not one, but two books about Amazon, one of which coming out on May 11th, or as most of you will know while listening to this, today. Brad, thanks for joining me.


Brad: Corey, thanks for having me.



Corey: So, what on earth would inspire you to not just write a book about one of what is in many ways an incredibly secretive company, but then to go back and do it again?



Brad: Yeah. I’m a glutton for punishment. And Corey, my hair right now is completely white way before it should be, and I think that Amazon might be responsible for some of that. So, as you contemplate your own project, consider that this company—will you already know: it can age you. They are sometimes resistant to scrutiny.



So, to answer your question, I set out to write The Everything Store back in 2011, and this was a much smaller company. It was a cute little tiny internet company of about $100 billion in market value. And poor, impoverished Jeff Bezos maybe had, I’d be guessing maybe $50 billion.



So anyway, it was a much different time. And that was a great experience. The company was kind of flowering as the book came out. And to my surprise, it was embraced not by Bezos or the management team, who maybe we’ll talk about didn’t love it, but by Amazon employees, and customers, and competitors, and prospective employees. And I was really proud of it that this had become a kind of definitive account of the early years of the company.


And then a funny thing happened. The little cute little internet company became a juggernaut, a $1.5 trillion market cap. Bezos is the wealthiest guy in the world now with a $200 billion fortune, and Alexa, and the rise of AWS, and the Go store, and incursions into India and Mexico and other countries, I mean, so much had changed, and my definitive history felt a little out of date. And so back in 2017—also a different world, Bezos is a happily married man; he’s the CEO of Amazon, Amazon’s headquarters are in Seattle only—I set out to research and write Amazon Unbound. And as I was writing the story, yeah, just, like, the ground kept shifting under my feet.



Corey: Not a lot changes in the big sphere. I mean, one of the things that Bezos said is, “Oh, what’s going to be different in 10 years? I think the better question is, ‘what’s going to not be different in 10 years?’” but watching the company shift, watching it grow, just from the outside has been a real wild ride, I’ve got to say. And I restrict myself primarily to the AWS parts because well, there’s too much to cover if you go far beyond that, and two, it’s a very different place with very different challenges around it.



I viewed The Everything Store when it came out and I read that, almost like it was a biography of Jeff Bezos himself. And in some respects, Amazon Unbound feels like it hews in that direction as well, but it also goes beyond that. How do you approach separating out the story of Amazon from the story of Jeff Bezos?



Brad: Yeah, you’re putting your finger on almost the core challenge, and the adjoining challenge, which is how do you create a narrative, a linear story? Often readers want a chronological story out of a miasma of overlapping events, and initiatives, and challenges. Amazon’s really decentralized; everything is happening at once. Bezos is close to some things, he was very close to Alexa. He is really distant from other things.



Andy Jassy for years had a lot of independence to run AWS. So, how do you tell that story, and then keep Bezos in the center? I mean, Andy Jassy and Jeff Wilke and everyone, I mean, those are great business people. Not necessarily dynamic personalities as, Corey, you know well, but people want to read about Jeff Bezos. He is a larger-than-life figure.


He’s a pioneer. He’s an innovator. He’s controversial. And so the challenge all along is to, kind of, keep him in the center. And so that’s just, like, a writing challenge. It’s a narrative challenge.



And the lucky thing is that Amazon does tend to orbit around Jeff Bezos’s brain. And so in all the storytelling, even the AWS bits of the book, which we can talk about, as an author, you can always bring Bezos back just by following the facts. You’ll eventually get, in the evolution of any story, to an S Team meeting, or to an acquisition discussion where Jeff had an impact, said something insightful, walked out of a meeting, raise the bar, had impossibly high standards. So, the last thing I’ll say is, because Amazon’s so decentralized, when you write these books you have to talk to a lot of people. And then you get all the pieces of the puzzle, and you start to assemble them, and the challenge as a writer is to, kind of, keep Bezos, your main character in the lens at all times, never let him drift too far out.



Corey: One of the things that I learned from it was just the way that Bezos apparently talks to his senior executives, as far as, “I will invest in this project, more than you might think I would.” I guess I’ve never really heard of a budget meeting talking about, “I”—in the first person—“Will invest.” Like, that is what happens, but for some reason the business books never put it quite that starkly or frame it quite that way. But in hindsight, it made a lot of things of my own understanding of Amazon fall into place. That makes sense.



Brad: He’s got a lot of levers, ways in which he’ll back a new initiative or express his support. And one of them is simply how he spends his time. So, with Alexa in the early years, he would meet once or twice a week with that team. But another lever is just the amount of investment. And oftentimes teams will come to him—the India team is a great example—they’ll come to the S Team with a budget, and they’ll list out their priorities and their goals for the coming year, and he’ll say, “You know, you’re thinking about this all wrong. Don’t constrain yourself. Tell us what the goals are, tell us what the opportunity is, then we’ll figure out how much it costs.”



And his mindset is like you can kind of break up opportunity into two categories: one are the land grabs, the big immediate opportunities where he will go all out, and India was a great example of that, I think the failed fire phone was another example, Prime Video, he doesn’t cap the investment, he wants to win. And then there are the more greenfield opportunities that he thinks he can go slower on and groceries for a long time was in that category. And there the budgets might be more constrained. The other example is the much older businesses, just like the retail business. That’s 20 years old—I have a chapter about that—and the advertising business, and he recognized that the retail business wasn’t profitable and it was depending on advertising as a crutch, and he blew it up because he thinks that those older divisions shouldn’t require investment; they should be able to stand on their own.



Corey: One quote you had as well, that just really resonated with me, as far as basically my entire ethos of how I make fun of Amazon is—and I’m going to read the excerpt here. My apologies. You have to listen to your own words being read back toward you—


Brad: [laugh].



Corey: These were typically Amazonian names: geeky, obscure, and endlessly debated inside AWS since—according to an early AWS exec—Bezos had once mused, “You know, the name is about 3% of what matters, but sometimes 3% is the difference between winning and losing.” And I just want to call that out because I don’t think I’ve ever seen an AWS exec ever admit that names might be even 3% worth of important. Looking at how terrible some of their service names are, I would say that 3% might be an aspirational target for their worldview.



Brad: [laugh]. Let me throw this back at you, Corey. Have you ever figured out why certain AWS services are Amazon and why others are AWS?



Corey: I did. I got to sit down—in the before times—with then the VP of Global Marketing, Ariel Kelman—who’s now Oracle’s Chief Marketing Officer—and Jeff Barr. And the direction that they took that in was that if you could use an AWS service without getting into the AWS weeds of a bunch of other services, then it was called Amazon whatever. Amazon S3, for example, as a primitive service doesn’t need a bunch of other AWS services hooked into it, so that gets the Amazon moniker. Whereas if you’re dealing with a service that requires the integration of a whole bunch of AWS in the weeds stuff—



Brad: Mmm, right.


Corey: —then it’s AWS. For example, AWS Systems Manager is useless without a whole bunch of other Amazon services. And they say they don’t get it perfectly right all the time, but that is the direction that it’s gone in. And for better or worse, I still have to look a lot of them up myself because I don’t care nearly as much as their branding people do.


Brad: Right. Well, I’ll tell you in the chapter about AWS, that quote comes up when the team is contemplating the names of the databases. And they do go into long debates, and I remember talking to Charlie Bell about the search for Redshift, and they go back and forth on it, and the funny thing about that one was, of course, Oracle interpreted it as a competitive slight. Its corporate color, I guess, being red, which he intended it more as a physics term. But yeah, when they were launching Aurora and Redshift, they contemplated those names quite a bit. And I don’t know if it’s 3%. I don’t know if it does matter, but certainly, those services have become really important to a lot of businesses.


Corey: Oh, yeah. And once you name something, it’s really hard to rename it. And AWS does view for—better or worse—APIs as a promise, so when you build something and presented a certain way, they’re never going to turn it off. Our grandkids are going to have to deal with some of these decisions once they get into computers. That’s a problem.


And I understand the ethos behind it, but again, it’s easy to make fun of names; it’s an accessible thing because let’s be very real here, a lot of what AWS does is incredibly inaccessible to people who don’t live in this space. But naming is something that everyone can get behind making fun of.


Brad: Absolutely. Yep. And [laugh] it’s perhaps why they spend a lot of time on it because they know that this is going to be the shingle that they hang out to the world. I don’t know that they’re anticipating your ridicule, but it’s obviously key to the marketing process for them.


Corey: Some of the more aware ones do. But that’s a different topic for a different time. One question I have for you that I wrestle with myself is I’ve been spending the last four years or so basically studying AWS all the time. And there’s a lot of things they get right; there’s a lot of things that they get wrong. But for better or worse, it’s very difficult not to come away from an in-depth study with an appreciation for an awful lot of the things that they do. At least for me.


I’m not saying that I fall in love with the company and will excuse them their wrongs; I absolutely do not do that. But it is hard, bordering on impossible for me, to not come away with a deep respect for a lot of the things that they do and clearly believe. How do you feel about that? Looking at Amazon, do you come away with this with, “Ooh. Remind me to never to become a Prime member and get rid of everything with an Amazon logo in my house,” versus the you’re about to wind up wondering if they can hire you for some esoteric role? Where do you fall on that spectrum?


Brad: I think I’m probably with you. I come away with an admiration. And look, I mean, let me say upfront, I am a Prime member. I have a Alexas in my home, probably more than my wife and kids are comfortable with. We watch Prime Video, we have Prime Video.


We order from Amazon all the time, we ordered from Whole Foods. I’m an Amazon customer, and so part of my appreciation comes from, like all other customers, the fact that Amazon uniquely restores time to our lives rather than extracts it. I wouldn’t say that about the social networks, right? You know, those can be time-wasters. Amazon’s a great efficiency machine.



But in terms of my journalism, you know, now two books and this big in-depth study in Amazon Unbound, and you have to admire what they have built. I mean, a historic American institution that has not only changed our economic reality, in ways good and bad but over the last year and a half, in the pandemic was among the few institutions that functioned properly and served as a kind of lifeline. And there is a critique in Amazon Unbound and we can talk about it, but it’s hard to come away—I think you said it well—it’s hard to come away after studying this company and studying the top executives, and how Jeff Bezos, thinks and how he has conceived products without real admiration for what they have built over the last 25 years.



Corey: Well, let’s get into your critique of Amazon. What do you think is, from what you’ve seen with all of the years of research you put into this company, what’s the worst thing about them?


Brad: Well, that’s a good way to put it, Corey. [laugh]. Let me—


Corey: [laugh]. It’s like, talk about a target-rich opportunity. Like, “Oh, wow. It’s like my children. I can’t stand any of them. How in the world could I pick just one?” But give it a shot.



Brad: Right. Well, let me start this way, which is I often will listen to their critiques from Amazon critics—and I’m sure you might feel this way as well—and just think, like, “Do they get it?” They’ll argue that Amazon exercised its size and might to buy the companies that led to Alexa. As I write in the Alexa chapter, that’s not true at all. They bought a couple of small companies, and those executives were all horrified at what Amazon was trying to do, and then they made it work.


Or the critics will say, “Fifty percent or more of internet users start their product searches on Amazon. Amazon has lock-in.” That’s not true either. Lock-in on the internet is only as strong as a browser window that remains open. And you could always go find a competitor or search on a search engine.


So, I find at least some of the public criticism to be a little specious. And often, these are people that complained about Walmart for ten years. And now Amazon’s the big, bad boogeyman.



Corey: Oh, I still know people who refuse to do business with Walmart but buy a bunch of stuff from Amazon, and I’m looking at these things going, any complaints you have about Walmart are very difficult to avoid mapping to Amazon.


Brad: Here’s maybe the distillation of the critique that’s an Amazon Unbound. We make fun of Facebook for, “Move fast and break things.” And they broke things, including, potentially, our democracy. When you look at the creation of the Amazon Marketplace, Jeff wanted a leader who can answer the question, “How would you bring a million sellers into the Amazon Marketplace?” And what that tells you is he wanted to create a system, a self-service system, where you could funnel sellers the world over into the system and sell immediately.


And that happened, and a lot of those sellers, there was no friction, and many of them came from the Wild West of Chinese eCommerce. And you had—inevitably because there were no guardrails—you had fraud and counterfeit, and all sorts of lawsuits and damage. Amazon moved fast and broke things. And then subsequently tried to clean it up. And if you look at the emergence of the Amazon supply chain and the logistics division, the vans that now crawl our streets, or the semi-trailers on our highways, or the planes.



Amazon moved fast there, too. And the first innings of that game were all about hiring contractors, not employees, getting them on the road with a minimum of guidance. And people died. There were accidents. You know, there weren’t just drivers flinging packages into our front yards, or going to the bathroom on somebody’s porch.



That happened, but there were also accidents and costs. And so I think some of the critique is that Amazon, despite its profession that it focuses only on customers, is also very competitor-aware and competitor-driven, and they move fast, often to kind of get ahead of competitors, and they build the systems and they’re often self-service systems, and they avoid employment where it’s possible, and the result have been costs to society, the cost of moving quickly. And then on the back-end when there are lawsuits, Amazon attempts to either evade responsibility or settle cases, and then hide those from the public. And I think that is at the heart of what I show in a couple of ways in Amazon Unbound. And it’s not just Amazon; it’s very typical right now of corporate America and particularly tech companies.



And part of it is the state of the laws and regulations that allow the companies to get away with it, and really restrict the rights of plaintiffs, of people who are wronged from extracting significant penalties from these companies and really changing their behavior.



Corey: Which makes perfect sense. I have the luxury of not having to think about that by having a mental division and hopefully one day a real division between AWS and Amazon’s retail arm. For me at least, the thing I always had an issue with was their treatment of staff in many respects. It is well known that in the FAANG constellation of tech companies, Facebook, Amazon, Apple, Netflix, and Google, apparently, it’s an acronym and it’s cutesy. People in tech think they’re funny.


But the problem is that Amazon’s compensation is significantly below that. One thing I loved in your book was that you do a breakdown of how those base salaries work, how most of it is stock-based and with a back-loaded vesting and the rest, and looking through the somewhat lengthy excerpt—but I will not read your own words to you this time—it more or less completely confirms what I said in my exposé of this, which means if we’re wrong, we’re both wrong. And we’ve—and people have been very convincing and very unified across the board. We’re clearly not wrong. It’s nice to at least get external confirmation of some of the things that I stumble over.



Brad: But I think this is all part of the same thing. What I described as the move fast and break things mentality, often in a race with competition, and your issues about the quality, the tenor of work, and the compensation schemes, I think maybe and this might have been a more elegant answer to your question, we can wrap it all up under the mantle of empathy. And I think it probably starts with the founder and soon-to-be-former CEO. And look, I mean, an epic business figure, a builder, an inventor, but when you lay out the hierarchy of qualities, and attributes, and strengths, maybe empathy with the plight of others wasn’t near the top. And when it comes to the treatment of the workforce, and the white-collar employees, and the compensation schemes, and how they’re very specifically designed to make people uncomfortable, to keep them running fast, to churn them out if they don’t cut it, and the same thing in the workforce, and then the big-scale systems and marketplace and logistics—look, maybe empathy is a drag, and not having it can be a business accelerant, and I think that’s what we’re talking about, right?



That some of these systems seem a little inhumane, and maybe to their credit, when Amazon recognizes that—or when Jeff has recognized it00, he’s course-corrected a little bit. But I think it’s all part of that same bundle. And maybe perversely, it’s one of the reasons why Amazon has succeeded so much.



Corey: I think that it’s hard to argue against the idea of culture flowing from the top. And every anecdote I’ve ever heard about Jeff Bezos, never having met the man myself, is always filtered through someone else; in many cases, you. But there are a lot of anecdotes from folks inside Amazon, folks outside Amazon, et cetera, and I think that no one could make a serious argument that he is not fearsomely intelligent, penetratingly insightful, and profoundly gifted in a whole bunch of different ways. People like to say, “Well, he started Amazon with several $100,000 and loan from his parents, so he’s not really in any ways a self-made anything.” Well, no one is self-made. Let’s be very clear on that.



But getting a few $100,000 to invest in a business, especially these days, is not that high of a stumbling block for an awful lot of folks similarly situated. He has had outsized success based upon where he started and where he wound up ending now. But not a single story that I’ve ever heard about him makes me think, yeah, that’s the kind of guy I want to be friends with. That’s the kind of guy I want to invite to a backyard barbecue and hang out with, and trade stories about our respective kids, and just basically have a social conversation with. Even a business conversation doesn’t feel like it would be particularly warm or compelling.



It would be educational, don’t get me wrong, but he doesn’t strike me as someone who really understands empathy in any meaningful sense. I’m sure he has those aspects to him. I’m sure he has a warm, wonderful relationship with his kids, presumably because they still speak to him, but none of that ever leaks through into his public or corporate persona.


Brad: Mmm, partially agree, partially disagree. I mean, certainly maybe the warmth you’re right on, but this is someone who’s incredibly charismatic, who is incredibly smart, who thinks really deeply about the future, and has intense personal opinions about current events. And getting a beer with him—which I have not done—with sound fantastic. Kicking back at the fireplace at his ranch in Texas, [laugh] to me, I’m sure it’s tremendously entertaining to talk to him. But when it comes to folks like us, Corey, I have a feeling it’s not going to happen, whether you want to or not.



He’s also incredibly guarded around the jackals of the media, so perhaps it doesn’t make a difference one way or another. But, yeah, you’re right. I mean, he’s all business at work. And it is interesting that the turnover in the executive ranks, even among the veterans right now, is pretty high. And I don’t know, I mean, I think Amazon goes through people in a way, maybe a little less on the AWS side. You would know that better than me. But—



Corey: Yes and no. There’s been some turnover there that you can also pretty easily write down to internal political drama—for lack of a better term—palace intrigue. For lack of a better term. When, for example, Adam Selipsky is going to be the new CEO of AWS as Andy Jesse ascends to be the CEO of all Amazon—the everything CEO as it were. And that has absolutely got to have rubbed some people in unpleasant ways.



Let’s be realistic here about what this shows: he quit AWS to go be the CEO of Tableau, and now he’s coming back to run AWS. Clearly, the way to get ahead there is to quit. And that might not be the message they’re intending to send, but that’s something that people can look at and take away, that leaving a company doesn’t mean you can’t boomerang and go back there at a higher level in the future.



Brad: Right.



Corey: And that might be what people are waking up to because it used to be a culture of once you’re out, you’re out. Clearly not the case anymore. They were passed over for a promotion they wanted, “Well, okay, I’m going to go talk to another company. Oh, my God, they’re paying people in yachts.” And it becomes, at some level, time for something new.


I don’t begrudge people who decide to stay; I don’t begrudge people who decide to leave, but one of my big thrusts for a long time has been understand the trade-offs of either one of those decisions and what the other side looks like so you go into it with your eyes open. And I feel like, on some level, a lot of folks there didn’t necessarily feel that they could have their eyes open in the way that they can now.



Brad: Mm-hm. Interesting. Yeah. Selipsky coming back, I never thought about that, sends a strong message. And Amazon wants builders, and operators, and entrepreneurial thinking at the top and in the S Team. And the fact that Andy had a experienced leadership team at AWS and then went outside it for the CEO could be interpreted as pretty demotivating for that team. Now, they’ve all worked with Adam before, and I’ve met him and he seems like a great guy so maybe there are no hard feelings, but—



Corey: I never have. He left a few months before I started this place. So, it—I get the sense that he knew I was coming and said, “Well, better get out of here. This isn’t going to go well at all.”


Brad: [laugh]. I actually went to interview him for this book, and I sat in his office at Tableau thinking, “Okay, here’s a former AWS guy,” and I got to tell you, he was really on script and didn’t say anything bad, and I thought, “Okay, well, that wasn’t the best use of my time.” He was great to meet, and it was an interesting conversation, but the goss he did not deliver. And so when I saw that he got this job, I thought, well, he’s smart. He smartly didn’t burn any bridges, at least with me.


Corey: This episode is sponsored in part by our friends at ChaosSearch., you could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like HubSpot, Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.



Corey: No. And it’s pretty clear that you don’t get to rise to those levels without being incredibly disciplined with respect to message. I don’t pity Andy Jesse’s new job wherein a key portion of the job description is going to be testifying before Congress. Without going into details, I’ve been in situations where I’ve gotten to ask him questions before in a real-time Q&A environment, and my real question hidden behind the question was, “How long can I knock him off of his prepared talking points?” Because I—


Brad: Good luck. [laugh].



Corey: Yeah. I got the answer: about two and a half seconds, which honestly was a little bit longer than I thought I would get. But yeah, incredibly disciplined and incredibly insightful, penetrating answers, but they always go right back to talking points. And that’s what you have to do at that level. I’ve heard stories—it may have been from your book—that Andy and Adam were both still friendly after Adam’s departure, they would still hang out socially and clearly, relationships are still being maintained, if oh, by the way, you’re going to be my successor. It’s kind of neat. I’m curious to see how this plays out once that transition goes into effect.



Brad: Yeah, it’ll be interesting. And then also, Andy’s grand homecoming to the other parts of the business. He started in the retail organization. He was Jeff’s shadow. He ran the marketing department at very early Amazon.



He’s been in all those meetings over the years, but he’s also been very focused on AWS. So, I would imagine there’s a learning curve as he gets back into the details of the other 75% of Amazon.



Corey: It turns out that part of the business has likely changed in the last 15 years, just a smidgen when every person you knew over there is now 10,000 people. There was an anecdote in your book that early on in those days, Andy Jesse was almost let go as part of a layoff or a restructuring, and Jeff Bezos personally saved his job. How solid is that?



Brad: Oh, that is solid. An S Team member told me that, who was Andy’s boss at the time. And the story was, in the late 90s—I hope I remember this right—there was a purge of the marketing department. Jeff always thought that marketing—in the early days marketing was purely satisfying customers, so why do we need all these people? And there was a purge of the marketing department back when Amazon was trying to right-size the ship and get profitable and survive the dotcom bust.


And Jeff intervened in the layoffs and said, “Not Andy. He’s one of the most—yeah, highest ceiling folks we have.” And he made him his first full-time shadow. Oh, and that comes right from an S Team member. I won’t say the name because I can’t remember if that was on or off the record.



But yeah, it was super interesting. You know what? I’ve always wondered how good of a identifier of talent and character is Bezos. And he has some weaknesses there. I mean, obviously, in his personal life, he certainly didn’t identify Lauren Sánchez’s brother as the threat that he became.



You know, I tell the story in the book of the horrific story of the CEO of Amazon Mexico, who Jeff interviewed, and they hired and then later ended up what appears to be hiring an assassin to kill his wife. I tell the story in the book. It’s a horrible story. So, not to lay that at the feet of Jeff Bezos, of course, but he often I think, moves quickly. And I actually have a quote from a friend of his in the book saying, “It’s better to not be kind of paranoid, and the”—sort of—I can’t remember what the quote is.



It’s to trust people rather than be paranoid about everyone. And if you trust someone wrongly, then you of course-correct. With Andy, though, he somehow had an intuitive sense that this guy was very high potential, and that’s pretty impressive.


Corey: You’re never going to bet a thousand. There’s always going to be people that slip through the cracks. But learning who these people are and getting different angles on them is always interesting. Every once in a while—and maybe I’m completely wrong on this, but never having spent time one on one with Andy Jassy, I have to rely on other folks and different anecdotes, most of them, I can’t disclose the source of, but every time that I wind up hearing about these stories, and maybe I’m projecting here, but there are aspects of him where it seems like there is a genuinely nice person in there who is worried, on some level, that people are going to find out that he’s a nice person.



Brad: [laugh]. I think he is. He’s extraordinarily nice. He seems like a regular guy, and what’s sort of impressive is that obviously he’s extraordinarily wealthy now, and unlike, let’s say Bezos, who’s obviously much more wealthy, but who, who really has leaned into that lifestyle, my sense is Andy does not. He’s still—I don’t know if he’s on the corporate jet yet, but at least until recently he wasn’t, and he presents humbly. I don’t know if he’s still getting as close from wherever, [unintelligible 00:32:50] or Nordstroms.


Corey: He might be, but it is clear that he’s having them tailored because fit is something—I spent a lot of time in better years focusing on sartorial attention, and wherever he’s sourcing them from aside, they fit well.



Brad: Okay, well, they didn’t always. Right?


Corey: No. He’s, he’s… there’s been a lot of changes over the past decade. He is either discovered a hidden wellspring of being one of the best naturally talented speakers on the planet, or he’s gone through some coaching to improve in those areas. Not that he was bad at the start, but now he’s compelling.



Brad: Okay. Well, now we’re talking about his clothes and his speaking style. But—



Corey: Let’s be very honest here. If he were a woman, we would have been talking about that as the beginning topic of this. It’s on some level—



Brad: Or we wouldn’t have because we’d know it’s improper these days.



Corey: We would like to hope. But I am absolutely willing to turn it back around.



Brad: [laugh]. Anyway.


Corey: So, I’m curious, going back a little bit to criticisms here, Amazon has been criticized roundly by regulators and Congress and the rest—folks on both sides of the aisle—for a variety of things. What do you see is being the fair criticisms versus the unfair criticisms?



Brad: Well, I mean, I think we covered some of the unfair ones. But there’s one criticism that Amazon uses AWS to subsidize other parts of the business. I don’t know how you feel about that, but until recently at least, my reading of the balance sheet was that the enormous profits of AWS were primarily going to buy more AWS. They were investing in capital assets and building more data centers.


Corey: Via a series of capital leases because cash flow is king in how they drive those things there. Oh, yeah.


Brad: Right. Yeah. You know, and I illustrate in the book how when it did become apparent that retail was leaning on advertising, Jeff didn’t accept that. He wanted retail to stand on its own, and it led to some layoffs and fiercer negotiations with brands, higher fees for sellers. Advertising is the free cash flow that goes in Prime movies, and TV shows, and Alexa, and stuff we probably don’t know about.



So, this idea that Amazon is sort of improperly funneling money between the divisions to undercut competitors on price, I think we could put that in the unfair bucket. In the fair bucket, those are the things that we can all look at and just go, “Okay, that feels a little wrong.” So, for an example, the private brand strategy. Now, of course, every supermarket and drugstore is going to line their shelves with store brands. But when you go to an Amazon search results page these days, and they are pockmarked with Amazon brands, and Whole Foods brands, and then sponsored listings, the pay-to-play highest bidder wins.



And then we now know that, at least for a couple of years, Amazon managers, private label managers were kind of peeking at the third-party data to figure out what was selling and what they should introduce is a private Amazon brand. It just feels a little creepy that Amazon as the everything store is so different than your normal Costco or your drugstore. The shelves are endless; Amazon has the data, access to the data, and the way that they’re parlaying their valuable real estate and the data at their disposal to figure out what to launch, it just feels a little wrong. And it’s a small part of their business, but I think it’s one where they’re vulnerable. The other thing is, in the book, I tried to figure out how can I take the gauge of third-party sellers?


There’s so many disgruntled voices, but do they really speak for everyone? And so instead of going to the enemies, I went to every third-party seller that had been mentioned in Jeff Bezos’s shareholder letters over the past decade. And these were the allies. These were the success stories that Bezos was touting in his sacrosanct investor letter, and almost to a one, they had all become disgruntled. And so the way in which the rules of the marketplace change, the way that the fees go up, and the difficulty that sellers often have in getting a person or a guiding hand at Amazon to help them with those changes, that kind of feels wrong.


And I think that maybe that’s not a source of regulation, but it could be a source of disruptive competition. If somebody can figure out how to create a marketplace that caters to sellers a little better with lower fees, then they could do to Amazon with Amazon years ago did to eBay. And considering that Marketplace is now a preponderance of sales more than even retail on amazon.com, that can end up hurting the company.


Corey: Yeah, at some point, you need to continue growing things, and you’ve run out of genuinely helpful ways, and in turn in start to have to modify customer behavior in order to continue doing things, or expand into brand new markets. We saw the AWS bleeding over into Alexa as an example of that. And I think there’s a lot of interesting things still to come in spaces like that. It’s interesting watching how the Alexa ecosystem has evolved. There’s still some very basic usability bugs that drive me nuts, but at the same token, it’s not something that I think we’re going to see radically changing the world the next five years. It feels like a hobby, but also a lucrative one, and keeps people continuing to feed into the Amazon ecosystem. Do you see that playing out differently?


Brad: Wait, with Alexa?



Brad: Absolutely.



Brad: Yeah. I agree with you. I mean, it feels like there was more promise in the early years, and that maybe they’ve hit a little bit of a wall in terms of the AI and the natural language understanding. It feels like the ecosystem that they tried to build, the app store-like ecosystem of third-party skills makers, that hasn’t crystallized in the way we hoped—in the way they hoped. And then some of these new devices like the glasses or the wristband that have Alexa feel, just, strange, right?



Like, I’m not putting Alexa on my face. And those haven’t done as well. And so yeah, I think they pioneered a category: Alexa plays music and answers basic queries really well, and yet it hasn’t quite been conversational in the way that I think Jeff Bezos had hoped in the early days. I don’t know if it’s a profitable business now. I mean, they make a lot of money on the hardware, but the team is huge.


I think it was, like, 10,000 people the last I checked. And the R&D costs are quite large. And they’re continuing to try to improve the AI, so I think Jeff Bezos talks about the seeds, and then the main businesses, and I don’t think Alexa has graduated yet. I think there’s still a little bit of a question mark.



Corey: It’s one of those things that we remain to see. One last thing that I wanted to highlight and thank you for, was that when you wrote the original book, The Everything Store, Andy Jassy wrote a one-star review. It went into some depth about all the things that, from his perspective, you got wrong, were unfair about, et cetera.



And that can be played off as a lot of different things, but you can almost set that aside for a minute and look at it as the really only time in recent memory that Andy Jassy has sat down and written something, clearly himself, and then posted it publicly. He writes a lot—Amazon has a writing culture—but they don’t sign their six-pagers. It’s very difficult to figure out where one person starts and one person stops. This shows that he is a gifted writer in many respects, and I don’t think we have another writing sample from him to compare it to.



Brad: So, Corey, you’re saying I should be honored by his one-star review of The Everything Store?


Corey: Oh, absolutely.


Brad: [laugh].


Corey: He, he just ignores me. You actually got a response.



Brad: I got a response. Well.



Corey: And we’ll put a link to that review in the [show notes 00:40:10] because of course we will.



Brad: Yes, thank you. Do you—remember, other Amazon executives also left one-star reviews. And Jeff’s wife, and now ex-wife Mackenzie left a one-star review. And it was a part of a, I think a little bit of a reflexive reaction and campaign that Jeff himself orchestrated at my—this was understanding now, in retrospect. After the book came out, he didn’t like it.


He didn’t like aspects of his family life that were represented in the book, and he asked members of the S Team to leave bad reviews. And not all of them did, and Andy did. So, you wonder why he’s CEO now. No, I’m kidding about that. But you know what?


It ended up, kind of perversely, even though that was uncomfortable in the moment, ended up being good for the first book. And I’ve seen Andy subsequently, and no hard feelings. I don’t quite remember what his review said. Didn’t it, strangely, like, quote a movie or something like that?


Corey: I recall that it did. It went in a bunch of different directions, and at the end—it ended with, “Well, maybe someday he’ll write the actual story. And I’m not trying to bait anyone into doing it, but this book isn’t it.” Well, in the absence of factual corrections, that’s what we go with. That is also a very Amazonian thing. They don’t tell their own story, but they’re super quick to correct the record—



Brad: Yeah.



Corey: —after someone says a thing.



Brad: But I don’t recall him making many specific claims of anything I got wrong. But why don’t we hope that there’s a sequel review for Amazon Unbound? I will look forward to that from Andy.



Corey: I absolutely hope so. It’s one of those things that we just really, I guess, hope goes in a positive direction. Now, I will say I don’t try to do any reviews that are all positive. And that’s true. There’s one thing that you wrote that I vehemently disagree with.


Brad: Okay, let’s hear it.



Corey: Former Distinguished Engineer and VP at AWS, Tim Bray, who resigned on conscientious objector grounds, more or less, has been a guest on the show, and I have to say, you did him dirty. You described him—


Brad: How did I—what did I do? Mm-hm.



Corey: Oh, I quote, “Bray, a fedora-wearing software developer”—which is true, but still is evocative in an unpleasant way—“And one of the creators of the influential web programming language, XML”—which is true, but talk about bringing up someone’s demons to haunt them. Oh, my starts.


Brad: [laugh]. But wait. How is the fedora-wearing pejorative?



Corey: Oh, it has a whole implication series of, and entire subculture of the gamer types, people who are misogynist, et cetera. It winds up being an unfair characterization—



Brad: But he does wear a fedora.


Corey: He does. And he can pull it off. He has also mentioned that he is well into retirement age, and it was a different era when he wore one. But that’s not something that people often will associate with him. It’s—


Brad: I’m so naive. You’re referring to things that I do not understand what the implication was that I made. But—


Corey: Oh, spend more time with the children of Reddit. You’ll catch on quickly.



Brad: [laugh]. I try, I try not to do that. But thank you, Corey.



Corey: Of course. So, thank you so much for taking the time to go through what you’ve written. I’m looking forward to seeing the reaction once the book is published widely. Where can people buy it? There’s an easy answer, of course, of Amazon itself, but is there somewhere you would prefer them to shop?



Brad: Well, everyone can make their own decisions. I flattered if anyone decides to pick up the book. But of course, there is always their independent bookstore. On sale now.



Corey: Excellent. And we will, of course, throw a link to the book in the [show notes 00:43:31]. Brad, thank you so much for taking the time to speak with me. I really appreciate it.



Brad: Corey, it’s been a pleasure. Thank you.


Corey: Brad Stone, author of Amazon Unbound: Jeff Bezos and the Invention of a Global Empire, on sale now wherever fine books are sold—and crappy ones, too. 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 and then a multi-paragraph, very long screed telling me exactly what I got wrong.



Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.



Announcer: This has been a HumblePod production. Stay humble.
Play Episode
Neurodiversity as an Advantage with Wesley Faulkner
Screaming in the Cloud
05.06.2021
31 Minutes
About WesleyWesley Faulkner is a first-generation American. He is a founding member of the government transparency group Open Austin and ran for Austin City Council in 2016. His professional experience also includes work as a social media and community manager for the software company Atlassian, and various roles for the computer processor company AMD, Dell, and IBM. Wesley Faulkner serves as a board member for South by Southwest Interactive (SXSWi) and is a Developer Advocate for Daily.

Links:
Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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.

Corey: The Apps ON Cloud Summit, hosted by Turbonomic, is a new action-packed not-a-conference happening online May 11th through 13th. It’s for everyone who makes applications in the cloud run, from IT leaders to DevOps pros to you folks. Take a break from screaming into the cloudy void to learn from some of the best, like Kelsey Hightower, AWS Blogger Jon Myer, and yours truly.  

Register now at turbonomic.com/screaming. There’s a swag box ready to ship for the first two thousand registrants – don’t miss it!

Corey: Let’s be honest—the past year has been a nightmare for cloud financial management.


The pandemic forced us to move workloads to the cloud sooner than anticipated, and we all know what that means—surprises on the cloud bill and headaches for anyone trying to figure out what caused them.The CloudLIVE 2021 virtual conference is your chance to connect with FinOps and cloud financial management practitioners and get a behind-the-scenes look into proven strategies that have helped organizations like yours adapt to the realities of the past year.


Hosted by CloudHealth by VMware on May 20th, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you have no excuses for missing out on this opportunity to connect with the cloud management community. Visit cloudlive.com/corey to learn more and save your virtual seat today. That’s cloud-l-i-v-e.com/corey to register.


Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Wesley Faulkner, who's a developer advocate at a company called Daily. Either the company's named Daily or there's a misconfigured cron job somewhere. Wesley, welcome to the show. Which is it?


Wesley: It is Daily and you can find them at daily.co. Because of the name, it's kind of hard to Google.


Corey: Yeah. It seems like the more interesting a company is, the harder it is to Google. When it's some common word where they had to cheap out due to a shortfall in investment round and they can't afford to, you know, buy a vowel, it becomes super EC2 Google once Google understands there's not an autocorrect story in there. But it seems like the companies that are really poised for success in some markets are incredibly difficult to Google for Puppet and Chef were some of the previous generation stories. What does Daily do?


Wesley: Daily makes a video API built off WebRTC. And today, as we record this, WebRTC went 1.0 officially. And what we do is allow applications to break out video and audio so they can use it and configure it for their applications any way they want. So, you can do like a Zoom competitor, or you can just take the audio feed and make a Clubhouse competitor.

Or you can make a new way of collaborating with those spatial-audio-virtual work environments. There's a lot of different ways that you can use video to make you more productive, and we allow you to do that with our API.


Corey: It seems like there's a lot of emphasis on video these days, given that as we record this, we're still in a pandemic. I keep hoping that one day someone's going to listen to this and “Oh, yeah. The pandemic. I remember those days,” but so far, no luck. Last year, it always felt like “Well, oh, wow, this must have been recorded a while ago. They weren't even talking about the meteor yet.”


So, it just becomes an escalating series of awful, in a bunch of different ways. But video has been something that's been on a lot of people's mind, usually when it breaks. Is this designed to be embedded in other applications? Is it designed to be a standalone application? Is someone going to have a Daily desktop app at some point?


Wesley: So, we empower companies to build on top of our platform to make their own products. There is a possibility that we might make our own branded plugins or proof of concepts that are out there for people to use, but what we really want to focus on is enabling the next video experience and the configuration is where the innovation happens in terms of how big a bubble is or when it shows up. We just want to make sure that we take care of the table stakes of video and make everything, in terms of the stack, easier for people to implement.


Corey: So, one thing I noticed on your website that's always of interest to me is the magic word, ‘HIPAA,’ which I used to think was the female version of an animal. Turns out no, English doesn't work quite the same way as Spanish does. It's for those who are unaware, or perhaps not based in the US, it's the Health Information Portability and Privacy Act, which means you are certified to carry video for medical uses.


Wesley: Yes. And that we don't track PII or making sure that all the information is secure. And a little secret is that HIPAA, sometimes, is easier because you don't need to get hold logs or store that information. So, HIPAA is the Snapchat of database information, which is really good in some cases.

Corey: So, one of the things you're passionate and talking about is neurodiversity. So, why not? Let's have a conversation about that with a segue that even works, which is whenever I wind up having a video call with someone, I use Zoom or something like it, but when I call my psychiatrist for an appointment, we're going back in time to some ancient thing that they've embedded that performs the impossible and makes WebEx look good. But it feels awful, and whenever I've dug into why is this so bad, HIPPA’s always the answer. It feels like it's stuck ten years in the past, and it's annoying and challenging to work with.

You're a relatively new company from what I can tell. You’re version 1.0.6 on the website, which unless you have a glacially slow release process, means you haven't been around for decades, yet you've got something that works performantly, and seems to be aligned with modern technology. How’d that happen?

Wesley: Actually, in the world of WebRTC, Daily is kind of ahead of the curve. I mentioned that it hit 1.0 today, and so we've been doing WebRTC since the early teens, and even before then the video technology has been something our founders have dabbled in since their graduate years of college. And there's a lot of flow and churn in terms of what to use and how to use it. Back in the flash days, of course, you had to make sure that you both had the same version, and that everyone 
had it installed, and that there were no incompatibilities with the network you're on.

And then there is a lot of ebb and flow in terms of, is it going to be good for this application or that application? Since we've been building on top of WebRTC in the early days, we've been able to stay basically cutting edge. And so the problems we're tackling is kind of the NASA of video. I think that if you try to use some of the older technologies, you're kind of stuck into being comfortable and just making it work, and we're just trying to enable all of these different scenarios that you couldn't before because we are trying to solve the problems no one else is looking at.

Corey: That's the problem. It always feels like on some level that—at least in the United States—that technology is going to be dictated by the insurance company and in the medical group, and by the time it gets to the doctor, I mean, ideally, they're doctors and focusing on the whole health aspect, not spending their nights and weekends messing around with various video codecs or whatnot. So, it always felt like an insurmountable problem to me. But honestly, this becomes a differentiator.

Wesley: Yeah. I mean, there's a reason why we exist is because there's a need that's not being met. So, if you need one of those off the shelves, just do a quick video chat, there are plenty of solutions out there. And even with WebRTC, you can probably build your own. So, if you were looking for anything that is somewhat complicated, needs a scale, you need to worry about bandwidth; if you need to worry about having more than 200 300 people on a call, that's something that it's really hard to do on your own.

Corey: Again, talking from a speaking to my psychiatrist perspective, that sounds like hell on earth. It's “Great. So, what am I doing now? I'm going to livestream my mental health sessions. That's going to go super well for everyone.” There's vulnerable and then there's just plain dumb.

Wesley: There's reality TV, which is also, if you need the—

Corey: Oh, my God, you're right. That's exactly what that is.

Wesley: [laugh]. I would pay to watch it.

Corey: So, you've had a fascinating career. Like I normally don't read through people's bios on the air, but I’ll make an exception for you. You're a first-generation American, which is awesome; you're a founding member of the government transparency group Open Austin; you ran for the Austin City Council in 2016—that phrasing tells me you did not win?

Wesley: Yes, that's correct.

Corey: You also worked as a social media and community manager for Atlassian which means at one point you were the poor shmoo who was on the other side of my Jira barbs. Sorry about that. I always hate my past comes back to haunt me.

Wesley: I love hearing the pain of others. I feed off of it.

Corey: Yes. And then you worked at a number of companies: AMD, Dell, and IBM, which were awesome, fascinating places in, you know, 1998, but I don't know that that's when you were there. But that's my prejudices, not yours.

Wesley: Yes. Every company seems to have their little nook of being big corporate company because they’re a big corporate company. I try to make sure that I carve a little space for myself. Sometimes I'm successful, sometimes I’m not.

Corey: Yeah, just as a passion project or something, you’re also apparently a board member for SXSW Interactive?

Wesley: Yeah, been a board member, I think, for over ten years now. Yeah.

Corey: And I'm guessing you are not yet bored with it?

Wesley: It's a great experience. One, you get a free badge every year. And so it’s… didn't do me any good in 2020, but hopefully, when we start getting past this pandemic, we start meeting people face-to-face. It's a sea of people and I love surfing that whenever I can.

Corey: I spend a lot of time at various conferences—in the before times—and one thing I've never been quite clear on is 
what the hell SXSW is. Is there basically a quick summary you can give us?

Wesley: SXSW, it started off as three main festivals: music, film, and then interactive. And interactive is the part that has changed throughout the years. Interactive used to be an encyclopedia on a CD ROM. [laugh]. It used to be video game technology.

And then “New media” started—quote-unquote—with social media, Facebook, Twitter. And those companies decided to launch some of their products and send some of their people to South By and it started attracting some of their same companies. And then, when the bubble started with the internet, with companies forming that are internet first, they also came to South By and they brought the VCs with them. And so it didn't just become a meet and greet, it was becoming a place to start and get funding for your company. And that whole crowd just basically made a beachhead with South By, and it grew because of that.

Corey: And it's turned into something that still becomes impossible to define. And I've basically been boycotting it because no one has ever invited me to speak there. And everyone looks at me super strangely when I say that and it's not that kind of thing. But I don't know, invitations work the same way, universally. So, I am insisting that my misunderstanding is something I'm imposing on the world. I'm really tech-bro-ing my way through it.

Wesley: Yeah. That’s the same reason why I don't go to TED or cons.

Corey: Exactly. If they want me there, they will have me on the floor giving a talk. It'll be amazing, and the 360 stage and all the amazing things that scare the heck out of people. But speaking of before times, you also describe yourself as a public speaker. What do you like talking about?

Wesley: I love talking about neurodiversity. I love also talking about diversity and inclusion, which is part of neurodiversity, but since it's one of those things that doesn't really get highlighted, I want to make sure that I break it out to give some focus. And I love talking about networking.

Corey: Well, tell me more about the neurodiversity piece. What exactly does that mean? Where does it start? Where does it stop? It's a term that not everyone is particularly familiar with. Until very recently, I was in that group.

Wesley: So, neurodiversity is the acknowledgment that brains work differently. And that a variety of functioning is considered normal. There have been names associated with different understandings and different processing like Asperger's or autism. I'm dyslexic, ADHD. And there are many different kinds that are there at birth, and then there are some that are inherited, like PTSD, or depression, or anxiety. Those are all different ways of processing and seeing the world or different situations.

Corey: I'm going to talk about something I haven't ever mentioned on this show because why the hell not? If I can't talk about it, who the hell can? When I was five years old, I was diagnosed with ADD which later became ADHD, and the more I talked to people who've been down this path—I mean, I've been on medication for three decades now, aside from a decade where I just white-knuckled it the whole way, and [laugh] that didn't work so well. But it seems that ADHD is very much a spectrum disorder, and everyone who has it experiences it very differently. And the universal constant though, whenever you talk to someone who has it is, they feel like they're a shitty person where they keep dropping the ball, they're a bad friend, they're bad at showing up on time. It's basically the single unifying theme, start to finish, always feels like it's beating yourself up for things that are fundamentally not really a choice.

Wesley: Yes. I would say from all the people that I know have ADHD, me included, that's definitely part of it, of feeling like you can't focus, which means that you're not paying attention to some of the details, but also ADHD, flip-flops between being hyper-focused on one thing or being focused on a lot of things, and it feels like the way that it's seen in the media, it's described differently. And I think that's part of the reason why I like talking about neurodiversity is to bring more awareness around this subject and for people to be able to understand that it's not necessarily someone's fault, but also to highlight some of the advantages of neurodiversity.

Corey: That's a good way of framing that. One of the things I did when I started this company was I built it around things that I was good at, and avoided things I was not. In my initial reports on AWS bills were two pages. And “Oh, yeah, do these five things. It will save you 20% off your bill. Have a nice day,” is what it distilled down to. And it was right, and it worked, but it turns out when you're charging people bespoke consulting project money, they kind of want something that doesn't fit in a tweet. Who knew.

So, as we expanded, I brought in a business partner who's my exact opposite, whose primary language is Excel. And slowly, we wound up building systems around me to at least mitigate an awful lot of my shortcomings in that respect. But I still can't shake the feeling that it's a lot of work people have to do that they wouldn't if I weren't this way. And that tends to disregard the fact that if I work this way, I would not be able to do the things that I do. It's a double-edged sword, and I think it's something I need to be a lot more public about than I have been. So, 2021, here we go.

Wesley: Yeah. I think if you look at entrepreneurs, people who are neurodiverse over-index because they don't necessarily fit in the systems that are considered standard. They problem-solve in different ways, which don't necessarily conform to the standard operating procedure of most established companies. So, if you—thinking that, like, “I had to break out and I had to do this,” what you're doing is you're doing it your way, and you're building a team around you, hiring people, give them a purpose, given them a function in their duty because of yourself and the gifts that you were given.

Corey: And that's sort of part of it. The fact that I can context switch very rapidly is helpful, the fact that I can't pay attention for super long means that I'm better at reading things extremely quickly. When you're trying to sort through everything coming out of AWS, that becomes an asset more than it is a hindrance. And in some ways, it's hard for me to remember and realize—I’m still learning almost every day—that there are different aspects and different manifestations of ADHD, and that in many cases, I've always just written them off for 40 years as “The way that I am.”

Wesley: Also, I mean, you probably can judge things fairly quickly. Like, “This is crap,” “This is put together poorly,” or “They didn't spend enough time actually getting to the root of the matter.” Because you get bored. You're like, “This is a waste of my time.” And that type of feedback comes quicker to you because you know what you're looking for, and you know it's not cutting it. And so when you pass on and you make people, quote-unquote “Adjust” to you, what you're doing is you're making their material more accessible for everyone, which is also really great.

Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: I'm trying. Every episode of Screaming in the Cloud has a transcript that goes along with it, and that's partially because not everyone wants to listen and other people want to read. I don't have the attention span to sit and listen to these things, even at 2X. I want the transcript so I can read it. And if I have that desire, it's a near certainty that I'm not the only person doing it.

Incidentally, if you're listening to this and didn't realize that, yeah, if you prefer to read, go to screaminginthecloud.comand take a look at all of the episodes: there's a full transcript for everyone because accessibility is important.

Wesley: Not only just important, it helps everyone. Like for you, it probably helps with your SEO, it helps with when someone's looking for a certain subject or a certain person, that you could be a hit on Google. So, it has some knock-on effects that people don't realize, too.

Corey: One of the things that I find continually surprising is just how many people that I have a deep and abiding respect for who when something comes up that alludes to being neurodivergent, which is the opposite of neurotypical for those who are not familiar with the phrase, it seems oh that everyone I talked to and work with extensively has something going on that is a deviation from the norm. And for someone who grew up in my position viewing it as just a set of weaknesses and a shameful thing you never ever talk about. It's kind of liberating in a way to realize, oh my god, I'm not alone. There's a community of us. And in fact, we formed a community and didn't even realize this was a common, shared thing.

Wesley: Oh, absolutely. And I think you mentioned the shame. That shame I have, and I'm still battling. And speaking on neurodiversity is something I'm doing to try to get past that. But as a parent, I want to make the world a better place for everyone, including my kids, so that they can not only accept who they are, but the world can also accept them.

Corey: It's a fascinating thing. One other thing we sort of have in common that I'm very curious about that you alluded to a few minutes ago is, you talk about enjoying networking. And sure enough, I pull up a couple of social media sites, and we have a crapload of people in common on all of them, but this is the first time we've ever spoken other than through a few messages back and forth and writing. How is it that you have traveled so broadly in the same circles that I am in--first off—and secondly, how have we never met before now?

Wesley: Well, I mean, that's one thing about networking is if you find a passion and you do it, you are able to broaden your network fairly quickly, especially using the internet. But for me, in terms of the circles, I'm in a lot of different circles. You mentioned my background, I'm a first-generation American. I'm also a Black American. When that kind of means that I've never really, in some ways, found a place where I felt entirely comfortable, which means that I am generally uncomfortable at a certain level, no matter where I am, which makes the barrier of entry for these different networks, all even. [laugh].

So, what I try to do is just find good people and talk to people. And when you do that, you meet people who do different things. So, in social media space, I've met a lot of people, and in marketing, I've met a lot of people, and in developers and developer relations, I've met a lot of people. How we have never met is one of those things that is just I feel is inevitable. I hopefully will meet everyone that I can, who feels the need to talk to people who care about other humans.

Corey: One of the things that I found that was very aligned with my way of thinking about the world was a book called Never Eat Alone by Keith Ferrazzi, a consultant. And he talked about how it was important to meet people as much as you can, to introduce people every chance you get, and do favors for people without ever really expecting anything in return. And it sounds hokey, it sounds like something you want the people you're about to take advantage of to believe, except for the part where I've lived the last ten years like this, and it absolutely is true. It comes back around in super weird ways. If I help someone without thinking about how this is going to benefit me, I just do it.

And invariably, people reach out randomly at appropriate times, and, “Hey, I've got this thing going on. Can you help us with this?” And it becomes a business opportunity, or it's a chance to wind up meeting someone who's aligned with some research I'm doing. It's one of those things where you put something out, and it sort of comes back in some weird ways. And in fact, there were studies that mentioned in this book that the wealthy, it was not about giving money to each other that led to a lot of their success so much as it was they did favors for each other.

One of them was on the board of a private school, so they put their thumb on the scale and got someone else's kid in. Admittedly not a sympathetic example. But the point stands, when you help people out it comes back in super weird ways. What's your take on that?

Wesley: Well, there's two kinds of economies. There's the money economy, and there's, like, the friend economy, when you have a roommate, and they eat some of your food, you don't necessarily keep track of how much they've eaten and make sure they pay you back. If you both live together, and it kind of just works out. Eventually, if you're really good friends, I am of the philosophy that if you are doing transactional networking, meaning that you're doing something to get something back, you're in essence, making a short term decision, not a long term engagement with that person because you're usually trying to get something because of their position, power, or influence. So, if that person's position, power, or influence changes, or yourself, and what you do and what you need changes, you kind of lost that relationship and it's inherently short term.

But if you are really trying to connect with people you care about, and people you want to be what I call fully present and fully seen, then you won't hold things back like say, “Hey, that's kind of racist,” because you want to cultivate that relationship for that transaction. But if you're truly trying to be yourself and you're calling that person out and that doesn't end the relationship, it'll in fact strengthen that relationship, and it'll be a longer commitment than just that one transaction that you're hoping for. And it'll come back because once you're in someone's life, you become top-of-mind. I give a talk on how to get over the awkwardness of networking. And when you look at your recent called list, and then when you look at who you're connected to on LinkedIn, if you don't have the same feeling of fondness, when you look at those people, then you can realize that those are just transactions and you're not building a network of people you care about, just a network of people who can take advantage of.

Corey: The idea of viewing relationships as transactional leads to an awful lot of negative things, the ability to be able to have a conversation with folks, regardless of who they are, it's its own skill in some ways. I've got to admit, when I first started doing this podcast, I was incredibly intimidated by some of the guests that I've had. And I no longer have that reaction, for whatever reason. And I think a large part of it comes from, I had an intern from Facebook, a while back, and I had the EVP that runs all of Azure, I've had the CEO of Stack Overflow, I've had personally what I find to be the most impressive guest ever, Mai-Lan Tomsen Bukovec, who runs S3 and storage at AWS, there are fantastic people and many more, and if you treat all of these people the same way, as people, it really goes a long way. I don't have a database of these people appointed to reach out for when it's time for a favor.

It doesn't work that way. And I feel like that would be a way of cheapening it in some ways, and in many ways working directly against me. When someone reaches out with a nomination for someone who would be a guest on this show. My response is always “Great, what story will they tell?” Not “Well, what's their job title? How long have they been doing it? Are they an investor? What do the VCs think of them?” It's the wrong angle. And every time I see folks who go down that path, I am discouraged by how apparently this is not what everyone [unintelligible 00:27:02].

Wesley: Yeah. And then let's say you do have the person who's in this high position, and then they are just a total crap person, but you're like, “I'm going to make sure I get them on the show because they have influence.” And then they get arrested. Do you still have them on the show? Probably not.

Because they've lost that position and they've tarnished their reputation publicly, even though that they might have a tarnished reputation privately. But if you're going by your own gut, and your own honor system of the kind of people that you want to honor with their time and your time and give them a platform, you won't fall into that loop or that challenge because you'll be governed by a sense of elevating people who care about other people.

Corey: I've talked about this on Twitter from time to time, but I don't believe I've ever said it explicitly on the show, so I'm going to hijack this to say it right now. If you're listening to this, I have two requests for you: the first is, if I can help you with anything, please ping me. Worst case, I will tell you, “I don't know. But I probably know someone who can.” Secondly, it turns out when you run a podcast, everyone is super nice to you, which means that very often trash fire people don't present that way.

So, if you ever listening to this show, and you hear that I have a guest that you know is garbage, please tell me that. Confidentiality is guaranteed, but I don't want to wind up platforming folks who are frankly, terrible. I'm losing my connection to the back channel network in some ways, as a result. It's a weird thing to ask for, but I'm quite sincere with it. 
Please, as a personal favor. And as always, if I can help you, please let me know.

Wesley: You already are.

Corey: I do my best wherever I can. Well, I want to thank you for taking the time to speak with me today. If people want to 
learn more, where can they find you?

Wesley: Well, you can find me on Twitter. I'm @wesley83, on Twitter, and I am at Daily. So, go to daily.co, and if you hit the help, it'll get to me, if you don't want to go that route. Those are the two main ways. If you send me a message on LinkedIn, most likely I will not reply. I do treat LinkedIn as my own personal network of people that I care for and about, so if you're sending me a request there, at least to chat with me first on Twitter so we can get to know each other.

Corey: Absolutely. And we will of course put links to all of that in the [show notes 00:29:25]. Thanks so much for taking the time to speak with me. I really appreciate it.

Wesley: Thank you, Corey. I really appreciate being on your show.

Corey: Wesley Faulkner, developer advocate at Daily. 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 entire podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me why you're the garbage person.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.
Play Episode
Screaming in the Cloud Trailer
Screaming in the Cloud
05.05.2021
1 Minutes
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Play Episode
Cloud Therapy with Bobby Allen
Screaming in the Cloud
05.04.2021
38 Minutes
About Bobby

Bobby Allen serves as VP of Strategic Alliances for Turbonomic. Bobby is a veteran of Intel, Bank of America, TIAA and multiple startups including one that was successfully acquired by the former CSC (now DXC). He went into corporate America after being an Intel fellow at the University of Michigan (MS in Computer Science and Engineering) and a Meyerhoff scholar at UMBC (BS in Computer Science). Bobby has been involved in cloud computing startups since 2012. 
He frequently advises CXO’s on cloud strategy and logical equivalents in cloud technology. His goal is to provide data-driven output to move decision-makers from information to clarity to insight. Bobby has been a featured speaker in various events and digital formats including VMworld, AWS re:Invent, theCube, crowdchat, The CTOAdvisor and Gigaom’s Voices in the cloud. He’s equally skilled talking to analysts or technical teams but most enjoys helping customers separate fact from fiction.
Bobby also serves as Stewardship Pastor of Wellspring Church – a Gospel centered, multi-ethnic community in Charlotte, NC. Bobby is a member of the preaching team at Wellspring and is responsible for technology, finances and facilities. He’s grateful to be part of the team that helped complete a multi-year building purchase and remodeling project. Wellspring moved into their new home in December 2019. 

Links:Transcript

Announcer: 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.

Corey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.

Corey: The Apps ON Cloud Summit, hosted by Turbonomic, is a new action-packed not-a-conference happening online May 11th through 13th. It’s for everyone who makes applications in the cloud run, from IT leaders to DevOps pros to you folks. Take a break from screaming into the cloudy void to learn from some of the best, like Kelsey Hightower, AWS Blogger Jon Myer, and yours truly. Register now at turbonomic.com/screaming. There’s a swag box ready to ship for the first two thousand registrants – don’t miss it! 
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. My promoted guest today works for Turbonomic. Now, Bobby Allen is the VP of Strategic Alliances, but on LinkedIn he’s something else entirely: A cloud therapist. As someone who called himself a cloud economist once upon a time because I figured no one would know what that means, great. That appealed to me. And I like the idea of someone calling themselves what appears to basically be unique in the universe, a cloud therapist. Bobby, welcome to the show, and what is a cloud therapist?
Bobby: Yeah, thank you, Corey. Thank you for having me on the program, first of all. Love the format and all the great guests who’ve had. And I kind of took a page from you, Corey, I kind of made up my own title and some of my own job description. So, I call myself a cloud therapist on LinkedIn.
Corey: Hang on. While I’m sitting here, I’m going to do a search. And as it turns out, if LinkedIn cooperates, yeah, there are—ooh, there is a second person calling themselves a cloud therapist.
Bobby: Interesting.
Corey: Well, someone in AWS, which is good. I had the same problem as well because when I was a cloud economist, someone was calling themselves that as well, at AWS. And well, I can let that skate because AWS inherently is terrible at naming things, and job titles, presumably are going to fall into the same bucket. It’ll be great. But I’m curious, what is a cloud therapist? How does that work?
Bobby: So, a cloud therapist to me, Corey, is really about listening because the reality is, there are a lot of things that happened before I got there. A lot of them honestly, they went very badly. And I’ve noticed that a lot of people have almost a level of PTSD, especially from big transformation projects. So, cloud therapy to me is really two things. One, I’m focused more on how I can help you than what I can sell you, and number two, I’m there to tell you what you need to know now what you want to hear.
Corey: A somewhat similar line that I’ve been using for the economic side of the world has been that I largely view myself as a marriage counselor between engineering and finance. Because that does seem to be two folks who struggle to articulate a common love language if you’ll forgive the allusion. And I feel like the more I look at this, it’s less about math, and it’s less about being able to prove things with technical correctness, it’s not about the technology, it’s not about the tools, it always goes back to the people. And if I were to start my business over again, four years ago, I would almost certainly align it more directly with that ethos in mind.
Bobby: Corey, I couldn’t agree more. I think you and I are so aligned on that. Part of my personal mantra for last year and this year has been—the short version—is that tech is the easy part. The longer version is that tech is the easy part, people are the best part, behavior is the hard part, and humility is the worst part. We don’t like raising our hand to admit that we need help.
Corey: No. And part of the problem too is that, on some level, we live in a society that winds up penalizing people when they raise their hand and say, “I don’t know something.” For better or worse, I figured, well, I have no technical credibility to speak of, so why not admit when I don’t understand something? It sort of snowballed from there where other people started speaking up too;, “Yeah, I don’t get it either.” And, “Oh, good. I see you had to wait for someone to speak up, but all right.” It became an interesting story. And I’m starting to realize now that there’s more psychology that goes into so much of this than I ever would have believed previously.
Bobby: Again, I couldn’t agree more, Corey. I think the thing is the soul of technology goes back to people. It’s so easy to forget that why are we tinkering with things? Why are we playing around with new stuff? It’s got to come back to are we solving a problem for a person or an organization to make life better for someone?
And I think, when I kind of step back at some of the conversations I have with executives, this is one thing I’ll throw out for the audience. I’m a big believer that everything new isn’t good, and everything old isn’t bad. Wisdom is about knowing which new things to embrace and which old things to retain. I call that mastering the remix. And if you’re not willing to ask for help and you’re overwhelmed, that mix of old and new is probably crushing you right now.
Corey: That’s a really astute way of framing it. I want to come back to that, but before we do, this is a promoted guest episode by your employer, Turbonomic.
Bobby: Yes.
Corey: My question for you is why Turbonomic? Now, this isn’t just a ‘what does Turbonomic do?’ We’ll get there in a moment. But you have an interesting and storied history as far as things you’ve done. You were at CloudGenera for a long time, and you wound up doing a bit of a tease as far as, ‘oh, where am I going to go next?’ at the beginning of this year, and the answer was Turbonomic. Where were you, and what made you decide that this was the next thing for you to do?
Bobby: Yeah, it’s a great, great question, Corey. We’ll hopefully get into automation a little bit more in the topic. I’ve got a different take on automation, maybe the [many. 00:05:15]. But I used to be a person, Corey, that talked about—folks would say, “I’m drowning in information,” and I would say, “No, no. What you really need is to move from information to clarity to insight.”
And I think the revelation I had within the past year or so is the gap, Corey, is not from information to insight, it’s really from intent to execution. Even if I tell you what you need to do, do you have the time and the attention to do it, or do you really need me to do it for you? So, the automation that Turbo does kind of helps free you up to go focus on the next thing.
Corey: I have a somewhat conflicted relationship with an awful lot of the cloud cost optimization tooling. And generally speaking, we don’t have a whole lot of them on the show, we don’t have a whole lot of them sponsoring our stuff because of a really strange divide that we’ve found over the years. Either I wind up actively insulting the tool or product—which is not a great look when people sponsor things so that’s a problem—or the other is I wind up saying great things about it; it’s perceived as a full-throated endorsement. And that’s impossible for me to do in this space just because, as we’ve discussed already, I don’t think that it is inherently a tooling problem nearly as much as it is a people problem. That said, one of the things I do appreciate about Turbonomic when I took a whirlwind tour through it was that in many cases, it is hands-off—you configure it to do certain things, and then you don’t have to mess with it anymore. It just works, and it’s a disappears-into-the-background offering. And that is, in many respects exactly what people need around a lot of things that Turbonomic does.
Bobby: Mm-hm. So, I agree, Corey. I think the other part is Turbonomic can kind of meet you halfway because sometimes the things you want to automate still need to be routed through something like a ServiceNow, to get people to bless it, so I think that part is really cool. But I’ll give this analogy to the audience, Corey. So, Turbonomic is not a cost optimization company.
We’re really a performance company focused on applications. And so here’s the difference; I’ll use a gym analogy. There’s a healthy way to lose weight, and there’s an unhealthy way to lose weight. So, for a layman, the way I would sum up Turbonomic is we’re optimization without unintended consequences. We’re not the diet pill you take to drop 50 pounds and your kidneys fail.
Think of us as a combination of the nutritionist and the trainer so that you lose weight and add muscle in a healthy way so that your body has the nutrition and the physical makeup that it needs for you to be sustainable and successful.
Corey: It’s effectively teaching people the long-lasting approaches rather than the quick fix of come in and, “All right, flip that button there. Hit that switch there. No, you flipped that switch incorrectly. Do it more like this. Thank you. Pay me.”
And then you vanish and you haven’t really fixed anything. You’ve just caused a minor inflection and made people feel good, but it isn’t building the lasting muscle that you need in these spaces to ultimately fix the root of the problem, which comes down to having communications, effectively, cross-functionally.
Bobby: Corey, you’ve said it well in other formats. Cost is a proxy for value, but cost is a symptom of, typically, something that’s a lot deeper. A bad cloud bill is poor communication, is overprovisioning because you don’t know what the applications need, there are other symptomatic things. And I think, again, back to being a cloud therapist, if you listen to people, they’ll tell you what’s wrong, they won’t necessarily be able to tell you why, and you’ve got to listen to the bigger point of what’s happening. And so sometimes, I’m screaming about the bill but there’s really a bigger issue. I don’t know what resources my apps need. I don’t know where to draw the line. I don’t know what I should be doing. I need some coaching, and I need some automation so that package can help me operate my environment better.
Corey: I think your framing of the question started out on the right path. “Oh, you get a bad cloud bill. Well, hang on a second. Why is it bad?” I mean, theoretically, you can drop the cloud bill to zero by turning everything off, but that is surprisingly unappealing for most companies.
It comes down to is it too high? Is it really that it’s high? Because people accept when they run businesses, that there’s a cost to providing their services or goods, and that’s a natural order of things, but what they don’t understand in many cases is that when finance is complaining about the bill, it’s not that it’s too much, it’s that it doesn’t align with projections. So, what is it that’s really driving that question? Was it that it wasn’t predictable, that it wasn’t planned for, budgeted for or, in many cases, is it the fact that you just hired a data science team and now the bills in the stratosphere while it’s very hard to articulate the value they’re providing for you so far?
Bobby: I think that’s the key, Corey, is that—you know, I’ll use another analogy. When grandma’s transmission goes out in her car and I’m weighing whether I put a $10,000 repair around that vehicle, I’m not going to do that if she’s going to stop driving next year. So, like I said, cost is a proxy for value. In the end, the real issue that we’re struggling with is what is the value of that application? Because applications are the bridge between technology and people, right?
That’s how we’re delivering something to make someone else’s life better. And we’re struggling because the bill may be going up, but the value to our customers and our users isn’t necessarily going up and we’re not aligned. If a Netflix cost goes up, or Disney+ goes up, that cost going up means they’re adding more value and they’ve got more customers. They’re not complaining about that as much.
Corey: Right. It’s you look at these things, and like, oh, wow, Netflix, or Lyft, or whoever it is, that discloses cloud spend in a variety of different ways through their public filings, it’s easy to look at that and, “Oh, what are they spending all that money on?” It’s the rest of the S-1. The business fundamentals that mean that they have successfully gone from harebrained idea to something that is viable in the public markets. That’s also invariably second-place—at best case—compared to the cost of payroll. In some cases, you’re also going to see office real estate trumps that as well, but let’s be realistic in a post-COVID time, that one’s a bit of a question mark in a lot of places.
Bobby: Exactly. Corey, just to kind of segue, communication and people is kind of a common theme I hope the audience is hearing. And I tell customers all the time, missed expectations sink more projects than bad code or broken APIs. We have all this tech, but we’ve gotten lazy in terms of having the right conversations. We went to the cloud, or we did this app this way to make things better.
What does better actually mean to us? Is it cheaper? Is it faster? Is it bigger? I’ll be specific about that for a second, Corey. When we talk about making something better, do I need to do a good thing faster, or make a mediocre thing better? Because a bad recipe at scale is still nasty.
Corey: I really, really wish that you could have said that story to some of the institutional kitchens I was at at a bunch of my early educational processes. Oh, my stars. “Yeah, could you fix the recipe first before you scale it?” Ugh. But there’s also this misguided belief that every company holds, every engineering department has, specifically with the idea that after this next sprint completes, then, then, Bobby, we’re going to start making good decisions, and pay off all of our technical debt, and start doing the right thing all the time. And we, of course, will agree on what the right thing is. It’s a ludicrous fantasy that everyone holds, on some level.
Bobby: And you’re right again, Corey. I feel like I’m saying that a lot today because we’re probably agreeing more than we usually do, but that’s cool. In grad school, I had a professor who talked a lot about verification and validation. The first question is, do we do it right, but the more important question is, did we do the right thing? We are not asking that question enough, Corey.
We’re building two-story houses for people that are in wheelchairs. And then we look back and we wonder why people are upset. It goes back to expectations, communication. The technology, all the stuff that we can do, Corey, is making us fall in love with a science fair project and not tying it back to is this what this person or this firm needed me to actually do for them? And then we get upset because we spend a lot of time and effort on things that really weren’t relevant to meet the need.
Corey: So, I want to take a bit of a detour as well where I normally would call this a side project, but that in this case, would be a horrific insult. And that is not at all my intention. You’re very upfront about not just being a cloud therapist, you are also a pastor. And I want to be clear, not a cloud pastor, an actual legitimate pastor. Tell me, first, about, I guess, trying to balance those two worlds, and secondly, how they inform each other.
Bobby: Thank you for the question, Corey. One, I know that’s maybe different territory for your audience, so let me try to sum it up.
Corey: Well, let’s be clear here. It’s also different territory for me. I’m a somewhat secular Jew, and the whole pastor, religious services, faith thing is an area that I always felt like a bit of an outsider in American Christian culture. And if I do, I know other people feel much more so. So, it’s time to start normalizing some of these things and say, “Yeah, I don’t know what I don’t know.” Please, continue.
Bobby: Oh, thank you. So, Corey, I serve as one of the pastors at a multicultural church in the south. I live in Charlotte, which I like to call Silicon South to let people know we’re not just country bumpkins sitting on tractors. And so my church is about half-and-a-half black and white. We have three black pastors and two white pastors.
And I honestly, Corey, feel like my life is better because I get to do life with such a diverse group of people. We have white families, for example, that have adopted black children. We get to process things together, we get to talk about is this racist, or is this ignorant? I’m struggling to find the words that have this conversation. We get to do a lot of those things and I think that’s why for me the pastor part of me wants to make sure that I listen for how people are hurting, I listen for, again, what happened before I got there, and I think about how to apply.
Here’s the key, I think, for the audience, too. A lot of times your passion projects can teach you skills that you can transfer to the enterprise and vice versa. Let me tell you what I mean about that. One of the biggest projects I’ve done—probably hardest thing in my life, short of somebody dying was managing a building renovation project. About the only thing harder than doing building stuff for a church is getting a loan for church, no bank will foreclose on the church so they don’t want to lend any money to you.
Managing that project definitely tapped into skills that I acquired doing things like the Bank of America-Merrill Lynch data conversion, managing schedule, resources, budgets. So, when that came down the line on the pastor side, I said, “I’m built for this.” Bank of America trained me for this CloudGenera and ServiceMesh trained me for this. And it also goes the other way. When I’m managing volunteers at church who don’t owe me their allegiance, I’ve got to lead them and motivate them; that applies to influencing people in the enterprise. So, I think they’re very complementary to each other is the way I’d sum it up.
Corey: It’s fascinating watching fo—at least from my perspective, who have this multidimensional aspect to them. I mean, we all have it to some extent. I spend a lot of time in my off hours—such as they are—being a parent, or indulging myself in cooking and whatnot. But they’re very different than the activities I pursue in my professional slash public life. And it always is, frankly, more than aspirational to find someone who’s I guess, non-public, non-professional aspect of what they do is also devoted towards, I guess, either transformation or in this case, helping people.
Let’s call it explicitly what it is; it’s helping uplift people, which is something I’ve threaded through what I do professionally, at least I try to. But in your case, it’s an explicit calling to my understanding. It is a, in many ways, relatively thankless task that is never done. Is that an unfair characterization?
Bobby: No, that’s fair, Corey, you’re not a pastor for the compensation package. You’re in it because you care about people.
Corey: Careful how loudly you say that. I’m sure some VC is going to hear that and their ears are going to go on point.
Bobby: [laugh]. You’re in it because you want to help people, and I would sum it up this way: being a pastor shows me how I’m a beautiful mess. I am flawed, I am mistaken, I’ve also learned a lot, parenthetically—thing that goes right along with being a pastor is being a husband of twenty-one-and-a-half years now. I’ve learned a lot of things from my wife, and humility has taught me one of the biggest things that we as men do often too, Corey, is we don’t listen to our wives enough. I’ve said on social media before, listening to your wife doesn’t make you less of a man, but not listening to your wife may make you a less successful man.
And being a pastor and seeing how many times I’ve been wrong about things, how many times my wife has been right about things has kind of humbled me to understand that. You know, my wife has been my test audience. I’ve also said that before, many guys say something deep, we did something dumb. So, we need to thank the spouses, partners, and mentors who gave us grace, while we figured stuff out, my wife definitely falls into that category.
Corey: I’m in the same boat. I always feel a little, I guess, ashamed, let’s be honest. Ashamed that so much of what I do and who I am is only possible because my wife has a job as a corporate attorney. And yeah, when I was starting this place out and figuring out how I was going to work, I didn’t have to support the family as I was going through that; that gave me certain amounts of latitude. There’s also the aspect of the constant emotional support, the ability to help pitch in and put the girls to bed when I have a late-night event that goes late.
There’s a lot in there and it’s one of those areas where if I did it, as the husband, I would be lauded for these things to help support my wife. But when my wife does that, for me, culturally, that’s very much a well, that’s what wives do. It’s a double standard and it’s terrible, and I am ashamed for the fact that I don’t do a good enough job of calling that out frequently enough.
Bobby: It’s balanced, Corey, I think the other thing that we’ve got to look at is even when we deal with challenges on the corporate side, it’s still informed by people. Sometimes people are frustrated with their jobs because they’re frustrated at home. It is really tough to like your job when your spouse can stand your job. And sometimes that happens because you’ve been giving your best to your job and they’re getting leftover energy at home. My wife and I are very direct with each other, and she’ll tell me—you know, sometimes, Corey, people will say, “You’re being a rock star at work.”
And my wife has said to me before, “I feel like your company is getting a rock star, but I’m not getting rock star at home.” And before I get offended, I remember what another one of my pastor friends said, you need to sit down and ask your wife, “How often do you have my undivided attention?” And be quiet and listen to whatever she has to say. Don’t be defensive. Suck it up and realize there’s some truth there in that feedback that you probably need to process.
Corey: Let’s be honest—the past year has been a nightmare for cloud financial management.
The pandemic forced us to move workloads to the cloud sooner than anticipated, and we all know what that means—surprises on the cloud bill and headaches for anyone trying to figure out what caused them.The CloudLIVE 2021 virtual conference is your chance to connect with FinOps and cloud financial management practitioners and get a behind-the-scenes look into proven strategies that have helped organizations like yours adapt to the realities of the past year.
Hosted by CloudHealth by VMware on May 20th, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you have no excuses for missing out on this opportunity to connect with the cloud management community. Visit cloudlive.com/corey to learn more and save your virtual seat today. That’s cloud-l-i-v-e.com/corey to register.
Corey: You have to sit with that for a while. It’s easy to wind up pointing out specific times and specific weeks for example. Like, during re:Invent as far as my family is concerned, I am basically calling in dead. And that at least becomes something that is time-bound. The more pernicious, the more dangerous aspect is when it slowly starts to become everything.
Because, “Oh, it’s just we’re on a tough sprint right now. I’m going to go ahead and focus on that instead.” Or, “Well, right now is a big deal I’m working on, so once this is done, then I’ll go back and have time to make it up to the family.” And then you turn around and you’re retired and elderly, on some level, assuming we’re all fortunate enough to live that long, and you realize you never made time for the things that matter. You missed watching your children grow up, and you missed being there to support the people who matter.
And, frankly, one of the reasons I started this place that I have to continually remind myself to keep in mind is that I did it because I didn’t want to continue working startup hours in the hopes that someday things pay off. And in fact, most of the people who work here work what amounts to a 40-hour a week-ish—schedule. And when I say ‘ish,’ that’s not at a floor; it’s at a ceiling in many cases, and that’s fine. The reason I do it is because I don’t want to do that grind, I don’t want to play those games, and I don’t want to wind up having these awful scenarios of having to figure out what it is that we’re doing, and promising people, and stringing them along, and burning them out. I want this to be sustainable. I want to build a place where I can enjoy my life and my job doesn’t consume me—unless I want it to—but also for other people as well.
And I’ll admit there are times that becomes very challenging, but that’s the beauty of doing things in a bootstrapped way where we’re supported by the magic of revenue and profitability. We don’t have to sprint to hit runway targets before we’re out of business, in the same way.
Bobby: Yeah. That’s why I say we’re beautiful messes, Corey. Especially as husbands and fathers, we’re working on a plane that we’re flying at the same time. And my kids are a little bit older than yours, I’ve got a 12 and a 14-year-old; I’ll give this piece of advice to your audience that may have younger children. I used to think that the kids were going to need me the most when they were younger, right, because babies and toddlers want to talk but don’t have a lot to say.
Teenagers, on the other hand, have a lot to say but don’t want to talk. They need you more as they’re older, where you have to watch body language and what they’re not saying. And again, the way this all comes together, Corey, is being a pastor, being a husband, being a father makes me better at my job, not the other way around. We think that they’re detriments, but learning how to read people, how to connect with them, and how to watch for what they really need, not just what they’re saying, will serve you in any aspect of your career.
Corey: I think that there’s an awful lot that needs to be aligned and built in a way that we start looking at people through the context of whole career. We don’t though. Everything short term; everything is, “Oh, just at this company, I’m going to work like nuts for a few years, and then it’s going to pay off and we’ll hit that equity point.” It’s a lie. It’s always a lie.
Look at how engineering works. We talk about sprints, a two-week sprint. And then what do you do at the end of the sprint? That’s right, you do another sprint. It’s not a sprint, it’s a marathon. If you’re running all the time, you burn out. It always bugged me, back when I first learned how agile is supposed to work, and I don’t think I’ve ever quite gotten over it.
Bobby: So, Corey, if I kind of build on that, but connect, kind of, life and technology because I feel like a lot of technology lessons are really life lessons or vice versa. One thing that I’ve been wrestling with, I feel like in tech and in life, Corey, we’re struggling with how to evaluate better versus different. Do I need a faster horse or do I need a car? And the challenge is, in a world of overwhelming options—watch this—how you choose is more important than what you choose. And most of us are overwhelmed I find because we’re focusing on a choice, not a plan.
Because without a plan, you’re one more option away from being overwhelmed or starting over again prematurely. We need things, Corey, that are going to free up our minds to go focus on the next problem. And so, tying this back to my firm for a second, Turbonomic is not a choice; Turbonomic is the way you choose. We need to pursue things in life that free us up to focus on family, to focus on spending time with people, to focus on solving the next challenge. Because other than that, our minds are still occupied spinning on things that we can’t resolve.
Corey: We spend so much time doing those things. You’re right. One of the things I like about what Turbonomic does, as well as a number of other tools, is it almost takes the big reserved instance or savings plan purchase out of the equation in some respects. And again, you can configure it otherwise, but something I’ve seen in my clients is we talk about the psychology and we talk about the math. Well, yeah, it’s pretty mathematically straightforward—especially in the world of savings plans—to go ahead and say, yeah, you should spend about $20 million on that savings plan. That makes sense.
Everyone can agree that, “Okay, well, what if X, X, and X?” And, “All right, fine. We’ll make it 18 or 17, or whatever it is.” Fine. That gets agreed upon. Okay, just click the button in the console, add it to your cart, now click purchase.
And no one does because it turns out that clicking the buy button on a cart item that is more than you’re likely to make in your career is a gut-check moment. And people sit around for nine months because they’re scared to click the button and it's great. Okay, having tooling do that is helpful. The way we approach it is we’re consultants and we’re sitting there next to them and hold their hands, in some ways, through it and where, if you’re still on the fence, cut it in half, buy that now and then we’ll reevaluate in a month and go from there. But you’re going to spend the money anyway, may as well do it at a discount. And that’s the psychology piece of it. I like your approach to taking that out of the critical decision path where people in some cases need to take a strong drink before clicking that button.
Bobby: Right.
Corey: It’s surreal. I’ve clicked that button before and every time I quadruple check it. I used to take the weasel’s way out back when I was running ops teams; for those big purchases, I would go ahead and make my Amazon account rep do it on the back end. Because if they mess it up—and spoiler, sometimes they did—it’s on them, and they can unwind it with an apology rather than me begging on my knees to please, please, please don’t get me fired and sued here. It’s a different dynamic there, and I really wish that there were more effective ways to do it.
One thing that GCP gets right, in this case, is the idea of sustained use discounts. Use something for at least x hours a month, and you automatically qualify for a discounted rate on that thing. Awesome. All I have to do is not do anything. Well, I’m great at that.
Bobby: That’s a very under-marketed part of their offering. I agree 100%. I think a lot of people don’t know enough about that. I do want to go back to something you talked about, Corey, with when we look at automation in general—and this may be a little controversial, right in ter—freeing up your mind, freeing up your time is a big thing for me. Automation doesn’t mean that you can stop thinking; it means that you can start thinking about the next thing.
And so I believe, personally, automation was really meant to enable thoughtfulness, not push us towards laziness. And that’s how some of us are using it, right? We talked about better versus different. The key is that you automate better so you can think about different. So, you can’t automate everything in the world.
That’s the other place some people get stuck is hitting the buy button, but then is thinking, “Okay, if we’re going to automate, let’s automate everything.” You can’t automate everything yet. Automate the stuff that’s better; focus on the stuff that’s different.
Corey: And that’s part of the challenge, too. I see this industry-wide, where people are approaching everything through a lens of SaaS. And well, great, can we turn this into something that can only be solved with software where maybe we have a pro services engagement from time to time, but it’s going to be software for that recurring revenue approach. When I talked about starting The Duckbill Group with a bunch of people who were kind enough to sit down and give me their unvarnished opinion. Most people were positive on that.
But one person who wasn’t was a successfully exited founder who had done very well, and their response was, “Yeah, this doesn’t seem that great a business to me because yeah, I can see you making 10 million bucks a year out of this place, but I don’t see a path to a half-billion dollar exit.” And I’m sitting there going, “Well, I appreciate your feedback, first, because feedback is a gift. Thank you. Secondly, exactly how much money do you think I need?” But the thing is, they were right, on some level.
If I want to become a celebrity force, who’s basically famous for being able to buy that fame and have an insulting number of commas in my net worth, I’m in the wrong business and I’m approaching this very differently than I should. That’s an intentional choice. It’s not that, oh, well, Corey, couldn’t find a way to succeed at being a billionaire. Well, first, probably right. But secondly, I was never interested in trying just because it’s—I want prosperity insofar as it is a successful outcome for my family where they never wonder if the roof over their head is going to be there tomorrow, whether food on the table is going to be assured, and have a nice life. And beyond that, I’m not sitting here thinking what I really want? Nesting doll yachts.
Bobby: Right, [laugh]. Right, right. Well, Corey, you hit a good point, though, because the reality is we need advice but we don’t like paying for advice. And I think the dilemma is when we tie that back to cloud, and applications, and the way that we look at technology today, cloud, in my opinion, is at best a teenager that just learned how to drive. It still needs adult supervision, it still needs boundaries.
And that’s what you do via consulting; that’s what my company does via software, but cloud is at a dangerous point, Corey, because the capabilities go beyond the ability to comprehend consequences. Help is needed, and I think that there are some people—I’ve heard this from executives—some people only want to pay for advice. Other people don’t want to pay for advice and only want to pay for products. I think there’s a market for both.
Corey: There absolutely is. And I’m not sitting here suggesting there’s only one right answer here. I want to be very clear on that. There are multiple paths to success, and I’ve always said that there is room for many more Duckbills Group in the world, and that is fine. I have no argument there.
I’m just a believer of things that make it easier for people to improve their situation. And one depressing but fortunate for my business aspect of cloud finance is that the AWS bill never gets smaller on its own. When I reach out to someone like, “Oh, no. We’re set with our bill.” Our response is always, “Great. We’ll talk to you in a few months,” because it gets bigger inherently on its own. And I don’t like that aspect of it because it seems to not make people super happy. But there is the counterargument as well of it does make for a somewhat sustainable and ever-growing total addressable market.
Bobby: It definitely does.
Corey: I would give it up if I had the option to and could wave a wand. I absolutely would. There are other problems I would like to tackle. But now I’m worried that I will retire without this problem ever being solved in a meaningful, global way.
Bobby: Well, I mean, that’s part of the total addressable market, as you talked about. I think Duckbill can have plenty of other little ducks and spin-off companies and ducklings or whatever because they’re going to be other adjacent problems that I think are going to crop up, too. People are going to need help, they’re going to start to embrace humility more, in my opinion, that I can’t do this on my own. I’ve talked about this in other forums, Corey. There’s a difference between self-help and self-service.
One is, “Can I do it on my own?” The other is, “Can I be effective on my own?” And again, if cloud is at best, a teenager that just learned how to drive, I probably can’t be effective on my own. I need to raise my hand and bring in people like The Duckbill Group or Turbonomic, to help me figure this thing out.
Corey: I also want to be clear that, from many people’s perspective of how this stuff works, it’s natural to conclude, oh, you’re a consultant, but Turbonomic is a product, so obviously, your competitors. No. Of course, that’s not true. It turns out that virtually every customer we talk to has some software thing somewhere that is, in many cases vendor-provided that handles aspects of this. We are not ever going to be an automated tool that solves these problems.
We explored that with our DuckTools experiment, and it turns out that what we think the industry needs, and what the industry wants to buy are two different things, so we shuttered the thing because frankly, I don’t have the stomach to sit here first educating people about the problem before then selling them a thing that fixes the problem I just taught them about. It doesn’t work. And that is too much swimming uphill.
Bobby: It is very hard. I mean, again, you’ve got a very successful [pocket 00:31:36], Corey. I think people trust that you have their best interests at heart and that you’re using real-world experience and customer exposure to help them not hit all the potholes. The thing that I think you do a great job of—and I talk to executives about this a lot—you want me to tell you what you didn’t ask that you should have. You don’t want to hit every landmine that the people did before you; they bring you in partially, Corey, because they don’t want to hit every landmine on their own. They want to hear your story so you can coach them on how to fix it ahead of time.
Corey: If we can delve into tech for a minute, there are more services than anyone can shake a stick at when it comes to cloud provider offerings. How do you help companies figure out which ones they should use? Which ones they should avoid?
Bobby: Yeah, great question, Corey. Without going into the weeds, I’ll give you this analogy. I call this ‘chicken in the cloud.’ And it’s all about what do you want to be known for? So, think about there being, kind of, five ways that you can engage with chickens.
So, you can grow it from a baby chicken, you can pluck a dead chicken, you can cut up a chicken that you bought at the store, you can cook a chicken that you bought in a pack, or you can use a rotisserie chicken that is already done. And the reality, Corey, is I believe that a lot of people are not going to pridefully say, “I groomed that little VM from when it was a baby chicken to learn how to walk and chirp.” The reality is cooking and creating are not the same thing, and the question we’ve got to ask ourselves is are we putting time and effort into things that really don’t matter? At the end of the day when that plate goes on the table, the person doesn’t care if I grew that chicken or if I started with a rotisserie chicken; they want to know the recipe and the dish is solid. They don’t care where I started from. So, think about what you want to be known for and let that guide your decision around what you choose to engage with.
Corey: Bobby, thank you so much for taking the time to speak with me if people want to learn more about you, about Turbonomic, about anything we’ve talked about, where can they find you?
Bobby: So, my company is at turbonomic.com, you can check us out there; there’s all sorts of information. You can find me at bobbyjallen.me. I’m also on Twitter; think ballen and Charlotte: @ballen_clt to represent Charlotte. And, Corey, I want to thank you. I want to leave your audience with this. This is, kind of, one of my personal mantras. “Greatness is about what everyone sees. Excellence is about what anyone sees. Faithfulness is about what no one sees.” Seek being faithful over being famous and everything is going to work out.
Corey: And that’s a great point to leave in on. Thank you so much for your time and of course your insight, as always.
Bobby: Thank you, Corey.
Corey: Bobby Allen, VP of Strategic Alliances slash cloud therapist at Turbonomic. 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 comment including your pitch deck for Pastor as a Service that I’m certain is moments away from being funded, as I speak.
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill 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 HumblePod production. Stay humble.
Play Episode
Splitballing on DevRel with Talia Nassi
Screaming in the Cloud
04.29.2021
33 Minutes
About Talia Talia Nassi is an international keynote speaker who delivers content on all things testing and quality. She is a developer advocate at Split.io where she works closely with engineering teams globally to ship software more efficiently. She is passionate about feature flagging, canary launches, CI/CD, testing in production, and A/B testing. She has spoken at countless conferences internationally, ranging from audiences of 100 to 4000!

Links:
TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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.


Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.


Corey: The apps on cloud summit is a new action packed, not a conference, happening May 11th through 13th online. Its for everyone who makes applications in the cloud run screaming. From IT leaders to DevOps pros to you folks, whoever you might be. Take a break from screaming into the cloudy void with me to learn from some of the best of people who actually know what they’re doing. Like Kelsey Hightower, AWS blogger John Meyer, and also me, because apparently they didn’t listen to me saying I had no idea what I was doing. Register now at turbonomic.com/screaming. Theres a “swag box” ready to ship for the first two thousand registrants, so you don’t want to miss this. Thanks for Turbonomic for sponsoring this ridiculous podcast.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Talia Nassi, who's a developer advocate at Split Software. Talia, thanks for joining me.


Talia: Thanks for having me. I'm excited to be here.


Corey: So, let's start at the beginning. What is a Split Software? And please don't tell me the answer is that there's two of them.

Talia: Split Software is a feature flagging and experimentation platform that allows you to create better software for your teams so you can gain insight into what your customers are doing with the use of feature flags. And Split provides all of that inside of their platform.

Corey: So, in other words, it's more or less the ability to enable certain things on the fly, disable them on the fly without having to, for example, do a whole new code deployment?


Talia: Right, exactly. And it makes the release process just a lot faster and more seamless because you don't have to have a big release, now, you can turn on a button or flip a switch and that feature will be on.


Corey: One of the earliest tech presentations I saw—and it feels like it was probably almost a decade ago—-, was talking about feature flags. It was from one of the big well-known tech companies. I don't even recall which one, which tells you exactly how well that branding thing worked. But it felt like, “Oh, this feels like something from the future that the big tech companies will do, and maybe someday a few other folks will be using it.” And that's kind of the really the last time I went deep dive, checking into that sort of thing. But looking at Split's website, for example, I wind up seeing a whole bunch of logos that I recognize, which tells me it has sort of come down from the ivory tower of the big well-known tech places and into something that, you know, human beings can use.


Talia: Yeah. Yeah, absolutely. So, we do have a ton of integrations with Google Analytics, and mParticle, and Amplitude. And then we have a bunch of supported SDKs, like, all of the main ones. I do a lot of tutorials in Python, and React, and JavaScript, but we have so many different places to start if you're interested in using our tools.


Corey: So, developer advocacy is one of those areas that means a lot of different things to a lot of different people. I mean the running joke is, what, get three DevRel folks in the room and ask what DevRel is, and you'll wind up getting eight answers at least. And again, my expression of it is usually aggressively shitposting on Twitter aimed at trillion-dollar companies. But everyone finds that they tend to embody different aspects of it. So, it sounds like a weird college entrance essay question, but what does developer advocacy mean to you?

Talia: It means someone who's an—I don't want to say an advocate for the developers, but it's someone who the developers can trust. And there's a few parts to that. So, the first part is just having some sort of engineering credibility. So, I started as an engineer, and I was a software engineer in test for five years before becoming a dev advocate. So, I do have a foundation of software engineering. 

And so the second thing, I think, is dev advocates are developers at heart, so they're not going to try to sell you on a tool. Like, I don't sell Split; we have a whole sales team that deals with that. But my role is to make it easier for the developers to use Split. So, I work on things like documentation, and I work on video tutorials, and code tutorials, and create sample apps, and just make it so that if anyone wants to use Split, it's easy for them and they have a really great experience.

Corey: At some level, you would think from the naive objective perspective that making sure developers have a great experience is the entire role of product and then, in theory, the engineers that build it. One thing that I've learned through fronting a small company of my own, is that every aspect of business is way more complicated than it looks from the outside, even at tiny scale, and you folks are larger than that. Where does the breakdown fall? Because it's easy to say that, “Oh, product should wind up making sure that the developer experience is a delight.” But if that were true and completely inalienable, then developer advocacy wouldn't exist because product would already handle it? Am I right on that? Am I missing something? Or is there some nuance that's, that’s—

Talia: You’re right. So, basically, what dev advocacy does is it finishes the feedback loop. So, you have product and engineers who create the product, and then you have developers who use the product. But then if there's issues, or problems, or things that can be improved, that feedback needs to somehow get back to the product team. So, I think what dev advocacy does is it fills in this cycle of when something goes wrong, or if something should be improved, or if there is a typo in the documentation or something isn't clear, that feedback all needs to get back to product to continuously improve, and that’s, I think, where dev advocacy comes into that cycle.


Corey: It's one of the I guess, big debates of DevRel across the industry has been, well, what organization does it belong in? At some level, it seems that some folks spend more time talking about what DevRel isn't than what it is: “Oh, we're absolutely not sales.” I agree with that. “We're absolutely not marketing.” Well, I have challenges with that approach. “We're not product.” Well, okay. Yes, but no. “We're not engineering.” Well, really? You write an awful lot of code for someone who's not engineering. And so on and so forth. It feels almost like it's an intersection, and it feels like it's a very nebulous thing to define.


Talia: Yeah, it is. And I think with every company, it's different. I think, in an ideal world, DevRel would just be its own division within a company, not with marketing, not with engineering, it would just be freestanding on its own. And it does combine a lot of engineering and a lot of marketing, but what you’re marketing is not the product, you’re marketing code, and tutorials, and things like that. You're not marketing, like, the actual product. 


So, I think there is an intersection, obviously, between product and engineering and DevRel, but in terms of where it should belong in a company, ideally, I feel like it should be its own division. 


Corey: The challenge, of course, is from a business strategy perspective. When it's nebulous, it's difficult to assign value and determine appropriate level of investment in it. Back in the before times, for example, it was always tricky to articulate the value. “So, let me get this straight. You cost as much as an engineer, and you spend about that much again in travel to go to conferences that look like giant parties from where we sit. And I talked to the VP of DevRel, whatever that position happens to be, and they say that no, you can't tie a sales quota to you folks. And okay. And I can't tie you to all the metrics I suggest, like, inbound leads are bad. So, without anything I can use to evaluate performance of whether someone is outperforming or underperforming in the group, what happens if I just let the entire group go?” 

And you see, in some cases when the pandemic hit, that's exactly what some companies did. I want to disclaim my own biases here. I believe that is a mistake, but I'm curious to get your perspective.

Talia: Yeah, there's companies that really benefit from having dev advocates, and I think those are the startups as well as the big companies. So, Split, for example, I think our team benefits from me because I'm so wonderful. I think we benefit because when developers have questions and when they need tutorials, that's where I come in. And they know that, “Okay, she's not trying to sell us anything, she really just wants us to have such a great experience.” And then there's cloud advocates like in AWS and in Microsoft, and they provide kind of the same tooling and support that we do at smaller companies. So, I think it is beneficial, but you just have to know how to do it the right way.

Corey: Back when I was on the speaking circuit—again in the before times—again, I was an independent consultant for a few years and then I wound up taking on a business partner and expanding, and one of the things I went through with taking on a business partner, who himself is engaged publicly. He's an O'Reilly author. Good for him. But there was a bit of where, how do we quantify the value of me going around and speaking at these events? And the answer that we ultimately came to—and I'm not suggesting this is perfect, ideal, or even good, if I'm being honest, was that we don’t. I know that on some level, if I go out, and I talk about the things that I do in front of an audience, good things happen. But, first, it's impossible to quantify and, two, attribution will drive you out of your mind if you let it.

Talia: Yeah, I agree with you. And I don't think that there's any way to quantify this role because you're not measuring the amount of leads because you're not doing sales, and you can't really quantify the traffic that comes to your site because it might not lead to a quantifiable number of sales. So, I really don't think there's a way to quantify success in the role, it's more of just the quality of what you're doing and how you're engaging with developers, and yeah, things like that.


Corey: And it's challenging in the context of larger organizations because as you start expanding your developer advocacy groups and your developer relations functions, they get—I don't mean to be unkind—pretty expensive at some point. And when you're investing vast seas of money and figuring out where to allocate that, and it's, “Well, this group makes good things happen, but we can't really define it,” isn't good enough from a executive level, the only reason I'm able to get away with it here is because I own half the company and cool, I can basically say, “We're going to do this,” and there isn't a whole lot of recourse. It's the first time in my career where I don't actually have to worry about getting fired. Most people don't have that particular luxury.

Talia: [laugh]. Yeah, the way that would be ideal is if the numbers didn't matter. But if for example, I put up a tutorial on setting up feature flags with Node and React, and then the next day, we see there's a lot of activity on the Node and React documentation pages, and we know that people are building these apps, I mean, it's something that you could use to provide value, but in terms of the quantifiable number, there's not a lot that you can correlate.

Corey: I don't have any answers for this. It's one of those areas that's just difficult to look at because a lot of my friends and associates are in the DevRel space and this is a common discussion. And I'm increasingly of the opinion that no one has really solved this, but I know that taking a step back, companies that have invested heavily in developer advocacy do well in this market when it's executed appropriately, and others who have cut back find themselves floundering, and there's enough data points to make it pretty clear what the right direction is. So, let's talk less than the abstract and more about you personally. There are an awful lot of things that DevRel can encompass. What parts of it do you do? What parts of it do you not do? Where do you start? Where do you stop?


Talia: One of the main things I do is I speak at conferences and meetups, and right now everything's virtual, but I speak at events, and I write blog posts and code tutorials, and I create code samples and sample apps. I also host a monthly roundtable with our developers, so anyone can join and talk about any roadblocks they had or implementation things that went wrong that we can improve. And then we also have community Slack channel where developers can talk and I can also answer questions there. And then—I think at the core of all of this, is I teach. And I think developer advocates, they should be, I think, really great teachers. 


So, you're teaching different things to do with the tools that you're advocating for and the products that you're advocating for. So, that's kind of what I do. And I got started with it at my previous company. I was a software engineer at WeWork. And I was doing this really cool thing, and someone suggested, “Hey, you should do a tech talk because this is something really cool.” 


And so I did a tech talk internally for the company. And then someone suggested, “Hey this is really great. You should submit it to a conference.” So, I submitted it to speak at a conference, and from there, I just kept getting invitations to more conferences and meetups, and it kind of just skyrocketed from there. And I think I realized that the part of my role that I was missing from being an engineer was this external PR teaching side of dev advocacy. So, now I'm a dev advocate, and I love what I do.


Corey: I adore the way that you started that with the idea of being a teacher. And you're right. One of the most transformative contracting projects I ever did was—must have been six, seven years ago now—where I spent a summer as a traveling trainer teaching people how to use Puppet. And that was fascinating to me from a perspective of… first you have a roomful of twenty people who are within punching-you distance, and you have three days to teach them on this thing. Secondly, they spent not small money to be there, so they're expecting an outcome. 


And in many cases, some of them are kind of angry, where there's a perception that, “Oh, this software is coming to take my job away.” So, they're already coming at this from a weird place, then, of course, it's software. And computers are notorious for doing what they do best, and that's breaking. So, at some point, you'll do a demo and it fails, and good luck. Have fun. 

Oh, by the way, if they wind up yelling at the company and demand their money back, you don't have a job anymore. So, okay, no pressure. I'm not saying that's the way to learn to speak publicly, but it's one of those drown or swim moments. And that really informed a lot. It was a rapid evolution. 


The first class I gave, I was terrified; the second one is I got this; the third one is I don't got this; and by seven, it started to wind up getting rote, and I started experimenting more and being more genuine, and it worked super well as I went down that process.

Talia: I think it takes a specific skill to be a great teacher. And it's one that is really important in being a dev advocate is that you need to be able to teach without belittling and be able to teach people with different backgrounds. Some people who go through our tutorials have twenty years of coding experience and some people have two weeks of experience. So, I think creating content and connecting with people with all different backgrounds is really important.


Corey: There's another thing I learned by doing this was I gave a talk once the early version of it was a talk on Git. And I wanted to go super deep—honestly, I wouldn't recommend this strategy to anyone—but I wanted to learn Git better, so it's all right, how do I force myself to learn Git? I know, I'll sign up to give a talk about it in three months. [laugh]. That's what we call a forcing function because they won't reschedule the conference if you run out of time. I know this; I checked. 

And where, time to learn Git. And the first iteration of that talk would have been hilarious to the five people who maintain Git, but it was super deep in the weeds. And I wound up taking a look at this and figured, you know, let's make this more broadly accessible. And it started off by even explaining what Git was. And yeah, there were jokes for all experience levels scattered throughout it, but the lesson I took from that is, it has never been a bad idea to make content more accessible to people. 


At some point, you do have to draw a line somewhere. I mean, when I wind up doing content about AWS, I don't start by explaining what AWS is every time; that would get very tiring. But the idea of reducing the prerequisites that are required in order to understand the context of what's happening is very important. And there's no perfect answer. Sometimes there’s—if people don't understand an environment, you aren’t going to be able to teach them effectively because they don't have the fundamentals. So, dialing that in is very important, but given the choice, I will always trend towards being more accessible to more people.


Talia: Yeah, yeah. And I think it also depends on your audience. If you're speaking at a meetup that is college students, and people who don't have twenty years of coding experience, you might want to add those introductory steps. But if you're speaking to all the architects at Google, like, maybe don't tell them how to create a React app.


Corey: No, no, when you architects at Google, they like to get on stage and tell everyone else how they're doing it wrong. There’s a little thing called context, it's, “Yeah, your company has invested tens of billions of dollars in your developer infrastructure. We have about, ehh, eight bucks.” So, yeah, Google scale solutions do not necessarily map to others. And in fact, that's one of the things that started to irritate me and I started getting louder and louder about is when you give a talk about how you do things in the right way to proceed with things and people leave the room feeling bad because what they've built looks nowhere near that good, you've kind of failed. 


The theme that I always like to go with is what you're doing is great. Now, here's how you make it even better. And that's an uplifting next step, brighter path, brighter future story. I used to think that there was something wrong with me when I would leave a talk feeling bad. And having done this enough, I'm firmly of the opinion that no, no. That was a bad talk.


Talia: Yeah. And I think you're absolutely right. I think when you leave a talk, you should feel empowered. Like, “Wow, I want to go do this thing that I just learned about and I didn't know that I could do it, and that it was so easy, and this person just enlightened me, and I just want to go do it now.” I think that's how people should be leaving talks that they hear.


Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.


Corey: The whole point is to be uplifting and inspirational and fun. And not everyone is going to have the same approach. Other people's material that's about as well as other people's shoes. But what I find is that my way of grabbing people's attention is humor. If I can make people laugh, I have their attention and then I can teach them something. 


Now, some people don't have that particular approach. Their humor doesn't work in that way, or that's not how they contextualize things, they don't know how to tell a joke, or—worst case failure mode—they confuse being funny with being actively insulting. And that doesn't fly. But that's always been my approach. I've turned them into sort of borderline stand up comedy, and everyone thinks, “Oh, that's what you have to do to give a talk?” No, that's my personality defect that I just managed to turn into something of a strength.

Talia: Yeah, I totally agree. Being humorous onstage. And honestly, mostly, what I do that works for me is I just make fun of myself. And that works really well. The other thing is, I'm like a very sarcastic person, and it comes out in my talks. 


And so yeah, I think humor is a great place to start. It's been rough during COVID because when I give talks, everyone's muted and I can't tell if they're laughing at my jokes. So, sometimes I'll tell people, if you laugh at my jokes, just unmute yourself, [laugh] so I can hear you.


Corey: Oh, and the delay, too. It turns out that there are a couple of things that are baked into human behavior. I discovered this once giving a talk to the silent disco type of talk. For those who are not familiar because it’s a weird term, there are—usually a big open room, and there are three stages next to each other, and all of the audience for each talk is wearing a different colored set of headphones. So, you're basically whispering into people's ears, and you speak in a normal voice onstage in front of everyone. 


But when you're sitting in a room wearing headphones, there's a societal conditioning thing of you don't laugh when someone says something funny. I mean, otherwise you turn into the person who just starts bursting out laughing at nothing while riding the train, and suddenly, oh, you're that person. So, it's challenging when you tell a joke that you know is good and you can see people smiling and laughing, but there's no visible feedback. And video—or recorded video—makes that even worse.

Talia: Yeah. I mean, it's hard for a first talk that you don't know what the audience reaction is going to be. But there's a couple of talks that I've done so many times, and I know that I'm being funny, in certain points. 


Corey: So, how have you found that your approach to DevRel has shifted since the before times where now it's, “Hey, do you want to come and hang out in a big room with other people?” “Hell, no.” It's definitely forcing rethinking of a lot of this. What have you been doing?


Talia: Yeah, I feel like right now, there's just more of an emphasis on digital experiences because everything is online from COVID. And I feel like the tech world is just booming right now, so I think, yeah, there's just an emphasis on everything being digital. And I don't know that it necessarily has an effect on my role, specifically. And the only thing that I can think of is that travel is obviously limited right now, and all the events are virtual.


Corey: There's an awful lot of things that a virtual event lets you do, and just as many things it doesn't let you do. And in some ways, it feels like people are still stumbling through figuring this out. It turns out that when people are in Zoom meetings all day long, they don't want to open up Zoom to attend the conference. It's, “Oh, cool. It's just another meeting.” 


Anything that doesn't have a strong social channel where you can talk to peers—which frankly, from my perspective has always been the best part of any conference I've gone to—is a problem. There are a lot of weird and broken approaches, and the technology isn't quite there in some respects, and everyone's trying to do the same thing, and, “Oh, we can do digital events. Okay, we'll make it three weeks long.” Why? How much attention do you think that people have? 


People don't want to attend online conferences three days a week, as it turns out. So, it's a matter of almost separating signal from noise. I don't have any answers here. It's just a painful problem I keep seeing.


Talia: Yeah, I think you just have to choose your conferences wisely and choose what you go to wisely because there are a lot of virtual events right now, and it can be a little bit draining if you decide to go to as many as you want. I feel like you should just choose wisely, go to the ones that you really feel like will be beneficial for you, and don't go just so that you can say, “Oh, I'm not working right now.” Split has a user conference coming up March 16th and 17th. It's called Flagship, and it's just a two-day interactive virtual conference where we'll have success stories about progressive delivery, and best practices of experimentation, and just, like industry trends. And so we have speakers from Google, and LinkedIn, and ServiceNow. So, that's happening in March.


Corey: Excellent. We will of course put a link to that in the [show notes 00:24:27] because honestly, attending conferences we get actual value out of them is super important. The painful part I've always found is how do you figure out which one it is? And I hate to be judgy but I'm going to do it: the more enterprise-y it looks and the more it looks like you're reading an airport ad billboard, invariably the crappier the conference is going to turn out to be. I'm sorry, but that's how I always feel when I look at this stuff. And credit where due, I don't see that Split is falling into that trap. Hazzah.


Talia: [laugh]. Yeah, it should be a good conference. So, we'll see what happens. I'm doing a workshop at the conference on setting up feature flags. So, yeah, we'll see how it goes.


Corey: It's one of those things I keep wanting to get into. Let's actually talk a little bit about that. Feature flags are something I keep meaning to look into, which makes me feel better about not having really looked into them in any meaningful way because it feels like it needs things that I don't actually do. For example, you know, testing my code. What are the prerequisites for making feature flags something someone should care about?


Talia: There aren't any prerequisites for using feature flags. You just have to have a stable app. But once you have the app, there's so many things that feature flags allow you to do, so things like testing in production, and A/B testing, and canary releases, and percentage rollouts, and things that without feature flags would be so much harder to implement. So, I think it just makes your development much easier, and Split takes care of all of that for you.

Corey: So, testing in production is one of those things that is very frequently talked about, but it feels almost like it's chaos engineering-focused where, it sounds, for the first time you hear about it, like, an absolutely terrible idea. And then it once you look into it, no, that actually makes an awful lot of sense, but it feels like you have to educate the customer before they see the value of it. And that always felt scary to me.


Talia: Yeah. So, one of the things that I talk about—and this was actually the first talk I ever did—was testing in production because it was something that I implemented end-to-end at WeWork. And so testing in production can be really scary because you're running tests in production, you could affect real end-users, you can break things in production. But the great thing is that when you use feature flags for testing in production, you reduce the risk of anything going wrong. So, what I mean by that is you target your internal teammates inside of the feature flag. 


And what that means is that you basically create a list of people, and you say only these people can see this new feature. And then you use that list of people and say, “I'm going to test my feature with just these people.” So, now your developers, and your QA, and your product people can go in and see the feature in production, test it out manually, and then turn the feature flag on once it's ready to be turned on. So, basically, you're not using a staging environment or a dummy environment; you're using production because that's where your feature is going to live. Your users aren't going to log into staging to see your feature, they're going to log into production. So, I think people do get scared, but using feature flags is a great way to mitigate that risk because if something does go wrong, your end users won't be affected. It'll just be your internal users, which are your devs, and your product, and your QA. 


Corey: Yeah, it's something you really need to get the entire team on board with in some respects. The other piece of it though, is by testing in production, on some level, you at least have the potential to inherently degrade the experience for your customers or your users. At least I have a hard time seeing how that wouldn't be the case. 

Talia: So, what you're actually doing is you're making the customer's experience much better. You're making sure that the features work before your customers can see it. So, if I'm releasing a feature, I want to make sure that it works in production, not in staging. So, you just want to make sure that you're doing it safely with feature flags and you have it implemented correctly, but at the end of the day, you're providing a really great user experience.


Corey: Yeah, there is something to be said for accepting a bit of short term pain in favor of making it better for everyone longer term. And I suppose that’s part of the reason why chaos engineering came out of Netflix as opposed to other places, where the failure mode of degrading a particular user's Netflix stream and having them have to restart it or whatnot, isn't super high. As long as you're not continually testing on that same one user. And if you are, honestly, the idea of having a canary list populated with people you don't like is amazing, but at that point, the stakes aren't super high. It works when you're talking about streaming movies. It feels a lot more challenging when you're doing feature enhancements on someone's bank account.


Talia: Yeah. So, we definitely don't recommend using real users to test in production, what I recommend is using test users that are in production. So, the same way that you would log in to Netflix and create an account, so you kind of do the same thing for test account. So, you just create an account in production that's used for testing that acts as a real user, but is not a real user. We had, like, automation bot after automation bot in production, and we would know that whenever any data comes in from these bots that they're actually testing in production and that they're not real users. 


And so we don't use actual users when we're doing testing. We're using test users that act like real users and look like real users, but they have this identification of being a test user. We use things like a back end flagging system to identify all test users and test entities in production. So, just some sort of Boolean that's ‘is test equals true?’ Or ‘is test user equals true?’ And that's how we would differentiate test data and real data in production.


Corey: One line that I liked about this was that everyone has a test environment; some people also have an environment where production lives separately. And on one level or another, you're always going to be testing your code, just can you do it in a way that doesn't cause serious damage or harm to users? And getting people onto that path is challenging.


Talia: It is. And I think that everyone has experiences of testing in a staging environment, or a QA environment where they tested their features and it worked so great in staging and they signed off, and then as soon as they pushed to production, there's an issue or something goes wrong. And I think using those experiences to get people on board is a really great approach.


Corey: So, thank you so much for taking the time to speak with me today. If people want to learn more about who you are, or what you do, what you're up to, where can they find you?

Talia: Oh, you can find me on Twitter. I'm @talia_nassi. And yeah, and I hope that you guys come to Flagship in March.


Corey: Excellent. We'll of course put links to those things in the [show notes 00:24:27]. Thanks so much for joining me. I really appreciate it.

Talia: Thanks for having me. This was great.


Corey: It really was. Talia Nassi, developer advocate at Split Software. 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 an insulting comment telling me that you hope someone tests in my production.


Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.
Play Episode
When Two Clouds Isn’t Enough with Alan Raison
Screaming in the Cloud
04.27.2021
26 Minutes
About AlanDeveloper and DevOps-er; interested in all kinds of cloudy tech, especially deployment pipelines and infrastructure as code. Also building the DevOps capabilities at Hitachi Capital.

Links:
Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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.


Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.


Corey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.


Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Alan Raison, who’s currently a developer meets DevOps lead, slash whatever you want to call yourself, really, over at Hitachi Capital in the UK. Alan, thanks for joining me.

Alan: Pleasure to be here.

Corey: So, what is it you do, exactly? It’s a truism that as long as we continue to improve our titles, it obscures meaning to the point where it, on a long enough timeline, is completely meaningless but has 500 words tied to it. Where do you start? Where do you stop?

Alan: Okay, so I’ve got a background in being a developer. So, I started at Hitachi nearly five years ago as a lead developer. But last year, I really sort of—well, I’ve always been interested in the deployment side, infrastructure as code, things like that. And so the opportunity came about a year ago to try and start up a DevOps team inside it, actually. So, I am now DevOps lead, one of two.

We’ve got a small DevOps team. As such, we work alongside the development teams, the testers, trying to set up their build pipelines, their cloud infrastructure, and any, sort of, bits and pieces along the way. So, we’ve got on-prem infrastructure, as well, that we do a bad job of looking after.


Corey: So, I think it’s fair to say on some level, that Hitachi Capital could be considered a ‘legacy’ company. And I use the term legacy in the way that I always hear it when other people use it, which means, it makes money, which is apparently falling out of fashion. It has one of those old-fashioned business models that our grandparents would have understood of, “Oh, you provide a service or good and you [unintelligible 00:02:12] for more money than it takes to wind up providing that service or good, and that leftover is called a ‘profit.’” and that seems to have not really been absorbed as a lesson by the venture capital set, et cetera. Is that a fair way of casting it?

Alan: Well, yeah, it certainly seems to work as a business model for us. [laugh].

Corey: Yeah, “Well, we’re losing money, but making it up in volume,” never really seems to catch on. But you were a listener of this show and reached out with some fascinating feedback. And you said that, “Well, you’re in a company that’s the antithesis of most of the things that I believe.” And you went through a laundry list of those, and we’ll get to some of them, but what I really appreciated about it was that… yeah, I agree with you; I absolutely have a certain perspective that aligns with a certain type of company, just because that’s what I tend to be surrounded with. It’s where my own career has taken me, it’s a large part of where significant and overly vocal—shall we say—portions of my audience tend to reside.

So, it’s very easy to lose sight of the fact that there’s a big world out there, and it doesn’t always align to a SaaS company in the Bay Area building something that is patently ridiculous. So, a lot of what I said doesn’t necessarily apply to what you’re doing and how you’re doing it. And I think that’s great feedback. More of that, please. But of all the weird positions I’ve taken, let’s start at the top. What offends you, slash you disagree with the most?


Alan: [laugh]. Well, I wouldn’t say anything that you say, offends me. I think, in fact, you’re probably on the right lines objecting to some of these things. But we are where we are, I guess. So, for example, multi-cloud.

As developers, we tend to like AWS. It’s in many ways built for developers. It’s the first one developers tend to go to. But hey, we’ve got a sizable Windows estate of servers and whatever else we do in Windows, including a number of COTS systems. And so it makes sense for us to not only use AWS, but we use Azure as well, and we’ve got some Windows engineers who are putting things into Azure, as well as the developers putting most of their stuff into AWS.

That doesn’t sound too crazy for starters; most people, I would imagine if they’re looking to go multi-cloud, would consider two of the big three—who I consider to be, like, AWS, Azure, and GCP—but we also have data centers. We don’t want data centers, but we do have a large Oracle estate, Oracle databases, Oracle WebLogic application servers. And when it came to putting that into AWS, it looked like it was going to be very expensive. Combine this with those Windows servers that these applications seems to talk to, and it was suggested, by I think it was an architect or maybe from some salesperson who spoke to an architect, that we use Oracle Cloud. And believe you me, me and my boss, we fought this for quite some time.


We thought, you know, [laugh] this can’t be a good idea. Three clouds is quite clearly crazy, and we don’t want to go there. But we did look into it, we looked in the numbers and the Oracle salespeople did their technical demonstrations and things, and it does seem that if you want to run the Oracle Database in the cloud, then Oracle Cloud isn’t actually too bad a platform to do it on.

Corey: Okay. A lot to unpack there. Let’s start at the top. Even though I talk about it otherwise, I fall prey to it the same way anyone else does, which is, it’s easy to talk about an ideal world and how you would do things in that mythical environment. It’s the whiteboard fallacy, almost, where design an architecture that solves for X, Y, and Z.

Well, sure, in a vacuum, it’s easy to do. In practice, there are questions of, “Well, what about the real world being messy?” Plus the whole aspect of we’re very rarely working with anything that’s purely greenfield. There’s got to be support for existing workloads that are not built in a way that align with cloud. So, I think that I need to be more cautious about framing things the way that I do.

So first, thanks for the feedback. I really do appreciate being able to catch these things when they slip out and inadvertently start tainting the ecosystem with, I guess, a too forward-looking SaaS-y startup-style company perspective. I mean that sincerely. It’s great to get feedback in a constructive way.

Alan: Well, I still think there is room for that criticism, and it’s not entirely unfounded. But that’s what works for us, and I’m not offended by your snark at the multi-cloud strategy at all.


Corey: [laugh]. I would also say that multi-cloud does make sense for different workloads that have very few points of interaction, especially if they’re already built to embrace the benefits that one cloud provider offers over another. I don’t really have a problem with that. My anti-multi-cloud stance—which I feel like it gets misinterpreted a fair bit—is, “We’re going to build one workload that we could seamlessly move between cloud providers, even though we either never do it or we’re trying to do it for the wrong reasons.” That’s the multi-cloud that I’ve seen being pushed by a variety of vendors and that’s the thing that upsets me.

But personally, I use GitHub, which is an Azure product or rapidly becoming something like that. I use things that are well under the umbrella of GCP. And I run a lot of infrastructure services on top of AWS. So, from that perspective, we’re all multi-cloud unless we’re doing something hilariously wrong.


Alan: [laugh]. Yep.

Corey: Now, as far as Oracle Cloud goes, I’ve played with them before, and I think I’ve been fairly public about it, in that, from a technical perspective, I like an awful lot about what Oracle Cloud is doing, particularly if you’re already an Oracle customer. From migrating a database that is already an Oracle Database onto a cloud, it’s hard to necessarily push back against some of the value propositions that Oracle comes out with. Even on a technical basis from a pure serverless perspective, Oracle Cloud is still pretty decent, based upon what I’ve seen. My problem has always been, honestly, their business practices, their salespeople, their approach to a lot of things that makes it unpalatable for certain customers to enthusiastically dive in.

Alan: Yeah, and I think that’s what made us nervous to begin with.

Corey: So, something else that you mentioned in your email to me was specifically around the idea of serverless development, and I find that fascinating on a couple of levels. The first is that in your parenthetical, you said—right after serverless development—“Not very well,” which is universally true every time I see someone start to work with serverless. It’s, “Are you using serverless?” “Oh, yeah. But we’re really bad at it.

We’re not using it properly.” And I’ve come to the conclusion that if that’s what people think about their own use of serverless, they’re probably doing it right because everyone feels like it’s unfinished. It’s weird. You’re misusing it in a bunch of different ways. But that’s exactly how everyone uses it. Tell me more about that.

Alan: Yeah, I guess so. I mean, there’s always more services to use in AWS. But yeah, we started as, I guess, most people start in AWS: writing applications that run on EC2, and then decided to tear that up and try it out with containers, and then we decided that that wasn’t good enough, so let’s go and try out Lambda.

Corey: And how did that experience unfold for you?

Alan: Yeah, so it’s a massive learning curve for anyone. So, I think I can pick stuff up quite quickly, but when you’re bringing a whole development team along with that, then there’s always going to be gaps in people’s knowledge and things people know better than other people. And so it’s just really hard to get everyone on the same level. And especially because we did, basically, a change of language. We’re typically Java developers, and now who wants to run Java in a Lambda? I don’t think anyone does. So, we now almost exclusively do TypeScript. So yeah, there’s, as I say, a learning on lots of different levels there.

Corey: One thing that seems to be true across the board with serverless, is that it may be one of the first, shall we say, bleeding-edge futuristic-looking technologies that's seeing greater adoption in the enterprise than it is at smaller scale. Is that something that you’re starting to feel yourself? What drove you folks to start looking at serverless, instead of a number of other approaches, be it containers, or something else?

Alan: I suppose it’s the promise of not having to look after infrastructure. We’ve got a number of infrastructure teams at Hitachi Capital, and it always seems to take a long time, or there’s a lot of roadblocks in server provisioning, and security hardening. And we just wanted to sidestep that, really, and go for the managed offering.


Corey: There really is something to be said, for letting the provider handle these things for you. There’s pushback from more traditional ops side of the world where it’s, “Well, at that point, you’re just letting your cloud provider dictate your availability.” Well, yeah, no kidding. You always are. With serverless, you’re just being a little more upfront about acknowledging that.

Alan: Absolutely. Yeah.

Corey: You said that the learning curve is steep. And you’re right, I keep saying that things like Lambda functions and their equivalent on other providers are inherently platforms that are defined by their limitations rather than by their capabilities. And honestly, I’m kind of on board with that, even though we start to see those limitations relaxing on a year-over-year basis, where it forces you to rethink about how it is you’re approaching these types of things. I find that in my experience dealing with enterprises, one of the first things to get Lambda-fied, for lack of a better term, is a cron job somewhere living on a job server where sometimes that job server fails—did it run? Didn’t it run?—being able to effectively shove that into a Lambda function almost feels like step one, where people start to get their feet wet. Does that align with how you approached it? Or did you come at it from a different angle?


Alan: I guess we came at it from a slightly different angle because we were looking to build applications on top of—so we have APIs that have a Lambda back-end; they’re usually, sort of, fairly dumb Lambdas. They’ve passed through to some third-party back-end somewhere, you know, doing a bit of mapping or transformation, a little bit of business logic, perhaps. But the bulk of it is just listening to a web frontend, calls a back-end API that has some Lambda components.


Corey: That’s functionally how I got into it at first, as well. I started off with a shell script that was great and all, to generate my weekly newsletter, and it was, yeah, what happens if I’m not in front of a box that has a console? I wanted to turn into something that vaguely looked like a web app, ideally that I could use from an iPad out on the road. And in time, it was, “Huh, maybe a Lambda function becomes the right answer here.” And it almost certainly wasn’t, but the way I misused it, it became the right answer and it sort of snowballed away from there.

But what you say about feeling like you’re doing it not very well absolutely resonates. Because the entire time I was doing this, I’m sitting here with the, “I am really not using this in the way it was imagined being used.” But I’ve never met anyone who feels differently.

Alan: Yeah, I think the range of different frameworks, as well, is quite daunting. So, you can either use AWS’ SAM framework, or you can just use the APIs directly, or there’s now the serverless framework, or there’s Architects, or a number of different other—

Corey: The CDK, Chalice, Apex, you can keep going on, and on, and on—


Alan: Exactly.


Corey: —and the problem is, if you start following random blog posts, suddenly it’s, “Oh. They’re using a different one. I should start over.” Or you wind up with this ridiculous combination of 15 different things that you’ve gathered from various places, and, “What on holy horror have I built? Well, [laugh] it’s something that works, so here we are.”


Alan: Absolutely. I think we sometimes miss the opportunity to really use some of the power of AWS, so it kind of frustrates me that—because we’ve always done relational databases, we don’t really have the confidence to use DynamoDB, for example, or if we do try and use it, then we kind of hurry back into our comfort zone when things get hard. So, that kind of frustrates me a little bit with serverless applications.

Corey: I can’t shake the feeling that everyone gets confused sooner or later. Speaking of things that are confusing and everyone tends to go in strange directions with, let’s talk about everyone’s favorite tech buzzword in the enterprise world ‘Kubernetes.’ You playing with that at all? Have any strong opinions one way or the other on it?


Alan: Funny you should ask. Yes so, I’ve been actually trying to promote the idea of using Kubernetes in Hitachi. And this may sound odd as well, but as I said before, we’ve got a number of commercial off-the-shelf systems that we use. They’re way too old to actually have heard about Kubernetes. But sometimes you just need somewhere to deploy something.

You know, not everything will run in a serverless platform. Sometimes I just want to deploy a dashboard somewhere or make this application that you can easily download run somewhere in our infrastructure or that includes cloud as well. And I think in that sense, Kubernetes would be a really good fit because we could have a common platform. As developers, they don’t need to care where it’s running, they just point to an API, and then voila, they can see an endpoint and access it without needing to provision hardware, get it certified by InfoSec, and all of that fun stuff.


Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.

Corey: I tend to shriek and something approaching horror whenever I see a Kubernetes deployment beginning because invariably it’s aimed at something that is a ‘Hello World’ style of deployment. And it’s, “Oh, dear lord, this is overwrought for what you’re trying to deploy.” The other side of it, though, is that the applications that people are looking to migrate into a Kubernetes environment are also a lot bigger than the Hello World examples that folks use. Are you already running these apps in containers and looking for a different orchestrator, or is containerization part of the Kubernetes experience as you’re approaching it?


Alan: So, we’ve wanted to run a few things in containers for a while, but they’ve never really sat anywhere, so we’ve just got a few services running just in Docker, and if they fail, then well, who knows? Someone will have to go and restart it when they find out. Whereas the behemoth that is Kubernetes which obviously sought that out for us, and hopefully, let the support engineers sleep better at night, as long as they don’t have to manage too much of the actual hardware parts of it. So, as I indicated, that’s not where my skills lie; I just let someone else deal with that. And I believe that’s probably where most of the complexity of Kubernetes is. So, maybe that explains my viewpoints.

Corey: I think in the aggregate, my take on it is that if you’re building something greenfield or vaguely close to greenfield, serverless feels like the way to go. But if you’re looking at migrating something pre-existing, then Kubernetes slash containers seems like the path that is the least disruptive to the organization. First, do you agree with that? And secondly, do you think that optimizing for not disrupting the organization is the right path?

Alan: I mostly agree with that. So, I would just add to that, that some things you can’t run in a serverless environment. I know that AWS have managed Grafana and managed Prometheus, but before then, if you wanted to deploy those sorts of services, you had to, sort of, roll it yourself or run some crazy infrastructure to do that. Or just deploy it with a Helm Chart into Kubernetes. So, I think there is going to be a place to package applications that don’t necessarily run in a service or as a service. And sometimes you don’t want to buy things in the cloud as a service. Sometimes it’s more convenient to run them yourselves in your own environment. And I think that’s probably where Kubernetes fits in.

Corey: I think that the cloud providers would shriek and scream at the idea of, “Oh, there’s a workload you think isn’t appropriate for the cloud? Well, you’re wrong, based upon nothing other than what you just said.” And that’s not a [laugh] helpful sentiment. “Cool. I’m not just going to grab petabytes of data and shove it on up there.” Or, “I’m not going to just migrate an entire massive fleet overnight.”

It doesn’t work that way. So yeah, I think there are a number of workloads that, based upon business constraints—internal and external—that you approach from that perspective. I think that there’s tremendous validity to having workloads that are at least capable of running in two places at once, at least during the transition, if not beyond. Now, every time you add a provider to that, it feels like you’re inherently limiting the capability story, whereas if you have something on-premises, great. You probably don’t have an object store on-premises that reacts in quite the same way that S3 does, to give an easy example. Does that align with your understanding, or do you feel differently about it?

Alan: Yeah, sure. So, as you say, we’re not going to have unlimited petabytes of storage in our data center, ever—

Corey: Well, you will, but your budget owner is going to have a minor heart attack [laugh] as soon as you try it the first time.

Alan: [laugh]. Yeah, exactly. So, I think our strategy, Hitachi is cloud-first, but some things we know aren’t suitable for that, so take a look at where it’s most suited to run.

Corey: So, looking at how you’ve approached it, is there messaging or storytelling that would have made it easier to wind up heading in this direction sooner? Was it a matter of waiting for certain levels of maturity from the provider perspective? Or was it entirely from an internal point of view where there are enough stakeholders that need to get on board with alternate ways of doing things before you can see any real traction?

Alan: So, I think it’s mainly a case of education. So yeah, definitely getting the stakeholders in the company bought into this crazy new way of working, so having this massive AWS bill land every month and not really being sure who’s paying for it, but it gets paid anyway. And also in terms of the developers, obviously, writing their code in a way that’s appropriate to deploy to the cloud, and also the support staff who monitor and look after these applications.


Corey: So, it’s easy for me to sit here and say, “Oh. You should just go ahead and do X, Y, and Z if you want to wind up exploring down this particular path.” But I don’t work at a large enterprise or even a medium enterprise as you describe it, which is still orders of magnitude bigger than my version of big company. So, what are the biggest stumbling blocks that you’ve encountered going down this path, and how would you address them differently if you had to do all over again?


Alan: Okay. So, one of the biggest issues we’ve had for years is the lack of cloud connectivity. That’s now being addressed, but we’ve had to work around that limitation in quite a few ways. And there’s been various reasons for that. Network infrastructure has changed a bit over the years.


But the lack of cloud connectivity was really a problem in the early days when we were trying to make useful systems run outside of our network, but still, be secure and communicate with the back-end services that we needed in our network.


Corey: So, if you could talk to other folks who are where you were when you started this journey, are there any resources you’d point them to, as far as something that they should understand, something that they should absorb, or just something to help point the way?

Alan: Yeah, okay. So, we’re really trying to change into more of a DevOps culture at Hitachi, and I’m really passionate about how we go about this. And as such, I really love the book Accelerate—which have you had the author on the show? I forget.

Corey: Oh, yes. Dr. Forsgren has been a recurring guest on the show.


Alan: Yeah, I thought so.

Corey: And she’s just spectacular at answering the questions that I wish I had been smart enough to ask in the first place.

Alan: Excellent. Yeah. So, they point out the four key metrics for a high-performing culture, and so I’m always trying to bring those up in team meetings and to the leadership of Hitachi. So: deployment frequency, lead time, change fail percentage, and meantime to restore. So definitely, that book, I think, is really key to understanding why organizations need to look at those metrics, as opposed to measuring lines of code, or hours worked, or anything like that, in terms of getting a high-performance culture.

Corey: And we’ll, of course, throw a link to the Accelerate book in the [show notes 00:22:29] because we are always fans of what Dr. Forsgren is up to, and any chance we get to wind up putting her in front of more people, we’ll take it.

Alan: [laugh]. Great.


Corey: So, I want to thank you for taking the time to speak with me in as much depth as you have. If people want to wind up learning more about what you’re up to, challenges you’re facing, how you’re overcoming them, okay can they find you?

Alan: So, I occasionally Tweet. I’m @alanraison. I’m on the GitHub, also alanraison there. That’s probably about it.

Corey: Excellent. Thank you so much for taking the time to speak with me today. I appreciate it.

Alan: No problem. It’s been a pleasure.

Corey: Alan Raison, DevOps lead at Hitachi Capital UK. 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 hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment giving me feedback the insulting way.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.
Play Episode