Screaming in the Cloud - The Operations of Operations with Jesse DeRose

Episode Date: August 3, 2021

About JesseJesse is a seasoned operations engineer with a deep passion for understanding complex technical and organizational systems. He's spent his career helping Engineering teams achieve their business goals by improving how they interact with their technical systems, and with each other. He's currently a Cloud Economist with Duckbill Group, guiding organizations along their journey of cloud cost optimization and management.Links:The Duckbill Group: https://www.duckbillgroup.com/Jesse’s Twitter: https://twitter.com/jesse_deroseAWS Morning Brief: https://www.lastweekinaws.com/podcast/aws-morning-brief/

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. Your company might be stuck in the middle of a DevOps evolution without even realizing it. Lucky you.

Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy-in on DevOps practices? Well, download the 2021 State of DevOps Report, brought to you annually by Puppet since 2011, to explore the trends and blockers keeping mid-evolution firms stuck in the middle of their DevOps evolution because they fail to evolve or die like dinosaurs. The significance of organizational buy-in,

and oh, it is significant indeed, and why team identities and interaction models matter. Not to mention whether the use of automation and cloud translate to DevOps success. All that and more awaits you. Visit www.puppet.com to download your copy of the report now. Up next, we've got the latest hit from Veeam. It's climbing charts everywhere, and soon it's going to climb right into your heart.

Here it is. Well, dang. Ransomware had my data all jacked up, only I had secure backup. Then I met you, me, my AWS backup dream team. Yeah. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jesse DeRose, my colleague and cloud economist at the Duckbill Group. Jesse, thank you for joining me, even though when I asked you, it isn't exactly like you felt you had much of a choice. You know, I appreciate being on this podcast with you.

I think you've had an opportunity to talk to a few other folks from our organization so far. So I'm just happy to be included. I'm hoping that I get the members-only jacket after this recording. Oh, absolutely. The swag that goes out to guests is secret and wonderful all at the same time. So let's start at the very beginning. It turns out that despite the prevalent narrative that we put out there, our clouds economist did not just spring fully formed from the forehead of some God and appear fully formed, ready to slice AWS bills to ribbons? There's a process and there's always an origin story. Where'd you come from? Where were you

before this? So my background is mixed. I started with a management of information systems degree, which is inherently interdisciplinary. You're linking the importance of both technical systems and business goals and outcomes into a single degree. And when I graduated with this degree, I went out to the working world and said okay I'm here I'm ready here's my degree here's here's what I'm interested in let's do this and nobody knew what to do with me Corey like nobody knew what management of information systems was they simultaneously said you know you don't have a computer science or a computer engineering degree, so we don't believe that you've got programmer chops, especially since this is the golden age of

boot camps and quick start programming books and this movement that, you know, anybody can be a developer, which makes it even stranger that I'm not spending my weekends learning every programming language under the sun and automating the little tasks. Oh, absolutely. In fact, I got the exact same feedback. I don't have a degree. And oh, you couldn't possibly be a good programmer because you don't have the degree. You didn't go to the right schools. You didn't go to a boot camp. And when I asked you to write some sample code to demonstrate you know how to program, you just started crying instead. Because yeah, it turns out I'm actually not a good programmer. I just sort of brute force my way through it. And so far, through a lens of the SRE movement, suddenly, hey, you used to be really, really good at all these Linux things and working on systems and

keeping them up. Great. Now learn to code. And that was a big lift, at least for me. Absolutely. I struggled with that so much because every company that I interviewed with, every company that I even talked to, just assumed that I had some kind of programming experience and didn't want to talk to me if I didn't have programming experience. And to me, looking back, I think I really look at it like I may not have the programming chops to be the software engineer that is going to write the code for you day in and day out. But I am the person who knows enough that I can have the conversation with the software engineers. I can be the SRE. I can be the ops person that has the conversation with your software engineers and knows the things that they're talking about, but also knows when to get out of their way

