Screaming in the Cloud - Being Upfront on CloudFront with Katrina Bakas

Episode Date: March 25, 2021

About KatrinaKatrina Bakas is a Senior Technical Product Manager at Amazon, working on CloudFront within AWS. She brings a lifetime of relentless curiosity to her role and a desire to simplify complex technologies to make them accessible for more folks. Previously, she brought the same inquisitiveness and desire to simplify to observability at Pivotal and VMware (upon acquisition), having spent time at start ups and in megacorporate Financial Services before that. She strongly believes the best tech is found at the intersection of psychological safety, Design, Engineering, and Product Management. Links:“What is a Cloud Platform? What is a Platform as a Service?”: https://medium.com/@kvbakas/what-is-a-cloud-platform-what-is-a-platform-as-a-service-eb2c33cfa38eTwitter: https://twitter.com/katrinabakas

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. they needed, so they built one. Sounds easy enough. No one's ever tried that before, except they're good at it. Their platform allows teams to create consistency for the entire incident response lifecycle so that your team can focus on fighting fires faster, from alert handoff to retrospectives and everything in between. Things like, you know, tracking, communicating, reporting,

all the stuff no one cares about. FireHydrant will automate processes for you so you can focus on resolution. Visit FireHydrant.io to get your team started today and tell them I sent you, because I love watching people wince in pain. 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. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Katrina Bacchus, who is a Senior Product Manager-Technical-that's a corporate title if ever I heard one-at Amazon, specifically AWS's CloudFront Group. Katrina, welcome to the show. Thanks for having me, Corey. Glad to be here. So first, I understand that you're soon to be transitioning to a different team within Amazon, but fortunately we're able to do this recording before that happens. What is a Product Manager--technical? And of course, we will not forget the word senior that goes in front of that either. Yeah, a product manager-technical at Amazon is

pretty much the same thing as a technical product manager anywhere else, which is to say, no one really knows what a product manager is, and it varies wildly depending on your role, sometimes even within the same company. Well, I have a friend who went down that path for a while, and one of the things that he kept encountering was at some companies that I won't name because you can tell a Google story from a mile away, it was great. Oh, you're a TPM. Wonderful. Please solve this algorithm on the whiteboard first. And it's a little ridiculous if you look at the role there where you have to be able to prove that you can code so you can get a job,

wherein you'll never have to code again. But okay, we'll roll with that. Other companies that he spoke to were able to have the conversation without ever getting into anything that could even remotely be considered engineering stuff. So between those two endpoints across a broad spectrum,

where does that land for AWS first and secondly, for you personally? Amazon and within AWS, I get the sense that it varies a bit per team. You can sort of choose your own adventure at Amazon with as involved as you want to be. It really is the kind of place where you can find a team that really needs your skillset and you can dive in really deeply there. I personally do not have a software engineering background, so I stay away from needing to make those implementation decisions. On my team in particular, I'm very much responsible for representing the customer in the room and balancing what engineering tells me is possible and know enough technical knowledge

to understand if I'm getting sandbagged or not, but not prescribing what the implementation details should be. I always try and steer away from saying, oh, well, do you write code or aren't you technical? I think that's one of the biggest tropes out there that is provably false. Anyone who thinks that there's not technical detail and minutiae and a whole universe around any aspect of business is frankly naive. There is so much depth and insight that is valued across the entire board that, oh, well, you don't know how to write a particular programming language, therefore you're not technical. It's just a terrible take. I totally agree with you. I think one of the things that's even more frustrating in this conversation is folks

who say, well, great, now more people can be technical because Jamstack exists so you can make an app. I would go one step further to say that to be technical, you don't have to be able to develop an app, whether it's code, no code or anything else. It's about understanding what the thing is that you're working on and knowing the trade-offs of any particular feature or chore or technical debt that you're introducing. To me, it's just about understanding systems, at least at a level where you're able to make trade-off decisions. Yeah, the idea of Jamstack is just fascinating to me and something I plan

on getting into a bit down the road if this year lets me. I love the concept. I love how approachable it's becoming. My static website template generator thing that I launched with a few years ago has been replaced by things that actually, you know, work. And it's nice to see that unfold. So getting, I guess, away from the high level and into a bit more of the weeds of what you do, CloudFront is odd to me in that it feels on some level like it was give or take feature complete. I know, I know, don't email me. While back, because it's a CDN that has various points of presence across the world. Above my desk, I have a map of the AWS global infrastructure because I am really sad. And every time I wind up hearing about a new release, I put a new pin in there and I look at

