Coding Blocks - Designing Data-Intensive Applications – Reliability

Episode Date: November 25, 2019

We start our deep dive into Joe's favorite new book, Designing Data-Intensive Applications as Joe can't be stopped while running downhill, Michael might have a new spin on #fartgate, and Allen doesn't quite have a dozen tips this episode.

You're listening to Coding Blocks, episode 120. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And check out CodingBlocks.net where you can find show notes, examples, discussion, and a lot more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net. And look at all our social links there at the top of the page. And with that, I'm Alan Underwood. I'm Drew Zak.

And I'm Michael Outlaw. This episode is sponsored by Educative.io. Level up your coding skills quickly and efficiently, whether you're just starting, preparing for an interview, or just looking to grow your skill set. And Datadog, the monitoring platform for cloud-scale infrastructure and applications allowing you to see inside any stack, any app, at any scale, anywhere.

All right, in this episode, we're talking about one of my new favorite books, being it's been released in like the last two years, I think, called Designing Data Intensive Applications. So really excited about that. In this episode we're basically going to be laying the groundwork for how we're going to kind of talk about distributed data intensive applications

over the next couple episodes with a big focus on reliability. And first of all, this is how we do. I've got to say a big thank you to reviewers Anonymous and Geoff Mann over at Stitcher. All right. And so this time we actually have some podcast news. This has sort of been missing for, I don't know, 20 episodes. I don't know.

We found a bunch of stuff that we want to. I mean, would you say you've been missing it? They've missed. Some people have missed it. Some people have not. We'll put it that way. But we'll try and chew through these things. First, thank you again for the reviews.

We were sad that we only got two this time. So, yeah, if you haven't left one, please do. The next thing is... We appreciate it. We're not sad. We're happy. We're happy about the new ones, for sure. Sad about the not ones. So, the

second in the series of videos that I did that are basically SQL Server and Docker-centric, I released that one. We'll have a link in the series of videos that I did that are basically SQL Server and Docker-centric, I released that one. We'll have a link in the show notes here. Go check that out. I think some people have really enjoyed that, even people that are like old hats at SQL Server and stuff. So this one is all about getting sample data that you can start writing queries in. So anybody that's new and wants to play with databases, this is a great starting point. So the next thing is, and I debated this one because I just, man, I hate being public about

I'm not going to be here. I am going to be. Well, it's a good thing you're telling us that now. Right, right. So yeah, after much debate and deliberation internally, I figured I'd go ahead and tell you. I am going to be at NDC London on January 31st. Well, I'll be there for a few days, but I'll actually be doing a presentation

on January 31st, 2020 on near real-time streaming with Kafka streams. And it also involves SQL server and elastic search. So my session is from 1140 AM to 1240. So if you're a listener of the podcast, please, you know, either come join the session or come say hi to 1240. So if you're a listener of the podcast, please either come join the session or come say hi to me. I think there's plans to meet up with several people. I think maybe Steve, you, the Cynical Developer,

I think we're going to do that too. We've got some people. So please come say hi. Let's hook up while I'm there. Hey, when you meet James in person, will you do me a favor? Will you go up to him and say, Michael says hi. Totally. We'll do that.

For you, James. The cynical developer. That's amazing. And if you haven't checked out his podcast, please do it. And Jamie, GA Progman, he just recently had some crazy stuff happen, right? So hopefully I'll be able to hook up and say hi to him too. So definitely go check out the.NET Core show too if you guys haven't. All right.

So with all that now, the last bit of news I have is i found this i found this video this is so good guys and it's perfect for this particular show because we're talking about designing data intensive applications this video is can i say one thing about it first before you before you do that i just want one extra tease to it because when you think about like um like what companies would be bleeding edge uh you know hyper uh aggressive like you know like on point with their technology data intensive technology right this is the first company that's going to come to mind now go totally john deere so i think honestly that's what wrote me in. So first off this, this video, it's a YouTube video where I think they had maybe an AWS architect or somebody

talking about some of their processes and their products in AWS. But then they have the John Deere guy that has worked on these things to come in and talk about the problems they ran into and, and how they've solved them. It is amazing stuff. The problems are trying to solve the, the amount of data they have, man, I'm telling you right now, it was, it blew my mind. So definitely if you are interested at all in just big data and some of the problems that you run into and how John Deere would actually be into this equation, right? Go watch this video. It's awesome.

All right. So with that, I'm out. Did, I mean, I just imagined they were just trying to make everything green that they are. All right. So,

um, well, I wanted to point this out because, you know, we had the, the, you know, the,

uh, shopping spree type episode that we did last, right, where we all talked about some of our favorite hardware for the year. And I want you to take that whole episode and just erase it from your mind. Forget it. Hit the delete key and delete, delete, delete. Because out of nowhere, Seagate has come out with the FireCuda 520 SSD. MVME M.2 SSD. And it is insane.

So we were talking about the Samsung 970 EVO Plus that came out. And how it was so awesome. Because it was 35500 megabytes per second sequential reads. Yeah. Seagate has stepped up their game with this FireCuda 520, 5,000 megabytes per second reads. And the writes. That is just off the charts. The writes are 4,500 megabytes per second. I guess it's not technically off the chart. Yeah.

4,500, isn't it? It's nuts. And here's the thing, right? Like, okay, theoretical numbers, whatever. Tweaktown put together a review of this thing, and it's legit. Like, it's fast. Yeah, man. And you can get it in either a 500, a 1 terabyte, or a 2 terabyte size.

And the thing is, the price is actually really good. It's competitive with the Samsung. It's cheaper than the Samsung. Right. Right. And faster. It kills me. Yeah.

And, oh, by the way, five-year warranty on those bad boys. Oh, I didn't see that. Yeah. Oh, so that's killer. Yeah. And, oh, by the way, five-year warranty on those bad boys. Oh, I didn't see that. Yeah. Oh, so that's killer. Yeah. All right. We have another shopping thing. So, yeah.

It was like, oh, great. Now I got to cry because, you know, I got the Samsung. So, you know. This is why I said that the last build wouldn't last me until March. Now you get it. Also, wanted to point out, it's that time of year where Pluralsight starts doing some of their big promotions. So they're doing the Black Friday sale that starts today 40% off. Now, let's be clear, though.

We say today. So our episodes typically drop depending on which part of the world you're in. The way I'm going to release this one, it will release to all the day. Oh, okay. Okay, cool. I already made sure of that. Excellent. Really?

Yeah. Why? Because you said the trigger word. Ah, sorry. Okay. Excellent. So yes. Do you want to share the link?

Yeah. Yeah. Yeah. So, go to codingblocks.net slash Pluralsight so that you can get to the page and get 40% off of your Pluralsight subscription. And that deal – let me see. I've got to remember. They're offering that deal through – I'm thinking it was December 6th if I remember right. Oh, nice. Or no. No, December 1st.

Sorry. December 1st. Okay. So you got like a week roughly. Yeah. Cool. But still, I mean it's a great deal. And if you've ever wanted an excuse to get a Pluralsight subscription, 40% off is a really decent excuse to get one.

And if you've ever had a Pluralsight subscription and you let it lapse, you know what I'm talking about. Go tell your boss, like, hey, hook me up. 40% off. Alright. And hey, I have some news too. So I was on several episodes of Waffling Tailors

recently, which is an excellent video game podcast. It looks like we talked about 19 games in just the first kind of segment. There's more going on. We definitely did some waffling. I also talked about the third-party Nintendo controllers. Remember the Advantage and the Max? So if those are the things you enjoy listening about,

then you should go check out the show. We also talked about Elvis sandwiches and my fear of crying in public while getting a tattoo. Wait, you got a tattoo? No, because I'm afraid of people seeing me cry. Oh, I thought he finally broke down and got that Visual Studio tattoo that he owes us. Right? Yeah, that's right.

That's right. We haven't forgotten. Yeah, I forgot about that one. Yeah, but guess who has it? All of Coding Blocks. Wait, so what do you mean? You did many episodes. Are you moonlighting on us? all of coding blocks. Oh, wait. So what do you mean? Like the, you did many episodes. Like do,

are you moonlighting on us? Is that what's happening? What's going on? Yeah. Well, like once, once I start talking, uh,

I can hardly stop. So it's like running downhill. Yep. It was like, what games have you bought in the last six months? I was like, all right, sure. I'm still picturing the running downhill i can't stop yeah we all been there except for

it's hard to do in florida uh but also uh amazing artwork commissioned uh by the the fellows over there and uh drawn by the hurricane. So if you want to see, uh, just some amazing art featuring me with super bling, a ding, ding smile, then you got to head to the website. We'll have a link on the show notes. So you got to check it out and subscribe to the show.

And seriously, the artwork is awesome. Like really awesome. I look amazing. So it's the best photo of me ever. best image of me ever yeah i don't i don't know like how what's the deal that he has with uh that ga progman has with the uh hurricanes the the artist yeah because like all of the episodes like he does that for every episode right so yeah i think think they commission it.

I don't know if they know the person or what the deal is. But I think Hurricanes, I think, is over in Savannah, actually. They might be a SCAD student. So we should get some stuff commissioned. Yeah, that's beautiful. That would be awesome. Cool. All right.

And also, I want to mention, since we're talking about a book, that we're going to do a giveaway on this episode. So if you want to win a copy of this amazing book that we're talking about, Designing Data-Intensive Applications, then just come by and drop a comment on the show, and then we'll hit you up in the comment and get it over to you. And internationally, it's no problem. A lot of times people say, when we talk about stickers or books or whatever whatever it's like oh but i live in uh i don't know philippines like uh that is totally fine we we love the philippines that's right and amazon is everywhere so yeah yep definitely do it all right all right cool kick us off okay so um talking a little bit actually about the preface of the first time, which is – I think this is the first time we've ever talked about a preface of a book.

But it's just so good. No? No, it's not. No? No. What other did we do? I'm pretty sure it was Pragmatic Programmer. Yeah, I was going to say.

Yeah. This one is good though. This one was filled with lots of meat, so we had to do it. Yeah, it's really exciting. This is a book I've told a few people about reading. It's like you've got to warn people ahead of time that you're going to want to make some stuff when you read this book. I don't know if there's ever been a programming book that I've read where I've wanted to put the book down and pick the keyboard up mid-sentence. It's just that kind of book.

We talked about stuff that was kind of more theoretical, but this one, for me, we're talking about the first chapter. We're kind of set the stage, but after you kind of get into the beat of it, it's very that kind of like we talked about stuff that was kind of more theoretical but this one for me like you know we're talking about the first chapter we're kind of set the stage but like out of the after you kind of get into the beat of it it's very much like hey here's cool stuff you can do are you telling me that when you read the O'Reilly get book you weren't like hold on I can that's how I can

add hold on let me like get command line oh wait did you read the O'Reilly get book Joe no I didn't think so I didn't either I mean, like, Git command line. Wait, wait. Did you read the O'Reilly Git book, Joe? No. I didn't think so. I didn't either. Oh, it was just me?

I'm just saying. Whatever. All right. I ought to. Have you seen my commit messages? Something to be desired. And I obviously have never learned how to rebase. 15 years in or whatever.

