Microservices Fails | Rubber Duck Dev Show 107

[00:00:00] Speaker A: Hello and welcome to the Rubber Duck Dev Show. I'm Chris. [00:00:02] Speaker B: And I'm Kreston. [00:00:04] Speaker A: And today we're going to talk about microservices fails, which is something I can bitch a lot about. But before we do that, week in Review, how was your week? [00:00:13] Speaker B: Unbelievably busy trying to keep plates spinning and not falling. And it's been a real struggle doing some yeah, I mean, I'm just basically consulting here, application stuff here. I'm pushing forward my new course and doing things related to that. This is my postgres course on performance optimization. Yeah, there's just a lot of stuff going on. I can't even remember something specific. There's just been so many things that's been going on. I'll try to think if I remember something. How's your week been? [00:01:02] Speaker A: Also very busy, and it's going to be a busy weekend. I'm actually off of work tomorrow, so I have a little bit of a compressed work schedule. But I'm off because my youngest daughter is performing at Ren Fair. So I'm going to RenFair all day tomorrow. And then Saturday my nephew's wedding is happening, so I'll be there all day Saturday, and then I'll go back to work. [00:01:30] Speaker B: No break for you? [00:01:32] Speaker A: No, so I'm busy, and then I get a break to be busy again. So this is going to be I think I'm going to be a tired puppy next week. But those things happen every once in a while in life, and you just plug on. [00:01:50] Speaker B: Thursdays are really busy because that's when I tend to record scaling postgres as well as we record this show. And I have all the other work going on at the same time. And now suddenly my dog I had to bring to the vet for some issues. She's fine, but still, it was just there's two to 3 hours out of the day. [00:02:16] Speaker A: Yeah, I had to go clothes shopping this morning because to get ready for the wedding, I realized, oh, yeah, I've lost so much weight since the last time I wore dress up clothes that I don't have any dress up clothes that fit for a wedding, so I can't go in shorts and a T shirt. So spent a couple of hours clothes shopping this morning, which I absolutely. [00:02:43] Speaker B: Hate. [00:02:43] Speaker A: That, but got to do what you got to do anyway. Microservices fails. All right, so let's first, before we get too deep into discussing it, let's kind of define what microservices are. So what does that mean exactly? [00:03:04] Speaker B: Well, I've never used them, so you probably have a better or more accurate description of them. I did find one that it's basically small services, and maybe each is running in its own process or two and just communicating, maybe using an Http protocol. So maybe you have separate services and containers and they kind of do one dedicated job, one service as a part of your application. That's my interpretation of it. But again, I've never used the architecture. [00:03:49] Speaker A: Yeah, that's kind of what I look at them at as is non monolithic apps just taking like extracting a set of things into little bits and pieces that sit all over the place. I've heard some people term this kind of like SOA or service oriented architecture, but you're calling a bunch of different services instead of having a monolithic app. I think serverless stuff kind of fits into this a little bit. But it's just I've got this little app that does one little thing. Like, let's say I have my Login app and all it does is logins and I have my scheduling app and all it does is processes, schedules and all these little things. Talk to each other. And I've got 100 of them all over the place. And every time I got it numb some new function in my product, I just build a little app that just does that function and then provision it and have everybody talk to it. So that's my take on what we're talking about. [00:05:06] Speaker B: It sounds like essentially modules in a normal right, monolithic application, instead of breaking apart things into modules, you break them apart into actually independent apps. Mini apps. [00:05:21] Speaker A: Yeah. [00:05:23] Speaker B: Which sounds like a nightmare to me, but that's me. [00:05:26] Speaker A: Well, yes, we'll get to that. It doesn't only sound like a nightmare to me, it is a nightmare for me currently, like now. So we'll kind of expand on that as we go. But the reason we came up with this topic, or you came up with this topic, is because you had read some articles and some of these articles were a few months back, but it was kind of interesting to look at like DHH was talking some about this and some other folks. So can you give us kind of a rundown of what those articles were? [00:06:12] Speaker B: So the one that kind of caused a whole bunch of people on social media to write additional things or to do YouTube episodes or whatever was the Primevidech.com website, which is Prime Video, which is part of Amazon, posted a blog post that was titled scaling up the Prime Video Audio Video Monitoring Service and Reducing Costs by 90%. So that was the title. But in the subtitle is they moved from a distributed microservices architecture to a monolith application that helped them achieve higher scale resilience and reduced costs. So basically they were using the microservices tooling of AWS, like their gosh, their lambda functions, they were using serverless, they were using lambda functions and s three buckets and all this architecture. And then that was prevented them from scaling to where they want to be. Like they got up to 5% of their goal in terms of where they wanted to scale to and they basically reexamined and reengineered it and basically rebuilt it as a monolith and they hit their performance goals as well as reduced their costs by 90%. [00:07:46] Speaker A: Gee. So what's the benefit of service oriented architecture then? I don't get it. I understand it from the whiteboard perspective, from a theoretical standpoint, it seems like it would be a good thing. You compartmentalize this stuff, and you have this app only does this thing. So if something goes wrong with this thing, I know right where to go. But from a practical standpoint, what you end up with is the same kind of theory that generated the concept of DLLs back in the windows days when you were doing well, they still have them, but there was a term for the first half of my career called DLL hell. And it was kind of the same thing where you just had these little bits all over the place, just getting confused all the time, and the concept of, oh, I can just update this one DLL and deliver it for a patch. Worked in theory, but almost never worked in practice, except for very nominal cases of things. And that's kind of what I'm seeing in the real world for microservices is sounds great in theory, but we're now in microservice Hell because where I work, it was set up as microservices, and we've got a little login server, and then we've got a little authentication server, and then we've got this and this and this. Well, I'm running into all kinds of problems, not only from, well, I'm not running into cost problems. That's not my department. But there are cost issues associated with that. But what I run into are troubleshooting tracing, maintenance problems. It's a nightmare to keep all that stuff straight. And then I've been trying to convert things to Rswag so to get our documentation, our API documentation over. But that's a nightmare because in order to let people actually use the Rswag, because with Swagger, you can actually set it up so that you can do the calls, do real calls, and actually practice with it on the documentation. But in order to do that, you have to call the authentication server because we have to give you OAuth tokens for your API calls and stuff. Well, that's problematic because it's sitting on a different server. So there are cross server problems and restrictions on Web pages and I think some with Swagger itself. And so trying to figure out a way around that has been a real nightmare. And it's all because this distributed microservices service oriented architecture stuff. And frankly, I'm not seeing any benefits to having that there. All I'm seeing is problems over and over and over again. And it's the same thing that I ran into when I was doing desktop apps 1015 years ago with DLL Hell because it's too hard to keep track of all these things. And then if I have to update this one little service and it interacts with another service, well, now I got to go open this other code repo and make a little change there, and then I got to go open this other one, and I get this domino effect of repos having to be changed. [00:11:41] Speaker B: And then you have dependencies based upon that. So you need oh, I need to have this API's change to be in place before I can put the change in this other microservice. Before the other microservice can do what it needs to do. Yeah. [00:11:58] Speaker A: And when you're in a big company, what ends up happening is, okay, well, in order for me to change this thing that I'm in charge of, I have to get this other service changed that I'm not in charge of. So I have to contact another team and get them to change this thing, which means they have to put it in their rotation, and until they get it changed and updated and deployed, I can't do the thing I need to do. And so it's a mess. Maybe it works for little one person teams who have, like, two or three. [00:12:27] Speaker B: Different services exactly when you should. [00:12:32] Speaker A: Right, but why are you doing that services? [00:12:34] Speaker B: Exactly right. [00:12:35] Speaker A: So I fundamentally failed to understand why this was a thing. Why this was a thing ever beyond a whiteboard, because I've never seen it work past a whiteboard in reality. [00:12:55] Speaker B: That's a good question. I wonder where it presumably works. Well, here's the thing. I think in the example of this AWS excuse me, I should say it's Prime Video. It's not necessarily AWS isn't doing it because they're part of Amazon. They're using AWS, but it's actually Prime Video that did this. I think they reach for microservices prematurely. I think you should start with lack of a better term, a monolith, and build up to the point at which you get pain. And then at that point, is micro service something? Makes sense. Well, but even then or is it macro servicing something? [00:13:45] Speaker A: Yeah, even then, if I was going to break things out, I'd be going in the direction of plugins or gems, shared libraries, not microservices. Which I get that in a lot of cases. That may be hair splitting that distinction there. [00:14:04] Speaker B: Not necessarily. But here's the thing where I think a surface I remember back in the day, 37 signals had campfire and base camp and backpack and all these different applications they said, all right, we're going to make but they had each had their own login. And then I think people were complaining, why do I have to have a separate login? You're the same company. So they actually came up with a login server. All right. I see that as a reason to have a separate login service so that people get authenticated in one place, and then they're passed off to whatever they have licensed to. Like, if you're only using campfire or backpack, whatever it is, then you do use the one login service, and then you get passed upon to that particular application. So I think that's an example where and I wouldn't call that a microservice. It's more of a macro service. It's a bigger type thing. I think that makes sense. But separating everything, I don't know. I don't get it. [00:15:08] Speaker A: I can tell you from first hand experience, it makes a nightmare. It's gross. And we're actually spending a good bit of time trying to collapse some of that stuff because it's like, what why do we have a platform that is the database talker, right? And it's kind of the hub for all the spokes of these different things, but it doesn't do some of the database. We've got some of the database things split out to microservices. And I'm like, okay, I think that's. [00:15:47] Speaker B: Normally how it's done. Well, again, granted, I haven't done it, but no, I'm saying I thought typically each microservice had their own database. [00:15:57] Speaker A: Well, yeah, except that it doesn't always like the login server does. The login server has its own database, and some of the microservices do. But what ended up happening is the microservices got so ingrained early on that even things that were talking to the primary central database started being partioned out into microservices. And then it started to get into a mess where all right? The main platform program does some talking to some of these things, and then this microservice does a lot of talking to some of the same things. And so now, once again, we're in a situation where, oh, I got to change something on the main platform. Well, I can't do it until we change this other thing and you get this ripple effect of gosh, now I got to go through 13 different repos and track down all the places where this is, oh, hey, I'd like to trace this problem. Well, I can only trace so far because once it gets to this point, it jumps to a completely different repo. [00:17:12] Speaker B: Yeah. And the other thing that when I'm looking at this that seems not right is that with microservices, basically your communication now has to take place over the network using Http, which is not an efficient protocol. I would call it a reliable protocol http TCP IP I would call it reliable, not necessarily very performant compared to one ruby process. Talking to another ruby process on the same box. That's going to be enormously. More performant or not even. But how many times do ruby processes talk to each other? I mean, it's more frequent that there's something that's within the same ruby process that memory saved here, exchanged there, and whatnot right, that's going to be dramatically faster than communicating over an Http call. [00:18:17] Speaker A: Yeah, you make a good point. I don't see a benefit of splitting a lot of things out. The only thing that I've ever seen really make sense for this is like you were talking about before, where I have a bunch of disparate products that I want to have a singular login to, but even then, I think there may be better ways to handle that. But I could give that one that makes sense. And once you get your login. [00:18:54] Speaker B: And again yeah. And I don't call that a microservice. I call that more of like a macro service type thing. [00:18:59] Speaker A: Yeah. And once you get that login service stood up, you're not going to have to make changes to it a lot. Your other services aren't going to depend on, okay, well, if I want to change this thing over here, I've got to make changes to the login to support that's not going to happen very much. And login is such a common thing that you're not going to have to uniqueify it very much across different products. It's going to be the same for every product you do. So that makes sense to me, but much else doesn't really. I mean, there are other systems like that that I could see. Maybe you pull those out. I can't think of any good examples off the top of my head, but I'm sure there's something but I think like you said, it just got too small. We shouldn't be micro servicing this. That's what models are for. [00:19:59] Speaker B: As I'm also thinking about this, I think it's a problem with tight coupling. So if you have something that's very tightly coupled, then you're running into this dependency problem where, hey, I need to change this service to use this because it relies on this. It's like if you can architecture your solution in such a way so that there's loose coupling. Like, again, there's very few interactions with a login server. I would imagine that it's just like authorize this or not. And you're not constantly all the features in an application aren't going to be constantly contacting the login server for different things. [00:20:33] Speaker A: Right. [00:20:33] Speaker B: Unless you somehow do some sort of authorization with regard to it. But exclusive of that, it should be very loosely coupled and I think coupled and I think that it can work if you have, again, more macro services. [00:20:49] Speaker A: Potentially, yeah. But even with the loose coupling, you still run into issues with maintenance and troubleshooting and conceptualizing the entirety of your product code. [00:21:05] Speaker B: And I'm not advocating for that. I'm just saying that's the only way I would. [00:21:11] Speaker A: Yeah, the more tightly coupled you are, the worse that's going to be. But even if you have perfection of loosely coupled code, I still wouldn't do it for most cases because the maintenance and troubleshooting aspects of it, not to mention the cost aspects of it, with the way hosting costs have gone, that quickly spirals out of control. We've done a show on that with the costs of stuff. I can't make a good argument for most cases of microservices. [00:21:57] Speaker B: Maybe we should have researched why microservices before starting the show. [00:22:04] Speaker A: Well, or we can ask the audience, why do you have good reasons for microservices other than login? We'll give you login. I get that that one makes sense to me. But other than logins, how are microservices helping you? Do they make sense to you? They don't to me, but maybe you can convince me. I'm always willing to have my mind changed. So throw in the comments below what you think about that because I really don't get it. I never have. [00:22:45] Speaker B: Now, what's interesting about this with what they were doing, going back to the performance of the system is one of the main reasons they stopped is because they were using serverless functions and they were passing this data around. They were storing stuff in an S three bucket. Then they were pulling it out again and they were doing all of these process things using very well, I mean lambda functions and stuff to do the transformations and everything. But there were presumably network round trips or all this stuff happening that was hurting performance and cost a lot of money to do the processing. Whereas they moved it to a they said an ECS cluster, which not sure what do you remember what ECS is? I can't remember basically, I thought they said they put it on an EC two instance and essentially and now everything took place within the process memory of the instance. So all of these things that they were passing around to this service, that service across the network now all happens in one machine and everything takes place all at once. And that's how they got the 90% savings because again, like I said on the cost episodes, just buying an EC two servers cheaper than dirt because it's a commodity, right? And so many other people can provide servers and yeah, they just ran everything on that and then that's how they got the 90% cost savings as well as far greater performance to meet their needs. [00:24:38] Speaker A: And so the pendulum swings back again. Get to DLL hell. Stop doing that. Hey microservices, stop doing that. I don't know. We've got world history classes. Should we have programming history classes? Should those be a thing in school? I'm just wondering. [00:25:03] Speaker B: I mean, even general technology because the technology keeps on yoyoing too. I think it's another generation, it's a history problem because one generation doesn't learn the I was going to say the trials of the past, basically what the previous generation learned. Yeah, it's like, I think the most recent generation, I can't remember what they're called. I mean, there's Gen Z, but I think there's even a newer one or whatever, but they say, hey, I got a new way of writing where you write but you don't take your pen off of the paper. And us are like you're talking about. [00:25:47] Speaker A: Curses which they don't teach anymore, but hey, somebody will come in with exactly. [00:25:53] Speaker B: But now they've found it and they think they found something new. [00:25:57] Speaker A: All these thoughts been thunk before. [00:26:01] Speaker B: And. [00:26:02] Speaker A: I mean, I'm all for let's think of new things and let's investigate and come up with some new stuff. But man, I just keep seeing over and over and over again the pendulum swinging back and forth and the stuff I was dealing with the first ten years of my career, and then it pivots the next ten years of my career. Now it's going back. Yeah. I mean, maybe we ought to switch to a history show or so. Tech history show or something, because we keep talking about these concepts that just. [00:26:38] Speaker B: Bounce back, and we are imparting history. You're talking about DLLs. Now, someone say some program watching us may say, what the heck is a DLL? [00:26:46] Speaker A: Right? Yeah. Go down that rabbit hole. Good luck. And like microservices, DLLs, ton of cents on paper from a theory standpoint, absolutely beautiful. Put them into practice, they choke. And that's kind of what's happening. [00:27:08] Speaker B: That's a very poignant phrase in theory, because in the blog post from Prime Video, they said, in theory, this will allow us to scale each component independently. However, yada, yada yada. And then DHH David Hannemier Hansen jumped all over them and said, took that phrase, and he says, that really sums up so much of the microservices craze that was tearing through the tech industry for a while. And he says, quote, in theory. So it's where the rubber meets the road that it fails. [00:27:53] Speaker A: Right. You got to have theories before you can have practice, because you got to find out. But I think there are two things that happen with stuff like this, and this is a little more of a general rant than just microservices, but microservices is a good example, is that people come up with a theory and they forget about A, they forget about fail fast, fail often. So just try it. If it doesn't work, either amend it so that it does work, or move on to something else if it can't. [00:28:35] Speaker B: Work, as opposed to double down. [00:28:38] Speaker A: Right. And B, I think you end up with this kind of I don't want to be rude. I'm not trying to be rude or condescending with this, but I don't know of a better word. It's just kind of this hive mind, fanboy kind of vibe that happens where, oh yeah, this is the greatest thing since sliced bread, and everybody should do this. And that's what gets propagated. And without a lot of critical thinking in all cases about, is this really a good idea? Long term, I think there's a lot of this is the coolest, sexy thing this week, so let's do it. Kind of the same concept that was happened with all the JavaScript libraries. It's like every other week there's a new freaking JavaScript library, and it's the best one ever until next. [00:29:31] Speaker B: And I think DHH either says this or alludes to it, but I think people are watching and listening. What Facebook does, what AWS does, where these gargantuan companies with thousands, if not tens of thousands of developers are doing, and they say, oh, they're doing we, they're doing that, we should do it too. But the problem is that either won't work at all or completely falls apart. If you're talking about your company of, say, three developers or four developers, right? [00:30:09] Speaker A: Yeah. You can't support that without this thing, without 1000 developers. So when you try to scale it back to ten developers, you're screwed. You also find out when you get into these big companies, like if you go to work for one of these big companies, and I'm not trying to pick on just Amazon, it's just any big company. The bigger a company gets, the more it has inefficiencies built into it and the bigger the boat is, the slower it is to turn. And so they start lagging behind best practices and they're like, well, yeah, it would be better to do this thing, but we've got this thing. And to try to get everybody in the company to change would be a monolithic task. So no, and you end up with a lot of inefficiencies. But if you look at that from the outside, you're like, oh, this works great. Well, yeah, until you realize that they have to keep hiring people to deal with it. [00:31:08] Speaker B: Yeah. The pattern is they're a successful company, what they're doing is the best thing to do. So people copy it and maybe it's not the best thing to do. [00:31:19] Speaker A: Right. I mean, it could be. Some of their things are the best. [00:31:23] Speaker B: It could be for them. It may not be, but it could be for them. But it might not work at, say, a smaller shop. [00:31:32] Speaker A: But I can tell you for a fact that in larger companies. [00:31:39] Speaker B: There are. [00:31:40] Speaker A: A lot of it's not the best thing to do, but that's where we are. [00:31:44] Speaker B: Exactly. [00:31:45] Speaker A: Because it's so expensive to change to the best thing to do. If I'm a one person shop and I want to change to a different project management system, it's not that big of a deal. I mean, it's a little bit of a pain in the butt, but do. [00:32:02] Speaker B: It in a weekend, right? [00:32:04] Speaker A: If I perceive that the payoff is worth it and then I'm going to be more efficient with this new project management system, I can just change it. Well, if you've got a project management system that 1000 people are using, that's half a year to start changing that over, it's extraordinarily expensive, it takes a lot of man hours. It may bring us 500% efficiency improvement, but it's going to take too long and cost too much to get there. Not only with money, but with opportunity costs. And then somebody from the outside looks at that and say, well, this is the project management system that they're using, so it must be the best one. Not necessarily. Think about that. Also, it could be the best one for 1000 people. [00:32:57] Speaker B: Exactly. Yeah. [00:32:58] Speaker A: But not for one. [00:33:02] Speaker B: The other thing that I think is causing these microservices is that I've heard from more than one source or more than one place that, oh yeah, this service is built in Haskell and this service is built in Node. So within the same company they're using different languages. And this goes right, which to me seems insane if you have, let's say, more than two Nths alludes to this as well. Because now suddenly you hire a person who wants when you have microservices, it kind of gives the developers license to, hey, Rust is cool, let me try doing this in Rust or hey, Go is cool. I want to write the new service in Go as opposed to everything else is in Python or whatever it is. So that tendency to say, hey, what can I build here and put on my resume is the thing I'm going to write it in for the next place I go. So then without strong management in place that says no, our languages are this and this, this is what you get. Now. I was surprised, but actually DHH in one of his articles was know if you need something blazingly fast, something faster than ruby, then okay, well, maybe you could have one other language and maybe you build again. He didn't call it a microservice because I interpret that as many different services, but one dedicated service where you need high performance. All right, maybe you do that in a slightly different languages language. You use your Rust, your Go, you're something else, right? [00:34:51] Speaker A: Or just write it in C plus plus, or whatever you got to do. [00:34:54] Speaker B: Whatever. Some compiled language or some functional language that's fast or whatever it is, which I was reading. This. And this goes back to something that I've done with my own product, is that I had built a game analytics SaaS app using Ruby on Rails. And I ran into what I perceived as performance problems scaling up. When I had someone, a company that I serviced was rated the top gain on the Apple App Store. So that sent a ton of traffic down. And I struggled with some scaling problems with that. Not necessarily database stuff, but with Rails and Ruby and getting it performance where I needed to be. So when I was doing analytics for my current app, I said, hey, I was looking at Elixir at the time and I said, all right, I'm going to build it in Elixir. So I did that. So it's kind of weird that DHH said that, but that's what I literally did. But however, to this day, I kind of simply regret doing it because I'm like, yeah, but now I got to have this other language that I got to remember certain ways to build it and stuff. So even though I've done it and I kind of have always regretted kind of doing it, now I don't know what the performance impact would actually be if I had it in Ruby on. [00:36:41] Speaker A: Mean we and we've run into that too. And that is a danger. That's a good point, is that when you have these microservices, people. May decide, oh, I want to write this one in this language. Well, we're a Ruby shop, primarily, but we have one of our little services got written in Go. One of our little services, a couple of the services are serverless, so they're foreign mess to me. And then we have one or two other languages. Then on the front ends, some of them were written with React, some of them were written with other JavaScript frameworks. What ends up happening is the thing that's written in Go. It's a pretty important service, but it doesn't have to get messed with a lot. But every time it does, there's only one person in the company right now that knows Go. Yeah, so that's the guy. Hey, we got this emergency fix that's got to go out. I don't care what you're in the middle of, you got to fix it. Sorry. Or we hire another Go programmer for this one thing, spend a bunch of time getting them ramped up. When we've got, umpteen, other Ruby programmers, had this been written in Ruby, we could hand that off in a heartbeat. But that's a problem. I'm all for right tool for the right job, but don't you know? [00:38:17] Speaker B: Yeah, I mean, like I said, I could see, I hate to say it not that I hate to say it, I always say that, but DHH's frame work or his viewpoint was, okay, you have one language you love to code in. Of course, this is Ruby, and it's very productive for the developer. But then when you need speed, you could have something else and write whatever service or whatever you need in that, and that's it. And that kind of makes sense to me. Yeah. But no more than two necessary, right? You're always going to have JavaScript, too. [00:39:02] Speaker A: Don't write every service in a different language or you're going to have a problem keeping those up. [00:39:07] Speaker B: Yeah, but I've heard of Organ, like I said at the beginning, I've heard of organizations that had this service was written in this, and this one's in this, and this one's in this. It's like, oh my gosh, how many? I guess if you have hundreds of developers, you can handle that, but still. [00:39:25] Speaker A: Not so well. Let me tell you from experience, that's still a problem with hundreds of developers. [00:39:36] Speaker B: That's where you go to every programmer. Anybody want to learn some Go? [00:39:40] Speaker A: Yeah, they tried that. They didn't get any takers. We were all like, a, we're pretty busy with the workload we've got right now, and B nah, nah, don't need to learn that one. Thanks. We'll happily rewrite that service, though, in Ruby. Just bring it into the monolith here. [00:40:05] Speaker B: Do you think there's a reason that it couldn't be written in that? [00:40:11] Speaker A: No, there's not a reason that it couldn't be written in that. It's just a time and priority thing. [00:40:16] Speaker B: Okay. That's all. Well, I mean, so do you know why it was written in that? [00:40:21] Speaker A: Or is it just, somebody got a wild hair up there? [00:40:24] Speaker B: Okay, all right. [00:40:26] Speaker A: That's the long and short of it, really. It was the hot, sexy new language at the moment. I guess it is what it is, but fortunately, it's not too big a deal. But it can be a huge deal. We happen to have, umpteen, developers that we can work around some of that stuff with if we have to. But if you're a little ten developer shop and you get stuck in that situation, that's a significant problem, you know? So I don't know, I just don't get microservices. But if you're listening to or if you're watching the show on YouTube, leave us some comments. I love to understand if people do have valid use cases in the real world where microservices are actually really helping, especially on the side of maintenance and troubleshooting, because I don't see it. But hey, if you can change my mind, I'm willing to have it changed. Anyway, love to hear from you. Hope you guys enjoyed that. If you did, please make sure to like and subscribe. That'll help us out a lot. Also, make sure you mash that notification bell so that you can get ding donged every time we upload a video. Yeah, I said that. It's okay. Also, you can join us on Rubberductdevshow.com, sign up for our newsletter and find all of our podcasts and videos there. We upload this show every Friday to YouTube, and it goes out to all of our podcast providers. So your favorite provider should have this as a podcast on it. So if you like to listen while you're jogging, running, or laying in your front yard stargazing, you can do that. So we will be back next week with a topic that we haven't decided on yet, but we will let you know. So if you want to keep up to date with that, you can follow us on Twitter X Twitter at Ducky dev Show, and we'll let you know there. You can also join our discord. The Discord link will be in the description below. It's also a pinned tweet on our Twitter account, x Twitter X Thing account. Anyway, we will see you guys next week, and until then, happy programming. [00:43:10] Speaker B: Happy programming.