and let them be the expert and do what they do best. There's something to be said for valuing expertise in areas that are, how to put this, not the thing that you think you're looking for. I mean, back when I was getting jobs before the Duckbill Group and I would be the first ops hire into a team of developers, which happened a few times, The process was always the same, where you'd have a bunch of developers asking what they thought were ops questions, or just giving up on that entirely and trying to figure out how decent of an ops person I would be by how badly I programmed. Or, okay, cool, you're an ops person. Great. Can you invert a binary tree on a whiteboard? It's no, but I can invert a rack in your data center. I'll go rage flip the rack. Why not? And it takes time. You have to sort of guide those interviews and those conversations, but it's always weird. Interviews are always weird because you're being judged on a skill set

that only matters when you're interviewing for a job. Yes. This is one of the things that I struggled with the most because I knew that most of the people who were interviewing me were either business people themselves. So they assumed that because their engineering team thought a certain way and acted a certain way that I should act that way specifically to the same way as everybody else on the team, or they were software engineers themselves. So they said, okay, I know how to invert a binary tree, to your point, Corey. So do you know how to invert a binary tree? If you know how to do that, then sure, you can be part of my team because you know how to do these things and think about these things the same way I do. Whereas because I was coming from this operations space, I knew other things that were equally as important, but weren't part of the conversations that they were used to having day to day.

So they didn't understand that just because I didn't have the same engineering chops as them, that I didn't have important information to share and wasn't able to stand on my own two feet in other ways. And that was one of the things that I really struggled with when I was starting out in the industry because I was thinking to myself, well, I have such passion to be part of these conversations, to have that conversation between the business side of the organization and the engineering side of the organization from an ops perspective, from a business perspective, from a technical perspective. And if I can't convince these people of my own volition, of my own passion for the good of the company, maybe data will help. Maybe there's something that I can find from a scientific research perspective. Maybe there's something that I'm sure somebody else has already researched this topic or found the same problems

that I have in the space. And maybe they're already talking about it. And maybe I can ride their coattail, so to speak, or follow in their footsteps and use the information that other people are talking about the industry to help me not just land these jobs, but ultimately better sell myself and help these companies move forward. That is fundamentally an encapsulation of what I believe the ops role to be of make things better and move them forward. But man, do we get stuck in an awful lot of weird and strange places. And interviewing itself is a skill, giving an interview. Very often it's a, I know a bunch of things that are trivia, but I know them. And if I know them, everyone must know them. Therefore,

if you don't know them, you must be bad at things. And it turns out for better or trivia, but I know them. And if I know them, everyone must know them. Therefore, if you don't know them, you must be bad at things. And it turns out, for better or worse, being able to memorize the documentation and spit out answers is not indicative of whether someone is a good ops person or a terrible one. Absolutely. I think that is one of the biggest problems that I have faced and one of the biggest problems in the interviewing space today, because it's not just about, can you regurgitate this information, but it's about, how do you think? How do you look at problems? How do you communicate to the rest of your team and within the rest of the organization. Those technical skills are ultimately important because you do need to understand some amount of technical information

to have those conversations. But the soft skills are also super, super important to be able to communicate effectively, to be able to think collaboratively and help everybody, not just yourself, but help the team build that shared purpose and move forward together. We're talking right now so far about traditional ops roles. Then we have what we do here, which is beyond the rest of all of that. All we just said is necessary, but not sufficient. Then it comes down to, great, okay, so you understand how systems work together. We found that for what we do and how we do it, you need to be a competent ops person as a fundamental tenant.

Otherwise, learning what all these AWS services do will occupy you for the next three years. So, okay, we start off there. Then, on top of that, it's, okay, there are consulting skills that it turns out are possible to teach, but incredibly challenging and time consuming because a lot of them boil down to can you be in a meeting with stakeholders of various levels? Can you deliver bad news in a way that they don't hate you because they don't really want to pay you to say yes to whatever they think? And can you do that in such a way without actively insulting them, which sounds like a strange thing until you realize, oh, wait, that's right. I do that in such a way without you know actively insulting them which sounds like a strange thing until you realize oh wait that's right i do that too so oh yeah cory's gonna have that problem isn't he yeah and that's part of the beautiful part about this place is that finally i'm able to hire people like you you were our first cloud economist here which meant suddenly

i didn't have to do it all myself and my mouth slowly stopped getting me in trouble in consulting engagements so I could spend more time having my mouth get me in trouble on Twitter. Yeah, I have to tell you, Corey, when I originally spoke with you and Mike about this role, I had just taken another operations position with a tech startup, and I was about two months into the role, And Mike sat down with me for coffee one morning and said, Hey, we're thinking about