It's good stuff. So the thing that the preface goes into is like, hey, what do we mean when we say data intensive application? And really, there's just a few things, right? The quantity of data, the complexity of the data, the speed at which the data is changing. And that means that the problem is different than processor bound type stuff, right? Like not compute intensive things. Yeah. And so is there like a, like a company or something that you could, you could say that like, obviously like Twitter is data intensive. Like what is there a company smaller than we think of that? Like would we would kind of count as being data

intensive? John Deere. Yeah, John Deere for sure. Watch that video. Yeah. No, I mean, look, I'd say even just regular web applications. Take a standard e-commerce site, right? The thing is, it's data intensive.

You have transactions coming in and out and you have to worry about the, like, what if I get a spike in traffic, right? Or something like that. I think that could be considered a data intensive application. It doesn't require that much processing power to save that order, you know? Maybe it's easier to say an app that isn't data intensive anymore. It's like if it's got a database and you're on the internet, like customers have gotten to the point where they just expect these really good, rich, amazing experiences.

It's something we talked about when we talked about search engines before. Your customers, if they go to your website, they're used to using Google and Amazon search every day of their life. So when they go to your website and they execute a search, they expect to have good results. They expect to have autocomplete. They expect to have suggestions. Somebody needs to tell that to Amazon

because their search results are awful. They are terrible, man. Golly, they are. You just got to know exactly what you're looking for. And then you still can't find it, right? And then you got to figure out which items are the knockoffs. That's the hard part. It's like, this thing's too cheap. Next.

Yep. Thank you. Next, next. Yeah, so I don't know. I think that pretty much any application that's on the internet It's like this thing is too cheap. Next. Yep. Thank you. Next, next. Yeah. So I don't know. I think that pretty much any application that's on the internet, in the cloud, dealing with database nowadays, like you are probably data intensive. I would agree. A lot of that. And I think it's just gotten – I don't want to say worse, but it's gotten more intensive over the years because it used to be, you know, people visited your site. You probably didn't pay that much attention to it.

But now people keep all their data, right, because they want to be able to analyze that data and they want to find patterns. Like even what could have been considered not really that data intensive before now really is. So I don't know. There's just been so much changing in the world that we live in. Like your phone. How many data points are collected from your phone on a daily basis? So you have no idea, right?

But I guarantee you there's data flying all over the place. So, yeah. Just think about what Google Analytics will capture about even a static website. Like your basic WordPress blog, you plug in Google Analytics and you see all the stuff that they're pulling, all the clickstream data that they're pulling from that. And it's just amazing what even a static website can generate with one person's activity. How's a WordPress blog a static website? It's not, but that's fine. We're going to let that go. Now it's debatable. Pull up a chair. I got you. Yeah, I'm still stuck trying to think

of even in today's world like a non-data intensive site or application that you would actually use. Not something that you made because you were trying to learn react, for example. But you know, something that that's widely used that would count as not data intensive. I mean, utility, something like link pad is something that comes to mind. Like maybe they're not collecting a bunch of data points.

Like, like things that would live on your computer or don't necessarily require an internet connection type thing, right? Like that's – Yeah. See, yeah. I was trying to like go to – I was trying to think of like a website. Yeah. Outside of marketing brochure type stuff like come stay at my hotel, I don't know that – I don't know that there's a ton of them nowadays.

I think a lot of people are collecting way more data. I don't even think your brochure where counts might be right. Because I mean, to Joe's point about the Google Analytics, even if you didn't go so far as to go Google Analytics wise, you might still have your own analytics or metrics to see like, hey, you know, how far down the page Your web trends. what you do with it, right? A lot of places don't do anything with it. So there's just a bunch of data collecting that never happens. And so maybe you consider those not data intensive, right? So maybe there's a lot of data being collected, but nothing ever actually happens with it. So it's still data intensive though. I mean, just because you don't do anything with the data once you collected it, though, you had to go through the act of collecting it. So it's still data intensive. So I think maybe the answer is that we should just assume anything that's on the internet is going to be data intensive. Anything that's networked, you should probably just assume would fit into the data intensive category.

Yeah. Yeah, I could get behind that. Jasonformatter.com. You don't know what kind of metrics they. Jasonformatter.com. You don't know what kind of metrics they've got going on. They might have all kinds of analytics there to see how well they're – how many pages. It's a great site. They might have to scale horizontally depending on all the – you don't know, man. Don't judge them.

Well, what's funny is if your site isn't data intensive, then Google is probably just going to end up like pulling your abilities out of your website and doing that little thing that they do where they just like go ahead and just do the work. You ever do that? Like you used to say like, hey, when's Thanksgiving? And then you would click on the first link and now Google is like, no, no, it's right here. You don't even need to leave the search results anymore. Like I'm not going to go to websites anymore. Right. Yeah, it's ridiculous.

I do the same thing with calculators. How many cups is in a liter? OK. Yeah, exactly. And now like 19 times four. Right. Yeah, it's ridiculous. I do the same thing with calculators. How many cups is in a liter? Okay. Yeah, I don't know. Yeah, exactly. And now, like, 19 times 4. Like, hey, there you go. Thanks, Google.

Yeah, I was going to say, okay, I'm glad I'm not the only one because the calculator was the exact example I was going to give. Because, like, how bad is it that rather than opening up a calculator application, sometimes you just be like, well, I already got Google. Yeah, yeah. I already got Chrome open. Like, you know. Yeah, yeah. Yeah. I already got Chrome open. Like, you know. Yeah. Yeah. Totally true.

So check this out. There are buzzwords that seem to be very synonymous with data intensive applications, right? No SQL. We've heard these things. Message queues, caches, search indexes, batch and stream processing. Like these are all things that you typically hear when you start hearing about data intensive apps.

And they wanted to point out what this book is not. And this is important for anybody that picks it up. It's not a tutorial on how to do data intensive applications with a particular tool set. They basically wanted to talk about the principles and the things that you need to understand about different systems that you will interact with so you can make the right decisions as those things come down the pipe. So what the book is, they say, is a study of successful data systems.

And they mention a lot of different data systems. So that's part of the inspiration for me is not only the ones I want to play with after reading about them, but also the ones I want to invent after reading about all those other ones work and the various different trade-offs. Like we mentioned clickstream stuff. It's very important for them to ingest data fast. And they don't really care about the consistency up front. They care that they don't drop any information.

So the book really gets into the kind of the trade-offs that different systems make, different databases, different tools, and different architectures make. And yeah, it reminds me a lot of kind of the data structures and algorithms that we've talked about, just at like a much kind of bigger level. Yeah, it's system design type level, right? And what you just said is a key part of this is examining the algorithms and the trade-offs they make. So basically there is no silver bullet, right? Like whatever your situation is, like the click stream, you got to write this stuff as fast as possible, right? There's trade-offs in what type of system you choose or what type of database

or what type of file storage or whatever is being utilized there versus something that's read optimized or whatever so there's there's truly like i i think all three of us have been doing this for a long time like we can't point at one single technology and say that thing will do everything i need it to do right yeah it's great when you think about when it comes to this like storing data in a computer like there's there's not so many really different tools that you have. You basically, you've got like trees, you've got hash tables, you've got arrays. And that's kind of it. And everything else is just how you kind of put those things together and how you use

that data, right? So this book does a lot of kind of diving into all that stuff for various different systems and relational databases. And even the different kinds of trees that different major databases use and make them different have a big effect on how they behave at a higher level and so before we get to all that we kind of have to lay out this baseline and kind of talk about the ways that we're going to kind of judge and rate and discuss these different systems and that's what today is all about but we're still in the preface. So I'm jumping ahead. Now, obviously, this book would be for DevOps engineers.

Absolutely for those folks. No, I'm just trolling you. Don't go there. There's no such thing. All right, moving on. We got some great comments, by the way, if you head to the website. Oh, man. Yeah, that was actually an excellent episode.

We got tons of feedback on that one. But yeah, seriously, who's this book for? Software engineers, architects, and system managers. People that are involved with keeping these things alive and understanding how they work. And who does it want to appeal to? I think anyone who wants to learn how to make systems scalable. There you go, Alan, knock, knock. A billion users. You need to make your applications highly available and more maintainable, which is something that we always keep coming back to.

And you just maybe want to know how these things work and building for scale you don't need is wasted effort wait i thought this whole book was about scaling what the heck i hate this quote uh i actually loved this entry in there is they were talking about it right like yeah totally if you if you're gonna go build it for a million users before you have the first user, then you're wasting time. It's premature optimization, right? We've talked about it before, the whole Yagney principle. part, just getting estimates on data transfer and data storage was for all the systems. So like when we're talking about Twitter, it's like, okay, well, how many terabytes? How much is going over the wire? How much are we storing about each user? How well is this going to grow?

All those things are really big questions to ask because they all help you kind of make decisions about the technology. And in reading this book, I realized that a lot of those decisions weren't so much like I need to go off and read a book about ECDs and come back. Like you could say, even knowing just a little bit about kind of high level how databases are organized and categorized, you could take a use case like that and say, well, numbers matter a lot and I don't care about selecting individual records. So I'm looking at OLAP databases so I can cut like half the databases off. I can just exclude them from my research right there.

So I don't need to go read about what's hot. I can like categorically filter down based on my situation to find the systems that are good for me. And even if I don't want to bring the systems in because, you know, adding new technology is always scary. I can look at how those systems solve those problems and use that to kind of influence my decisions. And that's basically what they said here is getting at what you just said is, yeah, you maybe don't need to build this thing to be able to scale like that from the beginning, but having an idea of what type of or how much data and what type of data in the complexity will at least put in your mind the types of systems that you're going to be targeting when you're building your application, right?

Like if you know you're going to be a right intensive application, you're going to be targeting when you're building your application, right? Like if you know you're going to be a write-intensive application, you're going to be looking at technologies that target that type of thing versus a read or an analytics thing or whatever, right? Like they all will, knowing these tools that are available will help drive better decisions. That's what it's all about. It's making a better data intensive applications. And what's the book? They, they mentioned the term big data. I think this book came out two years ago,

2017. And big data was like the term. Then everyone saw around the world. We've kind of gotten away from it a little bit because I think there was a kind of a ruckus around what people considered to be big. It was different for different people in different organizations. Obviously, Facebook's idea of big data is very different from almost anyone else's in the world. That doesn't mean that these tools aren't applicable to you or that some of the techniques aren't applicable. People just kind of got away from using that term.

I'm not really sad to see it go, but it does make things a little bit harder if you can't really kind of classify the type of stuff you're doing. But yeah. Oh, and the book doesn't like the term either. Yeah. Just to clarify, you were talking about when the book was released, it came out March 2017. Oh, it's two years old. Interesting. Yeah.

So, I mean, the term big data is even way back before 2017. Oh, it's two years old. Interesting. Yeah, so I mean, the term big data is even way back before 2017. Right. Five years at least before that. Because the previous election, they were already talking about, there were like big data teams working on elections to find out

what was going on. So 2016, there was... I mean, I can remember back to like 2010 hearing people talk about big data yeah so or data i'm not i'm not an early adopter so reading a book that's only two years old like i i should get a medal i should get a cookie for that uh obviously we were i mean this is awkward now we were going to give you one but now that you brought it up man hey but a heads up here too they don't refer to it as big data in the book because they didn't like the term. So they basically start talking about single node versus distributed systems because that's when you start getting into this whole complex system stuff with large data and needing to be able to do stuff with it.

