Coding Blocks - Are Microservices … for real?

Episode Date: August 16, 2021

We decide to dig into the details of what makes a microservice and do we really understand them as Joe tells us why we really want microservices, Allen incorrectly answers the survey, and Michael breaks down in real time.

All right, so Jay, how are we going to do this? Are you going to go in as a Mercy and I'm going to go in as Bastion? Or do you want me to play as Reaper and you be Lucio? What's the plan? Yeah, Lucio. Let's go Lucio Reaper. Is it Lucio or Lucio? Am I pronouncing it wrong?

Gosh, I suck. Oh, we're recording. So this is episode 165. You're listening to Coding Blocks. Subscribe on iTunes, Spotify, because I know that, Jay-Z, you want to do the new opening for now on. Let's cut the old opening too, though.

Oh, so it's a replacement, man. I'm messing up. Uh, okay. Well, we're,

we're on Spotify and Stitcher and iTunes, wherever you like to find your podcast apps. Uh, in case if you aren't already subscribed, if you aren't already subscribed, smash that subscribe button. Um, we would greatly appreciate it. And yeah,

have a good day. What do you call? I got a joke that I heard. Oh, snap. Nice surprise. What do you call a werewolf streamer? A werewolf streamer.

How something it's a like and subscribe. a werewolf streamer how something it's a like and subscribe like and very nice pretty sure I kind of goofed that up a little bit but I still like it I like it too you can find we should have a page for jokes

that would be amazing if we had all the jokes and if we did have that page it would be on codingbox.net where we have shown us these levels of discussion and other things. And you can fit, send your feedback questions and rants to comments at coding box.net. You can follow us on the Twitters at coding blocks or head to www.coding blocks.net.

And you can find all our crazy social links there at the top of the page with that. I'm Alan Underwood. I'm Lucio. And I'm Reaper. the top of the page with that i'm alan underwood i'm lucio and i'm reaper if we're going with our overwatch character names is that what we're doing yep i think alan messed up then yeah i don't i don't over oh gosh here we go we need to work on that we can't have nice things we can't even agree on anything call of duty man that's where it's. This episode is sponsored by Datadog, the cloud-scale monitoring and analytics platform for end-to-end visibility into modern applications. All right, so, yeah, a little bit of show introduction here.

I guess we're going to be talking about microservices, and if it's a real thing or not, the jury's still out. We're not convinced yet. And we're going to settle it once and for all for the entire Internet to find out. But in the meantime, we like to start the episode off by saying thank you to everybody who left us a review. And I got to say, Internet, I'm surprised because I really did you a solid favor last one by cutting alan and joe short and to as a way of thanking me there wasn't a review so now i feel totally awkward because i thought i was helping so maybe maybe i'll let uh one of them do their deal do the bag later but we might it might just be us here it's probably that's that is probably it for real but

i didn't want to like be negative and call it out like that but now that it's out there i guess we have to talk about it because it's now the elephant in the room thank you but it's back it's back to us so you know if you can this time no i think everybody's on that rick rock thing or whatever it is So, you know, if you can this time, no. Everybody's on that Rick Rock thing or whatever it is. All right. So I'll say to that we have no reviews to cover, please. If you if you do halfway want to do it, that'd be nice.

Also, I have published a couple of videos up on YouTube. They are like quick tips. And I say quick because five because five to 10 minute range. The first two are basically Visual Studio Code tips to help you be more productive and do some cool things. One was Jay-Z's tip for the partial disk. Another one was the HTTP extension and REST thing. So it might be something that saves you a lot of time, so go check that out on

youtube.com slash codingblocks. And, yeah. And, Jay-Z, you got something up there, too. Yeah, I did a video on I'm Loving Me Some Scaffold. We've got a talk coming up October 9th at Atlanta Code Camp that I pitched for showing you what Scaffold is, and I kind of use it

for local development in Kubernetes. It's kind of like a Docker Compose replacement. Love it. And so I did a little trial run of kind of a demo-y kind of thing that I'm kind of wanting to pile it out. So I went ahead and recorded it. It's like 15 minutes long that I really try to kind of hammer home and

focus on the main value of Scaffold. So I tried to make it short. I tried to keep it light. Still ended up being 15 minutes and uh i also use this like weird choral angelic background music so all all the comments of feedback i've gotten so far a bit about that so if you're into that sort of thing this is a great place to go to watch that video if you like that that's actually my favorite genre of music i didn't even realize that you had it there so angelic modern music yes yeah yeah it's really good especially like it when there's like a mosh pit for it you really wings just sprout you just fly over the crowd yeah gives

you an opportunity it's a good outlet for aggression and whatnot so you know it's healthy i like it so so a heads up on this Atlanta CodeCamp thing, like keep in mind, he said he submitted his talk. Like I don't think his has been accepted yet. I submitted two as well. One on why would you use Docker and another one on Flink data streaming or real-time data analytics type stuff.

I think both of mine are still sitting there and pending as well. So hopefully we'll be talking at Atlanta CodeCamp. So this is awkward because I recently wrote in a letter saying like, hey, these talks I'm not interested in the most. And those three came up. Was I not supposed to send that? Well, I'm a jerk. Yeah, that stinks.

So we might get approved for them. If we are, we will be. Oh, I need to finish that. We will be showing up all three together there to have a booth and do all that kind of stuff. Yeah. Assuming that everything still works out, that's the current plan. So I think that every public gathering has to be like, you know, asterisk, like there is the possibility that, you know, the thing gets canceled out from underneath us. Because they did have some kind of a verbiage about that from what I recall for the Atlanta Code Camp. So, yeah.

Jeez. Well, yeah, hopefully. So, yeah. Jeez. Well, yeah, hopefully. Yeah, hopefully. Yeah, I feel like Joe started us out with a joke, and I just can't let that sit. So, you know, I have the dad joke API just right here at my fingertips available to me, so I got to, like, follow that up. So, you know, there was a beekeeper that was

indicted after he confessed to years of stealing at work do you know what they charged him with buzz something and charged him with embezzlement there you go that and other quality dad jokes can be found with the dad joke API. So don't, don't, you know, like I know that you're going to be beating me down with emails and, you know,

messages on Twitter or Slack. Like, Hey, where'd you go? That great joke. And that's where I got it. Speaking of, I realized where I got my joke from earlier.

Like, like, and subscribe. Yeah, it was good. Like and subscribe. Yeah. It was Gaprogman.net core show. Thank you, Jamie. Thank you, Jamie. That was awesome.

He's going to get another shout out in this show too. Yeah. Word. So let's get into the meat here of this episode. We're talking about microservices. And kind of what did this was it triggered us in the last episode when we talked about the jet brain survey, when like over 80% of people are working with microservices. 35,

35, huh? 35%. Nah, I could have sworn it was way higher. Well, while Joe is verifying that number, I want to like kind of reinforce when alan says that it triggered him like

have you do you remember something about mary and like the guy the way he would twitch about the seven minute apps like that was literally like as we were recording the previous episode and we got to that to that uh metric alan really like it was like joe and i are in the back like if you take your medication medication, are you okay? Do you need a break? Do you need some water? Like, what's going on? So, I looked it up.

So, the deal is 35% of all respondents develop microservices. However, later, it goes on and says, what approach do you use in your system design? And 88% said microservices yeah that's crazy talk yeah and especially because rest is 83 right so 88 okay man like trigger absolutely sub-minute abs twitching all that if i recall though too like we actually joked about it like because it was like what approach do you take and like we actually joked about it, like because it was like, what approach do you take? And I think I joked about it at the time of something like, OK, well, like here's all the possible approaches we could take. Like microservices is one of them. Yeah, that sounds too hard.

OK, well, we looked at it. It was an approach we looked at. OK, let's move on. Right. So that's kind of where it's like I was like, do I understand what microservices are? Maybe it's time to kind of reevaluate that. And then got me thinking, it's like, well, does anyone understand what microservices are? Maybe it's time to kind of reevaluate that. And then it got me thinking, well, does anyone know what microservices are? Do we even have a refound agreement?

Is this an ubiquitous term or is it just completely vague? I walked away from that survey with the conclusion that if 88% are looking at it, then I'm like, I guess I'm not. I don't understand then. And I don't know because I wouldn't have guessed that high a number. No. So, so here's the deal, right? Like Joe went out and found the site that's actually really good. Microservices.io. I highly recommend it. It'll be in our resources. It'll be in the show notes. So definitely if you're on your podcast player or whatever you can swipe over to the notes and look at it and go to the link right um oh so so just want to take a quick on that so one thing i found with a bunch of sites this is like the ones that will have the like down

in the references including this one all the great sites uh even for for or pro you know pro or con uh for microservices all more sponsored by somebody that's got a vested interest in it. So microservices.io, it's Kong. And I looked up Kong. I've never heard of Kong. It's the service connectivity for modern architectures company. And, I mean, they have a microservices product. So, you know, like everything.

Yeah. So, you know, you know, like everything, you know, on here is coming from a company trying to sell that sort of thing and like we'll see that time and time again like every link we have like there's some marketing force behind this everything's an acronym so like i just expected it to be like kubernetes on angular you know like on ng you know so it turns out like that's not the thing they missed such an opportunity there. But you know what?

I will say this about this particular site. Yes, they do have this thing that they'll have some sort of service where they'll walk you through how to do certain things and evaluate. But they seem to be really honest about the pros and the cons of microservices, right? And that's really kind of what we want to get into here is because you first have to kind of understand what they are, and it all sounds absolutely amazing. And then you have to understand if they're for you, right? And that's where the rubber meets the road. And this is where I think a lot of people are saying that they look at,

you know, 88% of people are saying that they look at it. They probably look at it and walk the other way, or they, they don't realize that they're not doing microservices. Um, so what is a microservice from this microservices.io site, which I actually thought they did a pretty good job of breaking this down. It says it's a collection of services that are a highly maintainable and testable. Okay, cool. They're loosely coupled. Otherwise, you're just creating a distributed monolith, which I loved that they stated that because I think that's what a lot of people actually end up doing and don't realize it.

It's independently deployable. That's a really big key portion that we'll talk about in a minute. I mean, that goes hand in hand with the loosely coupled. Right. Because it, which to go back to illustrate your previous point about the distributed monolith is that if your thing, if you think you have a micro service, but yet your pieces aren't independently deployable, then you don't. Right. Totally. If you have to make coordinated changes, they're not microservices. but yet your pieces aren't independently deployable, then you don't. Right. Totally. If you have to make coordinated changes, they're not microservices.