doing this thing. Are you interested? And I said, Yes, but I just started this other operations gig. I can't up and leave them. I really care about the team. I really care about the company. And it would look really bad on me if I just two months in left. Because unless they were a really, really awful employer, which they weren't. So I said, sure, I'm interested in doing some kind of part-time work. And that's ultimately where I started with you and your business partner, Mike. And I have to admit too, when Mike originally approached me and said, hey, this is what we are thinking about. This is what we're doing. I didn't really think twice about the opportunity because I wanted to work with you and Mike again. But the way that Mike

described the work just didn't stick with me. It didn't resonate with me. It was more about, hey, I would love to work with Mike and Corey again, then, oh my God, this sounds like the dream role that I want to be a part of. And then when I came back to Mike, probably, I don't know, a month or two later, after I had started working part-time with both of you, I said, you know, Mike, I don't think I really made myself clear. I want to make sure that I help you understand. Ultimately, the things that I want to do are having these conversations, being that bridge with the business side and being able to talk tech and with the tech side and being able to talk business and make sure that both sides of the conversation are aligned.

And he just looked at me and said, what do you think we're doing? What do you think we sold you on? And it was that aha moment where I thought, oh my god, yes. I had already said yes. I was already working with both of you part-time. But that was the moment that really solidified it for me of like, this is what I've been moving towards. I've been wanting to be that person that can speak both languages and have a conversation with both sides of the table and speak to multiple different audiences. And now I'm finally getting the chance to do that. I'm getting the chance to grow both skill sets, which I think is extremely rare in a

lot of the smaller tech spaces that we see today. You hit on one of the secrets of the duckbill group, if I can be so grandiose as to claim that. And it's true because we take a look at people that we bring in and things that they're good at and things that we do, the things we do publicly and the things that we do sort of behind the scenes. And there's no reason we don't talk about them publicly, but there's no real reason for us to do so. Easy example, and what I want to talk to you about next is you are deep into improving understanding of complex systems, both technical, okay, great, that people expect that, and organizational, which sometimes throws people for a loop.

And it sounds like a weird thing to focus on here because we fix the AWS bill. We do not bill ourselves as management consultants. We do not bill ourselves as coming in and we will restructure your organization because that sounds patently ridiculous and no one in their right mind is going to buy that thing. I wouldn't buy it, at least not for me. My God, there are large consultancies that specialize in these sorts of things. I don't know how they do it because I certainly don't. We're not here to sell that,

though. Fixing the AWS bill, I mean, actually fixing it, fixing the business problem tied to it mandates an understanding of those complex systems. And your expertise and interest in that area is incredibly helpful here. Tell me more about it. This is one of the things that I've been really fascinated by ever since I joined Duckbill Group. I think everybody in Duckbill Group has a superpower or has a really passionate hobby to some extent, which makes each of us really interesting, unique individuals that can focus in different areas of a client's bill or a client's pain points when it comes to cloud cost management and help and find the parts that are frustrating, find the levers that can be moved and point them out and say, okay, this is ultimately where you want to pull this lever or not pull this lever to make these changes. And to your point, Corey, the one that is most interesting and passionate for me is that organizational development space. It is really understanding not just the small things that we can do today to help you save money on your AWS bill,

but how we and collectively how our clients can think about costs long-term to save money on their AWS bill. And I know that sounds really, really broad. And that's part of why I think that there is a lot of nuance in this space, to your point about other organizations or other vendors that are providing these consulting services. And I think it's also something that is also difficult to sell, which is why it's not our expertise in terms of what we are on the cover trying to sell to any of our clients. But I definitely think that there is opportunity to have some of those conversations within each of our client spaces to talk about some of the pain points that we see that may ultimately lead to better cost management practices long-term.

Things that ultimately might help the engineering teams communicate better with finance on a long-term basis, help the finance team and any of the leadership team more collaboratively talk with the engineering teams about understanding how much money is the product costing us? How much can we continue to spend on this product? Or how much can we discount one of our products for our customers before we are losing shares, losing money? What are the fine lines that we understand based on how much money we're ultimately spending on these features and on these products that will help us make better data-driven decisions about other parts of the company?