Two numbers in programming, one in many, right? Right. And off by one errors that throw that off to the book. Also, if you pick this up, they have a heavy bias towards FOSS free open source software. And primarily they said, because with that stuff, you can look at the underlying implementation of what it's doing. Right. So, which is so sometimes so frustratingly necessary because sometimes depending on what software you're looking at, the documentation is lacking and you can actually like find, uh,

you know, find, find that the code and or test that go along with it might be better. Oh, absolutely. I mean, I hate it though. I hate it when that happens.

Just like I submitted a pull request and got it merged into elastic search. So I am officially a contributor because I picked some documentation. Yeah. I thought you looked different. Yeah. I had got a little bigger that's awesome all right i think joe you've got a question in here i would imagine yeah and this is something i was kind of thinking about uh when reading kind of the preface of the

book and i don't think they really ever kind of dive into it but i'm kind of wondering like are we living right now in the golden age of data what does that mean yeah i was gonna say like how would you define that yeah so the way i kind of thought about this is like i kind of thought about like the history of the web and like there's been kind of like a couple big revolutionary kind of moments even in the last 20 years like when jquery coming out it was like a big pivotal moment because something new came out and a bunch of people flocked to it and a ton of innovation all happened around the same time and then things kind of leveled off and then like when ruby came out that was like another one and then um like what you call it um angular kind of kicked off another one where these things kind of go in like these

bursts of innovation when node came out my gosh that like changed the entire web and so there are these kind of these big leaping moments i kind kind of was wondering, like, are we at a point where we're kind of leaping right now really hard in the data space? And the reason I say that is because five, 10 years ago, when it came time to choosing a database, it was like SQL Server or MySQL or Oracle, right? Those are my choices. And then, you know, NoSQL was kind of new, I think, around 10 years. Maybe I'm not so accurate on that. But that was kind of new. And so people started thinking, okay, well, am I doing relational or NoSQL? But it was still kind of like that was the question.

It was basically, am I doing Mongo or DocumentDB or SQL Server? But now here we are in 2019, and it's a much more complicated question because even if you look at the the services for say amazon is like neptune and rds and then dynamo db and all the various different no sql providers and even neptune not neptune um i was thinking azure's cosmos has multiple different interfaces so if you want to do graph or relational or whatever it's it's just gotten a lot more complicated and it's competition and it's good. And I just think that there's a lot of cool things kind of being built in that space.

And there's a lot of like innovation happening specifically around databases and the different categories of databases that wasn't really happening 15 years ago, I think. So I'm going to say no. And here's my reason. So as we were talking about abusing the uses of Google, rather than going to like a dictionary or a thesaurus and saying like, okay, like what exactly would, how would you define golden age? I went to Google and said define golden age i went to google and said define golden age and google's definition for golden age is the period when a specified art skill or activity is at its peak and even based off of the things that you just said i'm like well we're still thank you thank you google google was recognizing we're having data's peaked, I'm calling it.

Yeah. Clearly, our bots in the house have not peaked. We're definitely not at the golden age for those. Okay, Google, stop. That's enough already. You've gone too far, man. How about we call it Cambrian explosion? Like there's an explosion of evolution. So I would say explosion to me is more accurate because I feel like right now there are so many – we've joked about in the past like there's so many JavaScript frameworks that seem to come up every five minutes or whatever. Like I sort of feel that way about about data tooling right now maybe not because you asked

if it's not databases but the age of data i think so because there's so much of it that people don't know how to handle it and there's so many tools springing up to handle so many different use cases that it is sort of a minefield to try and walk around and figure out what am I supposed to use here, right? Yeah, which is kind of just to finish my point where I was going. I was like, I think that because there's still so much new innovation happening in it, that's why I'm not sure to say like, I don't know if we're at our peak yet because maybe we could still be on the uphill climb i think we are um you know you look

at things like uh you all the different search uh technologies that are out there as an example right um the other thing i want to mention that just dawned on me too is that uh don't hate me if your phone or some device in your house just went crazy because I was trying to turn off the random one here in my house because it decided to listen. So I feel your pain is what I'm trying to say. So interestingly enough, if we think about this, I think we are entering an area to where it's probably one of the most important things that everybody cares about. Right. So I don't know that we've arrived at the golden age of it where we're at the peak or the epitome of it. But, I mean, just think about you guys saw the – I'm sure that you guys did saw the article about the Tesla thing that hit somebody because it only looked for people crossing the street at crosswalks.

Oh, right. Right? We're talking about the Tesla feature to bring the car to you? Is that the feature? I can't remember. I think the feature. It might have been. But I do know that it just didn't see a crosswalk.

And so when somebody just randomly crossed the street, it's like, oh, that's not a good Clearly, nobody would be jaywalking. Right. So it's definitely interesting because that would be jaywalking right so it's it's definitely interesting because that's all driven by data right like that's all it's collecting thousands of data points per what second or maybe even more and it hasn't been trained and so like this whole notion of every little bit that you get might matter. You know, we as humans have the ability to tie things together in ways that we don't really even think about.

Machines don't have that capability. So storing data is different when you're trying to put it on a hard disk than things that just bounce around in our little, you know, meaty heads here. So it's a. I don't know if you've seen Joe? Cause his bigger now. That's a big meaty head. Cause I don't know if you've heard, he's a, he got that PR.

That's right. Core contributor. Yeah. Yep. Put that on the resume. The other morning I woke up, I woke up really early, like four in the morning.

And I was like, I'm going to, I'm going to look at Neo4j. I've been meaning to get into Graphic Database for a while. At 4 a.m. in the morning? I tweeted about it, and they responded. Thank you very much.

So I got up, and I was like, let me do this. Man, within minutes, I had it running thanks to Docker. I found a compose file or a Docker run command and just ran it. I didn't have to set it up. I didn't have to install. It was just there. And if I wanted to publish or get my little app proof of concept running,

it was just really easy. And between the cloud, and I want to give some of the credit to machine learning too for kind of driving some of the needs for some of these different kinds of data processing. Because now, like we talked about with the example from tesla

like relational database doesn't really make sense for that sort of thing like getting the data in there really quickly is important and maybe dropping little bits of information little bits of information isn't such a big deal for that so like streaming data sources has had a big impact in real-time machine learning has had a big impact has been-time machine learning, has had a big impact, has been a big driving force between some of these big data systems that we didn't really have before. So it's like every time we invent some new way of, some new technique or ability, we have to go up in the whole apple cart in order to support it

and to make these things make sense. So I think that a lot of the things that have been coming out, and even services like AWS Kinesis, Azure's got their own kind of event hub. I mean, it's like every week, all these different kind of ancillary services are spinning up. You can see how many AWS services Amazon has. I don't think anyone even knows how many services they have.

People joke about a new JavaScript framework every day. Like, man, have you seen AWS? Right, their services are out of control. Have you noticed? I don't know if this, maybe this will be lost on you. I don't know if you've paid attention to this. But, you know, you remember the days of when you would go to the AWS console and you just saw all of the available options there and you would, like, click on it? Yeah.

And now it's just like, here's the last five you looked at. Do you want one of these? Yeah. i can't even tell what i have running anymore i legitimately don't know it's it's nuts but i need to talk to you about our bill but but on the flip side like you said a lot of this stuff is making the barrier to entry super low right docker the fact that you could have Neo4j running by Docker run Neo4j, like that's nuts, dude. Like we all remember the days where like, oh,

we got to get our development environment set up. That's going to take us a few hours because we got to download and install SQL Server. Like this stuff is turning into where people can get up and running so fast that it's insane. Docker is still so amazing. I mean, pretty soon. I love Docker.

You know what? I wonder. I'm going to go search Docker Hub for this. This has got to be a thing. I bet you somebody has just put something out there as simple as a calculator, and you could just Docker run calculate this. I bet there is. Because did you know that there's a whole slew of docker images

for windows oh yeah that would allow you to basically do linux commands curl or ssh or whatever there actually are there's like hold on there's if you search docker hub for calculator 512 results come back. That's ridiculous. That is way more than I thought. Yeah, there's Calculator services. I just want to like Docker Run Calculator and get something. Or Docker Run Calculate would be better. That's amazing.

That was a bunch of people taking tutorials. You know that was. Yeah, probably. You brought up the – where were you going with that, though? Like using the Windows Docker containers to run Linux commands? Yeah. Yeah, they basically have wrappers so that people that are in Windows that are more familiar and comfortable with Linux things, like curl was one. Wget might be another one. Instead of having to learn PowerShell commands, you could actually do a docker run curl

and pass it in the arguments and it'll basically run that stuff for you. So yeah. See, I thought where you might be going is that because we've talked about this before and I wasn't able to pronounce his name then and I won't be able to pronounce his name now. But he was the Docker Captain Microsoft MVP on Docker Hub.

He's got 87 repositories on Docker Hub. And as far as I know, I think they're all like Windows-based, how you could do things, different things on Windows, right? Stefan Scherer. I'm sorry. I know I'm like ruining his name. But yeah, so it's like to your point about Linux commands on there. So like one of them is who am I?

Right. Or, you know, there's another one on here that was open SSH. But then he's also got other ones on here that are like, let's see, let me find a good one. That would be.

Oh, I want to do an NS map or NS lookup or something like that. And I'm like, oh, but I'm on windows or even like what's called telnet, whatever, which is not installed by default. Like if like that. Or like, oh, but I'm on Windows. Even like, what do you call it, Telnet, whatever, which is not installed by default. Like, if you've ever looked like, how do you Telnet in PowerShell or something,

then you could instead Google how to Telnet in Docker. Right. I mean, he's got, yeah, Python for Windows, Postgres for Windows, Chocolaty. If you don't want to install Chocolaty, but you want to use Chocolaty. Ooh. That's pretty cool. I like that. That you don't want to install Chocolaty, but you want to use Chocolaty. Ooh, that's pretty cool. I like that.

It seems a little crazy to me, but Curl was another one that he had in there. He's got a ton of them. Yeah. So he might have earned that Docker captain title. I'm just saying. I mean, it is amazing the world we live in. And I think, too, you know, wrapping up that point, I think we are living in a world where data is king. I don't know that the tooling's there yet, but it's definitely…

Or the laws. Say what? The laws are still developing to prevent… GDPR. Yeah, some of the misuse. Oh, man. This episode is sponsored by Educative.io. Every developer knows that being a developer means constantly learning new frameworks, languages, patterns, and practices.

But there's so many resources out there, where should you go? Meet Educative.io. Educative.io is a browser-based learning environment allowing you to jump right in and learn as quickly as possible without needing to set up and configure your own local environment. The courses are full of interactive exercises and playgrounds that are not only super visual but more importantly they're engaging and the text-based courses allow you to easily skim the course back and forth like a book. No need to scrub through hours of video to get all the parts to care about. Amazingly, they have all of these courses available with free trials and a 30-day return policy. So there's no risk to you.

You can try any course to track that you want. So they just announced some awesome new ones. Grokking Computer Networking for Software Engineers, right? Which I was like, oh, that's amazing because we need to have an appreciation for the network layer as well. And then, you know, I think we talked about this before, too, but they've expanded the concurrency section. Does that sound familiar? Didn't we talk about that? Because I remember they like introduced it for C++ just recently.