Exactly. And we're going to talk about some of the specifics on how that ends up happening and you don't even realize it, right? They also put that it's typically organized around business capabilities, right? So it says that, I think somebody else put this note in here. Somebody want to talk to it? Yeah, I just want to say that a lot of the stuff that you read about microservices also deals with actual team architecture. So like what people are assigned to what sort of pieces here.

Because though you ever heard that old ad, I forget what the name of the rule is, but basically that your code architecture ends up forming around the same kind of company architecture. So basically you're at your org chart. So this kind of thing applies here. So like a lot of the architect, the microservices architectures that you'll see and you'll read about the architecture will mirror the organization of the company.

So like the services will be kind of grouped around the teams that actually work on them. So what he's saying there is like, if you have a customer service department, if you have an, a billing department, if you have a shipping department, you know,

that kind of stuff, you'll probably have microservices that, that are very much tailored to each one of those groups. Well, I think it's even smaller than that though. Right. Cause I think it was actually the, I think it was like one of the clean architecture books that that talked about it was either that or the data driven or design oh my god i can't

remember the ddd book uh it was data intensive domain driven design domain driven you said data it just shot it i was gone um i think it was like one of those, one of those books or something that, that talked about the it being organized around the team. And it could be like even smaller, like, you know, your team does the advertisements, you know,

that might pop up in your app. Right. And so like, that's your quote service, you know, that you bring in and another one might be responsible for like a search and discovery within your application. And so that's your, you know, kind of service. Uh, but it also happens to be like, Hey, you are the advertising, uh, arm of the development team. So, Oh, it makes sense

that you're the, you're also creating that service and you're, you're, you're responsible for, you know, your team is responsible for like elastic search and technologies like that and oh hey look happens to work out that you know that's the type of thing that you're you're delivering yeah we said maintaining that independent deployability was really important and that's also kind of a people problem so if you have a bunch of people on one team and a bunch of services that they all own then they're going to tend to make coordinated changes because they're all kind of work on the same stuff. But if you want to be able to deploy faster and smaller, then you kind of need these teams to be able to operate independently and to make changes independently and kind of publish those contracts independently. And so a lot of

the organization around the code is also organization to support that deployment strategy. Yeah. And that's their next point also is typically a microservices owned by a small team. I think they, they even brought up the thing that we've talked about in the past with two pizza teams, right? Like you're not going to have more than more than,

you know, X number of people basically no more than it would take two pieces to feed the team. So looks like somebody also added in some more stuff. The pizza thing, though, is like for like – I thought that was about meetings, though, right? That was agile. Don't organize a meeting that you can't have two pizzas feed all the attendees.

Well, they talked about that also on this microservices.io, saying that you don't want a development team bigger than that either for supporting microservices. And I think it goes back to what Jay-Z was saying, which is if your teams get too big, then you end up doing things that tightly couple things when you don't really mean to. I see.

And a couple things I would add here. So I talked to Jim Hummelsheim about this on the Coding Box Virtual Happy Hour on Saturdays. I just happened to mention that we were going to talk about microservices next, and he recommended me some materials, which we'll get to later. But also he had two really good points that he made. He talked about services being stateless. And the stateless, part of that is the scalability, which is also important and good for lots of reasons. But it's also about not coupling tightly things together.

So if your thing has states, because it knows something about a process that stretches on beyond itself. So that's not a market service to the point where you're expected to distribute monoliths. So by keeping things stateless, you just kind of help things remain atomic. That also means that they're independently scalable, which is a major benefit of having microservices and one reason that you might want to do this. But like, hmm. Okay. If I may. Because when we talk about that, like anytime we talk about like scaling

anything, right. It's never the stateless bits that are the problem, right? Like if you have a web app that has no state, like, you know, it's, it's easy to be like, Hey, you know what? I'm going to have a thousand of these, or I'm going to only have one of these things. Like, that's the easy part. It's dealing with the state, like, you know, properly sizing out like a Postgres cluster or a Kafka cluster. Like those are the things that are always problematic. But I think what, you know, if we were to also go back to the things that, uh, um, uncle Bob and, again, the domain-driven design, shoot. Evans. Evans, Eric Evans, I think was his name.

Then you would front that data layer with something. Nothing would have direct access to that data layer was something like nothing would have like direct access to that, that data source. And the thing that's fronting that would be stateless, right? Ooh, we'll get into some of that. here we go.

Yeah, we'll get into triggered Alan. He's already twitching. Yeah. There was a lot of interesting things on this microservices, microservices.io site, but they do talk about some of the state stuff. Yes.

Yeah. You had a couple more here, Jay-Z. Yeah. So Jim also turned me on to Sam Newman. So I ended up picking up a book from Sam Newman who got two really popular books on microservices. And one thing I noticed here in the definitions we got on microservices.io is none of them mentioned the size. We didn't talk about a small team. We didn't talk about, aside from the team, the small team, we didn't talk about the size of the service. So I just thought it was kind of funny.

And I quote here that microservices are small, autonomous services that work together. And so that was his definition. And even that, like, you know, right off the gate, we said that what is a microservice? It's a collection of, because it doesn't make sense to have one microservice, right? Because it really has nothing to do with size so much as it has to do with responsibility and working as part of a greater

whole you can't kind of by definition have one microservice i don't like your next line because i don't even i can't even figure out what it means yeah so this is something else i picked up from sam newman uh thanks to j, because I was reading the first chapter here. He talked about semantic diffusion, which is basically a way of saying, like, if a term gets out in the wild and kind of gets popular and it doesn't have a good, strong definition, then that definition will kind of grow and evolve. And people will hear something like microservice and apply it to something that maybe they're already doing or something else is doing and the definition grows until it's just so big and so even though we came and we just listed like seven things and said this is one of microservices the term is kind of made up right like no one defined this term in a paper written in 1987 like a lot of like vocabulary and technical stuff is this is a term that kind of evolved

and because there's a lot of disagreement over these things and so what we're trying to do is like retroactively find a definition and fit it to what people have kind of defined as the best practices and so you might find people that say we're doing microservices and then you find out what they really mean is small services that are distributed monolith And so by having these definitions here and this kind of like upfront definition, it just gives us a framework to talk about microservices. So saying the three of us are

agreeing that this is the definition that we're going to go with and we're going to talk about things because this is where the industry is kind of settled on this definition after the fact, after we're retroactively applying and trying to kind of find patterns here. And so it's just kind of tough.

And I found this vocabulary word that he mentioned kind of referring to that. Semantic diffusion being that vocabulary word. Hey, just to go take one step back, I think I might have referred to it as like data-driven design or something like that. But I was referring to domain-driven design. Right. You said that too. Okay, did I say it?

Okay, good. You did, yeah. It dawned on me. I was like, I don't think I said the right thing, and that's going to bug me. That's why as soon as you said data, I was like, data intensive apps, best book ever. All right, so the next part of the microservices that they say is a key feature of this type of implementation is it enables frequent and reliable delivery of complex applications, right? And that's because of the loose coupling and the independent

deployment and all that. And this one I found really interesting, and I like this one a whole lot, is it allows you to evolve your tech stack. And the reason that they stated behind the scenes for this is because you're deploying smaller services, typically these services are going to communicate on a standard protocol like REST, right? Like you might use the REST protocol when you're doing this. And so nobody cares about whether it was written in Java or C Sharp or Node or whatever, right? As long as these things can be called and a contract is met, you know, you call the customer service and the customer service returns you a customer object

in JSON or XML or whatever you want. Doesn't matter what it's written in. So you can actually evolve your tech stack more effectively over time because they're in smaller chunks that you can do so that was really interesting and i augmented you know so again we're already the strangler pattern which we've talked about a few times which is terrible name for pattern in fact i just when i googled it the first thing uh it sounds like uh some people are pushing to like

kind of emphasize it's the strangler fig pattern because we were talking about a strangler vine that would kind of take over a tree and that the idea there is that we talked about in non-microservices of code we talked about like basically introducing interfaces and then you slowly like replace the code underneath until there's no code or you know the original code left because you've all kind of replaced it over time and that's how this kind of this vine works this strangler vine that grows up around the tree eventually the tree dies but the vine lives on and so it's like it becomes strong enough to kind of become its own tree and so uh yeah i thought it was kind of funny so you know we say you can evolve your tech stack like what it means is like you start out with these 10 services and if you want to go from uh java to c sharp or whatever then that's fine uh and you

know you can do that stuff you can replace that stuff and as long as you maintain that contract then no one even has to know so it sounds like we should just microservice all the things all the time forever in life like i'm so it does right and uh you know i'm gonna i'm gonna from now on it's gonna be a microservice for everything right we can now be a part of the 88 percenters. I think that we're there now. Remember, so Python 2 to 3, how many companies are stuck? Imagine if they all had microservices, they could have just done one service at a time. That's great. We should all do it. Yeah, absolutely. All right. So this episode's over.

Yeah. And there's never a negative side to this either. This sounds amazing. I haven't heard a single con to it. I'm hearing know, I'm hearing nothing but positives. And so, yeah. We'll get there for sure. Yeah, so everybody just go ahead and start setting up your microservices. Right? Don't be negative. It's just natural.

Come on, man. We're going to have to kick you off the podcast. What's that about? Oh. All right. Wow, that got dark quick. Right? Yeah.

So, the very next line that they have in there is microservices are not a silver bullet, right? There are actually a lot of downsides. What? But before we get into those, that would be no fun if we told you what they are right now. Maybe even mostly downsides. I know. I kid. I know. I kid. I kid.

I don't know that you do. It's the same question. It's close, right? Yeah. Oh yeah. It's, it's actually a really good conversation when we get into there.

What's the M and M quote. A lot of truth is said in jest. Yeah, absolutely. Oh, so what they did say is you need to be able to sort of talk about some of these patterns in a language that makes sense so that you communicate with these. So this will be our ubiquitous language, right? That is definitely a spreading thing from,

I don't know, 1980. That's the strang the strangler pattern. It's taken over. Um, so, uh, so one of the things that they say is they go into this, there's a collection of patterns to apply for these microservices. So, um, one of the ones that they have here is they, they have these three patterns up here and they're called the way. Actually, I'm doing this wrong. I'm saying it wrong. Disregard everything I just said there. We're going to talk about one microservice implementation here just to make it easy to sort of conceptualize this stuff.

Right. And I have a link in the show notes to this specific page. So that if you kind of want to see how they drew the arrows and all that stuff, it'll help you when you're going through this stuff. But let's keep it easy. You have an inventory service, an account service, and a shipping service. Now this, based off the back end thing that you were saying earlier, Outlaw, this is where things get really interesting when they started in. And it's not just this site, by the way. Um, I, I accidentally stumbled upon capital one, uh, fairly large, uh, financial, you know, institution here in the U S uh, they have, right, there you go. They have an engineering