this thing and it's a sea of CloudFront locations around most of the world at this point. So turning up new edge locations is valuable, obviously, and necessary, but I don't see a rapid pace of innovation around the product capabilities. And to be very clear, I'm not necessarily sure I want to either. Am I wrong? What am I missing? I think you hit the nail on the head here. A CDN exists as ideally something in as much of the background as it can. A CDN will accelerate your website and protect it from DDoS attacks from around the world or various other types of attacks. People come to CloudFront for security and for reliability and for acceleration.

We do that remarkably well. Anything on top of that can be nice to have, but we don't focus so much on what are the additional bells and whistles that we can tack on to the core product that does things, as I mentioned, that we do really well today. So I feel like I should also clarify slightly here, where if I look over the past year, there was no big announcement about it, but CloudFront distribution updates used to take, how do I put this directly, an age. And it has consistently dropped to sub five minutes, which is awesome as a customer.

But there was no big announcement about that. It was a quality of life improvement that I thought was incredibly appreciated from my side. But there are also aspects for certain use cases where that feels like an eternity as well. There are, of course, enhancements and stories about making it better to work with across the board. But it's also something that is relatively arcane. If you talk to the typical person just getting into technology, a CDN is not necessarily intuitive. And it has a bunch of sharp edges, if you're not careful, that can cut folks to ribbons. That has nothing to do with CloudFront specifically and everything to do with the fact that networking on a global stage is super hard. Networking on a global stage is

super hard. And as someone that works in it every single day, I still find nuances just about every week that I didn't realize that I needed to know. I mean, even just taking a big step back and thinking about how the internet works at large and then replicating that in a private system so that your data can be more protected and managing that without necessarily all of the same, let's say, benefits and headaches of liaising with all sorts of government entities as the public internet does, it's quite, quite complex. And the thing that I most look for as a PM for CloudFront is how can I pass the least amount of burden of managing all of that to my users while still delivering the value of that acceleration and protection at the same time?

It's also a bit of a challenge because I would argue that people's first experience as they learn how all of the various AWS services work with CloudFront isn't particularly friendly. Because if I'm looking at this from the JAMstack perspective, I mean, one of my first outings with CloudFront was exactly this way. Oh, I'm going to build a static website and I'm going to have it live in an S3 bucket. Awesome. That's great. Now I want it to, A, have its own domain name, which is not unreasonable, and I want it to work over SSL slash TLS because this is no longer the 1990s. Okay. To do that, now I have to bring CloudFront into play and it have an interface with ACM,

the certificate management service that AWS offers. It has to integrate with S3. It has to integrate with Route 53, ostensibly a DNS provider, but here in reality, the world's greatest database. You have to get it to hook up to all of these different things. And as an initial starting out process, it's kind of formidable, at least from where I sit. And part of the problem as well, and the CloudFront specific piece, is that the things that make it awesome, which is its flexibility, also make it terrifying of, wow, those certainly are an awful lot of options of which I understand approximately none of them. Which ones can I safely ignore slash take the default on slash which one is going to turn my secure database backups into a new trending topic on Twitter? Gosh, I'm so glad you brought up this topic, Corey.

I came to Amazon, to CloudFront specifically about a year year, like you mentioned, bringing our distribution update times down to under five minutes consistently, one of the things that is absolutely on our mind as a team and on my mind in particular as a PM is how to reduce the burden of knowledge from the majority of the users who are coming to CloudFront for CDN usage to something that's much more approachable. One of the challenges, too, is even right now, the values that you articulate of having a CDN, the security aspect and the performance aspect, when someone is setting out down this path at the first time, they don't actually care about either of those things to be direct. And there's a strong argument that maybe they shouldn't, because I'm building a hello world website and I want to put that in a S3 equivalent and then I want to put that on a website to the world. Yeah, if that's not secure, I couldn't possibly care less as long as it's not exposing, you know, access keys for my AWS account because there's nothing in a security sense to worry about other than please don't

make the browser pop up a giant warning instead of the website. And from a performance perspective, when you're building out, oh, this is a simple HTML page, it says, hello world. How impatient are you is sort of the default response here of, I want to make sure that this is an easy to hit website. But if you're on the other side of the world, it might take half a second round trip to pull that up, but a CDN will make that faster. Well, who can't wait half a second after hitting a link on a website for it to load? The real world answer is that down the road, things get much more complicated