And now they've expanded it to Ruby concurrency for senior engineering interviews. Oh, that's really great. And like I mentioned on the, the a few times before, the grokking, the system design interview has just been amazing. And I've been looking at again tonight looking at the various ways that things have systems are put together and it fits really perfectly with the stuff that we've been reading and talking about on the, on the book. Yeah. Very applicable to this episode as well as the future episodes that we reading and talking about on the book. Yeah, very applicable to this episode as well as future episodes that we will be talking about on this book.

Excellent. So start your learning today by going to educative.io slash codingblocks. That's educative, E-D-U-C-A-T-I-V-E dot I-O slash codingblocks and get 20% off any course. All right. Well, I think now we can finally get out of the preface and move into the main chapters of the book, if you'd like. So we'll start with Chapter 1, Reliable, Scalable, and Maintainable Applications.

Yeah, most applications today are data-intensive, just like we kind of talked about. But they want to make the distinction here between data-intensive and compute-intensive, which I thought was interesting. When I was first learning programming, it was very much more about the computer. And distributed systems was kind of like a paragraph at the very last chapter of your Computer Science 1 book, just letting you know that it's a thing. And now it's much more common to deal with these distributed systems and you're usually traditionally uh commodity hardware and we've talked about this before where the price of compute doesn't scale linearly right so a hundred gigahertz processor is uh significantly cheaper

than uh it's it's more than 100. Help me out here, Harvard peeps. Like what's a real processor and what's one that's twice as fast? I wanted to hear your 1,995 megahertz processor. I thought we were going really good. Is it a Pentium? Okay, fine. 1.1 gigahertz.

And the turbo button. All your DOS applications ran too fast when did you not have that turbo button on when you played video games that were coded to a certain frequency because they would go too fast you're right yeah man I remember those days they were awful

fine how about this how about cores we say like you can do a cloud a cloud uh clouded computer ec2 instance with two cores and you'll pay uh ten dollars a month but you go up to uh four cores twice as many cores and now you're paying 25 bucks a month yeah and that keeps going until you get to where you're doing say 32 cores and it's way more than 16 times more expensive it could be 100 times more expensive because the costs don't scale literally. And so it's become more cost effective for businesses to just have more computers that are cheaper, crappier hardware. Well, that's one thing.

And I don't remember if it was in this book. It might have been. What I do want to point out is using the term commodity hardware. A lot of people – it used to be associated with buying really crap hardware, right? Like, hey, we can run it on the cheapest thing we can find. It doesn't matter if it fails, whatever. That sort of changed now to where commodity hardware means off-the-shelf type stuff. I always thought that's what it meant.

It was just off-the-shelf. It wasn't like specialized hardware. That's the key, right? It wasn't like you bought a – sorry to interrupt, but it wasn't like you went to Sun. Sun to buy a Solaris. And bought a Solaris workstation. Right. And that's the point is nowadays when they're talking about commodity hardware, it's just, hey, you bought some regular motherboards.

You bought some regular CPUs and you throw them in there. And it's not, like you said, it's not a risk-based processor to be able to do some sort of special compute type stuff. By the way, can we pour one out for Sun? Is it too late? We're very topical. Also, while we're on this topical note here, am I like maybe showing my age? Because Joe's talking about like, oh, hey,

you remember in your computer science 101 book and there was like a chapter or a paragraph on distributed computing? Yeah, mine didn't. Yeah. Okay. Okay, thank you. I feel a little bit better because I was like, whoa, dude. But in fairness,

I probably wasn't paying attention. Well, that is a strong possibility. Right. Yeah, so there might have been a chance. However, I would like to think that I paid attention. We're all showing our age by having books for our computer science courses. I know. In fairness,

I don't use books right well that's why you didn't notice that the paragraph was there that's a good point right yeah i just want mom and dad to know that i did pay attention i i wasn't out at the parties like i was totally studying i read every chapter and i don't recall that one uh-huh yeah so the kind of point is getting back on track that the cpu is rarely the bottleneck anymore in any sort of like kind of data-intensive application. So a lot more often now we're kind of talking about how much network or how much storage something takes or, you know, latency between systems. Those are the metrics that we care more about our own home computers, though, you know, I mean, you can remember back to a time where, you know, if you had the opportunity to upgrade something on your computer, right? You know, processor, RAM, those were among the first two things that you might go after.

Today, we're like, I mean, processors are fast enough. Like, I'm going for the ssd yeah you want you want the storage because that's where you're going to see it right yep so like even even my point is like even at home those things have changed yeah you know what you look for in uh you know reducing the bottlenecks on your own machine you remember our friend vlad obviously we do we had him on episode i don't know three who knows um it's been a minute i think you're pretty close but nine was it nine wow golly man you guys have i think he's speaking german so but here was the key like i remember having a

conversation with him way back when and he's like dude give me an i3 and an ssd over an i7 that's crazy and anything else but no dude i think i would almost agree with him like if you're gonna hand me two different computers and be like this one's got an i9 and a spinning drive and this one has a even lower than i3 i don't even know what it would be right but give me this with an ssd i'd be like give me the me the SSD. I can't deal with this other stuff. So, but at any rate, back on track again. So most of these applications that are data intensive have similar needs. They store the data so that it can be found again later, right? Like just about everything that you've ever used online, right? Like it's not even worth talking about.

That's basically everything. They cache expensive operations, so they'll be faster next time. Think about Stack Overflow or Reddit, right? Like these things, they are not pulling from a database live. They allow users to search. They're sending messages to other processes for stream processing or other things. And they probably process chunks of data at intervals, also known as batch processing. So all of these data intensive applications share these similarities.

All right. Oh, sorry. Oh, it's you. you yeah i was super curious it was episode nine nine wow dude that's ridiculous i remember the old ones because those are the ones i would spend hours and hours and hours editing oh that's right i remember the screenshots of those things. So are you saying they're painful memories? Painful memories. They were painful memories. So, uh, designing data intensive applications involves answering a lot of questions. And, uh, I think

that, uh, like I kind of said before, it, um, after reading the book, it kind of changed how I thought about things and it made it just kind of my thinking about these sort of things more methodical. And it's because we're coming up with like the kind of the right questions to ask about these systems and about these requirements. Like how do you ensure that data is correct and complete when something goes

wrong? And that's something we got to take for granted with relational databases because they had the right old head log that was, they were kind of designed that way in the seventies or eighties or whatever. And everyone kind of forgot about it because it just worked for the most part unless true disaster struck right the acid transactions right yep yep and yeah go ahead uh how do you provide good performance to clients as part of your system are struggling? We've talked about that a little bit before, either microservices or having other ways

to kind of protect the most important bits of your software and just keep things isolated. How do you scale to increase load? And how do you create a good API? And I got to mention that Educate, of course, again, because it was really good about kind of laying out questions like that. And basically what they were kind of saying is like, if you're in a system design interview, or if you're designing, if you're designing like a new system for work or something, like these are the kinds of questions that you need to be asking

along the way. So like come up with a rough draft, you know, draw a couple of boxes in the whiteboard and then ask yourself, like, how do I scale this? Like, what are my weak points how to reward how do i keep the main line up if this part fails and so it's nice to kind of have these uh rigorous kind of like straight straight and narrow questions to ask about your architecture now wait a minute just to be clear which uh course were you referring to uh it was a system design process let me get the exact name here. Grokking the System Design Interview is the official name. So we'll have a link in the show notes.

Because that course is truly amazing. In fact, I will go ahead and get that right now. It is like the perfect companion to this book. So you can just go read about like, I don't know, what's a good one? I forget. The link shortener. Bitly? Yeah, they do something like Bitly or a tiny URL. And they go through the math on the estimates of like amount of traffic, amount of things.

And even like the Bitly kind of tiny URL example is like really insanely interesting. And it looks like that's actually one of the ones you can look on the free. Let me double check that. Because you can access some sections of that it is so you can go check this one out we'll have a link to it so you can read about how tiny url is put together and just looking at the questions that they ask of their architecture is just fascinating like the way they kind of look at the different requirements for that system and how they approach it and how they get to where they go with that. Just really well done. Cool.

And then I think, Joe, you also wrote this one down here, right? While we're going through the episode, think about the systems that you use and how do they rate in terms of the reliability, scalability, and maintainability, which, by the way, we're not getting to the last two there, the scalability and the maintainability, because we know that this would go crazy long. But think about your system. How reliable is it, and what does that mean, right? And we're going to be touching on some of those points here in a minute. Yeah, and you can kind of take any system.

So, like, say SQL Server, like, how reliable is it? I would say SQL Server, probably A+. I don't know many more systems that are much better than that. But we could look at something like Elasticsearch and how reliable is it? It's definitely not A+. It's eventually consistent. And if nodes go down or partitions go down or depending on replication, these are things that you've got to fiddle with in order to get the things to be reliable. So you can absolutely have a system that's

not reliable, and I'm sure you could ruin anything, but it's just a little bit more finicky to get right with something on Elastic. So it's not SQL Server reliable. Well, in fairness, though, let's also talk about why. Real quick is SQL Server is typically on one box, right? So if we're not talking about failover and clustering and all that kind of stuff, it's a whole lot easier to ensure something when you know it's all in one nice little bundle, right?

Like there's no network to deal with. There's none of this stuff of distributing data between nodes. Like, well, you know. I mean, maybe we say it like, because it doesn't have to be SQL Server-based, right? It could be Oracle. It could be DB2. It could be any kind of database, right?

Usually for any HA environment or maybe say it even in an HA environment for those databases or database systems, you still – like your rights are going to be constrained. Right. If you're in an environment where you're lucky enough to have the reads not constrained. Right. And HA, for those listening that don't have any clue what he's talking about, is high availability. Oh. What were you going to say?

Ha. Ha. It's going down. Ha. Your box is dead. All right. So, yeah, as we're going through, think about how you would kind of grade your systems

in terms of these factors, and you can ask those questions about the applications that you're working on. Yeah. Who is it? I think it was like Mike RG was talking about, you know, it's gotten to the point where like whenever things are down, you're like,

oh, I guess I'll just go browse Reddit. And then when Reddit's down, you're like, oh, I guess I'll just go browse Reddit. And then when Reddit's down, you're like, oh, I guess I'll go browse Reddit. Wait. Yeah. All right. Well, it's that time to ask you to please leave us a review. The holidays are coming up, and this could be your present to us if you haven't done it already. We really appreciate it, and we need you to survive.

So if you could head to codingblocks.net slash review, we try to make it easy for you, and we really appreciate that. So just help us out here, please. All right. And with that, we head into the portion of the show where Joe mocks me. Survey says... All right. So, all right. No, not last episode, but a couple episodes back,

we asked, and this will be really relevant to this show, which relational database is your go-to? So your choices were Postgres, the elephant in the room, or MySQL, the digital adventure is a flipper, or SQL Server, it looks like you're trying to create a database, said Clippy. Or Oracle, the big red box. Or what else did I write here? No as in NoSQL, but I actually put that different in the poll, I thought. How did I write that in the poll? Oh, man, did I leave out NoSQL?