blog. That's actually really good. Kind of like like you know we've seen netflix and those guys capital one has a really good one and they had a lot of these same purposes or points that they pointed out so each service talks to a separate database or or storage whatever it is right like it doesn't have to be a database It could be whatever kind of storage that it has, Cassandra, relational Mongo, who cares? So none of them share the same database, right? Um, fronting these microservices are typically a couple of APIs. Um, so in this, in this imaginary setup that we have, you'll have this mobile gateway for your phones or whatever to talk to. And then you'll have an API that serves a website, right? And then, but that's kind of what I was getting at before though, with that example was that like, you wouldn't, your, your microservice wouldn't allow the database itself or whatever the storage layer is to be exposed to like external

connections. Like you would have something fronting that. Your service is fronting it. Yeah, that thing would be stateless. And how you scale the state behind the scenes, it would be like nobody else would care. And if you decide, hey, you know what? We no longer want to use Postgres. We want to use Oracle.

The service that everybody else is connecting to go through it would still be the you know be fine where that has come to issue like where i've seen it like there's things that like how how do you you know like oh gosh i'm even struggling to put this into words because there's such a temptation to be like, well, I want to be able to like just send it an arbitrary query or, you know, and at that point it's like, wait a minute, you shouldn't even know how to query it because you don't know what the storage is. So the mere fact that you even know, like would already be a problem, right? Totally.

Because then it's a total leakage of whatever. This thing is supposed to abstract away whatever it is, and if I'm going to leak that abstraction away, then I failed. Yep. So basically what you were saying, and just so that everybody kind of understands this, that microservice, so we said we have an inventory, an account, and a shipping service, three different ones.

The inventory service, let's say that it is talking to Postgres, right? Just to make things concrete and easy. You can scale that microservice. You could create 100 instances of it. Those can all talk to that same Postgres database. But that's it, right? And the only thing that should be in that database would be inventory-related information. So kind of going back to what you were saying, in a standard e-commerce application, you might have a customer's table, an inventory table, an orders table, all that kind of stuff.

They're saying no on that, right? The only thing that will exist in that one database is inventory information and we could even go back to a concrete example that we've talked about from the past like as it related to amazon right like the database that has the customers is not the database that has the orders and you have to go through another service to get customer data from and like, you know, off to that and you have a need for like, you know, and it's purposely done like that so that you can't join two different data sets together easily, you know, to get information out. So it has like in that particular use case, like an added security benefit on top of this ability to scale them independently and, you know, all the other microservices hoopla.

Well, I meant like pros, sorry. Yep. So what they ended up saying here is when you place an order, a request is made to the mobile API. Let's say you're making a request from your phone, right? A request is made to the mobile API. Let's say you're making a request from your phone, right? A request is made to the mobile API to place the order. The mobile API has to make individual calls to each one of the individual microservices to get and update the information for those various different pieces, right? So you make an order.

Your mobile gateway is then going to call the inventory service to deduct the amount of inventory from that particular product. It's going to then call the account service and update billing or whatever's happening there. And then it's also going to call to the shipping service and say, hey, I need a label for this thing. So it's sort of coordinating that stuff for you in that regard. And that's how the microservices work. So you've got three different services and potentially three separate databases all behind the scenes there. And they point out that this is in contrast to the monolithic setup to where you have a single API that does all that stuff, right? So, you know, in your monolithic thing, you're going to have place order and then it's going to go run and do all that stuff.

It's going to have all the logic there and it's probably going to be talking to a single database that places the order, updates the inventory and everything else. It's hard. It's a hard mindset to be able to convince people of too, because it's so easy to think about that, that monolithic one. Cause you're like, well, if I want everything to be like acid compliant, for example, like I want everything in one nice transaction to where if I had to roll it back, then it's just the one transaction to roll back versus if it's, if everything's separated and then it's like,

Oh, what if like I get to step four and step four fails, but all the other ones succeeded. Like you mean I got to implement that that rollback logic in my application? Like, that seems crazy. Why am I reinventing the wheel? There's already a database for this. And that's where like it's really hard to like try to convince people at a smaller scale to do this sort of thing because of these, I don't want to call them impediments,

but it's a different kind of thought process, mindset. It's more complex. It's more to code and it's more complex, right? And what you said is about it's hard to convince smaller scale type things to do it. That's when you kind of got to take a step back and say, should we do it? Right.

Do you need that extra complexity? Probably not. Right. Maybe you should be doing a monolith or maybe you should be doing an interior setup and not even be considering microservices until you hit the scale that requires you to go down that path. I mean, there've been some extremely successful companies that were monolith until

they didn't need to be. I mean like, I'm trying to remember some of the ones that we've talked about, like the big ones, but I think like Facebook was one that was just like compiled down to a single, uh, you know,

uh, I think it was down to a single C thing, PHP C thing. I forget exactly. Like it was PHP compiled into C or something like that. Right. And then, um,

wasn't there another one like an Instagram or, or maybe it was the original Amazon back in the, uh, I think, I think Amazon was another one back in the like nineties in early two thousands. Right. Like before they,

like that was their, uh, impetus to bring in AWS or or to what became AWS, right? It was when they started breaking apart Amazon.com, if I remember the story correctly. So yeah, to your point, oftentimes Monolith is good enough until it's not. And when it's not, by then you hopefully are successful enough that you can have the time and resources to start breaking it apart but don't let it be you know it's like the joke that we have with alan over the years right where it's like okay i'm going to start writing this new

application and the first thing i gotta do is get the authentication feature to scale to a billion concurrent users right and that's been like a like the running joke over the years for the show. Right. And you know, don't until it's a problem. Yeah. It making the decision to go the microservice route from the beginning, can really slow you down like majorly.

And also it's funny because they say it's easier to deploy and it's in and all that. And if you do it right, it is. However, there's a lot of overhead and just understanding how it all works, how it all ties together, how you make the messaging work, all that, because here's another thing that I don't even know that they point out in the pros and cons is typically in a microservice architecture, none of the other services know about each other, right? So if you have an account microservice and a shipping and whatever else, they don't talk to each other directly. They typically talk through some sort of messaging bus or a queue, right? Kafka or RabbitMQ or something, right?

So most things happen in an event-driven way to where new orders placed, okay? A message hits a queue. Everything that cares about that now reacts to it, right? So your account service, your shipping service, your inventory service, they're all like, okay, well, I have something now. I need to go do some work. And then they're not talking to each other. They're sending messages to a queue somewhere that other things then respond to. So that's a lot of coordination. You know, there is there, I think in like the,

within like the last few episodes, I'd made a comment to about like, you know, like there's all these patterns that we learn about and, and you know, like, like look at the catalog of episodes we've done over the years. Right.

And some of the books that we've, we've studied during that time. And there's a lot of great patterns and things that you should do in it. But I'd said that, and one of the reasons I put it is, all of these are great things, but sometimes they just kind of get in your way, right?

And to your comment a moment ago about with the microservices, it's like it getting in your way. It's the same kind of thing. Like sometimes it's better to not fixate on like all the, like, where should I, like, do I need a comma here? Or is, is this, do you know, do I need to dot this? I can, or can you still tell that it's an eye if I don't dot it?

Like just get the thought out and, and, you know, and sometimes like, you know, in anything that we're doing, like there are a lot of great practices and patterns and whatnot. And microservices is one of those at a, at a larger scale than say, you know, some of the ways to organize your, the actual code, but all of them are, are great. But sometimes it's just like to that monolithic conversation, like just get the thing out there. Like get the MVP out there. See what's what first. You know, don't start with the idea of like, well, of course, my thing needs to scale to a concurrent, you know, a billion users. Yeah, totally.

You know, on that note, like we talked about NoSQL versus relational databases, and we said that with NoSQL, you really have to understand your domain because the shape you give to your objects is harder to change once it's out in the wild. You can't really kind of combine that stuff in different ways. So in a lot of ways, any sort of startup is going to be rough with microservices

because you don't really understand your domain yet, and it's harder to change once you have to split things up in services because you can imagine like you you say okay we've got an inventory service card service a payment service whatever let's put this stuff out there and then you start realizing that there's rules that kind of blend across two and which one does it go to and like how do we have to do this and what you're finding out is basically that there's some shared behavior that maybe should be a whole other service or maybe those two services should really just be one but how could you know that up front until you really start kind

of evolving the product you're still building the product you're defining the product so how can you really split this stuff into multiple different components until you totally understand that domain and that doesn't happen until it's a mature product it does make me question though that like um i had this thought while you were describing it, while Alan was describing it, where like picture, what if you're in a situation to where like you know, multiple teams do have access to say like a same database or whatever the storage tier might be that like maybe, maybe you know,

your team should protect themselves against that. Those other teams and the changes by even if there isn't already a service to front that storage layer, you create one that your team goes through. And then that way you only have the one single thing touching it that you're like, you know, you have a layer of protection against. Right. that you're like, you know, you have a layer of protection against, right? It's kind of like the idea that, um, I think it was from the clean architecture book where it was talking about like, uh, you know, like putting an interface around around those external kind of dependencies, you know, but in this case it's not like just an interface. It's, it's, uh,

you know, like a, a service. So it's funny that you say that because that specifically was one of the things that was called out both on the Capital One stuff and even in this website is you should never share a database. And the reason is, is because you accidentally start doing tight coupling. So for instance, if you update a table in a database, in a shared database, everybody knows that that table's updated, right? And so now it's, it's almost harder to do these independent deployments because you now know the contract of that particular table shifted. And, and if you don't follow suit in something, right? Like if somebody, let's not even say that you just added a column to a table, let's say you deleted a column from a table and you broke that out into a bridge table or something, right?

That's something that leaks through your implementation. And so anybody that's accessing that same database has to deal with that same thing. And so now you can't really independently deploy things because your stuff's going to be tied to the other team's stuff who are using that same database. And that's why they were like, you have your own data stores. And then that way, the only thing you honor is your contract. Doesn't matter if you delete something behind the scenes. As long as you're always honoring your contract on what returns from your API, you're good. See, I was actually thinking of something

even simpler than that. Like don't change the schema, leave the schema as is, but you go through a version upgrade. Yeah. You know, and sometimes the ramifications that that might have, you know, mess up every service that touches. An older driver might not be able to know how to talk to that newer version of this,

of that storage layer, you know, things like that. Yeah. Cause now all of a sudden they're not independently deployable. You're going to have to deploy them all. So, so my app that hasn't changed in like two years, you're saying like, Oh, Hey, Michael, by the way, we're doing an upgrade on our storage layer and you need to update your driver. And I got to go through a version upgrade on my app for no other reason. And oh, by the way, maybe that new driver version breaks other things in my application that now, like my two-year-old application, whatever it might be,