and there are security concerns up the wazoo. And well, it turns out most of us write websites like crap and there are 30 sequential requests to the same thing, and that half-second latency for each one of those winds up multiplying, and now your website takes two and a half minutes to load. So at that point, you may as well just store it in Glacier and wait for the retrieval times. I'm less concerned about that particular user of the Hello World app builder who's then adding on new and new tiers and then making their way to production by adding all of these different things onto their website. Maybe you start with Hello World and end up with a really cool site to sell Billy the Platypus merchandise on where people can buy it from. We are working on that. And that's a great use case. But at the same time, typically,

as you're building up those building blocks, something tells you that you need this protection. Maybe when you're implementing your checkout process, you realize that that encrypted field could be better powered by using signed cookies or something like that. And then you get down this rabbit hole and discover that's a feature available of a CDN or that you don't have to write it yourself or something like that. What I'm possibly more interested in, or maybe just more top of mind for me, is the opposite use case. Where someone comes to AWS and says, I have the world's coolest merch store.

I need to put it up online. I know either not very much or very little, or I just can't be bothered with knowing the intricacies of what a routing system is. But in figuring out how to set up my first e-commerce site, it tells me that I need something called an SSL TLS or something called domain name registration, something called a CDN because that DDoS thing sounds scary. How do we make that experience as easy as possible from that entry point, which is that you already have a predefined goal in mind. You already know that you need to serve this content that is really hot for your

users in a way that's not going to negatively impact neither them nor you. Yeah, there's a lot of opportunity there. And I feel like those are the cloud stories of the future. I mean, this idea right now feels almost like a temporary aberration where you have a developer who wants to get into doing these things. It seems like the much more common path down the road, if not today, is going to look a lot more like I'm just new to the workforce or I'm changing careers or I just graduated school and I will have an idea for a business. That business involves computers in some form, as most things do. Today, the answer is you have to go to basically software engineering school, or at the very least, cloud school, to start understanding how a lot of these things fit together. Down the road, I'm more and more convinced all the time that that is not going

to be a permanent state of affairs. Oh, I totally agree. And I would challenge you on that even one step further, which is that I'm more curious about the folks who set out to solve any particular problem. And that solution tends to have some sort of technical impact to it, usually involving a website in some way, but more so than saying, I'm going to set out to create a business

that's going to do this particular thing. Sometimes it's just I'm really tired of having to keep track of what's in my fridge. So I'm going to start in an Excel spreadsheet of all of the ingredients. And then maybe I want some sort of logic on top of it that removes them as I use them. And oh, that gets really cumbersome in Excel. So I'm actually going to throw that into this simple web page. And I know how to do that because there are a billion tutorials and blog posts out there. And now you've just backed into creating your first app when you never set out to create an app.

Yeah, it's almost on some level, too, where we start to see the parallels between that and career aspects and career paths, where I will never be a software engineer professionally, according to some people, because I didn't go to Stanford and get a degree. Awesome. That is certainly a take people can have. But you're deeply involved in this and have a level of insight into the running of a CDN that I'm never going to have because I'm not getting the same hands-on experience that you are. But your degree is in, I believe, international studies and biology. That's right. My undergrad degrees are in international studies and biology. I was pretty convinced I was going to be a neurosurgeon for quite a long time. And now you wound up going through a variety of different career moves. You were at Pivotal and then VMware when they did that whole shell game, game acquisition divesting. I don't even know who owns what anymore, nor do I particularly

care. You were in a bunch of other areas, loyalty marketing, you were in large financial services, and now you're a senior TPM at Amazon. What about your background makes you, I don't know how to put this politely, so I'm just not even going to try, relevant to that. Yeah. The thing that makes me relevant to being a really good product manager is caring at the core about what users' experiences are, whether it was in marketing or working in startups on real estate CRMs or any other job that I've had so far, at the end of the day, I just want to solve interesting problems

with simple solutions that actually impact the lives of my users in some way. Sometimes that's a really clever problem. And sometimes it's a problem of how can I make you care less day-to-day about the thing that I work on by the end of, you know, the time that I'm working on it. So for me, that variation in my background, having a lot of different roles that have exposed me to all sorts of different industries and

