Productivity Engineering at Netflix  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: Productivity Engineering at Netflix - Category: #podcasts - URL: https://share.snipd.com/episode/abbf34c2-361c-4956-9cf2-96859a7f0e13 ## Document Notes ## Highlights - **Platform Engineering as Leverage Play** - Platform engineering is a leverage play to make development teams more productive. - It covers development experience, compute infrastructure, and storage domains. Transcript: Speaker 2 Kind of goes back to platform engineering and what your team did is letting, you know, engineers focus on doing just the writing of code while you worked on the infrastructure. So maybe you could explain what a platform engineer is and what the team did. Yeah, exactly. Speaker 1 And I think what's fascinating, by the way, is that like platform engineering is becoming kind of like a buzz phrase in our industry and at Netflix, platform engineering, at this point, It's probably been around and it predates me. So we'll say 13 plus years. And the whole idea of platform engineering at a Netflix, or I would imagine any company, it's a leverage play. And so when you think about, again, trying to get a product from, you know, zero to 60 or, you know, like idea to customers hands, your most expensive resource is people, you know, whether We like it or not, you know, developers, I think we like it are very expensive. And as a business, you're like, hey, you know, we want to get this thing, this feature, whatever it is in front of people as quickly as possible and obviously as reliably as possible. Well, and so when you look at a platform team, the whole idea there is to ultimately make, we'll say, development teams more productive. Again, it's that leverage play. Like what can platform engineers do to enable the feature engineer to like work on their feature and not have to worry about like, quote unquote, we'll say, the platform or in this case, Infrastructure, but I'm putting that as quotes as well, because like infrastructure is very large. It's not just machines, but it's everything around the machine. And so at Netflix platform, largely is three domains. It's like development experience, compute, basically where all this stuff runs and then storage and that's platform. And I imagine that's pretty much platform at any large or any company. It doesn't, you don't have to be a large company to have a platform. But certainly I imagine, you know, big enterprises like Disney, Netflix and the like have platform teams. And again, the whole purpose as a platform engineer is you are enabling other engineers to be more productive. And we can talk about what productive means, but that's the goal. Speaker 2 Were you guys like the beginning of the concept of the platform teams? Speaker 1 Yeah, I think Netflix probably was leading the charge there. I mean, I'd never really, it's funny because when you're there, you don't realize it. Speaker 2 Well, I mean, at Netflix, were you guys the first platform teams at Netflix? Speaker 1 Were we the first platform teams at Netflix? Yes. So like when you start, right? Speaker 2 Because like you said, people are expensive and you're getting this whole team that you're creating to do this. What metrics did you use to kind of quantify like you were doing a good job and this was valuable? Great question. Speaker 1 I think in that story, it definitely has evolved in full disclosure. So I imagine still evolving in Netflix. So when I got to Netflix, the metric for leverage at the end of the day was very much like asking other teams, are you getting value out of these platform teams? And there was no like singular metric that you could measure other than like, hey, Justin, you know, your team does this feature thing on iOS. Do you feel platforms giving you some sort of leverage? And usually the answer was yes. If it was a no, then it was like, well, how can then we like do better? Autumn, are you getting what you think you need out of platform? And so it was a constant conversation across the company to ensure that we were providing value. And I think the metrics were even finer grain at a team level. So like I ran delivery engineering. So ultimately I was charged with enabling people to move fast with reliability. And so my metrics would be like, Autumn, are you using my products? And if you weren't, then it's like, why aren't you? And what can I do to enable you to use my products today? Or I'll say, when I was leaving, there was a much more rigorous process put into place to say, could we actually measure, you know, quote, unquote, productivity or spend? So how much, you know, from a productivity standpoint, what's the lead time for developers? When they come to, you know, Netflix, when are they actually, quote, unquote, productive? And we'll say, you know, pushing to production. Speaker 2 So how many days is that or hours? That seems to be the industry standard now of all big enterprises. Like when can you get people in and when can they start contributing, basically? Speaker 1 Yeah, because back to that, it's, they're expensive. Yeah, it's a return on investment, right? It's like, hey, we're investing in this person. We have a contract and their time is now should be making us money. And Andy, you're mentioning Disney and I don't know if we actually have mentioned on the podcast yet, but I used to work on the productivity engineering team at Disney Plus. And so this topic is near and dear to my heart. And so you've talked about platform engineering. How do you differentiate that from productivity engineering? Well, so at Netflix, productivity engineering was a sub org of platform. So again, back to the notion of, you know, lowercase P platform teams are charged with a leverage play. And then there's a focus of that leverage. And so at Netflix, productivity engineering, when I was there, was very much focused on the developer experience at Netflix. And how could we make developers more productive through the life cycle, you know, the SDLC of your day to day interaction, let's say with code. And so we thought of it in three domains. There was a focus on the local development experience where you and I were talking about like spring boot and whatnot. And there's other languages in there. And then it was the delivery experience, CI CD, like, so how do I take, you know, what I've written locally and get it somewhere reliably? And then there was like, we'll call it like the, you know, production or operational experience. Like, how can I observe it and obviously fix it if something happens. And that's productivity engineering that sits in a larger organization that is then like charged with, well, where's all this stuff run? Where's the, you know, the compute infrastructure, if you will, which is quite large at a, you know, again, a streaming company. And then actually even bigger is data, right? And like, so where's all the data that we're gathering? Where's it rest? And then like, you know, how can we access it and what can we like make sense of this? Or how can we make sense of it? ([Time 0:25:36](https://share.snipd.com/snip/407cbb31-f6c6-4075-894b-333201374308)) - **Containers Improved Dev Experience** - Netflix transitioned from VMs to containers over several years, which was a painful migration. - Containers improved developer experience but introduced complex infrastructure challenges. Transcript: Speaker 1 Or how can we make sense of it? Speaker 2 It's really cool because your time at Netflix not only went from like the DVD to like streaming, but also it was a huge time for infrastructure, right? Like infrastructure has come so far in the last like five, 10 years. There's just so many more, I guess products in the market for like, hey, come do this, come use Terraform, come use Ansible, come use like all these different like parts of like, and more Things are available. People want to automate it in different ways. So how did like the boom of like, I guess, infrastructure tech, maybe? I don't know what you call it. And like the fact that you were transitioning from like DVDs to like streaming, like that's a lot of change and a lot of industry change and growth. Like that's a very exciting time. Speaker 1 It was. I joined Netflix in 2013. And they had already as a organization decided, hey, we're going to do this streaming thing. So they had been streaming for a little while. And moreover, the big thing that Netflix, you know, pioneered then, which now is like, it doesn't even seem neat is they were in a data center and they were like, hey, we're going to the Cloud back to your point about infrastructure. And so that also coincided with it. We've got this DVD thing and we want to do the streaming thing. And so there was a very deliberate decision to separate the two, like DVDs going to run on its own all to intents and purposes in a different room, different infrastructure, different, You know, teams. And then we're going to do this streaming thing and we're going to do it in the cloud because we want to be able to scale basically or, you know, burst out into more capacity, which is really Speaker 2 Smart too, because you can completely turn off the DVD because it's separate eventually. And the fact that they started in the cloud meant that they could like, you don't have to know all of where you're going to scale because it's easier to scale in the cloud. Also, I think Netflix is so good at teaching when they do these transitions or they do, like what they learn, they're super good at kind of playing it forward and like putting it in a blog Or giving talks at like reinvent or like different places. Like they're really good at sharing their experience, which I think is cool. Speaker 1 I agree with you. I mean, that was one of the reasons why I wanted to go to Netflix is there was this brand of like, hey, they're doing really interesting things and sharing it with the world. And I think there was a deliberate decision, you know, that obviously predates me where leadership said, Hey, let's do this. Let's share with the world one so that we can pay it forward. Like you said, I think the other one was to its industry validation. So if Netflix shares like, Hey, we did this really cool thing. And you all are like, that's the, like the worst idea we've ever heard. We solved it in this way. It's like, well, maybe Netflix is doing it wrong. It just so happened. Netflix was doing a lot of things right because they were early. Speaker 2 It's also great recruitment tools. Cause when, you know, the next engineer reads it and they're like, that has awesome. I want to be a part of it. Speaker 1 You know, that's a really good point about like recruitment and sharing because I was from the outside following what Netflix was doing for a very long time. With when you initially was, we're going to the cloud, you were making a mutable infrastructure. You were making these, you know, VM images and then you were shipping your application as a VM and then containers came out and Netflix didn't share a lot because you had this product As a productivity as a platform team. You were all in on VMs for a while. You were shipping VMs and packaging those in ways that could be reused and scaled. ASGs, it works great. But then like containers comes around like actually we could chip a smaller package and we can make it react a little faster. And it took a little while for Netflix to really come out and start talking about containers and how you were using it with Titus, the container orchestrator, that was built that originally Was Meso space and I think it's now it's Kubernetes based. But like you went through these multiple cycles as a platform team. How did those migrations essentially impact what the developers were responsible for or how much they had to know because that shift from on prem to golden image VM building to container Orchestration are very different environments for one platform team to kind of see it through. So the short answer is it's super, super painful. And I've got like scars all over me. And so if I start weeping during this conversation, like, please edit it out. Speaker 2 When you get like PTSD, like, oh, I remember that. Speaker 1 Gosh, Justin, why did you go there? So you captured it. So he's sweating. So I think this is a lesson learned, you know, for all of us, right? It's not unique to Netflix. But what happens is you build this machine that works really, really well. And so what you painted is like, yeah, Netflix built, I'll say, a machine that enabled rapid development and I'll say reliable development in AWS with VMs, right? And, you know, I mean, in retrospect, everything's great in the rear view mirror. And it was like, yeah, it was kind of painful here and there, but like it was battle hard and rock solid. And then containers came out and there was a, you know, oh, my gosh, a lot of conversations on, hey, how do we take advantage of containers? And there's kind of two ways of looking at the advantage of containers. There's the developer experience, which I want to definitely, you know, come back to. And then there's the infrastructure, like, how do you actually run these things, right? ([Time 0:31:08](https://share.snipd.com/snip/bb7ee768-c988-4a81-99c8-7ed32019c6aa)) - **Disney Plus Launch During COVID** - Disney Plus launched during COVID-19 with massive unexpected scale and did not crash on launch day. - They pre-worm-scaled infrastructure instead of relying solely on dynamic cloud scaling. Transcript: Speaker 1 Both. I mean, we never met before, which is fun, but also like when I joined at Disney Plus, it was a year before Disney Plus launched. And so we had one goal in mind was like, it cannot crash on launch day. There was a lot of the stuff that already been established. They already had a lot of containers up there. We had a very similar productivity engineering team where we had a deployment team. We had a CICD team and then we had an infrastructure observability team, which was my team. I was I was the group I was on. Speaker 2 But let's give you credit though, like it launched during COVID and they had so many more users than it was supposed to be. The fact that it didn't crash is like, wow, like, you know what I mean? It launched November saying it launched just before COVID. Well, but I mean, like it was such a rush. You know what I mean? Speaker 1 I did not sleep that night because I was just excited for it. Right. Like it was coming. I was like, this is literally like I was watching the Slack channel of people like, hey, we're pushing the app live in this store, pushing the app live here. Oh, it's going live in this region. It's going live here. And I'm like, I slept for I think three hours that night. And I to this day, the very best thing that I ever did was I just before I went to bed, I'm like, I'm just a Twitter alert for hashtag Disney. And I'm like, I'm like, I'm like, I'm like, my alarms aren't going to hit at some point. And I want to know from my customer if this is going to happen because I was responsible for the infrastructure. Speaker 2 So it launched and didn't go down. But the fact of scale, think about the fact that they had Disney, like sing alongs and all these things that they had to add because all of a sudden we're stuck in the house. Okay. Like we are our kids are like, like Disney plus got me through like having an apprenticeship during COVID. And can you imagine how much scale that they did not expect for like you guys had so many customers? Speaker 1 Andy, I don't know about for you, but like one of the, I don't know, dirty secrets, the interesting secrets for me was the fact that like Disney plus was not dynamically scaling on launch Day. Like it was scaling a bit, but like we had scaled up for probably three weeks before. Like we're like, this is how much we expect to need. We need to pre-worm load balancers. ([Time 0:41:19](https://share.snipd.com/snip/3462154d-dc81-4a0d-879c-a957645c623b)) - **Saying No Is Crucial** - Platform teams must say no to some feature requests to maintain simplicity and focus. - Trying to solve every problem adds complexity and hinders productivity for most users. Transcript: Speaker 1 And being able to say no to people is like a huge benefit. It was just like, actually, no, I'm not going to do that for you. Couldn't agree more. Easier said than done. Yes. Yes. You need political capital for that. And so a lesson learned and I think, you know, there's three things that came to mind as you were talking about that is, it's certainly me as a leader. I have made those mistakes in my past at Netflix is not saying no, right? And it's usually like, no, not now. It's not no, not never. Yeah. And I think in general, because platform teams are, you know, a leverage play and again, we'll say, with lack of like hardcore metrics, it was very much like a, you know, we'll say kind Of a feeling like, again, autumn, am I helping you? And if you're like, no, then it's like, well, I got to figure out how to help you. And so I'm almost incentivized to say yes, even when I should be saying no. So there's that that's a lot of pressure. Yeah. So there's a balance there, but I couldn't agree more, Justin, in terms of, I think, to be an effective platform team, you have to like basically say no and figure out like, what is the Leverage play that? And there's other metrics in there like, let's say, let's imagine, you know, your or Justin in this imaginary world is, is bigger or like generates more revenue, whatever it is, there's Metrics there that help inform like, okay, platform is going to provide leverage to Justin's team. Autumn, we can't do it. And then empowering, you know, let's say that those teams to be like, you can build your own platform team if you need to. And like, we'll figure out a path in the future to, you know, maybe reintegrate that to a, you know, a commonality play. The other thing that came to mind, we were talking about this earlier, lesson learned is evolution is hard, especially in the infrastructure space. ([Time 0:53:24](https://share.snipd.com/snip/5426ec16-a593-4ad5-98d2-4278e4a09627)) - **Netflix Chaos Engineering Insight** - Chaos engineering accepts that distributed systems will break and proactively tests failure and recovery. - Netflix leads industry by intentionally breaking things to improve resilience. Transcript: Speaker 1 And if you are a customer of the quote, quote, quote platform, you don't think about it, right? If you've done your job well as a platform team, app teams don't know, right? They only know when it breaks. And that's that, you know, 0.01 time. And that's when they're really upset because they're like, hey, this thing isn't working. And I can't like do my job. And it's, it is a rightful kind of like surprise or whatever anger or frustration. But you have to have that humility to not be like, hey, Justin, it was working, you know, for the last 25 hours. And you didn't never say thank you. And then you just got to jump on and be like, Justin's blocked. Let's fix, you know, let's fix his problem. And the other thing I'll say that again, testament to investment and platforms is, you know, you build these massive systems. And one thing Netflix, and we were talking about this earlier, Autumn, that Netflix invested heavily in was the, I'll just, I'll put it in quotes as the idea of chaos, right? It's like things break in a distributed system. That is a certainty, right? Like, in fact, there was a almost a mantra of like, let's not try to, you know, get every edge case tested, because we know it's going to break into some weird way. ([Time 1:02:01](https://share.snipd.com/snip/11a656bc-cf30-4dab-b622-2985ad48b402)) - **Prioritize Observability First** - Fix your observability before attempting chaos engineering. - Without good visibility, breaking things can cause uncontrolled failures. Transcript: Speaker 1 And then there's a technical aspect of having like a great observability platform. So you actually know that, you know, what broke and how it broke. And so I think there's like this, you know, I talked to some companies like, yeah, we want to do chaos engineering. And I was like, well, let's talk about observability. Like, you know, what's, you know, how are you using whatever data dog, whatever it is? And it's like, oh, we don't really have a great story there. It's like, well, you definitely don't want to be breaking things. ([Time 1:04:20](https://share.snipd.com/snip/999fde10-08eb-4856-8a09-c1ef39e73936)) - **Platform Metrics Are Qualitative** - Platform engineering success metrics are often qualitative and rely on user feedback. - Metrics alone can miss the actual user experience and value. Transcript: Speaker 1 And I think that's a really, really difficult thing with something like productivity, engineering or platform engineering, when the actual metric you're getting from someone, Like you can get the are you using my platform, right? But like at the end of the day, it's kind of just like a vibe metric, right? Like you have to go talk to the human. You have to go ask the person, hey, is this valuable? ([Time 1:05:51](https://share.snipd.com/snip/21e7da8c-6745-45ff-a03f-d23a61d7383c)) - **Embrace Negative Feedback** - Empathize with users' frustrations when they give negative feedback about your platform. - View angry feedback as a blessing and an opportunity to improve. Transcript: Speaker 1 I think that's a really, really difficult thing with something like productivity, engineering or platform engineering, when the actual metric you're getting from someone, like You can get the are you using my platform, right? But like at the end of the day, it's kind of just like a vibe metric, right? Like you have to go talk to the human. You have to go ask the person, hey, is this valuable? Whatever your definition of valuable is, you need to tell me yes or no. Speaker 2 But just like Andy said, that's like a Yelp review, right? Like do people make Yelp reviews when they're happy? No, they make them when they're mad. So like, you know, it's that's such a hard like I feel like I almost have so much like empathy for the pressure that you must have been on because like, can you imagine they're only calling You when they're upset? Like, you know, so like it could be great. But it's like people are just like, oh, it's another day, you know? Speaker 1 Like so. Yeah, I know we at one point there, the team was leveraging like NPS, you know, net promoter score. So it's like, Hey, Autumn, would you would you recommend platforms tools to your friends is kind of a maybe another way of nobody pays attention to those surveys until you have the bad Speaker 2 Day where you're like, I hate this and you're like, no, never. Speaker 1 You know, and so one other lesson learned for what it's worth going back to empathy is again, having the humility to sit there and listen to you, let's say, Autumn, when you're angry, Writing the Yelp review of like, how horrible it is. But then being able to have kind of again, the realization of like, she cares enough to tell us, right? Because the worst thing is, I don't like your product. And so I'm just not going to use it. And I'm never going to tell you. And so having kind of like, the presence of mind to be like, okay, this person doesn't like what I've built for them, but at least they care enough to tell me. And so let me learn. And then I can figure out how to prioritize that having gone through that process many times, both then Netflix and before, I do find that that's kind of another skill of sometimes people Just don't want to hear from the angry customer. It's like, they took the time to tell you that's a blessing. You should thank them. Speaker 2 I love that you said that because we used to always get like, well, your connection part is broken or we hate this here or we don't have this feature. ([Time 1:05:51](https://share.snipd.com/snip/60201e5a-0eaf-4c1e-a031-d33322fd98f7)) - **Build Engineering Relationships** - Build relationships with other engineers by meeting and having low-pressure conversations. - Connecting personally improves trust and understanding in product development. Transcript: Speaker 1 It did feel this. I knew every engineer in Netflix, you know, let's say in 2014, 15, because we were all on the same campus. We had lunch together. We could get coffee. And I would go to you, Justin and be like, Hey, I'm building this thing. Like, can you help me like, or can I help you? And can you help me make it better? And COVID obviously dispersed everyone. We had to go remote. And we lived on those kind of relationships because I had met you autumn in person. You know, we had we had coffee together. We had that kind of like trust. And then obviously we did a bunch of hiring. Every company did that. And so I think one of the biggest, you know, issues that I think we're all struggling with is how do we move fast with, you know, empathy, obviously getting stuff done from a tech standpoint And humility in this remote, you know, hybrid world. It's hard. I don't have a good answer. Some companies are just like, Hey, returned to office. You got to come to the office, you know, whatever, x days a week. Speaker 2 We're actually doing a talk on that me and a couple of my friends that also work at the same company because we're a nonprofit and we like, we have a board, but our board is dispersed, like All over the world because they're military spouses. So there's people in Guam, there's people in Japan, there's people in California, just everywhere. And we're all in different time zones, right? So like, we planned full hackathons across the country and different time zones. We've run a whole nonprofit, like, and scaled it from like, no money to like giving out scholarships and like, at this point, we're partners with the DoD with the military spouse employment Programs. And like, we're the only nonprofit in there. And you have to be able to like, ask questions, like ask about people's lives, like, Hey, like, I saw that you had a kid or a dog or like me and Justin will talk about Disney or, you know, like, And me and Justin have never met in real life. Well, this is real life. Speaker 1 No, this is actually not. You know what I mean? Speaker 2 Like, not in person, we've never been in like this, like, scale will be the first time that we ever meet each other, like in real life, physically. So it's like, I think people need to make the effort and there needs to be more, like, to get to know people as humans, you know what I mean? And to treat people as we're humans and we're all going through our own things. And you know, and to like actually reach out. But like, I think sometimes so much is put on like, technical skills, but you need to be like a human that can relate and talk to each other because we're trying to solve problems and engineering Is a team sport. Yeah, you need each other to do things. So I think that would really help get people forward. Speaker 1 At the end of the day, I think, you know, human beings, we, I think we all value a sense of belonging, whether it be in a group or with another human, you know, and that's to your point about Like chitchatting about like Disney or the stuff in Justin's wall or whatever, or, you know, and what I certainly found and have found with remote is it's very like tactical. It's like, hey, I got 30 minutes to, you know, talk about business. Let's say autumn. All transactions. Yeah, transactions. That's the word I was looking for. And it's like, and you've got to take a moment, you know, it was like, how's it going? You know, what's going on in life? Like, what did you do this weekend? You know, and I make like a point to do that just because like, I want to know the people I work with, you know what I mean? Like, ([Time 1:11:04](https://share.snipd.com/snip/16282df6-7ae6-4970-93e3-db7e87dab7dd)) - **Demystify Tech Acronyms** - Use numeronyms and acronyms to simplify complex technical terminology. - Explain acronyms with relatable examples to avoid gatekeeping and increase understanding. Transcript: Speaker 1 The acronym? What the acronym? Of course. I love that you came up with that. Like it's so it is obvious, right? It's what the acronym. So as we've been continuing making outros that are not consistent and it's different every show. Speaker 2 You mean variety? Like it's perspective variety, Justin. At some point, I'm going to lose ideas and we're just going to go recycle them again. Speaker 1 But at least we have five or six of them ready to go. Speaker 2 Don't lie with us. We'll find another tangent to go off on. Speaker 1 If there was video in this podcast, we could do gifs. We could do so many other things. But because it's audio only, we want to focus on the audio. Speaker 2 We have some limitations. Speaker 1 But anyway, we wanted to explain just some acronyms and what they mean and maybe even where they came from because acronyms are kind of a core part of tech. And sometimes they're very gate-keepy. And sometimes there's also like obvious like, oh, I use that acronym all the time and I did not realize that's what it was. And so we wanted to share some. And I'm going to start with actually things that are not technically acronyms, but our numeronyms, where it's a number and a shortened word from and it has numbers in it. So the one that I use a lot is K8S, K with the number eight and S is a shortening of the word Kubernetes. But why? Because between the K and the S, there are eight letters. And that's it. And it's just it starts the first letter, how many letters in between and then the last letter. Speaker 2 I always felt so left out. Like, is there like a container secret here? Speaker 1 Nope, it is not. Some people pronounce it K8S as in K-A-T-E-S, like a name or something or Kate or something like that. But it is just it's a numeronym that shortens Kubernetes because sometimes people don't want to spell it. Speaker 2 I love that you made all of your acronyms this and like you went off another Justin tangent. And that's great. Speaker 1 A lot of them are in like front and development more and design because observability is one of them, which we owe 11 Y for there's 11 letters inside of observability between the O and The Y. Internationalization, I 18 N, because that would be a hard one to dispel. Speaker 2 Are they like variable names or are they actually like people referred to them with these? Speaker 1 Usually you'll see them in like documentation about like how to do something or it's like, hey, we just don't want to spell. We need to internationalize this all the time or accessibility A11Y where it's like, hey, this needs to be accessible. I just need to add the accessibility or whatever. You just put A11Y and people are like, oh, okay, we need some accessibility in there. And then the last one that I had was Y2K, which obviously doesn't mean that there's two characters between a Y and a K, but it's a millennial tech problem. This was if you're old enough to exist on the internet and be around. It was Y2000. Speaker 2 Are you calling us old? Like, I feel like you're calling us old. Speaker 1 I'm calling myself old because I remember it. I did not work in tech at the time. I was still in high school when Y2K happened. Speaker 2 So I did not even have a computer and I saw it on the news. I feel better because you're older than me. So I'm just going to assume you're going to be the old one and I'll just like pretend like I'm not. Okay, so mine are like very database featured and you know how much I love data. So I'm super excited about this. So asset, they're usually asset transactions, which is like, autonomous consistency, isolation, and durability. So if you're a website or any kind of transactions or doing any kind of sales transactions, you don't want your card to be charged twice. Right. So like, if you refresh or something or something doesn't load, you don't want to have multiple transactions. So it's basically like a check to making sure the transaction went through and it's not happening multiple times. Speaker 1 You want something to happen only once, right? Exactly. So every time I like pull out Apple Pay and tap to pay, I'm going to say asset. Yes. Like I don't want to get double charged, right? Speaker 2 So I just have to like, it's really important because for one, people would stop using their cards to pay online, right? You have to have that trust that people are going to have accurate transactions. And then you also don't want to end up giving away your product without being paid for it. Right. Speaker 1 So, but this is more than just card payments, right? I mean, this is you need other things to be asset to compliant or yeah. Speaker 2 Also, just making sure that you're getting data. It's a whole compliancy, but that's just to me, like the easiest way to explain if you've never seen asset before, I guess, or, you know, if it's a new concept, I guess. I like to find real world, like relations for things because like I hate when people do that, like gatekeeping stuff where they explain stuff at like a really high level, but they don't Make it digestible for someone who's never heard it before. Right. Speaker 1 An actual use case. Speaker 2 Yes. Like, well, use cases or like some sort of physical relation to something because I like it when it's related to something that everybody can understand. Speaker 1 I feel like the word acid, like I wish it was more relatable. Like we had a fuzzing on the last show, and that one has like a very. Speaker 2 I'm really sad that didn't make it into like Ralph, and I'm just going to be sad about it or to my watch Ralph. Speaker 1 But at least that one, like, I have a visualization of like what fuzzing is is just like, oh, it's like a fuzzy amount of data or something like acid, I feel like should be. I don't know. Speaker 2 It seems like it would hurt. Once you know what it does though, and you start seeing it, like it kind of is nice that like, like crud, like at first does like crud, but like it makes sense because it has all the different, Like the verbs, not your verbs, but I was thinking like not events, but different things that you would do with the database, right? So credit is create, read, update, and delete. Those are all the functions that you want to use with a database, but they're like crud operations, right? So like, I think it's cool that these are like useful, I guess, because sometimes you have like abbreviations and you're just like, we did like a whole like, why do we need this? Yes, like you're just being so extra. Like, that doesn't even make sense. ([Time 1:20:10](https://share.snipd.com/snip/00b9019f-e4c9-4c40-941b-e5db62879acb))