I got to go through a bunch of hassle and headaches to deal with that. So yeah, I mean, shared databases were kind of gross, but that's why I was thinking like, you know, you could, you could, um, what's that, that, that expression about like, uh, be the, be the, um, the force of change that you want, you know, or I can't, I can't remember. I'm misquoting it, but, um, that's why I was thinking of the idea of like, okay, if there's not already a service involved, then you could, you know, create one for your team to go through. So at least you're protected. And then maybe that thing would grow enough popularity that others would start

using it too and it would eventually become the thing that abstracts away the actual storage layer to where you know uh you know maybe the data team that that would own whatever that storage layer is would actually like take over the ownership of it but you know if you want to if you wanted to see that kind of change happen then you know be the the force that starts it you know yeah that's kind of change happen, then, you know, be the force that starts it, you know? Mm-hmm. Yeah, that's kind of the thing, too, like, about studying things like microservices. Like, you might know, like, listening to this episode going in, you're on a small team,

you're not going microservices. But you listen to the episode anyway, and maybe, you know, like, for us, like, we research this stuff anyway. Like, maybe there's some things you take away from it, and you're like, you know, there's some things that I do like, and maybe I can get some of that benefit by doing this, that, or the other. And, you know, I don't have to go full hog. You might sit back and say, well, you know what? This might be what's wrong about these two services that we've been having trouble with.

We're both sharing a data store, and we're having these kinds of problems. So it's always good stuff to learn about. Yeah, totally. Learning is good. So before we go into the break here, let's talk about the pros of the microservice architecture. We described what it is, and in describing it, I think we hit on some of the pros, but let's call them out explicitly. So we mentioned the size earlier. Each service is small, so it's actually easier to understand by a developer and easier to change.

That's a really big pro. It's easier and faster to test as they're smaller and less complex. Excellent. Better deployability. You can deploy them independently of everything else, or you should be able to. Easier to organize development effort around because you have smaller autonomous teams. Sounds great. Because the code bases are smaller, the IDEs actually work better.

And this is true. That may sound kind of silly, but we've all worked on really big projects where the IDEs don't even like them. We've definitely had issues like that in the past. We were talking in the last episode about JetBrains IDEs for example. WebStorm specifically was called out and I remember

getting in a discussion because years ago WebStorm was my go-to daily driver for doing any of my JavaScript development. I remember at a, it, uh, meetup, um, they used to do, uh, this particular, it was a JavaScript meetup and they would do these lightning rounds. And, um, I don't even remember how it came up in the meetup, but somehow

like, you know, IDEs, you know, uh, of, of, uh, preferred IDs came up and, uh, like me and another guy, like, I mean, we didn't get into like an argument, but we, we did get into like a discussion about like why he was adamantly opposed to web storm.

And his reason was because in his large scale projects, he was like, it just broke down. Like it would be unusable when web storm would go through its indexing process and whatnot. And like he was like, yeah, you could go into the settings and there was like a thousand different tweaks that you can make to be like, hey, I'm not going to ever have this type of file. So don't even try to like maintain, um, uh, web storm in order to use it all because of how gigantic his,

his project was. And because my projects weren't at the same scale, I'm like, are you kidding me? Like web storm is amazing for web development. What are you talking about? And he, he just like, he couldn't,

he couldn't get on the same level with me. Like he couldn't comprehend how awesome it was because his project was too large. Yeah. I mean, we've seen it. We've definitely all been a part of them. Yeah. So the the next part improved fault isolation. And this one's actually a really awesome pro is we've seen it before. If there's one piece of code in an API

that just operates like garbage, it's slow, it's inefficient, whatever eats up a ton of memory, your entire API goes down, right? In this case, the only thing that's impacted by that is that one microservice, right? You could have five other versions of it running or five other instances of it running. It's only that one. And it doesn't impact anything else. Right. It's just that one thing. We've ever seen like system designs where it's like, hey, we know that there's like a bug in this thing. Like eventually it'll restart every three hours. But who cares? We're just going to spin up a thousand of them and we don't, whatever,

it'll be fine. And that's kind of what you're at here, right? So if something does go wrong, whatever is only impacting that one thing and it doesn't have any state that it cares about. So fine, whatever. Here's another one.

This one, whatever applications start and run faster when they're smaller. Sure. That's true. I've gotten to the point where I think hardware is fast enough to where I don't really care about that stuff anymore. But, you know, maybe there are other situations. I know you've been working on Spring lately.

The Spring startup is, even if it's like Hello World. Well, coming at this from like a Kubernetes point of view, like this super matters how fast your application can spin up because in the case that the uh the coordinator decides to move it to another node pool or to another node or whatever like it it it wants to be able to like shut something down quickly and then spin it back up quickly so that there's you know uh or actually i guess it would like spin up the other one before it shut down the other one, but whatever it, you know, the point being is that like it, it wants to be able to do those things really quick in, in order to, um, not have downtime, you know, cause that's the goal in a Kubernetes

environment. Yeah. Good point. Um, and so the other one that we already called out earlier is it also allows you to be more flexible with the tech stacks, right? You can totally change out pieces as you see fit because they're smaller and easier to do that with. Or experiment with new technologies. You've heard a lot of great things about Rust. Let's check out this Rust thing.

What's this Rust thing about? Does it bias anything? All right, totally. Now, don't tell your boss that this is what your microservice is for. Right. I mean, this is what we all actually want it for. But this is not how you sell it. Right.

Today's episode of Coding Blocks is sponsored by Datadog, the unified monitoring platform for full visibility into all your serverless functions. Troubleshoot performance issues faster by seamlessly navigating between logs, Lambda metrics, and distributed request traces all within one unified platform. Datadog provides real-time screen boards and service mappings, so you can get complete observability in your service environments. And I'm looking at what they have to offer for microservices right now. And, I mean, it's just literally beautiful.

I just want to cry looking at it. It's such a hard problem, and they make it so easy by tying all this stuff together, giving you things like distributed tracing and mapping, monitoring, visualization and tracing and correlation across different logs, sources across different services to figure out like what went wrong it's so important to and it makes things so much easier you really need to have this stuff and it's great to see what they've got there for microservices and they take that same level of like quality and detail and just attention to your needs customer no matter how you're using the product it's just well you just gotta go google data dog microservices it's it's he's

not wrong i'm telling you like we have talked and gushed about data dog before like their blog is incredible with how much stuff they have out there and, and, you know, they really are a thought leader in this. So of course they have an amazing article, uh, for example, on full stack microservice monitoring, right. And to Jay-Z's point about the visualizations that they have in some of their dashboards, like it's like you ever seen those, uh, those types of relationship graphs where, uh, you know, you see a bunch of things on the, you know, a bunch of nodes all connected and, and you're like, Oh, that's cool. It kind of looks like, you know, stuff coming in from one country going across another country or whatever. But now imagine

if you had that type of visualization, but for your microservice architecture, and then you're like, Oh, let me just drill into one of those things and see your microservice architecture. And then you're like, Oh, let me just drill into one of those things and see what it's doing. Like this, this visualization that you're showing here is just amazing. And these are the types of you know, if you I'll include a link to this in the show notes, if you go here and you look at these types of visualizations, these are the amazing types of functionality that

you're going to get with Datadog to, you know, when we talk about how troubleshooting your performance issues faster, yeah, you know why? Because you could easily visualize where the source of the problem is without having to like go and manually read those logs yourself. Instead, you're like, oh, this little blip right here was red. Let me click on it, see why, right? And then see some. So you owe it to yourself to go check out Datadog. I'll have some links in the show notes for you to make it easy for you

to point you in some directions. But go check it out. Start monitoring today. You can get a free 14-day trial or receive a a free data dog t-shirt after creating one dashboard. Yeah. So again, go check out data dog, hq.com slash coding blocks to learn more about how data dog can help you optimize your serverless environment. Okay. Well, it is that time of the episode where, you know, I was going to do the beg here.

But since I saved the Internet last time and it didn't seem to matter, maybe I should let one of our late night radio DJs do it. But, you know, hey, I tell you what, Internet, I'm going to do you a favor. I'll go ahead and ask for the review this time and it but but i'll with a threat that if i don't get any reviews this time i swear i'm going to unleash them what is one of them are come out you're going to be upset that you had to like hear alan or joe do their uh late night dj voice uh asking for a review but instead you're going to hear it from me. So if you haven't already left us a review, we would greatly appreciate it if you did

leave us one. It really does mean a lot to us. Every one of them that we read puts a smile on our face. We get asked often like, hey, if you guys had a Patreon or some way that I could donate, I'd love to be able to donate or buy you a cup of coffee or whatever. And you know what?

Leaving us a review is your way that you can do that for us. It takes no money out of your pocket. It just takes a few moments of your time and we really do appreciate it. And so with that, we head into my favorite portion of the show. It's the tip of the week. Oh wait, no, it's not. I'm sorry. Wait a second.

Yeah, I got, I got sidetracked there. I don't even know why I said that. Do you ever just say stuff and you're like, that was so random. Like the words that I saw in my head were not the words that came out of my mouth. Data-driven design.

Wait, domain-driven? Data-driven. Yes. It's one of those two. We'll never know. There's no way we could ever know. We can't possibly rewind and know that I said data-driven when I thought I said data domain-driven. Or no, wait, I did say domain-driven and I thought I said data-driven. You know what? I've already confused myself.

We've just seen the breakdown of Michael Outlaw live. Yes, it's happening in real time. My Michael services are failing. Yeah. Thank you. Okay. Well, it's time for Survey Sets. All right. So I'm actually really excited about this survey. So a few episodes back, we asked the all-important question that the Internet needs an answer to. How do you put your shoes on? Sock, sock, shoe, shoe. Just in case I decide I only want socks.

Or sock sock shoe, sock shoe. You can't have a foot only partially dressed or shoe sock, shoe sock, or wait a minute. That ain't gonna work. Uh, socks.

You don't wear socks with boat shoes or shoes. It's a flip flop life for me. So, uh, what episode is this? 165. So Alan, according to to tech has trademarked a pattern. You are first with, you know,

to give an answer. So what do you think is the, the most popular answer and a percentage? All right. So I'm just going to assume that flip-flops are not going to be the vast majority only because we have a lot of Northern people that listen to the podcast and they would get frostbite in their toes. Nobody wants that. So I'm going to go with the only valid answer here if it's's not flip flops and that is sock, sock,

shoe, shoe, because that, that makes sense. Um, go with 35% on that one. So I've been thinking about this one a lot, uh,