therefore different users has allowed me to think about or to be better at understanding and seeking out what my users' needs are and then bringing those into a business and, frankly, just advocating really well internally by being able to describe what impacts they have on users and, therefore, what impacts that has on our business and making good cases for developing better experiences. One of the most valuable things that I see time and again is folks who have come to this industry, by which I will round to cloud as a whole, through, I guess we can call it non-traditional paths, but it always feels weird because I know more people who have come to this industry through those paths than folks who went and got the degree at Stanford. So I really do object to that framing on some level.

But I find that the folks who have that wild, varied background lead to teams that generally tend to be stronger, which is something that the studies have borne out as well. Now, that is the abstract. In a much more practical sense, on some level, it's a CDN. This is not the sort of thing where I'm going to put up a bit of a straw man for you to

knock down, so please don't write me emails, listeners. It seems like on some level, the idea of having diverse and inclusive teams, including particularly diversity of background, isn't the most important thing when you are running a CDN. It's not something that is going to, for example, suffer from algorithmic bias issues, where we're seeing a lot about that in the news these days. It's not going to, for the most part, wind up being something that is a differentiation

along axes that are problematic to various constituencies. It's basically a, we make the network faster the end. What is the value of having, I guess, a more humanistic approach to these things? I think the value of having a more humanistic approach to providing a really robust and usable CDN is understanding that if CloudFront as an org only hired diehard DevOps folks

who have only ever worked on DevOps, only have these extremely coding rich technical backgrounds who just love building extremely beefy apps, then the way that the product is going to be made very wildly away from that. There are people, like we mentioned, who want to tinker around with every configuration or who have to because they run really heavy and robust workloads, like maybe video streaming platforms or other applications with highly concurrent needs, like big banking applications and things like that, all the way down to the Billy the Platypus commerce site that you're building right now and not having that, all the way down to the Billy the Platypus commerce site that you're building right now and not having that same level of expertise. And what I think is the value of having and what I've seen is the value of having folks come in with a variety of different backgrounds is just a greater ability to empathize because

they can relate to different people's experiences. And when you have a thousand of all of the same exact person working on a thing, then you're going to end up with a thing that reflects all of those thousand people. But if you have a thousand different perspectives working on a thing, you're going to end up with something that works well for, well, more than just that one persona type. No, you raise an excellent point. There are ways now to get things up and running effectively with CloudFront for those folks

among us whose first language is not JSON. So you're right in what you're saying. The user story is becoming much more simplified. The ability to have things start being removed from the console, it's becoming much more approachable to the point where, do I have to use this? Or is there a click-by-numbers option I can use instead? There is something to be said for folks who are representing different customers getting a voice. What we have to keep in mind is that the edge is simply just a proxy to the rest of your system, if not configured right, or sometimes if configured

exactly right. So the more that that investment in that edge logic continues, I see more and more possibility for just more creative usage. I will say that I had the privilege of talking to a sarcastically senior engineer on the CloudFront team a year or two ago, after I was doing my typical way of filing bugs against AWS services, which is complaining loudly on Twitter. And they had the grace to always respond with that typical Amazonian response of, interesting, can you tell me more about your use case,

as opposed to the much more direct slash honest, what the hell's your problem, which is basically what I deserve. And the answer that I had at the time was, I was complaining about the 45-minute distribution updates. And the problem that they said, and they're right, by the way, do you want us to just lie to you and come back when we wind up having the update not done, and you'll be serving different data than you think to customers? Or do you want it to be technically correct? And because we strive for correctness here. Because that's a great question. It takes time to update stragglers and the rest. And my

answer was also a very legitimate, I could not possibly care less. The reason I care about this at all is that in order to update a Lambda at edge function, I have to wait for a distribution update to finish. There's no option for me to just deploy it to a single pop basically instantaneously in the region I'm developing in. I have to option for me to just deploy it to a single pop basically instantaneously in the region I'm developing in. I have to wait at the time, 45 minutes, to discover, yep, I forgot to put a comma in there and there are syntax errors

because see previous notes about terrible coding practices that I do. And that was a use case that it turned out was echoed by more than a few people. We're all secretly terrible developers, as it turns out. And that understanding was taken and obviously acted on because it's now way faster. But it's still challenging in some ways to have a four-minute wait when I want to see if I forgot a comma again. But it's more tenable. It means that writing a lambda at edge function isn't going to