Oh, no, I said... I see it now. I said RDBMS, NoSQL, or graph databases are where it's at. All right. So, Alan, you go first. I'm going to say here... Just kidding. Joe's go first. I'm going to say here, based on... Just kidding. Joe's going first. No, no.

It's my turn. I'm taking this one. I think based off... Did you know that as soon as I said you go first, he was like... Yeah. Conversations in Slack, I think, are going to lead me to SQL Server Clippy. And I'll go with 45% here. Whoa.

SQL Server and 45%. 45%. Wow. Okay. Well, I think I'm going to go with Postgres. No. Okay, you do that. I'm a Java guy now.

What can I say? I will say Postgres is my new love. It's pretty awesome. It's pretty nice. It's pretty awesome. I do love Postgres. So what's your percentage there, sir? Are you going with $1?

Let's go with $30, $32. All right, $32. $32. Okay, so SQL Server at $45 Alan and Postgres for 32 for Joe. And somehow you both managed to, like, overshoot the mark. I would have. Really? Okay.

Yeah, so you both lost. But I picked the right answer. All right, so I will say this. The top answer. All right. So I will say this. The top answer was SQL Server. But all of those people are wrong. Because what they meant to click was the second most popular answer, which was Postgres. Interesting. All right.

So how far off were we on the two? It sounds like they had to have been somewhat close. You were closer. SQL Server was 43% of the vote. Man. And Postgres was 26% of the vote. So what was down below that? MySQL, I assume, would be next.

Yes. MySQL, NoSQL, then Oracle, and then Graph. Man, people just do not know. They don't understand the glory that Graph can be for the right use case. I was sad to see Graph as low as it was. Well, it was the bottom. Thank you, Andrew Diamond, for your vote. And I kind of wish that Oracle was down there, right?

You're not the only one. Because I was like, that's not my least favorite. Oh, man. Yeah. And we didn't include like, you know, like looking back at this, I'm like, oh, you know what? We didn't include DB2. Why would you? And nobody complained.

I think maybe Oracle kind of. of this and I'm like, you know what? We didn't include DB2 because nobody complained. So maybe implicitly DB2 was on the list. I think Oracle might want to be at the bottom of the list too. They don't seem to really like their customers today. Really? I don't know.

I guess I shouldn't say anything about it because I haven't ever really used Oracle in depth, but I've just only heard Veritrol. I've only heard bad things about Oracle, so maybe my mind has been poisoned by – Yeah, there are definitely people that are – I know people that love them. Heavy, yeah. Slash r slash programming has brainwashed me. Well, slash r slash programming is not very nice to anything.

That's true. Have you ever seen any of our posts? Yeah. All right. I take it back. You're right. Yeah. No.

All right. All right. So, for today's episode, I thought we would have a little fun, or we thought we would have a little fun, with continuing along the lines of the last episode with the hardware-heavy episode. Because, I mean, if you might have gathered, at least 66% of this podcast really likes hardware. Or two-thirds if you're keeping count. Sorry, Michael Dippet. No, no.

So we thought today's survey would be, what is the single most important piece of your battle station? And your choices are the keyboard, of course. Johnny Five need input. And if you get that reference, you're a little bit up there with us. Yeah. So it's all right.

It's all right. Need data. All right. The mouse, my clicking game is on point. Get it? The monitor, I see dead pixels. Or obviously not the peripherals. It's all about the tower of power.

Or the chair? Or should I say the CEO chair? Now, who gets that reference? That'll be a curious one. Slocum Valley. Dang it, Joe. Yep. Oh, it was. I remember it.

Yes. I got a reference. And, or lastly, it's all about the desk. Nothing else matters if it's sitting on a TV tray. That's awesome. Hey, wait. Back up. What did Michael, does Michael Tippett not like hardware?

He's not. Me and him are bonded together on our disdain for hardware. Man, you guys. Really? It's just gross. You can't undo. There's no Control-Z. I'm ready to ascend. But without hardware, you can't have a Control-Z, so what are you going to do? That's right, man.

So did you not get the Johnny 5 reference, Joe? Oh no, I did. It was just too old. Oh my gosh. I know Johnny 5 is still live. I don't know about Need Input. You don't remember that one? Nope. That was what Johnny 5 would say. He'd pick up a book, Need Input.

Johnny 5, Need Input. Johnny 5, Need Input. If Joe doesn't like hardware and he also doesn't like movies. Apparently not. He doesn't really enjoy much of anything. That's true. I'm a crutchy old man. And I hope you got the Dead Pixel reference, because that one, if you didn't, we seriously have to have a talk.

Oh, yeah, yeah, yeah. Okay. Okay. You know, I do like this book, though. Designing Intensive Applications. That's what I like. That and Borderlands 3. That's all.

And Slay the Spire. That's all I need. Okay. Well, then fine, then. If you're going to be that way, let's talk about reliability. Yes, let's do it. And Silicon Valley. And what is reliable?

Clearly not your index on movies in your mind. And I really liked, actually, that they broke it down the way they did. I'll try not to believe the point. But it's just kind of nice to be able to say, like, you know, I kind of advise, like, think about your systems and ask yourself what's reliable. You know, how reliable is your system or your database? Like, how do you define what reliable is? Well, right here. Does the application perform as expected?

Can it tolerate a user mistake or misuse? The performance is good enough for the expected use case. And the system prevents any authorized access to abuse. So you can kind of grade those individual pieces, see how it does. And I mean, that's where I would kind of say like sql server like i still feel like it does a really good job on all those points but i think it's supposed to be like all of those yeah and that's right to me i think it does really well for all of those no no i'm saying like to define reliable it's all of those it's not just one of those points right

right right right but you like yeah so i kind of think of it more as a scale so i can say like this this system is more reliable than that system right i can compare two systems and say which one i feel like is more reliable and the way i'm going to kind of compare those or figure that out is by kind of breaking up into smaller pieces and kind of trying to to grade it based on that so now in fairness though i do want to back up like we said sql server right or probably point it at most rdbms is out there they probably check a lot of these boxes but we're also talking about your system as a whole right like yeah the whole thing the whole architecture right does your application with its database and with whatever technologies are in between and all that kind of stuff, does it perform the way that we're talking about here? So in short, does the thing actually

work even when some minor things go wrong? But it would be interesting though, because like, depending on if you were maybe Google scale, Amazon scale, Facebook scale, you might have additional, uh, metrics in there about like, you know, page load time. Like, like if it takes,

you know, three minutes to load. Yeah, fine. Okay. It loaded, but that's not expected, right?

Like you're expecting like, you know, really fast sub-second load times no oh outlaw i am i'm so happy to be reading this book with you i've read ahead quite a bit there's going to be some chapters in here that you're really going to like we're going to talk about slos and slas and i think you're just you're going to talk about SLOs and SLAs, and I think you're going to be in your element. Okay. That's amazing.

Hey, but in fairness, one of those bullet points did cover what you were saying. The performance is good enough for the expected use case. And if you're a Google or a Facebook, those are your expected use cases, right? Like somebody clicks my page, it better load in 200 milliseconds, right? Okay. Well, fine. Fine, then. It's fine.

Alan, it's fine. It's fine it is fine it is fine but no i mean that's that's a super important thing to to be aware of right like for somebody if you have some internal analytics application that your department relies on that you homegrown built for yourself and people expect it to load in five seconds and you said hey that's good enough we're not gonna spend any more time on it in five seconds seconds is the bar that you set, and that's fine for that use case. Whereas, like you said, if Facebook or Google is going to be like, no, that's not going to work for me. We need this time. 500 milliseconds. Right, right.

So it does depend on the use case, and that's very important to keep in mind. Yeah, and even how you get those metrics is pretty interesting in the way that you kind of measure them, like in terms of like, you know, median or averages or even percentiles, like you would say like 99.9% of page loads are less than 200 or something like that. You can get, you can get all sorts of crazy with those, those surface level objectives that you really care about. And that's how you can really add a fine grain, measure your reliability, and then compare that to your kind really care about. And that's how you can really add a fine grain, measure your reliability, and then compare that to your kind of past performances. And so you can kind of like at a very fine grain level,

grade yourself and give yourself a very accurate rating at how you're doing with all this stuff. If you really want to go that far. And I do. So when things go wrong, not if, but when they go wrong, they're called faults. They're usually Alan's faults, but... Fair enough. Some people are more faulty than others.

Some code. Is it wrong that I laugh at my own jokes sometimes? No. All right, whatever. All right. So systems that are designed to work even when there are faults are called fault-tolerant or resilient. Hashtag Fartgate. And it's important to note that nothing is 100% fault tolerant except for my code, obviously. Right, right.

I mean, obviously. Yeah. Yeah. You couldn't make anything 100% fault tolerant. It's not even possible at all. Not even in the realm of possibility. I don't know if I agree with that. Is that true?

What could you make that is 100% fault tolerant? You can make a Hello World app. You can't guarantee that that app's not going to crash when the thing launches. There is nothing you can make. You can't control the system that is running that thing. Would you call that a fault of your code, though, at that point? It's not fault tolerant. Does it relaunch itself a million times trying to overcome it?

I could scale this out on Amazon, have it set up to auto-scale, just have a Lambda function that when you call it, it'll return hello world and scale out as much as it needed to. You know what, though? There. Now I've solved your system. Actually, you know what? The next point actually debunks exactly what I just said. So let's go ahead. Faults are not the same as failures.

A fault did something not to spec. So technically your hello world probably did everything to spec. Ha ha ha. So I was completely wrong here. A failure means a service is unavailable. A fault means something didn't operate the way that it was designed to. So then that previous statement we can say is wrong. You can have 100%.

So we're going to just scratch that right off the record. We never said it. I still feel like there's room somewhere. So the goal is to reduce the possibility of a fault causing a failure. So faults are bad. Failures are kind of the worst, right? If the whole thing goes down and there are various reasons for why we kind of say failures are one of the worst things. And in part, it's because failures often can cause a cascade of even bigger failures.

And so if you ever had a system that crashed and caused another system to crash and you couldn't bring either one up because they would both crash each other, then you know what I'm talking about. So let's put this into layman's terms. You create a bug and it crashes the whole system or brings the whole system down. So an example of that could be your code runs in an infinite loop, and so it just never responds to any other request because it's stuck. Yep, so the service is unavailable. Heck, we just had one with some stream stuff, right?

Like it didn't recognize a piece of data, and so it just shuts down the entire thing. You're like, what? Why? Yeah, fault turned into a failure. Did you hear about Pokemon Sword and Shield is crashing Roku boxes? No. Yeah.

If they're on the same network, it turns out Sword Shield, send out a particular network discovery packet that gets intercepted by the Roku, but I don't know the details of why this particular message is so poison to the Roku, but it causes the Roku to just restart. And every time it comes back up, it gets hit by this thing again. It's constantly going

out there pinging for basically other Sword and Shield players and it's constantly crashing roku and i think they've issued an update for it now but yeah if you've got pokemon sun and moon god dang it sword and shield running on the same network as roku then your roku is probably shutting down constantly oh that's brutal man stinks well and whose fault is that rocule whose fault yeah it's roku roku. Literally whose fault? Yeah, it's Roku. Roku is experiencing unexpected behavior and it's failing because of it. Yeah.