ever since I brought it up, I tried to kind of pay attention to what I do. And I found that I'm completely inconsistent. Like I just thought, obviously it's sock, sock, shoe, shoe. And then I caught myself doing, to kind of pay attention to what i do and i found that i'm completely inconsistent like i just thought obviously it's sock sock shoe shoe and then i caught myself doing sock shoe sock shoe um so i uh i i don't know i mean i think that sock sock shoe shoe just makes sense um in case you only want to do socks but um i don't know there's something nice about doing one at a time too you know let's say it's better to do one thing completely than two things you know halfway right

no man so that's so that's my answer you gotta give percentage 11 11 11. 11. Okay. So Joe goes with sock, sock, shoe, shoe, 11%. And Alan, you said sock, sock, shoe, shoe, and I forgot your percentage there. 35. But you know what's great about this is, all right, we're doing prices right. So I would love to just choose 11, you know, because that 10% buffer underneath it doesn't matter at all. Let's just hit somewhere between 11 and 35 for the win. So both of you go sock, sock, shoe, shoe.

Alan, 35%. Joe, 11%. I guess. Well, i'm happy to report that we have a solid winner yes it's interesting how confident you are right now alan it can't be between 11 and 35 no it was you alan okay this is like 71 percent wow sock sock shoo shoo now i because alan you were saying that that was the only one that made sense was sock sock shoo shoo totally and and joe uh did i just lose joe or is he just napping i dig that's a great shot of him napping go ahead so so uh joe if you said you go back and forth sometimes you're sock sock shoe shoe

and sometimes you're sock shoe sock shoe yeah i mean i do all of those except for shoes that doesn't make any sense but so i i'm i would i'm really kind of shocked at the where this landed because like so flip flop the flip-flop choice was the number two answer so and that one had like 21 of the vote so there right away like that's the you know we're over 92 percent at that point right yeah this all came about because i am sock shoe sock shoe all right because like i i focus on one foot at a time and that's what that's the foot i put on right it don't make no sense but it does especially does. Like, especially when I go mountain biking, for example, because like, for example, when,

when I get to the trail and, and, you know, I'll, I'll go to the trail wearing flip-flops and then sit down and put my shoes and socks on, you know, at my car. But I don't want to get like dirt and everything on my on my feet and once you put a sock on you can't wear a flip-flop right so put your sock on then you put your your cycling shoe on and then you do the other foot right so that you're putting a foot into you know a clean foot into a sock so yes i mean like that's just one example where it makes sense but like just in my general like this all came about because my wife saw me putting on my shoes one day and she's she had dawned on her she's like wait a minute what psychopath what are you doing put the other

sock on and i'm like i mean you have them both in your hand. Like, why would you put down one of your socks and then grab a shoe? Whoa, whoa, whoa, whoa. Wait a minute. You don't tuck your socks together and put them in your drawer? No, but what you just said is misspoken. You're not holding both socks at the same time you're putting one on. You set one down, you put one sock on, and then you can pick up the other sock. But that's completing the task, sir.

So is completing the task of the foot. I've already got this foot up in the air to put the sock on. Why not just grab the shoe, put the shoe on while it's in the air? I bet there's some psychological study out there that says you are a little bit insane for that. No, I'm telling you the internet is wrong. You guys are wrong and the internet is wrong. The proper order is sock, shoe, sock, shoe, done. He's right.

He's right. So I realized the source of my inconsistency is because I usually keep my shoes outside, like in the garage. So I put my socks on, go downstairs, go outside, socks socks shoe shoe the times when I put my shoes on inside like if it's dress shoes or you know like if I'm you know put like putting on shoes inside for some reason like I'm gonna vacuum or something I put sneakers on I do sock shoe sock shoe because I don't want to get uh dog hair on the bottom of my socks. So that's why I'm inconsistent. And you just made me realize that it wasn't inconsistent.

It's just that I did sometimes one way, sometimes the other. Man. All right. I'm glad that most people are saying and voted that way. No, I think if anything we've learned over the recent years of this podcast with these polls like the majority of people are insane it's sock shoe sock shoe and this is just yet another data point to confirm that like i feel like we should follow this up at some point in the future be like okay now that everybody heard the other episode we need more people to vote and tell us if if if this is

crazy that's pretty funny though that's good i mean yeah whatever just saying i'm the same one here uh yeah so all right well how about this how about if i ask you this instead how was the snow globe feeling after the storm? Pretty shooken up. Pretty shaken up. A little shaken, yep. That's good. Fine then, Mr. Jozak. You think you're so smart?

Why do birds fly south for the winter? I don't know. It's too far to walk. Yeah, okay. too far to walk yeah okay so for your next uh survey enjoyment um this one isn't going to be as controversial i mean i think the sock sock shoe shoe or sock shoe sock shoe question will be forever like the most controversial question we've ever asked as a survey but uh yeah don't i see you questioning did we do times and spaces i think we might have at some point this one is way way more controversial like this this was this is definitely the holy

war of the internet all right tabs versus spaces just among software developers or whatever but like you know you might have a point yeah this This one affects the whole internet. So for this episode survey, we ask, for your next laptop, are you leaning towards something with Windows 11? It'll be fine. Or something with Apple Silicon? It'll probably be fine. Or something running some Linux distribution? App install, fine. Or something running some Linux distribution app install. Fine. Or probably a Chromebook.

That's good enough. Or is it laptop? I'll stick with my desktop. I don't go anywhere anyways. Nowadays, truer than ever. I'm curious of this one. I don't think we've done one like that in a while.

I don't think so. But, and I heard you like, you know, passing judgment on the Chromebook. It's good enough. It depends on what you're doing. We've actually had,

you know, people who've written in, in the past that like, you know, use a Chromebook to get all through their CS degree and, you know, used online services for everything. Well, Google employees do the virtual desktop stuff too.

I don't know about all of them, but you know, and it's common. So it's probably fine. That's because they own the cloud compute, right? Like they can afford to do that. They spend a million dollars on VMs that are all funny money internally. So yeah, whatever. All right. So, so we finished up with the pros of the microservice and, and there were some good ones, right? Like I think we all thought that those were all pretty good. All right. So here's the downsides. Here it comes. Let's hit the cons. All right. So this one cannot be overstated.

There is additional complexity of a distributed system. Man, isn't there? Holy moly. Yeah, for real. It's miserable. I hope you look at the logs in some sort of aggregation tool. And then all the authentication to go across all of them like if you have to do any kind of certificate management among them wait i feel like jay-z

had more to say there like he was quick and hot to jump off yeah i mean it's such a pain you should you should never do a distributed system never unless you have to in which case well like the best of it but yeah i mean the debugging is terrible it's so hard to see like setting debuggers and stuff like having multiple editors open and stuff like that's stuff that like nobody wants to do like maybe it looks cool and like the uh you know the dashboards like data dashboards are amazing but if you could just do it all in a single pane of glass and a single file, you would. Everyone would, right?

It's huge. And what you said about debugging is no small thing. I don't remember if I have it in the show notes here or if it was just something I read on one of the several pages I was on. A lot of IDEs are built for more monolithic type approaches. And I'd never even thought about it. But if you ever try and debug a distributed system, you'll find that to be true real quick. Like, it's just not easy at all. There's just not good tooling for it.

It's like you said, it's crawling crawling through logs and that's not fun so if it's just to you by default it doesn't like you start a project it'll stop whatever other one you got you have to go turn a setting on and even then like it like an intelligent too kind of like it wants one to be prominent like this is the one that you're in right now you know everything else like it's a drop down so it's all built around having one thing selected at a time so you can do it but it's just yeah it's just awkward yeah they're not built around it um so another one you have additional cost overhead of services network traffic all that good stuff uh additional storage you you could be duplicating storage for that data totally totally um multi-system transactions are really hard i don't know't know if we get into it in this episode or not, but that is super true. What Outlaw brought up earlier about

you have a four-step order process. In a database, you have a transaction you wrap around those things. If something fails on step three, then you just roll back, right? Like it's done. In a distributed system where they all have separate data storage uh you have to manage that on your own that's that's not easy um uh somebody's got something here on a stack overflow thing yeah so so check out this uh click this article and i think this is a diagram that we can actually describe. If you scroll down into, you'll know when you see it. I just love the title of this article, the macro problem with micro services. Yeah. The duct tape.

Yeah. Yeah. So does anyone want to describe this picture? I see your, uh, your, uh, celery's in there, Alan. Oh man, it really is yeah so i mean i haven't read this article but it's really it's kind of funny they have they have these pages that are duct taped together with technologies right so you got duct tape like holding a page together with reddit so you've got duct tape holding together uh my sequel with

another one and then there's like a barbed wire chain no it's broken chains broken chains oh broken chains it's chains with a bunch of weak links that are already broken a rabbit of cues afraid thread that's that's being linked to from like it's pretty funny yeah so i do have something funny to say about this article or i don't know if it's funny funny yeah so i do have something funny to say about this article or i don't know if it's funny or not so this is the stack overflow blog right so let's go check out this author yeah this is so november 2020 so way before the acquisition acquisition by their parent new parent company happened a couple days ago it finalized this happened months ago.

Ryland Goldstein is the author of this blog post, right? And they're the head of product at Temporal. Who's Temporal? Well, they're a microservice company. They've got some products around microservice. But he doesn't work for Stack Overflow. As far as I can tell, he never works for Stack Overflow. They work at Temporal. So I thought, well thought well does stack overflow blog just have like guests posts but you you won't find the word

guests anywhere on this blog post interesting yeah and like if you scroll down like about halfway through it starts talking about temporal's products so this is not like someone who used to work at stack overflow and then you know wrote this article and then moved on and updated their bio or anything. Like half is like about halfway down the page. It starts talking about temporal and their services. And they literally said, so now comes the part where we pitch you on our solution. Right. But it doesn't say anywhere on here promoted blog post.

Huh? Yeah. You would have just assumed that it was something that Stack Overflow people would have said something about. Yeah. And if you go to the author's page on Stack Overflow, it's just Stack Overflow dot blog slash authors. Everyone, I believe, on this author's page actually works at Stack Overflow. And this person is not shown there. But if you click on their title in the article, they've written several articles on Stack Overflow. Oh, that's pretty.

So that's the side of it. But it was funny because I kept noticing that every blog article that was pro-microservices was written by a company that sold something in the microservices space. That's not new. That's not unique. It's just kind of funny that there's this big microservices industrial industrial complex it's like churning out these articles about like you know what's good about it why you should do it when you should consider it and then you're gonna see a bunch of like hater articles that are like my company started doing microservices they're the worst and we quit and that's all these tiniest companies that have like 10 employees you know and they're