be something that's going to take two days for me to spit out before I finally get it right. Things improve all the time, and it's easy to complain about the things we don't have rather than the things that we've been given. It is often easy to complain about the things that we don't have versus the things that we're given. I, as a PM, absolutely understand, though, sort of like as users, we're conditioned to always want more, to always want better. We're conditioned to want the perfect thing that works for our exact use case and to understand. And as you said, complain loudly about that when it doesn't work out. I take that responsibility quite seriously. If there are ways that we can improve our users' lives, like continuing to work on the change propagation time so that it continues to be lower and lower and you have more of that instantaneous feedback.

There are certainly other ways of solving that problem that we've heard lots of requests for, like different sandbox environments, for example, or a blue-green deploy system, or like you said, the ability to specify a specific edge location to where you can deploy code. We have to consider, what I try to consider as a product manager is what are the features and the sort of bells and whistles and the customizations that I can offer that impact the most of our users in the most applicable way rather than how do I design for just one customer's need. Some people need dozens of tools to visualize their stack, but not you. You've got

New Relic Navigator. All your hosts, services, containers, and anything else you can monitor are all in one dense hex view, so you can check system-wide health at a glance. And you can sort by platform, service, app, or any other tag, which makes it easy to navigate your entire system and see what needs your attention. Go to newrelic.com and get started for free. Tell them I sent you and watch the wince on their face. And this is the thing that I've had to learn again and again and again. Every time I think I've seen it all in the context of a given AWS service or even AWS as a whole, all I have to do is talk to one more customer and I'll discover a use case that I hadn't considered or hadn't envisioned as being something that real people did. No judgment intended on that one, by the way. And you really do go about learning from customers as you go. But it's also hard, particularly on the cloud front level, where of all the environments I've been in, there have been remarkably few requests I've had of a CDN that were not a modified form of either make it easier or make it faster or get out of my way more.

Those are the only three requests that everything winds up in a CDN piece that I ever saw going down that path. And I thought that that was it. Okay, CDNs are boring. Why does everyone care? And then I started talking to customers. So from that perspective, what do you think, in what you've seen, is the most misunderstood aspect of CDNs and or the most curious use cases you've seen? The most misunderstood aspects of CDN that I have experienced in my work has been this notion of, back to the beginning of our conversation in this podcast, the notion of my CDN should be everything to me. It's kind of conflation of CDN and application or Jamstack or application. And that's been a really interesting space to kind of step into and figure out what that balance is

for me as a PM in terms of where I want to continue to advocate for taking the product. Do we want to be everything to everyone or do we want to do our core competencies really, really well? In terms of the most interesting use cases that I've seen in the CDN space, gosh, it's sort of limitless. Some of the more fascinating ones to me are understanding how really large players

out there use CDNs in incredibly complex ways. The interconnectedness of it all completely blows my mind, especially when I use the end user facing product and realizing that when I navigate, say, to a website and let's say watch a movie or something like that, say that I'm watching something on Prime Video, let's say, it blows my mind that complexity that can be underlying for this in a way that customers somehow can keep track of all at the same time and continue to iterate and improve on. And it just kind of magically works for me as an end user. That's the biggest thing that continues to amaze me almost in equal measure. First, the fact that I can wind up having some crappy line of code and push a button and it gets deployed at world scale for fractions of a penny. Followed, secondly, by the fact that I am pissed off about minutiae of that experience and want to take to Twitter and drag AWS for it. Those two senses of wonder are always competing in my mind. And on Twitter, I do bias for the latter, I admit, but it's magic. You have built what is

fundamentally magic. We have. We've built fundamentally what is magic through a lot of conversations with the users, endless back and forth debates about what is doing the right thing. And then, of course, fast iteration and learning from it. There's so much that goes on, as with any technology, but behind the scenes, even in what we'll call a slow feature time, if you'd like to call it that, just all of these underlying improvements and underpinnings that continue to make the experience better and easier to use, and at the same time enable people who didn't know anything about a CDN before to deploy their code to over 220 edge locations around the world. The idea that

someone who's never written a line of code before can, within a day for sure, learn all there is about it in tutorials and online and whatnot, and then come to a service like CloudFront and deploy that brand new code, the first line they've ever written, absolutely mind-boggling to me. One thing that never really occurred to me to ask before, but since I've got you on a recording and it's impossible to say no when I ask these things, I'm going to ask my question now about this. AWS is somewhat famous for not having a global control plane. It's avoided things like global outages of every region at the same time.