I really love installing, upgrading, and fixing security agents in my cloud estate. Why do I say that? Because I sell things for a company that deploys an agent. There's no other reason. Because let's face it, agents can be a real headache. Well, Orca Security now gives you a single tool to detect basically every risk in your cloud environment that's as easy to install and maintain as a smartphone app. It is agentless, or my intro would have gotten me in trouble here, but it can still see deep into your AWS workloads while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets,

no DevOps headaches, and believe me, you will hear from those people if you cause them headaches, and no performance hits on live environment. Connect your first cloud account in minutes and see for yourself at orca.security. That's orca as in whale dot security as in that thing your company claims to care about but doesn't until right after it really should have. And I want to call out that this is something that we are comparatively enthusiastic amateurs around. It's valuable. It's important. It's an awful lot of deep work. But I'm not sure that we go want to talk about organizational challenge and improvement. Oh my God, talk to Dr. Forsgren. Holy crap. She's been on this show at least, I think, three times now. And in seriousness, every time I start to question the value of expertise, I look at how deep she goes on all of these things and the level both of understanding that's baked into this and the amount of sheer work that it takes for her to take

all of that very deep penetrating analysis and make it accessible and understandable. I mean, every time I look at her work, I come away more impressed than I started. And that wasn't a low bar to begin with. Yes. And this gets back to my earlier comment about, I just want to be here to help. And in a lot of cases, when I was starting out, folks didn't know what to do with me because I didn't have data. I didn't have any information. But we have folks in the industry like Dr. Nicole Forsgren and other folks who are doing the research, who are knowledgeable in this space, who are putting in the effort to run these studies, to analyze this data, to share the results, and to your comment, Corey, to share the results in a way that makes sense

to everybody. That's easy to read. It's approachable. It's understandable. And I am so thankful to have folks in the industry who are doing that work because that is not my expertise. But that means that I get to say to the folks that I'm working with internally and with our clients, hey, don't take my word for it. There are other folks who have done research, and here's what the data says, and here's how we can help you apply this work, or you can apply this work within your own organization. And this is the challenge in some cases, too, where there's a lot of organizational theory, and that is being advanced heavily. And ways that makes teams more effective is super helpful. The challenge, of course, is that sitting here and talking about the theoretical layout of teams and how to improve

functioning as an organization is all well and good, but we're brought in by our clients to help them with their AWS billing situation. So at some point, the conversation has to evolve beyond, okay, so here's what you could do in theory in a vacuum, assuming spherical cows, et cetera, et cetera. And their response is, that's great. You actually gonna fix the bill or just pontificate for a while here? So for better or worse,

we don't really get to sit there and have deep organizational conversations at length with our clients just because that's not the problem we're there to solve. Everyone's busy and we want to make sure that we're respectful of their time. Yeah. One of the things that I've learned through my time with Duckbill Group and through other similar roles in the past is that I may have a strong passion. I may have this strong guiding light in my head,

but it's not the same guiding light that our clients or our customers have. And that's fine because we don't need to necessarily have the same goal in sight. But that means that I, to best serve our clients or best serve our customers, need to make sure that I am aligning, that Duckbill Group is aligning with the clients that we're working with, with the organizations that we're working with. So I may be thinking to myself, oh my gosh, I would love to come in with this long list of organizational development practices and share a million different things. But that's not ultimately what they need. Maybe that's something that they're going to

want long term, but it's not what we're here for today. And it's more important to help serve the client that is in front of me that is asking for things now today than try to educate them on what their problem is and then sell them on a solution. The thing that I think gets lost as well, whenever I start talking in depth about what we do on Twitter, for example, is generally from other engineers whose response is, okay, yeah, it sounds great. You come in and say that we'll save a bunch of money if we re-architect our application, but that's an awful lot of engineering time, so I bet engineers must hate you. And the honest answer is, yeah, we know that you would save some significant money if you re-architected your application, but we also pay attention to organizational dynamics,

and we know you're not going to do it because there's no business justification for doing it. So we're not going to bring it up other than possibly in passing, just so people are aware of the relative benefit if they want to bake that in. But we don't go in and suggest nonsense that is abhorrent. We all started as engineers ourselves. We are sensitive to engineering time, both in terms of what engineers enjoy working on, which is more important than people think, as well as the sheer cost of engineering time. People get concerned about the AWS bill, but it's invariably pale compared to the cost of the people working on the AWS infrastructure. You want to optimize the right things, and then you want to get back to doing what your company does, not continue to