like microservices suck and so it's just funny that there's this big gap between those companies that are like trying to sell to you and there's like these small companies which is probably inappropriate in the first place and they hate it so it's kind of funny but yeah it kind of gave me um i'll say like an icky feeling to kind of think like stack overflow when you go to the blog you kind of like assume that this is stack overflow and by having the opinion on there it kind of makes you think like stack overflow is kind of a hindrance and i always thought of stack overflow as being a shining example of like a monolith. So the whole thing was weird in the first place. And so it was just kind of weird to be like,

this looks a lot like a promoted post or guest post. And neither one seems to be the case here. Like I cannot find any sign of that on the blog page. So we'll have a link there. I don't know. That's definitely a side note. But it was just kind of like, I don't like thinking that I'm reading a promotional post and it's not called out. You got to be careful with that stuff. Yeah. So the next con of this is

implementing the inner service communication and handling of failures. That's a really big one. It's not simple. I've seen some really complex setups. Implementing multi-service requests is more complex. Not only more complex, but you may be interfacing with multiple developer teams as well, which that has some overhead, right? Communication is hard. It really is, man.

It doesn't scale at all it's like if you're like well this team should fix it but they don't have time we could get this team to fix it and that's really not the appropriate place to do it but they've got the bandwidth to do it now or maybe i should band it over and write a ticket blah blah just like having that like that sounds like a meeting right and we'll have a couple emails we got to make sure to document it so and and so is out on vacation. We'll talk about it. Maybe we'll just bump this whole thing in the next sprint. Like, that's how this crap happens.

Yep. I feel like we've hit his button tonight. Yeah. Yeah, I much prefer Michael services. Last episode, Alan was twitching, but this one, Jay-Z is definitely

needs his medication. That's awesome. Testing interactions between services is more complex. I mean, that kind of makes sense, right? You're basically going to have to be doing integration-type testing at that point. Yep. We already said this. IDEs don't make distributed application development easier.

It's not even close. Deployments are more complex. So even though you can independently deploy these things, managing multiple services and dependencies and all that stuff, it is actually harder, right? Like it's not just cake. Well, I mean, to be clear here, what we're talking about is that it might be a requirement that you have multiple versions of your service deployed. And that's why the deployments are more complex. Because you might have to support a V1, a V2, a V3 of whatever your thing is. And think about it from the data layer.

You're abstracting that database layer, but you might still need to have a way to have that, you know, as you want to like add or remove columns or whatever, you still need to support V1. And so now you got to like deal with that in addition to upgrades that you're making. Well, and this also does, you know, taking that a step further is you have to start thinking about, you know, you've seen in code where things are deprecated, right? Well, if you're going to say that you're going to deprecate in your service, I mean, you've seen it before. You can send out a thousand notifications and be like, yo, we're not kidding. On September 1st, these things will no longer exist and inevitably when you deploy your thing out on september 1st with those deprecated pieces gone you're going to start

getting emails like you know why did this stop working i i can promise you like here's an example this one uh i hope this doesn't like bring back any uh ptsd for you guys but i can promise you come december of this given year then then I'll, you know, whatever given year it is, this search service will go away. Oh yeah. And you can get that notification for a year in advance and you can keep ignoring it and ignoring it and ignoring it and ignoring it until it's like two weeks before. And you're like, I think they might be serious. Oh, they really did mean that.

Oops. Oh, I guess technically in that case, it was, uh, after it actually did get shut down. Then they were like, Oh,

they were serious. Yeah. Oh yeah. They weren't kidding. Um, so yeah, deployments more complex. Oh,

increased infrastructure requirements, right? Like if you have a monolith, you can set up a few servers and is more complex. Oh, increased infrastructure requirements, right? Like if you have a monolith, you can set up a few servers and you're good. If you're doing microservices, it's probably a little bit more complex than that, right? Like whether you're running on VMs or you're doing Kubernetes or whatever, you have to have CPU memory requirements, all that kind of stuff, right? So that gets a little bit more complex. It looks like we have distributed debugging in here again. I was going to say that. Is it called?

Yeah. It's real hard. Real hard. You know what? I think that was like a race condition. Like it was supposed to come in the first, but because it didn't, because of the timing, it ends up coming in here as a duplicate. So, yeah. Sorry.

We'll have to debug that, figure out what happened. Yeah. Well, I mean, that's not a real problem in prod, right? Like, let's have a meeting about that. Yeah, you're probably right. Yeah, it's just a dev thing. Let's just ignore it. This is Twitter thing we got here. Yeah, so I thought this was really funny.

So I got this from one of the articles I read. But it's a tweet from Simon Brown, who has written a book on software architecture at some point. And we'll have a link here in the show notes. And he says, I'll keep saying this in this tweet. If people can't build monoliths properly, microservices won't help. I think that is the perfect thing. Microservices are not going to fix your crappy application, right? If your monolith has problems, if you've got problems with abstractions and configuration and deployments for a monolith, well, I got bad news for you. This is not going to make your life easier.

So true. So true. So true. And by that, kind of what he's getting at is if you've got spaghetti code and tight coupling all throughout your application effects all the way through your application, you're probably in for a world of hurt if you think that you're going to be able to turn this into a microservice type thing. The first time I heard of microservices, it wasn't called microservices to me, but it was working at Amazon. So it was talking about having like, okay, you're going to have a tax service, you're going to have a shipping service, you're going to have all these different services, you're going to have a cart service. And the deal was like it would go off and call

this. I remember thinking it was crazy, but it was because they were dealing with the kind of scalability. And they had teams that made a really good tax service. And there was teams that had a really good shipping service. And there's all these things. And that makes sense to have like a team working on shipping or a team

working on tax at amazon and it's fantastic that they're not all kind of blocking each other they've got independent deploys like all this stuff makes so much sense for amazon it doesn't make sense for a five-person company though right um all right so the next thing here is we've talked about some of the amazing pros and we've talked about some of the really dark, deep cons. How do you know when you should be choosing the microservice architecture? And this also came from a little bit on the microservices.io site. And it's a hard problem to even answer this question because like Joe said earlier, if you're a small startup, like he said, most of the blog articles out there, we did microservices

and they were terrible. We trashed them. If you're a small startup, your primary goal should be to start making money, right? And to start making money, you need to get your product out there and working and selling and all that kind of stuff. If you try to go the microservice route, it will slow you down. It is way more complicated than standing up an interior application, period. There's no question. There's way more infrastructure that has to be in. There's more tech stacks. There's more everything. It's harder. But wait, Alan, tell me more about this N-tier application.

What's that? I mean, I think we all know this one, right? Like that's your, you have your front end, you have your middle tier, and you have your data storage, right? Like that's kind of the simple one that's been around forever that I'd say a lot of people are probably most familiar with. Yeah, I just wanted to make sure that we defined it in case. Good call. Okay. But here's the, here's the downside of not choosing to go the microservice route. And this is totally true too. So this is a catch 22, right? Let's say that you do create a product that becomes very popular and you start hitting scaling problems. It can actually be really difficult to split that thing apart.

If you didn't design it in a way like saying something like domain driven design or, or something along those lines, trying to figure out how to split the thing up and turn it into a scalable implementation may be really hard. You know, if everything writes the same database and your database is your bottleneck, you got to figure that out.

If your API is set up and it's heavily based on state, you got to figure that out. Like you can't just start running 12 of them. So it becomes a really difficult thing. So does that mean you should do it at the beginning? Like you can't just start running 12 of them. So it's, it becomes a really difficult thing. So, so does that mean you should do it at the beginning? Probably not. But know that if you do end up hitting that tipping point, like it's going to take some work to do it.

And maybe that's, that's fine. If you're making money, then, then you bite that bullet when it comes. Yeah. Like an example might be, Hey,

you know, one, one web server does just fine for your, your small store. Right. And then eventually you're like, you know what? Uh, we're doing pretty good. I need, uh, more web servers for my store. And, uh, you know, I don't think I have state. Oh wait, no, I do have some state information, uh, related to shopping carts and everything. Okay. So I do have some state. Oh gosh, how am I going to do that? Maybe it'd be good enough to just do like a sticky session. So, you know, customer A comes in and they always get server three and a customer B comes in and they always

get server one and you know, that'd be good enough. But then over time, maybe, uh, you know, your, your company's really, really successful. And then it's like, Hey, you know what? Maybe I just need to move, uh, you know, some of this into a caching layer that is independent of my app server. And now the app server can scale independent of that, you know, and I don't have to worry about sticky sessions and things like that. Right. Like, you know, there are, you evolve into these architectures over time. You don't start with them. Like that old expression of like Rome wasn't built in a day, you know, kind of thing is, is, you know, still applicable here. Yeah. And when we went over domain or designing domain, domain driven design, designing data intensive applications, that's where the data came in

like they even called out twitter right several times in that book twitter didn't start off as a hyper scalable company right like they grew into it over time because as the need and the user base and all that stuff was there then it, Oh, I mean, if you remember like the fail whale, like it was like, even once they were popular, they still weren't scaling, you know, like, like they might've wanted to. Yeah. So this is where I thought this was a really good portion of it. So they start talking about, all right, so let's say that you've hit that point. You're not trying to build Roman a day. So you start out, you do things sort of a way that's easier for developers to get their heads around and start getting a product out there. And now you need to scale. How do you decompose this application that you've built into

microservices? Like what are some good keys on how to do this? And I thought these were good. Um, one of them was do so by the business capability. I think Joe Zach, you brought this up earlier, right? Like you kind of do it around what your company functions are. So they had some examples. Uh, you have product catalog management, inventory management, order management, delivery management, right? Like, those are all good candidates for setting up as a microservice, breaking those out. Then they go into, well, how do you know the right way to break down the business things? By the way, you do this with code all the time, right?

Like, I'm sure all of us look at our code and they're like, should I make this another class? Wait, should this be another class? Should this be another method in this class? Like, you know, this is not easy stuff. You know, remember when we worked in e-commerce stuff for a large e-commerce company, the front end and the back end kind of systems were like totally separate. So it was amazing because shipping could be down. Right. Oh, my gosh.

All day. Horrible. Awful. Oh, my gosh all day horrible awful oh my gosh the orders kept coming in and vice versa you know website sometimes you do scheduled maintenance or something go down for a little bit things are still shipping you know you've got people coming in hourly whatever you know it's not like you'd have the warehouse worker sitting around all day and then they go home at night and oh now you're back up now you're not shipping you know so it was really great to kind of have that there and i don't i doubt we would have called them microservices even if you know had the term been around back then but uh it had a lot of the advantages of