Those boundaries don't really exist with CloudFront. I have never yet seen an announcement of this new feature has come to CloudFront, and there have been a lot of those, but only to the following three global regions, with more to come in the future. Features are rolled out either globally or not at all, and I can't remember, although I'm sure someone will have some document somewhere that'll yell at me for this, a single global cloud front outage. How does that happen without the blast radius being either monstrous, which it clearly is, or the pace of innovation slowing to a crawl, which snark aside, it isn't. Through a lot of diligence, Corey, that's the best answer I can possibly give. Having this extremely globalized service that is still, though, by nature, at the core of being a network of interconnected physical locations deployed all over the world. each particular place are separated. So we are to some extent naturally protected from

large natural disasters by having edge locations in each place, much like different data centers or availability zones. So we continue to keep it at absolute top of mind to be able to redundantly support workloads through any sort of localized or even regional outages that may happen so that we can continue to serve the information that we need to. It's never ceased to amaze me just how much of these various concerns AWS has to hold in tension with each other because customers want new features and they want them quickly. They also don't want you to drop their entire banking presence onto the floor while doing it. And every time I've had a feature request, the answer has

been, there are extremely complicated reasons why it doesn't do X. I've never yet come to an AWS team with a feature request and had them drop a cup of coffee and holy crap, we never thought of that before. It's always the, we'd like to, but it's really hard. And on the one hand, I'm very sympathetic about that, and these things do take time. On the other, I'm not paying my fractions of a penny so that AWS can only solve the easy problems. So again, it's a study of contrast, a study of tension. And I feel like, just through this conversation, I now have a better idea of what product management is than I did when I started half an hour ago. That's lovely. That's a great meeting of my goal then of spending this time with you. Exactly. So one question I have

before we call this a show is what is the best and worst you've ever felt about your job as a product manager? Oh gosh, that's a great question. The best or the worst I'll start with, which is more fun. The worst is always the good stories. It's the, what do you regret the most is, is always a great question to ask someone. It's super weird when you ask it in a job interview, but that's a separate story. I would love to hear a screaming in the cloud of just Corey's regrets. That would be lovely. Oh my stars. I don't know if anyone else would. That's the problem. Once I start complaining, I don't stop, but you're not getting out of the question that easily. The worst I've ever felt at my job as a product manager was sitting

down. I had worked on this very large feature release with my team for about six months at another company. I had had tons of you dessert interviews, felt really good about the research that we did, the design phases, had these iterations with real live customers in hand, testing things out, did all these recordings, like couldn't have done anything better by the book. Sat down after, and when it was in beta with the customer, had them test it out, and the customer just struggled. They could not get through the very first thing they needed to do to even log into the application, much less use the new feature, which was this really tricky authentication maneuver. So they sat down, they struggled, they struggled, they struggled, they couldn't get any further. And finally,

this customer who I knew really well had built a good relationship with, turned around to me and said, I've been doing my job for 20 years. And I've never felt worse at it than I do today. And it's because this experience has been so rough. And as a product manager, that's about the worst thing in the world that you can hear from, which in this case was something as simple as a backend authentication. That one absolutely resonates across the board. I believe wholeheartedly that if a user is working with an AWS service and feels dumb, That is a failing of the AWS service team. And that's a very hard line that I draw in that none of the services that AWS offers, mostly, I'm going to carve out exceptions

for some of the advanced ML stuff and certainly the quantum computing folks, don't get me started on that. But for most of these things, the fundamental concept of what the various services do is not that complicated. Someone who has gotten far enough to have spun up an AWS account specifically should be able to grasp on some level what these things are. And every time they're struggling trying to get something done in an idealized version of the world, that's a service team failure and is an area in which a customer can reasonably expect the cloud provider service

team to do better than they have. It's the divinely dissatisfied in perpetuity approach. Absolutely. Anytime that I can free up my users' busy time to get to the core of whatever it is that they have to do. With the CDN, for example, I want to give my end users time back to do whatever they want to do. That is not spending hours figuring out which CloudFront configurations apply to them. You would much rather be doing something else, be it coding an application, be it spending time with your kids, be it literally anything else in the world, than trying to figure out what this very, very particular setting might be. And for me,