Yeah. And that's the tough one, right? So, yes, it's their fault. Is it something that they could have easily ever tested for? It doesn't sound like it, right? Otherwise, it wouldn't have been there. So, that's a hard one. And that's a software failure failure which we'll be talking about

in a minute um yeah well it sounds like they just weren't running that process in a try catch and then they get a bit right i think it um i think i read that it had to do with uh rokus that were on the kind of a network together they could kind of do something to like update each other so if you're like a hospital or something that has like a bunch of you know a thousand rokus then they can kind of spread updates across each other without like bringing the whole you know uh network down and so they've got this kind of protocol for communicating amongst each other and it just so happens that sword and shield just sends out this thing that just is the right combination of things to kind of trigger a reboot and yeah it just kind of stinks man this reminds me of a podcast episode I listened to where there was some sort of, there were

podcasts that would play in like Mazdas, and it would crash their system. Oh, yeah. Oh, man, what podcast was that? I know the podcast you talked to. Reply All. Reply All was the one that mentioned it. And it was, they

thought, like one of the theories was it was the name of the podcast that was doing it. Yep. I don't even remember what it was now, but it's one of those things. It's exactly what we're talking about. It's failures that you don't expect because they just don't happen. And then it does. And trying to find it's a pain. But here's one thing that's interesting that they say here is it may be beneficial to introduce or ramp up the number of faults thrown in a system to make sure the system can handle them properly.

And I think outlaw may have mentioned this in the past is Netflix wrote their own and they called it chaos monkey. Right. And this thing basically just goes around trying to mess things up. Which is crazy and we'll have a link to the GitHub repo in here. It was 99% Invisible.

It was the podcast that was crashing the Mazda. Yeah, I found it. I was going to say the same thing. What did they end up finding? It was characters back to back that were causing i think it's the percent space or something or 99 something that had to do with this this personal character but yeah it would crash it right like it would it just would not play their episodes or something ultimately they like after years of trying to figure out what was going on

they found the random developer who wrote the code for the Mazda entertainment interface, and he was able to say like, oh, yeah, this is what it is. And the guy who reported the problem to them, like he was an avid podcast listener. Right. Like he had years worth of podcasts. It was like, I don't see how you can ever get through it. Respect. Right?

Yeah. And then the last little bit here that we've got is the book prefers tolerating faults over preventing them, right? Except in crazy cases like security where you really don't want to just try to catch something. But the primary reason is building a system that is healing or curable, right? So it can recover from these faults. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly.

Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. And when I say that they provide the ability to, in one platform, that you can get end-to-end visibility quickly, I am not joking around. So they have a great blog article where you can troubleshoot your.NET apps with auto-correlated traces and logs. And what I mean by that is they have a library to where when your requests come in to your application, then they will tack on an ID. And as it runs through all the various parts of the system, which might not be the same physical machine, that ID can float along with it. And now they can correlate all the logs from all the various systems. And they can say, here was this one request as it went through the system.

And that is super valuable if you've ever had to debug requests as they move through the system. And also super valuable, Datadog just announced a new security monitoring capabilities. And if you scroll through and look at the images in the blog post that I'm looking at right here, it's making me want to drool here. The information is great and it's organized really well, which makes some of this stuff so much easier to see. And they've got turnkey security integrations with things like Node.js and Nginx. So it makes this stuff easy to hook up. So you can start getting the information you need fast and you're able to actually make use of that information. So definitely need to check that out.

Yeah, they've got integrations for all of your favorite technologies. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. Head to www.datadog.com slash codingblocks to see how Datadog can provide real-time visibility into your application. Again, that's www.datadog.com slash codingblocks and sign up today. All right, so let's talk about hardware faults. Because if we're going to blame it on anything, we're going to start with error, right? Absolutely.

So it's obviously going to be the hard drive failure or it's bad RAM or the problem is because of a power outage or Joe tripped on the cable and unplugged the computer. That's going to be the hard, you know, the fault. Right. And those things happen a lot, right? Well, I mean,

there's some crazy, like speaking of, you know, cause I listed hardware, a hard drive failures first. There are some crazy hardware failures that have happened. A hard drive failure, should I say that have happened where like,

have you heard the reports about the, where like they'll scream in the data center and it'll cause uh oh the frequency drives to fail there was one story that came out about like the the data center had an alarm go off and the the alarm the sound of the the alarm caused the drives to fail. There was another story of a guy was able to prove that his RAID array – this was like in a home or something like that. His RAID array would degrade if he screamed at the array. Like he could just yell at it. How do you find that out like okay i mean cool the dude found out that it happened oh oh i think you mean like how did i

find it no no no no like what are you talking about i mean i'm not going to like random parts of the random corners of the internet at one point the dude just look at his radar and just start yelling at it i was like wait this thing seems to be slowing down. I don't, like, that's weird. I'm just saying. But the point is, though, like, those are, I mean, you talk about unexpected, right? If you were designing a hard drive, would you take into consideration the sound levels around you? No. As part of the consideration?

Right. You probably wouldn't. No, that's. levels around you as part of the consideration, right, you probably wouldn't. Now imagine my Hello World app that I'm going to write that's going to be just a simple lambda function that's going to scale out as infinitely as it needs to. Now I've got to worry about somebody screaming in the data center.

And shutting down your app. Totally. One of the things that was interesting here is when they were talking about hard drive failures, and by the way, I think Black Backblaze is the one that will publish their failure rates, which is really cool. We should find out. Google has two. Oh, Google does? Oh, that's nice. I haven't seen one like, you know, in the last 12 months. I haven't gone looking for one, but I have seen where Google has published this same kind of, what do they

call it? There's like a death rate for the drives. So, yeah, I don't know. But so- Mortality rate. They call these things the MTTFs, the mean time to failure. And most, I guess, enterprise hard drives are 10 to 50 years but what that means in real life is a cluster with 10 000 disks should have one disk failure per day like 10 000 disks in a data center

isn't really all that much i mean there are buildings full of these things right so a disk failure a day can cause some problems. And typically, the thing that's gotten interesting with hardware over time, and we've seen this, is you usually solve this by adding redundancy, right? So you add multiple power supplies. So if one fails, the other one picks up. If a hard drive fails, then it swaps over to another one. Hot swappable CPUs, hot swappable drives um you know rate configurations like there's there's all kinds of ways that they've gotten around this with we'll call them single servers right like a piece of hardware and then having additional hardware that bolts

onto the thing to to help with this failover type situation yeah maybe it's a good analogy is uh like hard drives and ram both have like faulty sectors sometimes or various pieces they can't use and if they're fault tolerant then you don't even know about it right it just kind of uh it fixes the errors it figures them out and avoids those sectors because it's fault tolerant but if your whole hard drive crashes or information isn't retrievable because of those then i guess is that a failure at that point? Yeah. At that point, it is.

If it's truly kaput, you're done. But the fault tolerance is exactly what you said, right? Like, hey, don't write to this sector because I can't get to it. You know, skip these. And even error correcting bits and stuff like that. It's crazy how good they work for how poor they work. Right. Right.

And I mean, we're talking about things that spend all day long in some situations. Right. So the fact that they. Maybe yours. Yeah. The fact that they work that long is impressive. Granted, nobody's happy about that when it does fail. But I will add to.

Sorry. But, you know, we've had some random tangents with stuff and I'm like loading up all kinds of links of interest. So, you know, that will be in our resources we like portion. Excellent. Love it. And then here's the other thing to mention, though, is as time has gone on, the whole idea of single machine resiliency, it's not as important anymore as much as companies are focused more on elasticity, meaning, hey, I want to be able to just, hey, if one machine dies, then I can just have another one load up in its place. So it's not as much about single machine failure anymore as much as it is just being able to have something else jumping in its place. I mean, it wasn't too long ago that – think back about like you would buy these big, beefy boxes. But not only were you buying those big, beefy boxes, but you were paying a hefty premium because those manufacturers were guaranteeing like this box is not going to die. Like it's, it's,

and, and if it does have problems, you can do maintenance on it while it's still running. You can swap out components while it's running, you know, so hot swappable like power supplies, for example. I mean,

you were paying a premium for that as well as paying a premium for the support contract for it. And, you know, eventually we as a, you know, people just decided this is getting to be too much, right? And so, you know, that's where you're like your commodity hardware comes in, you know, kind of idea where it's just like, you know what, rather than putting all my eggs in this one basket, let's just spread that out to, you know, I'll have 20 of them. And if I lose one, who cares? And we can thank the cloud for that, right?

Well, I was going to thank Google. Yeah. Because, I mean, that's kind of how they started the whole company, right? Because it wasn't cost effective. I mean, like you said, you can remember back when we were paying a premium, like it was nothing to have a dev server that costs you 60, $70,000. Right. Um, and, and that's not something that works well when you're having to scale like the Googles, the Amazons, the Facebooks of the world. So they're like, Hey, let's figure out how to make this work on cheaper hardware that we can just plug and play, plug and play an entire system as opposed to just a piece of hardware on that system.

Yeah, absolutely. And so now I want to talk about a couple different kinds of errors, basically software errors and human errors. So I'll talk about software errors first. We're talking about the kinds of things that are often more difficult to track down than hardware errors like if your hard drive goes down then it's usually pretty noticeable or your if your ram isn't working then you can get to that pretty quickly but if it's a bug in your software that only happens uh every 17 000 requests or something then that could be much more difficult um so we're talking about things like runaway processes, services that start getting slow, which counts,

so we're not meeting our objectives anymore. Also, like I mentioned before, cascading failures where one thing breaks and it causes another thing to break. And so you might be looking at a secondary effect or you hope there's only two effects down the line from where the real problem actually hit. And these things usually happen by some kind of weird event that wasn't planned for and it can be really difficult. So we don't like software errors.

Right. So how long did it take somebody to figure out that Roku thing? Right. Like, seriously, that's I can't even imagine how maddening that would have been. No. Like. No. That was a bad day for some roku people probably still is a bad day for some people so how do you get all those updated

and you just know that nintendo or game freaks like nah that's you that's on you so the uh other kind of errors is human errors. So humans are the worst. Well, that's a fact. Yeah, I mean, like this is probably going to be your normal errors. These are going to be the errors that you're probably going to expect. I don't know, man. I think both software and human. I think they happen just about as much because there's been many times in my career where I'm like, how did that even get hit?

No, no, no. I didn't say which – I wasn't talking about occurrence. I'm saying these are the ones you're going to expect. Oh, okay. Yeah, fair enough. capturing, right? You know, user input capturing, you're probably gonna be like, oh, well, let me protect against this. They'll probably type in something silly

here or, you know, this is, you know, maybe a phone number field. So you can only type in numbers, right? And, you know, configurations is

another big kind of common cause. Like the other day, I was working with an API that involved two different systems and I configured one right and the other wrong. And guess what happened? I got into kind of common cause like the other day i was working with a api that involved two different systems and i configured one right and the other wrong and guess what happened i got into kind of a weird state because half things worked right and the other half didn't so it was weird to track