being able to kind of scale and whatnot but it was split up by business capability there so it was totally separated and we had an etl process for getting things in between and it totally functioned like that yep yep yeah i don't know that i want to be careful though because like just because you have different applications for different you know business departments within your business that doesn't necessarily that doesn't equate to microservice though right right they were systems right yeah different databases different systems but they definitely were not microservices they wouldn't have scaled right like i think that's the big differentiator that of what like what he said is you know one system could go down and the other one still be running but

they were still potentially using the same database um you know like one system we was using one database so if something went wrong in that database it didn't matter about the services or anything else the whole thing was down right well what i'm talking about erp was uh oracle and friday was single server so they were totally disconnected and there was like a queue between them right so in that case like the databases were so the applications and like they were totally disconnected the only thing that connected them was a queue yep or a series of queues. But they weren't scalable, right? Like we couldn't spin up a thousand order processors or anything like it.

You still had, you still had some of those issues. Yeah. So old school. Yeah. Um, what else we have? Oh, so like, how do you break down the business capability? So it could be organizational structure, right? Like he was talking about departments earlier, customer service, oh, so like, how do you break down the business capability? So it could be organizational structure, right? Like he was talking about departments earlier, customer service, shipping,

whatever. It could be the domain model, like what we covered in domain driven design, you know, what are some good bounded contexts to set up? I know we talked about aggregate roots and things like that back in the day, right? Like these Like these units of work that kind of needed to happen, which the next bullet point is, which leads to decomposing by domain-driven design. So this was interesting. I don't know if you guys have seen this or heard this before, but I thought this was really good. You can decompose by verb.

So like an action, order, ship, pay, something like that, right? Or decompose by the noun. So you have an account service or an order service, like the things that are parts of your system. I kind of like that. Go ahead. kind of like that um go ahead well i mean and we definitely had this kind of conversations as it relates to rest so now i'm i'm trying to think like how that would work like if you decompose this microservice as ship right you know like well it would be a service for shipping, I guess, is what they're saying. You would create a shipping service because that's your verb. Right.

If there's an ordering service where somebody places an order, that would be the service. So it's pretty interesting. I'd never thought about it in that way. But I guess it would be it'd be a good way to start looking at your system and saying, what are the actions that either the system takes or that users take when they're interacting with it? And then go from there. I think that might be a good way for you to sort of visually parse and break apart the features. I think the part that it dawned on me, I was getting caught up on the semantics of it. Because I was thinking of shipping service as like, well, the shipping department is the noun, right? Just like the billing service here is the noun, right?

And that's why it was just purely a semantic thing that was kind of like, you know, hanging me up. Yep. And then here's another thing they say, and this is sort of a parallel to how we design software is follow the single responsibility principle. So that service should be responsible for one and only one thing, right? If, if you have a billing service, it shouldn't be doing anything with a customer. It shouldn't be, shouldn't be doing anything with a customer. It shouldn't be doing anything with the order. It's only for taking payments or doing refunds or something like that. Get that money. Oh, that's right.

So I think, Jay-Z, you had some interesting things in here. Oh. Yeah, I had some fun questions. Part of this is kind of like if you ever listen to Software Engineering Daily, ZZ, you had some interesting things in here. Oh. Yeah, I had some fun questions. And part of this is kind of like if you ever listen to Software Engineering Daily, the host of that show, he's definitely kind of skeptical of microservice industrial complex. I think I actually stole that phrase from him. And so I think it's a good thing to ask is like is microservices

a marketing term is this what i'm kind of getting at here is is is this you know real help me out what's the question i'm trying to ask is basically like is this a solution for problems that people have? Or is this, you know, a demographic or a market that companies are trying to create? I think it's legit for, for businesses that need it because of things like scale and, and maybe complexity too.

Right. Yeah. And so it seems like, yeah mean that's what that's what i would agree with too because like uh i went and looked at like who uses microservices and netflix uber amazon they are a different kind of class of companies and they need that stuff like we mentioned you know with shipping and whatnot it makes sense that maybe they have 250 developers that all they do is work on shipping software that figures out the best prices and how to coordinate that. Netflix too. Maybe they've got

teams of people that just work on recommendations and teams of people that just work on streaming and teams of people that just work on authentication. Who knows? It makes sense for them to organize like that. I don't know that it makes sense to go smaller but maybe. Maybe those companies that are kind of targeting them are trying to bring other companies up.

And the way you do that is you go after kind of smaller developers and you hope to raise them up. And I mentioned the articles I saw for who has abandoned microservices or if you just search for microservices fad or anything like that. I always like to try to look at the negative articles for stuff. You'll see a lot of it's just like people who had smaller teams or tried to share databases or they tried to basically have a distributed monolith and they weren't getting what they got out of it and so it's just scary to see how many projects for smaller teams have

turned out really badly like so badly that they wrote articles about it you know yeah i was going to add that you know to the question about like are they are microservices a conspiracy that um you know kind of echoing what you guys said like it is a necessity but i think that part of this in recent years like why it's become a thing is that if we were to rewind through our history right like i mean computer science as a whole is like an evolving thing that we're constantly studying new patterns, like trying to apply things and seeing what works, what doesn't. And, you know, if you were to rewind like, you know, 40 years, then the way computers were used is drastically different. So like, because of their limited capabilities and whatnot, they were

already like single purpose or for a given department. And, you know, you weren't trying to do everything with it. And then over time, uh, you know, it grew to scale where like we had enough compute power that, Hey, we could do all these things on the same machine. But then as we got to an internet age, then it was like, oh, but the amount of requests that we're getting, we can't possibly handle it in this way. We got to figure out a better way to distribute this. And so we're still evolving this thing that is computer science and learning. And from that, we're getting new patterns as our needs are growing because of the additional capabilities that we're using. And I mean, I imagine that, you know, if we're, you know, so by the time that Coding Blocks gets into the episodes, you know, the 1000s, based on our release schedule, it'd probably be like 30 years and you know like i imagine that like in 30 years there there's going to be patterns and and uh things that are like have evolved

because of needs that we we haven't even we don't even foresee yet like it it's so so far out there like you know i mean imagine imagine what the what kind of design patterns might be necessary for interstellar communication, like real-time interstellar communication. Because we have somebody on mars and that's not going to happen if he can't talk to cosmonauts in the international space station so um but you you see what i'm where i'm going with this though like so that's where like micro services you know 40 years ago maybe or like well i mean i think we established that all the great things in computing happened in the 70s whatever they were doing right then they got it right but you know it wasn't a thing that they talked about then right because they didn't have those the same

kind of needs that we have now yeah absolutely i think a lot of it is just kind of this uh expand and contract and expand and contract and so new ideas come in. People jump to them. Sometimes they pull back on them. But always some things stick. So there's some good things that have come about from this kind of revolution. And we'll keep on evolving and keep on doing that game. So here's a question for you that's not in our notes or anything. Sure. So we talked about what microservices are if you set up your own microservice implementation, right?

Would you consider things like AWS Lambdas or Azure Functions or Google? Yeah. Is serverless a form of a microservice? So to me, the microservices that we've talked about so far have been more kind of like application level focus, where they do some sort of feature-oriented or business-oriented type thing. And those are so technology-focused. They're literally bound by the technology, not by the use cases. And so I kind of feel like, no, but then when I scroll up and look at the definitions, it's like, well, kind of.

I mean, the reason I say is technically, if you were to create an Azure function or an AWS Lambda or whatever that takes orders, right, or does billing, you can set up the function to do very specific things, right? Or does billing. You can set up the function to do very specific things, right? And technically, it's kind of stateless. It can work with, you know, a messaging backend. Like, I mean, there's all kinds of things that you can do with them that technically they are just little services out there that will scale. And if you design them right and you're using the queuing systems and stuff right in the various clouds, you can almost make an argument that you're getting the benefit of microservices without having to manage the crazy implementation and infrastructure that you'd have to do on your own. I guess that's the

answer is like they can be if you have them share a database if you have them not be independently deployable because they're all tightly coupled then no right but it does seem like a good way if you're doing things right in those you know with those services that's you're kind of i mean i would think kind of yeah like you're you've got a good you're a good step along that path yeah yeah i was kind of thinking like to your question well if it was like if you had a uh serverless function hey am, am I microservices? But I think we decided it wasn't just one thing. I think part of the definition from earlier

in the episode was multiple things. So I was like, okay, well, I guess maybe if you were to stitch together multiples of these things that could version independently, then it could be. So really the answer is i don't know kind of maybe i guess it depends if you set it up right yeah yeah because you could you could still make a you could have a serverless function that could still be like tightly coupled to something oh i'm sure you know like absolutely um i mean i think okay like case in point like you did one for uh as part of a talk

if i remember correctly on um where you were scraping libsyn but you're real in that kind of way you're kind of coupled to whatever libsyn was doing so your thing could definitely break you know if libsyn changed their ui yeah that i wouldn't have called that one a microservice. I guess if I were to stand up three different Azure functions, like going back to the order thing earlier, one that does billing, one that does the order placement, one does shipping, you could totally set up those functions to where they just shoot off a message in Azure, right? In the Azure queues. And one of the things that's really nice about functions or any lambdas in most of the cloud platforms is they can be reactive. You can say, hey,

fire this function based off some trigger. And you could totally hook those things up by saying, hey, if you see a message hit the queue that there's a new order, then I need you to go create a shipping label in this function. And I need you to go do a billing thing in this function. So I think that all the building blocks are there. So, so you could set them up to basically be microservices that you don't have to manage all that entire, you don't have to set up a rabbit MQ. You don't have to set up the messaging bus and all that kind of stuff. Right. Like it's sort of all built for you. Yeah. Stitch it together. Well,

I want to be clear. I wasn't suggesting that it, that the Libsyn thing was a microservice. I was saying that it wasn't, even though it was built on top of a serverless phone. Right. Yeah, totally.

So I was trying to point out, like there are definitely cases where you, you can make something tightly coupled. Yeah, totally. All right. Yeah. One last question is basically, how can you tell if you should pursue microservices?

If you're making a lot of money and you can't keep up with the demand. Yeah, I think it's something if you're chipping over your own fee. If you've got a bunch of developers and it's constantly like, well, I can't do this until they do that. Wouldn't it be nice if we could just deploy without them?

So if you're starting to have those conversations, then I think you're having these kind of different self-organized teams that are getting each other's way. Then I think that's really a good sign that this might be for you. Yeah, I'll stop. All right. Well, we're're gonna have several links uh in the resources we like section for this episode uh microservices.io will definitely be in that among uh many other links

but uh yeah and so with that we now head into the favorite portion of the show alan's favorite portion specifically that i messed up earlier cause I thought it was mine. So, uh, yeah, I guess like we said, uh,