that's a big part of that is making sure the things that users have to do routinely are easy and fast and get them to the core of the thing that they have to do or that they want to do. So basically removing the obstacles from the things that you have to do to get you to the things that you want to do faster. Yes, I do want to caveat my statement as well, because I know that there is some junior product manager out there somewhere at some startup who's going to hear that and think, oh, well, our predictive algorithms are really good. So we're just going to go ahead and send things to our customers that we know that they would like and charge them for it. No, stop. That is called credit card fraud. No, stop it. You still need to get consent from users to sell them things. The fact that I'm not entirely sure

whether that disclaimer was a joke or not should tell you a lot about the state of our industry. We want things to be easier to use. I think that's a great fine line to call out that I don't want to be making predictions about what I think you might want and get that wrong. That feels worse than just giving you the option to do what you want super easily. Right. There's a reason that none of the cloud providers have implemented the web console version of Clippy of it looks like you're building a CloudFront distribution. Would you like help? No, because the first time it gets it wrong, it annoys the hell out of everyone. Damn, cat's out of the bag. Roll back the feature release, everyone. Exactly. Yeah. But I assume it's also going to be Amazon centric. So, you know, it wouldn't be a paperclip because that's too derivative instead of, I don't know, a binder clip or a nail gun. There we go. The jokes would write themselves at some point. So that was the

worst experience that you've had as a product manager, but I don't like ending on down notes. What's the best? The best experience that I've had working as a product manager was different was a different company again a couple of years back. I took the time to sit down and in lay people's terms write out what a platform as a service meant. It ended up I guess setting me up well for my career at Amazon because it was about six pages of a narrative of just what what a platform as a service was, what the cloud was, how it integrates, how servers play together, wrote an analogy about how these things interconnect and why it matters. And just sort of understanding that there were probably a lot of people in my same shoes, maybe even working at my same company, who, despite working on a platform as a service,

didn't quite understand what it was that it did and why that layer of abstraction was important, much less the underlying infrastructure as a service that powered that thing. And taking the time to write that out in really simplistic terms, then created the experience where when I shared it out, I had several folks come up to me and just say, hey, I've never really understood that thing. Thanks for making it approachable. And thanks for making me understand this piece of technology in a way that I otherwise wouldn't have. And lowering that burden of information that you had to go seek out yourself for other people that, you know, I went through the experience of finding myself

and trying to understand and reading through incredibly dense technical blogs to understand something that could have been simplified much better has probably been the pinnacle of my product management experience so far. very simply to people and removing the burden from them, having to go self-serve that information through the same pain that I had to, to understand it was, was a really great experience for me. There's a lot of power in being able to, I guess, have the position in the market, which I do. And I basically took it because I figured what's the worst case someone's going to do, take away my birthday and say, I don't get it. And that tends to be valuable because every single time I've done that, people have come forward and said, oh, thank God it wasn't just me. I just didn't want to say it out loud. But there's much more power in being able to take that feedback and fix it, make it

understandable in a way that is extraordinarily approachable. There's a reason that people don't just ask for a list of API options as documentation. They want to understand what business problem do I have that this solves for me. They want to see code samples, but they also want to see something in between the very high level and the very low level that explains considerations of using this, the trade-offs, the design reason, why you would use this, and very often, why you wouldn't use a particular feature, product, or service. Anytime someone says, oh, my product's awesome, and you should use it for everything, they're doing a sales job and not a particularly good one at that. Absolutely. I think a really apt analogy here is you should disseminate whatever

information you have and whatever knowledge you have in a way that is consumable to your users. And the analogy to me that comes up is a water fountain. If someone is thirsty for knowledge, in this case, and you are trying to supply them with water, you might think that the very best thing that you can do is open up a fire hose on them because it's more water than they could ever use. And it's fantastic. And you're giving them all of these things, but you're also going to drown them. If you give them something that's more approachable and let them opt into consuming more as they're ready, it's a much better experience for users and you're enabling them to have their needs met, to opt into more

information, to self into more information, to self-serve that at the same time, and then continue to grow with them. I think that's a terrific sentiment to end the episode on. If people want to hear more about what you have to say, where can they find you? Folks can find me at Katrina Backus on Twitter. Feel free to reach out anytime. Excellent. Thank you so much for taking the time to speak with me. I appreciate it. Thanks, Corey. It was my pleasure. Katrina Bacchus, Senior Technical Product Manager at AWS's CloudFront. 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. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. And in the comments, tell me what year you graduated from Stanford. 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.