iterate forward and spend thousands of dollars to save tens of dollars. Yeah, it's an extremely difficult balance to find. And it's really important to think about, is the ROI on this change worth the change? How much money am I ultimately going to save for the amount of engineering effort that I'm going to put in? Because we don't want to run in

and tell your engineering teams re-architect everything if it's going to maybe save them tens of dollars. We want to make it very clear that here are the different levers that you can pull to affect change within your AWS bill, to optimize your AWS bill. It's up to you which ones you want to pull. We are just giving you that guiding path. And then you have the option to say, yes, I want to spend the engineering effort to get this kind of ROI. Or you know what? I don't think that's the priority for us right now. One of the things that I've noticed with a number of our clients is that balance of, do we focus more time on building new features, which brings in new customers, or do we spend time

on the existing infrastructure and making changes to the existing workloads that we have. And it's this delicate balance of internal work, the things that you have put on the back burner over time that you ultimately say, well, I'll come back to that versus the new things that are ultimately going to bring in new customers, bring in new users, potentially bring in more money because both are important, but there needs to

be a delicate balance of both. And I feel like that's one of the biggest challenges that we face when managing an AWS bill and trying to optimize and organize and better manage cloud costs. And that's fundamentally what it comes down to. What is the best outcome for the client? And the answer to what is best varies based upon their constraints, what they're focused on, what they're trying to achieve. You could look at the end result of one of our analyses for a customer and take issue with it in a vacuum of, but they're spending all this money on things that they shouldn't be doing or don't need to be. Why didn't you suggest this or this or this or this? And the answer is, is because based upon our conversations, we knew that they weren't going to do it. And suggesting things that we know they're not going

to do is one of the best ways to erode trust. We're there to deliver an outcome. We're not naive software that is just running a pile of tools on an Amazon bill and saying, here you go, have fun. We're not the billing equivalent of a Nessus scan that someone slaps their logo on top of, drops off, and it's 700 pages long. Have a good one, check please. It doesn't work. Not well anyway, it doesn't drive to lasting change.

Yeah, and I think that's ultimately part of where we come in best because we ultimately want to be that bridge between the engineering teams and finance and leadership and essentially the business side of the business. We want to give both sides the information that they need to be able to speak effectively and collaboratively with the other side. We want to make sure that the finance side understands enough tech that they can work with the engineering teams to guide them in terms of what goals are important for finance in terms of managing budget, in terms of forecasting spend.

And then from the flip side, we want to make sure that engineering understands that the business collaboratively wants to manage these things and also help build the organization. And engineering has great, great potential to do little things, take little steps to help the organization get the data that they need to make these decisions. And that scratches that itch for me. That scratches that itch of how can I really be both sides of the conversation? How can I flex the business lingo and also flex the tech lingo, maybe not in the same conversation, but with the same client over time to really help both sides understand that both sides are important and both sides need to understand each other in order to help the business succeed. And that's ultimately what it comes down to.

Jesse, thanks for taking the time to speak with me. If people want to hear more about what you have to say and how you like to say it, where can they find you other than going to the Duckbill group and getting a consulting engagement underway? So there's two places that folks can find me. The first is on Twitter, at Jesse underscore DeRose. And then the second is our other podcast, the AWS Morning Brief podcast

on the mornings where we don't get to hear your melodious voice, Corey. My colleague Pete Cheslock and I are talking about all of the interesting things that we've seen at AWS, from client-specific situations to things that we've seen on the job in previous organizations that we used to work at, to new features that AWS is releasing. There's a whole slew of interesting things that we get to talk about from a more practical perspective, because there's so many releases coming out day to day that you're obviously helping us stay on top of

Corey. But there's so many other things that we want to make sure that we're talking about from the real world applicable perspective. And we will, of course, put links to these things in the show notes, but you should already be aware of most of them, at least the ones that are on the company side. Jesse, thank you so much for taking the time to speak with me. Thank you for having me. Jesse DeRose, cloud economist here at the Duckbill Group. 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 organizational dynamics really aren't that hard, and you could solve it better

than Dr. Forsgren does in a weekend. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production.

Stay humble.