things down and figure that out and i was ultimately at fault for that but the system had to be able to kind of understand that something happened and the other part didn't. And it had to make a decision about how to relate that and what to do about it. And oops, that was my bad. My B. It was definitely my best effort to crash it. So the question is then, like, how do we design our systems so they can put up with that kind of garbage? And I think one thing that they hit on that I think is actually really important is just having a good UI.

Like that problem could have been solved, could have been avoided, if maybe that UI had like a test feature. Like when I put in the two configurations, it went off and did some sort of basic check to say like this one worked and this one didn't before it's tried to actually start up and running it. So if I had a good tool around that that made it easier, then that would have been great. And same with APIs, too. Like I'm sure we've all seen like APIs have terrible documentation.

They have terrible function names, terrible argument names. And it's kind of hard to understand. Like one term that I always see in kind of distributed systems is replication. It's like sometimes it'll be replication factor. Sometimes it'll be replication factor. Sometimes it'll be just replication. And the question is, does the number I'm giving you include the source? If I say replication one, does that mean I have one node or do I have two nodes in my cluster? Right.

And that's always kind of confusing, and it's totally different in different systems. And so if you can just make that easy and just like, you know, maybe call it number of additional, uh, you know, the longer variable name, then you can save a lot of people out of trouble. And if you're especially like a big vendor, the big product, then there can be a lot of headaches and a lot of time lost over little things like that. You know, the, the good UI point though, is kind of like with the example that I just gave about, uh, you know, the good UI point, though, is kind of like with the example that I just gave about, you know, like if it was a phone number, you might protect the user from entering letters by only allowing numbers to be entered into it.

I'm sure we've all seen these like credit card fields, for example, where that might be another case where you only allow numbers to come in. But even in that example, though, you would have a field that only allows numbers. But if you don't restrict, have any restrictions on how many numbers, right, or a minimum number of numbers, it's still no good. I absolutely love the UI experience where as you're typing in the credit card number, it'll figure out, oh, this is a Visa or an American Express or whatever. And it'll start – it'll actually put in the spaces that are consistent with – and format the number consistent with whatever that particular card is. Like an entry mask yeah so so like uh you know like a typical visa might be like four numbers space four numbers space four numbers space four numbers right but amex isn't it's like you know four numbers space six numbers

space some more numbers i i don't know but you you know what I'm saying, though? And it's like you can instantly tell. I mean, that's the difference between, you know, like, yes, if you restricted it to just the numbers, okay, that's one level of, yeah, you're getting there. But that other case where you're actually, like, reformatting the number based on and telling, hey, you're entering in an American Express number and you're showing them the format. And then that way it's really clear to the user, you haven't entered in enough digits yet, or you have entered in and don't enter in anymore. And then if you do, then I can tell you something,

you know, hey, you messed up without even having to go back to the server side. Or maybe if you don't enter in enough, I can immediately say, no, no, no, you're not done entering this number again before I even go back to the server side. Right. Yeah, it's so hard. You could be, I don't want to say too smart because it's not smart.

But I remember the time I stored credit card numbers as a number rather than a string and that problems with leading zeros. But another one is addresses. Like if you only set up a form for US addresses and someone comes in with something international that formats things a different way, then that's a problem. Same with names.

That's a big deal. I don't think anyone should be doing first name and last name boxes anymore. You still see it all over the place, but there's people whose names don't fit into a clear first name and clear last name. The addresses has been really great, though. I've really gotten spoiled now where I go to a food delivery place or something, and there's just one box. And as you start typing your

address, it finds it for you. That's the better way to do that. Of course, it's more work, and now you're involving a second system. Actually, yeah, typeaheads were an example I thought they gave in this section of the book did they not was it not this section maybe i don't remember it in this section that's one of my favorite things i think it's further ahead but yeah like the next thing that they had on here is like another way to create a a reliable system in spite of ourselves is create fully featured sandbox environments

where people can go do these things, right? So it's not just they're doing it in production. They've been able to do this and sharpen and figure out what's going to work and what won't in another environment that's basically a copy. Yeah, and you do that too. You'll see mailing list providers

will have things, a way to send a test email to an email address before you send it out to 200,000. So nobody has any excuses for making typos or mistakes in emails anymore. Speaking of which, just sign up for our mailing list. We definitely never have those. You might catch some mistakes. What? Testing thoroughly.

This is Joe's favorite. yep uh things are changing my mind's changing on some things we'll talk about later but uh no third testing is is really good and helps a lot with things like this and it's uh a lot of times so you know if you make a change to code and it's not tested then you know are you you have to like wondering, does your code still support nulls or still support those cases? Are you going back and testing all those every time you make any sort of change that is in the area, whether you think it is or not? So having good tests around that sort of thing is really important. And that's how you prevent, you know, things like human errors from taking out your site. I like this one too allow for fast

rollbacks in case of a problem so kind of a you know a backup plan i'm not huge fan of typically rolling back things i like to roll forward to assuming that the problem is something that you know was a little unexpected and it's quick to do, but having a plan in place can be massive, right? Whether it's a roll forward or a roll back, either way. Well, even, but yeah, but you still need to have time to address, to diagnose and address the problem. So, I mean, it might not necessarily require a rollback if you have like a blue-green deployment schedule or, you know, set up. So you could just say like, you know, if you have like a blue green deployment through schedule or you know set up so you could just say like you know if you're not familiar with with blue green you would have like

two different environments that serve as your production environment and maybe you know you you run on the on one infrastructure on one side of infrastructure and then when you want to roll out an upgrade, you upgrade the other one that is currently offline. So maybe blue is currently online and then you upgrade green and then you swap over to it. So maybe you would have like DNS pointing to one versus the other as an example. Well, technically that would give you the fast rollback, right? Because if anything did go bad, you could just swap back to the previous one that was in place. You swapped out in that example at the, your rollback was a DNS. A DNS switch, right? Yeah. Yeah. You didn't change the code on that

other piece of infrastructure yet because you still need to diagnose what the problem is. Right. Yeah. And then another thing that's so important, like so hyper important, and by the way, this is another vote for Kubernetes, is amazing monitoring, right? Like – I was going to say Datadog. Datadog is a good one too. Yeah, yeah. Totally. cannot stress enough that getting a call from somebody and saying that something is a problem is not the most effective way to do things, right? Like have some monitoring and alerting set up

so that when things do go wrong, you get a notification. And there will be cases where something goes wrong that you never ran into before. Then you should be setting up alerting for that in the future right like having these triggers in place to help you do this stuff is is a major tool in making sure that your systems run as necessary yeah and uh good go ahead i was gonna talk about the next point yeah sure oh so uh good training is really important too uh because mistakes do happen and i And I remember working with customer service people, new people. Something bad would happen, and they would try to fix it and delete the order in order to, oh, I can't create an order on behalf of the customer. I can't fix this.

Oh, well, now we've got a big problem. So we don't have a good way of reliably contacting that person. And so just knowing what to do when something goes wrong and how to kind of basically have some good training and practices around how to use software in cases like that is really important. So reliability on a scale of not so to very so in terms of how important is reliability? Probably just me. It depends.

I hate that answer so much. How important is reliability? Probably just me. It depends. It depends. I was going to say the same thing, and I hate that answer so much. So obviously there's situations where it's really important, like Chernobyl nuclear power plant. There's other times when we might choose to sacrifice reliability to reduce costs. I'll say, too, I've been doing some stuff with the Kubernetes, um, man, I'm all about failing and having Kubernetes restart. So now if things crash and it's just not a big deal because it'll restart it.

And so it kind of saves me some time thinking about stuff. So I'm thinking about what to do in cases and trying to try to catch all these different various problems. So like, as long as I make sure I crash at the good spots and I have some control over that, over when it happens. Yeah, all that's to say that I like crashing. And the crashing can still be reliable if you've got systems set up to enforce that.

And either way, you just got to make sure you're making a conscious decision about this and not just kind of letting things kind of fly. It's important that you understand the system that you're trying to build and make decisions that are in line with that. It almost sounds like you were advocating for like, you no longer like to catch exceptions though of any kind. And I'm,

my mind is still a little bit like, Whoa, wait a minute. What? Yeah. So I definitely like to make conscious decisions about it. We've talked about this a little bit before. I don't like to just let anything throw an exception because then you don't have any control over where your process exits.

And sometimes that could be really bad because maybe you did some stuff that needs to be rolled back or whatever. So I still like things like transactions and things like that. But I tend to do the things that are most important in something like a transaction. So I still like tries and catches and the most important kind of sensitive bits. But now what I'm kind of coming around on is basically just crashing the application, even if it's me just taking an exception, cleaning up after myself, and then throwing another exception. As I say, the application is in a bad state.

A good example here is something I did recently. I kind of had a static initializer for a class where basically you would create like an admin client whenever the class was first called. And it would just reuse that admin client statically. And the deal is sometimes network something or other happens. And anyway, the client has to go out and get another, uh, it needs to do another handshake and basically reauthenticate. So, uh, you know, one way to handle that is like every time you try to use that client, you can check to see if it's still open, it's still available. And if not, maybe you return some sort of exception or something,

or you could just try to use it. And if it can't work for whatever reason, it just crashes. And then the application will shut down because I'm throwing the exception, and then Kubernetes will start it back up again. So, you know, maybe that's just being lazy, but I liked being able to just kind of think about it that way. I kept it all contained in one class, so it was all pretty small. But it was just nice to be able to kind of have my code just reflect the logic of what was happening and not be so concerned with checking every little possible educate case for

something that didn't matter that too much to me so one thing worth calling out here on what he said is you made a conscious decision to say, I'm more concerned about ease and understanding than I am speed or, or, or durability of the application, right? Like I'm going to rely on some external tool, which might take longer to kill the old one off and start up a new one than I am about just because it would have been faster to have the retries in the application, but it complicates your code and that kind of stuff. So, so this is one of those places where you made the conscious decision for the trade-off, right? Yeah. And you can definitely argue that it could have been handled better and it absolutely could, but like every piece of code I write,

I don't try to, you know, to A plus it because there's some things that are much more important than others to get right. And so adding additional complexity for anything is you just got to understand the trade-off. So this is a case where in a perfect world, maybe it would have kind of been done to the nines, like A plus perfect and then very explicit. And like any programmer comes after me could have understood that I had thought about this and had decided to let this error go if I had been more explicit about it. But there was something nice about just going to the class and seeing the little one or two liner method that I was actually trying to do without having

all this to kind of try catching three miles of comments explaining, you know, why we need to check and how, you know, every seven days of the service being up, it might have to reauthenticate. Right. And I should mention too that this is probably something

that is going to happen maybe once or twice in a year. The service restarts and it's minor anyway. So it's all about it depends. So this was a case where it's okay. And if I'm wrong about how often it crashes and how much it gets used, then I will surely pay the piper. And when I get that null exception error, maybe I will add some more stuff should I ever need it. Well, I think one of you wrote some questions here. Yeah, I just kind of want to reiterate that kind of after listening to this episode or

the next couple of ones, just think about your system. So basically, if you use SQL server, think about like how reliable you consider it to be and why you consider it to be that way. Why do you have those feelings? So if you use elastic search, what kind of reliability assumptions have you made about it? And have they kind of made about the requirements that you're placing on it?