I'm falling apart and we saw it happen in real time and we appreciate you checking out the show and you could catch us out on, Oh wait, I forgot. Yep. This part of that breakdown. I'm just kidding. You thought I was really going to skip it,

right? Uh, yeah. So it's, it's, it's it's uh alan's favorite portion of the show it's survey says oh no i'm at tip of the week or whatever i don't know like did somebody put something in my water like what's going on here well i mean you're florida man there's always something in your water right like well yeah speaking speaking of florida man do you

might know the answer to this did you know that uh crocodiles could grow up to 15 feet no they only have four yeah they usually most of them are four they can but most only have four. Yeah, they usually. Most of them have four. They can, but most only have four. Yeah, you're right. Wow. Nice. Fine. Fine. Be that way.

You know they're making a movie about clocks? No, I don't have time. It's about time. Okay. Okay. Very well done. I'd like, I'll have seconds of that or something. I don't know.

I got nothing. All right. I do have a tip though. Okay. Let's hear it. Yeah. So, uh, NeoVim, uh, recently, uh, I was talking about wanting to learn Vim while I had a little vacation because, uh, that's what kind of person i am i guess and uh so uh klaus from slack uh comaton said hey

why don't you why don't you do neo vim instead so i looked it up and neo vim is a fork of them seven and them eight is like the what's out right now so fork of the last version and uh the main purpose behind it was to address some kind of technical debt and kind of design decisions that have grown a little long in the tooth. And it still acts like Vim. I haven't found anything yet that didn't work. Just, you know, like it's basically a drop in a replacement. But it has made some things better around plugin creation. And specifically, it did some kind of code cleanup to make it easier to make changes and speed up maintenance in the future.

And it now supports RPC for plugins. It's got a better plugin system. The RPC is important because it means you can do things in other languages if you want to. And it'll call out to it. So it doesn't have to just be written kind of in the older framework that it used to. It's got better support for like async background jobs, stuff like that. So I went ahead and installed it. I haven't made use of any of those new features.

But it works exactly like Vim. And remember, Vim is VI improved. So Vim was already kind of like an outgrow of the VI. So it's kind of funny. So when you install it, it's NeoVim, N-E-O-V-I-M. But when you run it from command line it's just nvim so you can do it apt to get or you can do a scoop or choco install or whatever brew install and uh yeah it's kind of like one of those things where if you're using them like why not uh try this out so

it's pretty cool and one thing um i read it was when i was reading about it um some of their kind of experimental features have been popular have now been incorporated into them so it's kind of been this kind of cool outgrowth where the person maintaining them was able to see like hey you know what they did this thing and it works so we kind of pull some stuff in here so just kind of cool to see the evolution of software that's been around for like

you know I don't know before IRO keys were invented that's how old them is like 40 years or something so it's cool to see it's still evolving. Awesome. All right. Well, uh,

for my tip of the week, I thought I would share like a recent, uh, find and purchase that made a super inexpensive purchase. But, um, you know, for the Apple watch owners out there,

um, you know, for the Apple watch owners out there, um, like sometimes, sometimes you want to have a, like another charger for your, for your Apple watch. And specifically for me, what I wanted, the reason why I wanted an additional charger was, you know, the charger that came with it had, you know, I've been using that forever since I got it, uh, or since I got my first one in and it was fine. But, um, with like a version or two back, I don't remember when Apple introduced this new, um, uh, functionality into both iOS and watch OS for like sleep tracking. And then it was like, okay, well, when do I ever have time to charge my watch? Because previously I would charge it while I was sleeping. And I've gotten into

wanting to understand, okay, what are my sleep patterns? Because sleep is really critical to your health. If you want to think about your mental health or Like, you know, if you want to think about like, uh, your mental health or just your physical health, like, you know, sleep is ultra, ultra important. And it's definitely something that I have never put a priority on, but, but I, but I want to try. Right. And, and so, uh, I wanted to start tracking my sleep to just kind of understand like, what am I doing and everything. And so I needed a place to charge and I didn't want to just buy another charger like what Apple has because then you know I don't want to deal with the extra cabling and whatnot and you know so that that just sounds messy and like I'm the type of person that like for my desk if I need a cable that's only seven inches long I will find somebody

that sells that cable in that length so that I have like just enough cable, you know, so that I don't have to have like eight feet of cable wound up and, you know, bunched up somewhere because that's like a pet peeve of mine. So this is a charger for the Apple watch. It's got almost 5,300 reviews on Amazon with a 4.3 rating on it. So we've seen higher reviews, but out of 5,300, I would call that pretty darn good. And what it is, is if you have an AppleWatch, think of if you had that little magnetic base and it plugged directly into a USB port and there was no wire at all. And that's what this is. It's a portable, uh, Apple watch charger. You could just plug it

directly into the USB on your laptop and then just set the watch there. Or in the case that like mine, I have it sitting on top of a, um, I have it plugged into a USB dock. So the, it's, uh, so the thing is standing up vertically, but there's a cover for the USB port, uh, portion of it. And the cover has a hole on it so that it slides up and over that to act as a shelf for the watch. so that if you do have this thing standing up, it can still support the watch in that vertical stand, if I'm making any sense at all. But if I'm not making any sense, then trust me, there will be pictures. You can see what I'm trying to describe on the pictures on Amazon, but this thing is like less than 11 bucks in a variety of colors. And it's fantastic. It's just so convenient and easy

to have that charger there with no wiring cluttering up my desk. I like it. Although I'm not a wearable guy, but I like it. All right. So, um, I did a lot of work this week and I don't think I actually learned anything or accomplished much, unfortunately. So I didn't have any good tips myself, but I did go to our Slack channel, which is amazing. So if you're not there, you should definitely contact us, leave us a DM on Twitter or email us or go to the contact us form on our site. There's a few ways to get ahold of us, um, and ask to join the Slack. So most of these came out of our tips channel and Slack and really some good ones. So again, we said, uh, Jamie at the top of the show for, uh, on GA prog man. Uh. So he shared a link that is a free download,

a free download, a free download on Docker security practices. And it's basically a little ebook that will tell you some really good things to do to make sure that your Docker images are secure. That's most excellent. So go check that link out. And then also from angry Zoot up there,

she had one that was pretty interesting. I don't usually install a bunch of Chrome extensions, but there is one here that is really cool. It is basically the daily dev homepage. And it's, it's a, a Chrome extension that allows you as a developer to kind of get news about, um, development stuff going on. So instead of you having to go, you know, through hacker news and all that kind of stuff or Reddit

or whatever, this is kind of way to get it on, on your own homepage so that you can see that stuff without having to go all over the place. So it almost looks like an aggregator for dev information. It's like RSS feeds have been aggregated into an app or an extension to your browser. Yeah. So really nice. Right. Yeah.

Um, and then another one I, that I want to share from Derek chase that was up there in our Slack as well. And I don't even remember if this was, this might've been an episode discussion, but I don't even know how we got on topic but it was about like uh code coverage and that kind of stuff and and we've talked in the past about setting up something like an independ or not independent well we have talked about independent yeah independent coverage yeah and setting those

things up on build servers and that kind of stuff. So anytime people do PRs or whatever it goes in and Derek was like, dude, I run this thing local, right? So that I can sort of see if things are good on my system before I even put in a PR to change. run sonar cube and a docker image and and if you go to the link i've got here on docker hub then you can actually see that they've got it set up to where you can mount some volumes do your sonar cube stuff after your builds and you're good to go you can get the reports and everything right there so um i thought that was a really good tip right like you don't necessarily have to go through all of it on a Jenkins build or something like that. You can do it locally and see that stuff. So in Sonar Cube is something we've talked about many times. We should do an episode at some point.

Episode 61, episode 69 and episode 72. Yep. So yeah, I mean all three great tips. go check those out i mean again those are from members of our community that are constantly sharing and just giving great information out there so thank you there's an implicit tip there that you didn't call out which is like i don't got all of these from our slack community so i did i did call that already well well what i'm saying though is the the tip wait for it oh is that if you aren't already a part of our slack community community you should you should become a part of our slack community and then you don't have to wait for alan to find these and save them on air as a tip of the week you could just be part of the conversation as

it happens totally um it is really an amazing group of people there. Uh, we, we, you know, are fortunate to, uh, you know, have virtually met them and, uh, yeah, we really do appreciate it. So, um, I guess you could go, you know, find, uh, some, uh, go to, go to codingbox.net slash slack and then be disappointed when the app tells you that you need a certain domain in order to get access to it. And then you can send us a tweet or an email and say like, Hey, what do I got to do to get access to that? And then we'll just reply back with a invite sent.

Right. So yeah, there's your easy button for that. Well, speaking of easy button, there's a link on that page now that you can click to send yourself an invite sent. Right. So, yeah, there's your easy button for that. Well, speaking of easy button, there's a link on that page now that you can click to send yourself an invite. Well, actually, I mean, it just flat out is the invite link.

I like it. Oh, you did get it to work. You fixed it. Nice. Yep. So I think this link should never expire. So it should work. We should no longer have any problems.

It's not as slick as the solution we used to have, which is now gone. But yeah, if you go to coding box, that's a Slack. There's a big link around the top. It just says, click here to invite yourself.

And boom. Awesome. Jay Z with that SLA meeting requirement. I like it. All right. Uh, so with that, um,

you know, as I mentioned earlier, if you haven't already, uh, subscribe with that, um, you know, as I mentioned earlier, if you haven't already, uh, subscribed to us, you can find us on whatever your platform of, uh, choices where you find your other fine podcast, but, uh, you know, iTunes, Spotify, Stitcher are definitely some of the big ones. Uh, and as I asked earlier, well, I guess I should rephrase this as I threatened you earlier. Um, if you don't leave us a review at www.codingbox.net slash review,

where you can find some helpful links, uh, I'm, I'm gonna, I'm gonna do it. I'm really, I'm going to unleash Alan or Joe next episode to do the bag. And then,

you know, you're gonna, you're gonna regret it. So like save yourself the trouble and give a review while you can before it's too late. Trust him. Oh, geez. Coming to you live from WJZZ. Save yourself the trouble and give a review while you can before it's too late. Trust him. Oh, geez.

Coming to you live from WJZZ. It hurts. I can't hear it. So while you're up there at CodyBlocks.net, make sure you check out our show notes. If you haven't before, they are copious. We have examples. We have discussions. definitely leave a comment on on things say hi whatever and also if you have any questions or feedback or anything you can

hit us up on slack or go to the contact us page on codyblocks.net and whatever you do do follow us on twitter at codyblocks and head over to codyblocks.net and you find all the social links at the top of the page yeah