Same with like MongoDB, you know, like just, I think it's good practice kind of take a moment to think about the things that you interact with and things that you build and understand the decisions that you made and they made to get you where you are. All right. Well, with that, like I said, we'll have a lot of links in the resources we like section because unlike normal, we might've gone on a tangent or two.

And so, uh, you know, I wanted to make sure that we captured some of those things that we were talking about. And with that, we will head into Alan's favorite portion of the show. It's the tip of the week.

All right. So, uh, I will go first. And since, um, Joe says he no longer likes tests, I'm going to convince him why he should with a, uh, in unit specific, uh, tip here or, or really advocate for something. So, um, we've talked about, uh, parameterized tests and, and like how that's a big advantage of using like an in unit or an X unit over, um, like an MS test, for example. And within unit, you can also do, um, so you can, you can use just the test case attribute and then provide the parameters in there,

but that's only going to work if the parameters are compile time constants. But if you need to create an object for anything, then you can't use that. But what you can do is you can provide a test case source, and then that thing, you're going to pass into that thing the name of some IEnumerable type, right? And inside of your IEnumerable, you can have a return statement or multiple return statements where you'll yield to return back whatever your new object instance is. And while it's perfectly valid for that test case source to be something like an IEnumerable of my fancy object, I'm advocating that you shouldn't do that. And instead, your test case source type should be of I enumerable test case data. I'm sorry. Yeah. Of type test case data. And the reason why is that in test case data, you could then put in your, uh,

my fancy object, you know, as my example, you know, you could create it and put it in there, but test case data has specific, uh, you know, has could create it and put it in there, but test case data has specific, you know, has, has additional properties and methods on it specific to the testing framework. Namely, there's like, for example, a dot explicit method. So you can have, if you needed to have some of the, uh, data points that you would be yielding to be explicit for some reason while others aren't, or maybe you want all of them to be explicit,

you have flexibility like that that you wouldn't have if you just had like a I enumerable of my fancy object. That's nifty. Yeah. Yeah, very nice. I mean, it's not Kotlin, so I joe's gonna be like yeah i was trying to try not to say anything yeah reason 498 why i prefer kotlin i don't

have to deal with test case data uh yeah uh so uh my tip of the week is db-engines.com. I don't know if you all have ever seen this or run across this, but it's, um, a website that, uh, ranks databases and I have been able to figure out exactly, oh, they have a link here that talks about how they, they rank it, but they actually come up with a, basically a number based on number of mentions on websites, uh, general interest in the system based on Google trends, job board offerings, relevance in social networks, stuff like that. And it ranks databases, which sounds kind of boring, except you can realize it's also got a lot of information that you can kind of pivot on. So if we wanted to say, we got a couple different categories here, like relational,

key value, document. We talked about graph today, so let's do that. So now I'm looking at the most popular graph databases, and I can go in there, and anyone want to guess what number one is? Graph database, Neo4j. Yep, number one, with a score of 50, which is up this month, and number two is Azure.

Azure. Azure Cosmos DB at 31. That's quite a gap there and then after that and everything else is like five and below so if you don't know much about graph databases this is a good way to come in here and say like okay if i wanted to learn about graph databases who should i start with like well here's some pretty good evidence on which one is uh is a good one to start with and then if you drill into one of those, like for instance, Azure Cosmos DB,

it says it's multi-model. So we actually click into that. We can see that it's selected as primary. It's got four categories. It's a document store, graph database, key value store, wide column store. And you can just go crazy in from there so just about anything that you want to uh to kind of to look at like final world libraries uh languages and sports uh you can

kind of drill into it and look at here so like um the other day i was talking about trying to figure out like a olap graph database and unfortunately they don't really tell you which ones are uh lap i've been able to figure that out but it's something you can kind of figure out pretty quickly by just opening a couple different tabs and kind of scrolling through and trying to read about like you know which databases would be which graph database is more kind of tuned for like counting data rather than getting individual entities back and i don't know any better way of figuring that out aside from using basically this one site, which is in English and German. Yeah, it's a really good site.

Well, this makes it sound like going back to our relational databases, that you should spend all of your time on Oracle. Right. Yeah, Oracle is number one. And I just talked about how nobody uses it and everybody hates it, and it's like number one by uh you know a fair bit yeah top five are oracle in this order oracle my sql sql server postgres and db2 yep no you see db2 i see mongo no no are you looking at relational yeah you got to click

on relational okay you didn't do all of them. Oh, by the way, on the graph thing, this is interesting for anybody that didn't know this. And this is not my tip of the week, but it's cool to know. If you want to play with graph databases and you have SQL Server, SQL Server actually supports graph inside it. What? Yeah, yeah. Oh, yeah, it's listed as a secondary store. So you can do graph in document store. It is, and really it uses relational tables to do it. What? Yeah. Oh yeah, it's listed as a secondary store. So you can do graph and document store. It is, and really it uses

relational tables to do it. I've actually seen a talk about how that stuff's done, and it's interesting. I mean, I probably wouldn't use it for my graph database if I had a choice, but it's possible. Like, it's the hammer, right? You can do everything with it. So basically the point is, next time Reddit is

down, go to db-engines.com. Yep. And it'll give you something to do while you wait. And find your ranking. Yeah. All right. So my 12 tips of the week are. So the first one, what are you on, Joe?

Are you on a Mac right now or are you on a Windows machine? Windows right now. Do you have Commander installed? Yep. All right. Open that up. Outlaw, you're on a windows machine windows right now do you have commander installed yep all right open that up outlaw you're on a mac open up terminal so here's something i accidentally found out the other day and i was so excited when i did it i think i thought i was on a web page and i went to hit ctrl r to refresh the page and it didn't work and i and i was getting mad at it and i look over in my command window and there's something weird happening and it didn't work. And I was getting mad at it. And I look over in my command window

and there's something weird happening. And it's got this like little search prompt type thing. Now I know I've seen you do it outlaw. I think I've probably seen you two do it also, Joe Zach, is if we're in the middle and we're typing in a bunch of commands, Docker is a perfect example. You've got 5 billion Docker commands

that you've typed in, right? Typically the way that you get back to them is you hit up arrow 5 million times until you get back to the one you want. You can search for recent commands. So if you hit, if you're on a Mac, open up terminal and do controlR. You can start typing a search, and it will bring up your most recent one that matches that. Okay, well, let's say that it was Docker Run, and you had four or five of those things you ran. So the most recent won't get you what you want. Hit Control-R again. It'll take you to the next one, previous.

And Control-R again, the next one. Just hit Enter, and you run it. It is amazing. So it searches your last commands that you typed into your terminal. Now this works as far as I know in bash. So like get bash, it works on terminal on Mac and it works on commander and probably Kana move. Amazing.

Absolutely amazing. By the way, since we're, since you're bringing up Mac, uh, by the way since we're since you're bringing up mac uh by the way we you know when we were talking i don't remember how far back it was though we were talking about favorite shells yeah right and bash but have you updated i'm assuming you've updated uh catalina right and you've seen that now the default is going to be switching to ZShell. And so they'll give you a message, like if you haven't already changed your shell, that you should go ahead and change it because pretty soon ZShell will be. Oh, that's cool.

No, I didn't know that. I always use iTerm2 on Mac, so I probably would have never gotten that message. Oh, really? Yeah. Why? really? Yeah. Why? It's good. It's better than Terminal. It's like Terminal on steroids.

It's amazing. Terminal's pretty amazing. I don't know if you know this, but if you- Have you done iTerm2? If you press Control-R, you can search through your command history. It is like, seriously, when I accidentally did that the other day. I was like, what is this magic that I've unlocked? Right.

Like, I don't know what I did, but I need to figure it out. And so I just started pushing buttons until I figured it out again. So, so yeah, that one's that one truly made me smile. Joe, I saw the look on your face when you did it. It truly is magic, right? Like, yeah. How have I not had this in my life all these years? Um, all right. So the next one, we were talking about hyper expensive KVMs

last time, in case you wanted to mortgage your second born or anything like that, you could go buy these, these KVMs that we talked about that were anywhere from 400 to 500 and something dollars. Right. And Joe Zach and I basically went off on a tangent about how much we hate KVMs because none of them work well. So here's something cool that I don't remember how I stumbled on it, but I did. There is a thing called Mouse Without Borders that somebody that works at Microsoft actually created that is a software KVM that I believe will work with up to four machines. So as long as they're on the same network, you install the software on the four of them and you can digitally have a KVM so that you can work between those four different machines with just the software installed.

From what I understand, it works really well. I haven't tried it yet because I forgot about it. But this is basically like you have to be able to see all the displays at the same time, though. I don't know. I cannot. I cannot attest to any of it because I haven't tried it out. All I do know is that it apparently will work between them. I don't think you do have to see all the displays at once.

I think that's the whole point of it is it is truly a virtual KVM. Well, because I've seen I've seen software like this before, and the point was that you would move the mouse until you got to the other screen. So you were using, because there was a piece of software similar to this for macOS 10 years ago, right and and but you had to i don't know you had to be able to see the other you had to be able to see both monitors so you weren't sharing a monitor is my point i don't know how this one works i know that it shows a keyboard and a mouse um

don't know about the monitor thing i do know that i tried to use the stuff that was built into our lg 34 inch ultra wides and i hated it like i couldn't i couldn't do it i don't know wait what you hated what so our our 34 inch lg monitors can't they actually would allow you to use the monitor as a as a pass-through kvm for your attached devices and i tried the software and i never got it to work exactly how i wanted it to. And I think it was for when you did the split screen of the HDMI inputs or whatever. But anyways, so this is there. I haven't tried it out.

I do know that they're pretty forward about what some of their issues are. So you might want to look at that and find out if they are. But I thought it was worth mentioning. It frees a lot cheaper than four or $500. And then the last one I have here is from our buddy, Micah G over there in Slack. There's this cool thing that he found that is called USQL. It's a universal command line for Postgres SQL, MySQL, Oracle Database, SQLite 3, Microsoft SQL Server, and many other databases, including some NoSQL ones. And it's, again, it's, if you think about like SQL command for SQL Server, it's basically that type of thing, right? Like it's a command

line thing where you can issue queries to all these different RDBMSs and non-RDBMSs like NoSQL databases. So really cool. I mean, if you work or interact with a bunch of different data systems, this might be super helpful to you. So pretty neat stuff. And that was it. I truly didn't have 12. I think it was three.

Alright, well, I hope you enjoyed the show. We talked all about reliability and designing data-intensive applications. And we also had news. Very exciting. So make sure to subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcasting app. And while you're up there on CodingBlocks.net. No, go ahead. But, I mean, you know, I mean.

Oh, yeah. No. Now. It's your turn. Now. And be sure to give us reviews by visiting codingblocks.net slash review. And while you're up there at codingblocks.net, check out Shownut's examples discussion and more. And I definitely get to say this part because, you know,

senior feedback for any questions to Slack at Joe. What language did you just speak in? Well, he says it like really fast. So, I'm not used to saying his part. So when I tried to say his part, I obviously failed. Thank you for calling that to our attention. We have come off the rails. So yeah, follow us on Twitter at Coding Blocks and head to CodingBlocks.net where you might find a page or two of interest.

And, you know, all your complaints sent to Joe. Hey, that was a fault, not a failure. That was. That was a fault, not a failure. Amazing. Pretty reliable.