Coding Blocks - Transactions in Distributed Systems

Episode Date: September 27, 2021

Joe goes full shock jock, but only for a moment. Allen loses the “Most Tips In A Single Episode: 2021” award, and Michael didn’t get the invite notification in this week’s episode. The full show notes for this episode are available at https://www.codingblocks.net/episode168. Sponsors Datadog – Sign up today for a free 14 day trial […]

you're listening to coding blocks episode 168 subscribe to us on itunes spotify stitcher and more using your favorite podcast app and leave us a review if you haven't already and uh this is the coding box today we'll probably show notes examples discussion and more and send your feedback questions and rants to uh comments at codingbox.net and you can follow us on twitter at coding blocks where we're super busy or head to www.codingblocks.net. And you can follow us on Twitter at Coding Blocks, where we're super busy. Or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I am Alan Underwood

recording from a dungeon. I'm Joe Zaka recording from sunny Tidesville, Florida. And we're missing outlaw. We're missing outlaw today. And we've kind of bootstrapped this whole thing right like jay-z's put together his own mic stand uh i'm in a corner it's gonna be a fun time

yep and we're both surrounded by alcohol so who knows what's gonna happen we truly are that's awesome this episode is sponsored by Datadog, the cloud-scale monitoring and analytics platform for end-to-end visibility into modern applications. And Shortcut, formerly known as Clubhouse, because you shouldn't have to project manage your project management. All right, well, this week we're going to continue talking about microservices, which is a discussion we started a couple of weeks ago. We're going to talk a little bit about transactions and some best practices.

And, yeah, that was episode 165, by the way. And you don't have to have listened to that already. So this is just kind of picking up on some notes we had. We got a little distracted there for a minute. Yeah, but why wouldn't you listen to 165? I mean, everybody has two hours to burn in their life, right? So if you have you know maybe it's a good one yeah all right cool and so a little bit of news um so first of all huge thanks to scott harden uh who mentioned to me that we have missing our podchaser reviews it's a service we haven't checked on in a while so that's a way to leave reviews which we love without having to create like an apple account or whatever. So, yeah, we've got a couple names to read here, so sorry for being

late. So, Are you going to do this one? I guess the first name has a bit of a word in it, so hold on, I'll censor it. So, a big thank you to Alexi Beep, Nicholas J. Larson, Kubernetes, on i'll i'll censor it so uh big thank you to alexi beep uh nicholas j larson uh kubernetes

gaming fix uh jay carty madsen uh rm quist martin smith 1968 and uh midardus i guess uh pod chaser is a little bit uh lax with some of their naming rules. But thanks for the reviews. And if you have a creative name that Apple won't let you get away with, leave it on Podchaser. Right. It will do the censoring. So, yeah, in iTunes, I've got Kid Boyati, Metal Geek Steve,

Came Tumbling, Jstuff16, and Freak. Oh yeah, cool. And hey, we got a review on Audible too. So this one's from Anonymous. I guess Alan, you probably put this

in here, right? Yeah. You want to mention what they said about it? Yeah, so typically when people leave us a review on Audible, they'll sign it at the bottom of it so that they don't have to create a name or log in or do whatever. But he didn't, or she didn't. So he did put in his review that we're kind of like his mother, right? Like we tell him to go learn things, and he's like, eh, maybe. So right now the message is go clean your room and learn Docker,

please. Anonymous. Um, and, and honestly, there were some amazing reviews in here. Uh, we got people that said that, you know, we've helped them throughout their career. We got people that left some funny stuff in there. Right gave us some laughs like seriously really appreciate you guys taking the time guys gals taking the time to write us and you know seriously put a smile on our face and also you know share with us that we have helped you i mean we've been doing this for almost nine years right jay-z something like that just had the eighth anniversary thanks devon for pointing that out we totally totally missed it that's crazy so yeah man awesome stuff yeah and uh we got atlantic code coming uh kugan coming out um and uh yeah so that is in a couple weeks here october 9th uh and we've got a booth right uh i

think so so right after we're done recording this episode, I am signing us up for a booth. That is going to happen legit for sure today. Yep. Sorry, Jared, for the, uh, I got her feet there. You know, the Corona coronavirus, you know, what are you going to do? Everything is backed up, you know? That's right. That's right.

All right. Yeah. So, uh, stop on by there and, uh, hang out. Say hi. Yep. All right. Yeah. So stop on by there and hang out. Say hi. Yep. All right. So again, we're picking up where we left off on the last one is we were talking about like we had gone over all kinds of information about microservices, but where we left off was decomposing microservices or decomposing an application into microservices, right? Now what we want to talk about is one of the harder parts of dealing

with microservices. Well, I say harder parts. Is any of it easy? I'm not really certain that it is. No. So, one of the things that you get when dealing with a relational database that you kind of take for granted over the years when you've been doing it are transactions, right? We've used our canonical reference in the past, which is, you know, an order table and then an order details table, and then maybe a products table hanging off that. And if you're going to place an order, then you're going to decrement the inventory there. You're going to add an order detail record and you're going to add an order detail record, and you're going to add an order header record, right? And those all have to complete successfully. And if they don't, then you have a rollback that'll basically, you know, delete those records back out. Well, in a microservices

world, each microservice sort of handles its own little piece of things. And because it's distributed, dealing with these type of transactions and making sure that the state is good at the end of it becomes way more complicated. So that's what we're talking about today. So yeah, what about transactions? I think we left off the site that we used, and I think Jay-Z, you're the one who found this site, and it's really good, Microservices.io. They suggest this thing called the Saga pattern. So you call it Saga or Sega?

Saga. Saga, right? Oh, my gosh. I didn't even think about it. I call it Saga. And I want to mention, too, on the book that we love so much, Designing Data-Intensive Applications, they actually have a whole chapter just on basically the saga pattern. So we're definitely not going that deep this time, but they have all sorts of really good information and like really dive deep

on it. Oh dude, maybe that'll be the next episode then. I didn't even realize. Cool. Yeah. One of our favorite books. Yep.

All right. So, uh, called saga. And, the deal here is that remember, we talked about microservices. We said that for them to be microservices, they really need to talk to their own databases. So if you've got a customer microservice and a product microservice, one might have Postgres database.

The other might have Mongo. Who knows? And it's up to them to kind of abstract and protect that. And so if you need to have a transaction that spans those two data stores, like a customer purchases a product, then you need to make sure that the whole thing goes through or it doesn't. And so if one of those services might fail and the other services dependent on it, then both of those transactions need to fail and essentially be rolled back so that no changes are made to that data but when you've got microservices that's spread out you've got two different databases and so when we had a single database that was asset compliant it kind of had this um basic pattern is a two-phase commit where it basically ensures that uh you know things happen in the right order and they either happen fully or they don't they provide a mechanism that makes it easy but when you have distributed services all bets are. And so the patterns we're talking about today are ways to make sure that happens across different systems. And you have to, as a developer, take on a lot more responsibility there.

Yeah, it's a lot more code. So this is where they start talking about with the saga pattern. You have to have a sequence of local transactions, right? So unlike a regular application that maybe is just talking to a single database where you might put the transaction either in a stored proc, right, with a commit and a rollback, or you might even be able to do it in the application just because using the database driver itself, the code itself can have a transaction that knows how to communicate with the database to do it. You can't do that here. So basically let's, I guess, um, probably the easiest thing to do is stick with this order

and order detailed thing is you need to call the order microservice and say, create an order, right? And then this thing is going to manage its own transaction. And then after that, you know, maybe that thing finishes, you get the order information. Now you have to go to the order detail service and you say, hey, now go do this. It has to maintain its own transaction, right? And the way this thing happens, I'm going to read this off here because i actually did the note so that it would make a little bit of sense um your order service saves to its data store and then it sends a message out saying that it's done the customer service attempts to save to its data

source and if it succeeds then the transaction is If it fails, it sends a message saying that it failed, and then the order service would need to run another update to undo it, right? So basically, you're gonna have this message broker that's sitting there somewhere that you can send these messages to, and depending on whether or not something succeeds or fails, then the other microservices are going to be listening on those message queues

and react accordingly, right? So it's already way more complicated than just a regular application that's talking to a single data store. Yeah, this is really interesting because it distributes the logic and so that each individual service only needs to know where to listen for work and where to publish the results of that work. And so it keeps them dumb to the whole chain of events and lets you kind of orchestrate things. So if later you want to add a fraud service or some other new services into the chain, you don't have to make any changes. Because each one basically is listening on this side and publishing to that side. And so you can kind of interject stuff, which is really cool.

And it makes things kind of easier to work in isolation. And so, you know, there's some, some good things about that. Just being able to have your services as dumb as possible is really nice. Now there is, there is something to call out here. So there's a couple of ways to achieve this, at least called out by the articles and stuff that we were reading, there are choreography based, um, you know,

transactions or orchestration based saga transactions. And to, to call it out here, essentially when you're in the choreography one, each microservice handles its own thing. So as, as you say that I want to save the order when it does it, if it succeeds or fails and it's going to fire off its own domain event message. Right. And then, like I mentioned before, the other microservices are going to listen on those cues and say, OK, the thing succeeded.

So now I need to do my part. And then it's going to send off its domain event at the end of whether or not it succeeded or failed. And then maybe some other microservice has to respond to that. Right. So each microservice handles its own state and notifying whether or not something finished or didn't successfully. And then other microservices just react based off that, right? So there's no central brain in that, in that particular setup, which is super nice because it's loosely coupled, but it's also way more complex because you have a lot of touch points, right? For everything that happens, there's multiple actions that can happen after that, that occurs. And sometimes you want a brain. So, you know, what happens if you've got some complex logic, like I mentioned, like a fraud service, like, and it says, well, if this thing, you know, gets such and such score back from, you know, my fraud machine learning algorithm. And also this transaction is coming from a vendor that has a lower rating score or something,

then in that case, I want to take the information from those two individual services and change the flow. And that's not something you can easily do without having to do a lot of kind of carrying that information forward. So it doesn't really work very well with this choreography-based saga. And so we're going to talk about a way to introduce a brain in order to be able to kind of make those flow changes, which is even more complicated,

but offers you some more advanced control over what you need to do. Yeah, the interesting thing is what you just said. It is true if you're trying to separate your microservices into, I don't know, let's call them like well-defined bits of things to do. You could potentially do what you're talking about, which is having more complex things, but you'd probably have to add even more microservices, which basically imply that, hey, if A, B, C, D, and E get done, then F can do its work. But that means that you have a whole ton of microservices to go down as opposed to, as opposed to if you have the, the orchestrator, then maybe you only have three microservices and it can know what the state is of things after the first two finish. Right? So it just, you're going to be adding complexity either in the amount of infrastructure you have

or in a single piece of infrastructure that has the brains to know how to handle these other things that are going on, right? Yeah. And, you know, we've talked about Lambda architectures before, which is an architecture for event streaming where you've got these long running processes like fraud is a great example where maybe it takes a few minutes to fully vet a transaction from a credit card but you don't want to hold the person there at the grocery store up for a few minutes and so what they'll do is they'll do a cursory like a simple check and say yeah this looks good enough for now and then we'll double check it later and so in that case you've got like a fast service and

a slow service that do the same thing and then the slow service ultimately wins but we don't want to hold up the transaction. So it kind of becomes like a problem that we'll deal with later. And so it's just more advanced routing that we have to deal with there. And you totally lose that with the choreograph. So an example might be like,

well, if the fraud service is down, maybe we just want to wait 30 seconds and then we'll just bypass it. We'll just skip it and we'll mark it for later you know like a fraud checking later and so there might be services where you say even though it's down i don't want to stop this whole transaction we'll just you know mark it for checking later and if you've got this flow where you're relying on some piece to go and kind of publish to the next spot and you've got this daisy chain

of things that need to happen one piece in that chain is down the whole thing is down yeah and the whole transaction fails and so it just it's simpler um but still not simple uh but uh it's it it works for i think probably most use cases yep and so real quick just to this up, to wrap up this choreography one, the way that they say it here, and it makes sense, each service knows where to listen for work it should do, right? So new action from a customer. Hey, place an order, right? Something finds that, hey, I need to place an order. It goes and does work. It knows where to publish the results of its work, which then means it's up to the designers of the system to set up all the hooks to know to do the next thing in the chain. Right. So your complexity comes in managing the message queues and knowing which microservices need to respond or do some action based off a message

that hits a particular cue so that's where the complexity comes there um did we say what was good about the approach i think we did just the simplicity sort of right yeah yep and i want to keep this section uh short because I have many tips this week. So I want to make sure that they have the time to properly shine. Jay-Z, you make it up for like a year of tips. Nobody knows how the sausage is made in this factory, but we all stress about, man, what is our tip this show? So it's always a scramble, right?

But he came loaded with like a book full this time. That's right. You're ready. This episode is sponsored by Datadog, the unified monitoring platform for full visibility into all of your serverless functions. Triple-shoot 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 mapping so you can get complete observability into your serverless environment. And if you're interested in

microservices, and based on this episode I'm going to go out and limit the time. Datadog is like the champion of tracing and observability and their company is perfectly set up to be the ones to help you with all of your needs for those things and tracking what's going on for the health of your microservices

as well as what's going on between them with tracing which is just fantastic and bonus their Dash conference that they do every year is going to be online this year. It's coming up October 26th to the 27th, and it's free and it's amazing. The talks that come out of it are really great. And even if you missed the conference,

I believe every other year they've ended up publishing the talks there. So you can check it out. And it's going to be a fantastic just dump of really great content out there. So make sure to pay attention to their website or Twitter or wherever you get information. Yeah, maybe we'll try and find a link and put that in the resources as well. So start monitoring today with a free 14-day trial and receive a free Datadog t-shirt after creating one dashboard. Again, visit datadoghq.com slash coding blocks to learn more about how Datadog

can help you optimize your serverless environment. Again, that's datadoghq.com slash coding blocks. All right. Hey, I think you dropped, somebody dropped a note in here that we got from micro g we should probably share this now yeah yeah so uh i was here not here so we are skipping the uh we're skipping the uh survey because it's you know kind of hard to have the guessing game with only one person uh so uh this uh this is just a quote um and i don't think he he came up with this quote but he did share it today in Slack, and I just thought it was funny. So the code I wrote sucks. The code I'm writing right now is cool,

but the code I'm going to write rocks. Yeah, man. I identify. That's how I feel. I identify completely. Oh, and this is the portion of the show where you need to do our late-night DJ voice section. That's right.

Yes. All right. Hey there, listener. portion of the show where you need to do our late night dj voice section so yes all right hey there listener this is uh rock and roll jay-z here asking you to leave a review because we love them so much so uh fire up that pen and paper get yourself a uh whatever you use to write write reviews i don't know i'm sorry this. I'm not, we need to take that improv class. I keep saying it until then. Uh, you can go to cutting box.net slash review. And,

we try to make it easy by having links up there. So if you don't mind, uh, leaving a review, there's several different ways to do it. And we, uh, are eventually consistent about reading them.

So might be a little late sometimes, but we'll get there and really appreciate it so it helps us grow the show that's so awesome and so this was the shock jock voice this time yeah i was going for like the obnoxious like morning dj you know it's like seven in the morning and your alarm clock comes on and there's somebody who's just so excited to you know talk to you there and it's terrible that's amazing hey i gotta say that we have had an overwhelming positive response to the to the dj voices so um if you disagree with that you just have to write a review and tell us that you don't like it right like that's how you get that voice heard so um yeah excellent that's how

it works you tell us you like something we just keep doing it until you don't that's right if you've been with us a while you know how we work all right so the next portion is the second part of the saga stuff so we talked about the choreography right the next one is the orchestration based saga and i do you want to read the steps on this one jay-z uh yes so uh in this case we talked about there being a brain and this is you know what we're talking about that and what we're calling the brain is an orchestrator because the orchestrator knows about the different uh other services that are around and it's able to call them to do things so if you remember the example

alan gave before uh where we basically placed the order. So here's how that same flow would work if you had the orchestrator. So the order service receives the post to slash orders, and it creates the create order saga orchestrator. So it's actually creating the orchestrator object. This is the brain, remember, for this particular transaction. And the saga orchestrator goes, and it the brain, remember, for this particular transaction. And the Saga orchestrator goes and it creates the order in the pending state. It then sends a reserve credit command to the customer service. And then the customer service goes and tries to reserve the credit for the charge. And then the customer service sends back

a reply. And then the Saga orchestrator takes that reply and either approves or rejects the order. So in this case, the orchestrator was created by the order service and then communicated with the customer service object. And once it was done, it relates information back to the order service. So it kind of acted almost like a mediator there. Something that's standing in the middle. Yep. And you know what's funny is you said that you say saga but every time since you said saga so i i don't know that i could trust

your um yeah your pronunciation bias on this i don't know what to say now i'm consistently inconsistent what can i say that's good um so we said, this, this orchestrator has a brain and so it centralizes that logic. That's really the big difference. The, the choreography was all distributed logic. It was all distributed, um, local transactions. And this other one is basically like, yo, I'm going to be the one that goes and gathers all these things, which is to me, it seems easier to reason about, right? Like you have one spot to where you can go and you can trace how things happened. Right. But I'd imagine this also is quite a bit more complex. Yeah. And that that's the thing is like this orchestrator has to know about these other pieces.

And so if you want to make a change, then you might end up having to change both the customer service piece and the orchestrator in order to do things the right way. And so you've got this integration piece and that's where a lot of bugs happen because that's where a lot of changes happen. And so it just kind of brings the complexity to one spot and it can be harder to abstract that a little bit. And so you can imagine, you know, we talked about these services being designed to operate in isolation. Now, if you're a developer wanting to test something, instead of just kind of like looking at my piece and say, did the message go from here to there, you kind of have to look at them more. So it's just, I don't want to say tightly coupled, because you have options and how you actually implement it, but it's harder to do it right, I would think. Yeah, I think what you just said is really the key is it's not, this one piece will be tightly coupled, right? Like this one piece has to be tightly coupled to all the other services, which kind of stinks because it sort of breaks the whole paradigm, what you're trying to do with microservices. But on the flip side,

you have one place that can maintain the data consistency for multiple services, right? So it's like one consolidated place to look at this because I don't know about you. I think you have as well. If you've ever worked with some sort of microservice setup, one of the hardest things to do is to piece together what happened, right? You're basically trying to look at logs across multiple pieces of infrastructure that hopefully you've set up via a data dog or a Splunk or, or an elastic search or something to where it ingests these logs. And hopefully you set it up right where you had a transaction ID that went across all these things so that you can see what happened. But trying to tie all that stuff back together from an asynchronous type of of world is really difficult.

Whereas if you're doing this orchestrator, you might have one spot that you can look at and say, hey, the orchestrator started up its own orchestrator object. And then it called the order service. Then it called the customer service and it got these responses or whatever. Right. So I don't know, man, it's, it stinks because you're, you are more tightly coupling it, but it also centralizes a lot of the pains of what you experience when you do microservices, the, um, I guess microservice way yeah you kind of convinced me so originally i kind of liked the idea of the uh like the daisy chain uh the choreography uh because it seems simpler i can like focus on each piece in isolation but now you kind of

convinced me the other way because what it does is this uh this orchestrator is a model for the process and so when i think about this as a, like this needs to happen and this needs to happen based on that result, either this or that needs to happen. That's how I think about the problem. And so now we've got this service that models that. And like, if I want to know if things happen correctly, I can go look in one spot rather than trying to figure out based on,

you know, the tracing or whatever information, what happened and what was supposed to happen. So now it definitely seems like a more kind of procedural way of doing things, which is how I think about things a lot. So that's pretty great. It's easier to mind map for sure. But so here's one of the things that stinks about it, right? Is they say the programming is quite a bit more complicated because now your orchestrator has to have the logic on how to do rollbacks and undo transactions on multiple services, right? Because you can't rely on that ACID type of transaction that we've used in databases for so long. So this episode is sponsored by Shortcut, formerly known as Clubhouse.

Have you ever been really, really, really, really, really happy with your project management tool? Most are either too simple for growing a engineering team to manage everything, or it's too complex for anyone to even want to use them without constant prodding. Yeah. Shortcut formerly known as clubhouse is different though, because it's worse. No, no, no, wait, wait, wait, wait. We mean it's better. So shortcutcut is a project management built specifically for software teams, and they're fast, intuitive, flexible, powerful, and many other nice, lovely adjectives. That's right. Let's look at some of these highlights. So we've got team-based workflows.

We give you individual teams that can use Shortcut's default workflows, or you can customize them to match the way that your teams work. Yeah, they have org-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and vice versa. And they have tight version control system integration. So whether you use GitHub or GitLab or Bitbucket, Shortcut ties directly into them so you can update progress

from the command line. They have a keyboard-friendly interface, which for me is super duper important because I don't like using mice. The rest of Shortcut is just as keyboard-friendly with their power bar allowing you to do virtually anything

without touching your mouse, throw that thing in the trash and iterations planning. So you can set weekly priorities and then let shortcut run the schedule for you with accompanying burndown charts and other reporting. So yeah, give it a try at shortcut.com slash coding blocks. Again, that shortcut.com slash coding blocks shortcut again, formerly known as clubhouse, because you shouldn't have to project manage your project management. So while it'll be easier for us as people, as humans to be able to go in and reason about what had happened at that time. Again, I go back to what you said about the tight coupling and it

really does make it right. Like if, if you need to modify that, that order service or that customer service or whatever, your orchestrator has to change now. And it may have to change all kinds of pieces such as, well, this is how you create the order. Well, now how do you roll back the order, right? Like there might be something that changed there. So you have a whole lot to manage in that one object now, as opposed to in the choreography one, you don't care about what these things do. Those microservices are made to operate 100% independently, right?

So as long as you've hooked up the right triggers for the actions that happen when something succeeds or fails it may not be as easy to go back and reason about later but it's a whole lot easier to to develop in general because these things have one job right so i don't know man yeah i like that to be able to do things in a debugger that sounds pretty nice that's true that is true that that is one thing man i think we even mentioned in in the last episode when we talked about microservices is it was mentioned somewhere on some site and i'd never thought about it ide's have been developed with single threaded um monolithic applications in mind.

And it was nothing I'd ever really thought about, but it's absolutely true. Like when you spin the thing up and you run it and you put a break point or everything, anything in there, you're good. When, when you have 10 microservices and a bunch of other things happening, your IDE is not super helpful in, in getting you where you need to go a lot of times. Yeah, it's totally true. So maybe we'll see some new IDEs in the future. Who knows? I don't want to build that one.

Yeah. True. So we got a list here of other issues to understand. So the service must update the local transaction and publish the event. True. So we got a list here of other issues to understand. So the service must update the local transaction and publish the event. So remember here, we said these services probably have their own data stores that they're interacting with in order to persist things. And so what we said about relational databases and asset compliance, all that stuff still applies. It's still there.

It's just in addition to that, you also have to worry about the whole chain. And so that kind of adds some complexity there because you think about, you know, you got a Postgres database associated to your product service and it makes a change to quantity. That means locally that's going to happen in transaction. It's going to be a commit. And if later an orchestrator or you get a message telling you to roll that back, you know, needs to come in and do that, then you can't rely on the database's normal mechanisms in order to kind of roll back that transaction. It's up to you to figure out, okay, what do I need to do to undo this? Maybe it just means updating the quantity back. But you can imagine some other cases where maybe things happen across multiple tables or collections in that primary data store for that service. There's got to be some brains there just in that service locally in order to roll that back.

And you think about all these different services working together, each one of them not only managing the global transaction across all of them, but they're all locals and being able to roll those back. And like it's a lot of stuff that can go wrong. Yep. And, oh yeah, so that was just the first bullet point there. The next one's interesting to me too. If you think about this in terms of a user on a website, let's just say to make it easy, the client that initiates the saga,

so the UI, right? You place an order. It's going to initiate the saga asynchronously. It needs to be able to determine the outcome at some point, right? So you made a request to the server to place an order at some time in the future. It needs to know that it completed. And so when that service sends back a response, it needs to do so when that saga completes, right? So this place order thing that's going to span however many microservices out there. So they also go in and say, hey, let's say that the service sends back a response when the order ID is created. And then it pulls, how do you say that well on on air so it makes sense

for the status of the overall saga so what they're saying here is you made a request for the order as soon as it can it returns you back an order id but it's not done creating everything it's not done doing the credit check and all that other kind of stuff that it needed to do so it's going to start sending back like this this loop that says hey keep checking to see when this thing's done and when it's finally done then it needs to send it back yeah and what happens if it what happens if the orchestrator goes down yeah right yeah i mean you need an orchestrator for the orchestrator hopefully you've got that thing redundant right so uh yeah so back to back to uh the episode uh the service sends back a response when the order id is created

and submits an event via webhook or similar uh when the actual saga completes and so remember said and uh order service kind of kicked this whole thing off so that's the final step there and i think we want to cover this i put a, so that's the final step there. I think we might cover this. I put a little question here at the end saying, when would you use orchestration versus choreography? Yeah, I don't know. I mean, we talked about it. I mean, I can think of good reasons for both, right?

And like we mentioned, the orchestration is easier to reason about as a person. The choreography seems to be way simpler and more loosely coupled than right than the orchestration so i man i don't know and either way you really need to uh you kind of need to solve the tracing problem because if you're dealing with market services you need tracing like period right you flat out you've got things happening across different systems you need to be able to debug that stuff and figure out what happens across these things in like a way that's human readable and human understandable so um that's kind of the the downside of the choreography

there is it's it's harder to see what's supposed to happen but either way you have to really solve that logging so i still kind of think of it as being simpler. Um, and maybe if you've, if you've got like a rigid workflow or pipeline where it's like these three things happen and maybe there's one branch, then, uh, I would probably lean towards choreography, but you know, obviously if you need some brains, if you need to make any decisions and kind of dynamically change that pipeline, then that would be a case where, uh, I want that orchestration. Oh, I like that that i like that more so than the just readable just if you have complex decisions that happen at some point i like that

because then it's then you have a place where you can go build that logic and you know there's a couple third-party services that um that will do stuff like that um that will actually act as an order straight i think um i want to say swix works for one let me check it's a sean swix uh let's see here i guess i don't have to hold the whole episode up for this uh you can look at uh i had another thought on this too and maybe i should have put it in the tip of the week but you'll get a bonus one here in the middle. We might've talked about this in the past too. So this whole ability to trace the flow of, of data going through microservices and things like that, there is a product out there called Jaeger, which allows you to sort of be able to see things that distributed systems and how they flow through.

And it'll, it'll sort of like tag extra data as it goes through that is really nice i'll see if i can find a link to it so that we can include it in the show notes and the other thing i mentioned it earlier so splunk is i mean if you've not heard of splunk then maybe you're not dealing with this type of or this volume of data but splunk was was sort of built as a log aggregation tool, right? To be able to pull things from, from multiple sources. Well, if you don't want to spend money on Splunk, another option that you could look at out there is Elasticsearch and Logstash. Those, and they come with a bunch of different agents for, I think they're called beats that you can set up to push data into Elasticsearch and use it very much like Splunk. So there are options out there and also Datadog, right?

Like Datadog probably makes it easier than anybody else on just setting these things up and then being able to go look at your data and visualize it. So, you know, there are options out there that you can use both paid and I don't want to call it free because setting up, you know, Logstash, Elasticsearch and all the agents is not a free thing. Although you may not be paying for the licenses, but, you know, just know that those are some of the things you can do to trace data going across multiple microservices. Yep. And I did look it up by the way so sean uh sean swicks uh at swicks the swyx on twitter um just friend friend of the show we talked before he's really big in the react community but he's working for temporal now which is basically microservice orchestration as a service and so they've got uh kind of built-in tools for

for saga patterns which is really cool very nice all right so that wraps up those two things on sagas well when when i was doing some some research and reading on this kind of stuff i came across a fantastic article so i've talked about in the past one of the things i love are these big tech companies or not even tech companies in this case, big companies that share what they learn as they're going through their development phases. And so Capital One had an article on how to avoid tight coupling in applications. Now, ironically, the link, if you look at it, their link was named terribly. It says how to avoid loose coupled microservices. I don't think that's what they're going for, because the whole point is to have loose coupled.

And if you read the article, you'll see. But I just wanted to quickly touch on it because it sort of reinforces some of the other things that we talked about here. The first thing that they mentioned in the article was, hey, make sure that you're using separate data storage. And the reason for it, I thought was really good is if you're sharing a data storage, if you have a an Oracle database or a SQL Server database or whatever, and all of your information is in that one database, it's almost impossible to hide the implementation from other services because they know what's happening behind the scenes. Right. And if you do that, you as a developer or a development team have a tendency

to design your stuff to fit what you see in that database. And it's hard not to. I mean, I know I've done it, Jay-Z. I'm sure we've all done it over time. Oh, yeah, definitely. Yeah, I still think very data-centric. I can't help it. Yeah, you think about the storage engine, right? Like anytime that you're writing a front-end

or a back-end application, you're like, oh, well, what's the database look like? Let me make sure that this will work with whatever data storage tier is. And so that ability to not hide something will know anything about it right so you are just going to design what you need your microservice to do to be as efficient and effective as possible given your data engine which is beautiful that's what you want yeah speaking of efficiency here this one always hurts every time i hear this uh share as little code as possible and this is something we've talked about a few times where um sometimes things can be kind of coincidentally the same.

And so if you've got like two services that both need to know about a customer, for example, it's very tempting to say, well, we'll create a core library and we'll have the definition of that customer being both and then they can share that. And so if I make a change to one field or add a new field or something,

then both get the benefit of that. And that makes so much sense as a coder. But what you're doing is you're tying these things together. Now you've got a strong coupling to this library that changes these two things. And, and that has implications for like, you know, deploying microservices and versioning and all sorts of other stuff that may not be immediately apparent. And so really, these things need to be as separate as possible. And so, of course, there's times when it's more practical to share code and you can get away with it. But the less you do that, the better off you're going to be.

Yeah, and it's funny. They call it out explicitly. I mean, again, this is Capital One. And I'm sure you can imagine any company out there that's like a credit company, they handle, God, I don't know, hundreds of millions of transactions a day. I wouldn't be surprised, right? So they actually say it is better to nearly duplicate those objects in a non-shared way, meaning literally copy and paste the code more or less. Um, so that the services can change independently, right? Even if it's a one-to-one copy of code, if they are going to be in two different services, do not link them together at all ever. Just don't

do it. Yep. That's yeah. That's tough. Uh, like I think we've had like, like if you're a programmer in the nineties, then you had like dry, literally like stamped into your think we've had like, if you're a programmer in the 90s, then you had dry literally stamped into your head as you were reading every article or graduating college or whatever. It's just such a way of doing things. But it makes sense. You'll lose some flexibility and agility there. Lowercase agility.

Yeah, exactly. Now, keep in mind, we're talking about microservices specifically. If you are in a monolithic application, I'd venture to say, then you probably want to figure out how to share that code, right? If you know that's not being used by anything outside of it, but in a microservice world, you know, it's going to hurt your brain to do it, but do it that way. Yeah, and the model that you deploy all at once. So if you change the code and it's used by two different faces, great, done. It's simpler.

These things share the code. You know that when this function returns the object to the next thing, it was expecting the shape of that. And so you can't guarantee that with the microservices. And so they need to be able to grow and do their own thing and move, and you need to be able to deprecate services and all sorts of stuff. Yep, totally. One of the other things that they say here is avoid synchronous communication where possible. So what this means is you have to buy in. If you want to go into the microservice world, you have to buy into the other infrastructure that always comes along for, for the ride. Meaning you have to deal with

message brokers, polling callbacks, all that kind of stuff, right? So we talk about message brokers, some of the popular ones that we've mentioned on the show before, RabbitMQ, Kafka is a big one. And also you're probably going to be looking at things like service buses, right? Like so ESBs we've talked about in the past that some people love, some people hate. They definitely add some complexity, but enterprise service buses,

those kinds of things that allow you to send domain messages that other things can listen on and react to. Like those are things that you're going to be buying into if you buy into the microservice approach. Yeah, absolutely. And, um, you know, kind of along the consistent with everything else we were saying, I should say, uh, they say, do not use shared test environments, test environments or appliances, which again may not sound right, but sharing a

service can lead to problems like multiple services using the same test service. And then, you know, that becomes a bottleneck or, you know, like one service bogs it down, or needs to go down for maintenance, or you're swapping it out or something, or it's just getting pummeled by all these other services. And you didn't really think about that being like a chink in your armor. And that's a really bad thing. And so that's where the problem is going to be. And then all those services are affected, not just the, you know, the one that's having the problem. So it's creates this cascading failure. You know, this goes back to something we talked about, I don't remember how long ago, but a lot of times they say that services, microservices should be

owned by independent teams, right? So, um, you know, the team that's working on the order service may not be the same team that works on the customer service. And part of the benefit there is, you don't know about what the other team has, what they're using, what they're doing. And so you don't, you don't really step into these pitfalls because you just, you're not aware of them yep and yeah you know i think in um adding fields is not a big deal right if all we ever did was

add fields to objects and yet we had to do it in five different places like that is a trade-off i'm willing to make it's really when you change the shape of things that it becomes a problem so what would happen i think it is like you just wouldn't you wouldn't do that refactor that you really should because you don't want to change the shape of an object or you know an aggregate root or something because you don't want to affect everything else downstream um but that's yeah it's tough so i don't really know what the solution is there i would definitely afraid of this code duplication encouraging you not to do the kind of refactors that you should. It discourages you from cleaning up data, which is a shame. Yeah.

Now, this last little thing that I had here, this was really interesting. I want to say that they had a diagram. Again, we'll have a link to that Capital One article in the show notes here. But they say share as little domain information as possible. Um, so I want to say that the one that they had is, and this goes back to not duplicating or not sharing your domain object is you have a tendency. If you're a developer and you're running an order system, you're going to have an order number on there. You're going to have a product ID on there. You might even have a credit card number as things are getting saved, right? That credit card number should only ever be passed to the account service, right? To charge that credit card,

then it should disappear. That particular field doesn't belong on any other microservice out there, right? Your customer microservice should not care about that credit card number. Your order microservice should not care about that. It is literally just for capturing that payment at the time of it. So you really need to be careful to not just try and duplicate all those fields across everything. Use the bare minimum of what needs to be there. I mean, it's almost like when they talk about in security and development, you know, least privileged access, right?

You give them the bare minimum of what they need to do it. Same thing with the fields. Only give that microservice exactly what it needs to get its job done and then move on. Yeah, that's a good point that, you know, that example of adding a field, how many of those services even need to know about that field? So if you're adding, I don't know, a picture to a customer's account, so the customer can upload an avatar.

Do you really need to have all your services know about, you know, that link to the avatar? Probably not. And so you shouldn't be sharing the object because it encourages you to send stuff and to multiple services. And then it's harder to see what actually needs that information. You're just opening up security holes along the way too. So yeah, I'm on board just copying, copy, paste, modify. Yeah. Build up what you need. Yeah, totally. Yeah.

So with that, I think, you know know it's been a month and a half i think since we recorded the other episode all the microservices so you know this this ties up this portion of it although knowing that data designing data intensive applications has a section on it maybe we'll revisit because that book's phenomenal. Yeah, absolutely. And now on to Alan's favorite portion of the show. Wait, wait, not yet. We got resources we like. We got those. So there's a few books from Amazon here that we'll have links to.

We've got some Stack Overflow stuff and the microservices IO. So definitely if you have not been up to the site before or you haven't looked in your pod, it looked in your podcast player app. There's probably a way to get to the show notes there. So there'll be links to all this stuff in the show notes. So definitely go check it out.

It'll be coding blocks.net slash episode one 68. Yep. That's right. And what I mentioned to Jim, Jim Hummel sign design painter evangelist you can find him on twitter and the slack channel uh he recommended a couple of really great books from sam newman um so we'll have links to those in the show like monolith the microservices and uh really goes uh deep in depth on these subjects so really good stuff and uh i mean the the author

of this is like that he's the person you know that you think of when you think of microservices. So check him out. That's excellent. And Jim knows his stuff. So if he's sharing something, definitely worth going and taking a look at. Yep. All right. So now are we on to Alan's favorite portion of the show?

I think so. But you got to say it the right way. All right. Here we go. It's the tip of the week. There we go. All right. And it's not a tip of the week there we go all right um and and it's not a tip this time right i think jay-z has like 20 tips did the internet go down for a second

we're having some uh network difficulties doggone it all right well you go ahead and start because i think you got like 20 of these all right yeah i Yeah. I don't know what you're saying, but I'm going to go ahead and just start talking, which is what I usually do anyway. So it's not a big deal. So yeah, I have several different recommendations here, several different tips here. So I'm just going to start. So we talked recently about Docker and some of the licensing changes that they're doing around Docker desktop. So if your company has more than 250 employees and there's some other rules around that, then you're going to start paying for Docker at work. And the fees range from $5, which works for individuals or, I think, low-income companies, or all the way up to $21 per seat for each person, which is, you know, adds up, uh, it's really

expensive. And so it's, uh, you know, a big deal and we're not opposed, you know, we talked about this depth before, but, um, I'm not making any sort of judgment on the fees. You know, I think people should get paid for their work. So, you know, that's fine. But, uh, I did want to check out some of the alternatives and I stumbled upon pod. And Podman is an open source containerization tool from Red Hat. And there's a couple of really important things I want to call out about it. One is that it's a drop-in replacement for Docker. It's even got the same number of letters. So you can actually just alias Podman as Docker.

Or sorry, the other way around. Alias Docker as Podman. So when you type Docker, it actually calls Podman and everything will still work. All your scripts, anything that you do normally, you know, your Docker run commands, your Docker build commands, they all work exactly the same.

It's just the underlying implementation is different. And before I tell you what that difference is, I want to call out too i heard an interview recently which will have a link in the show notes uh with the main person on the project and they have been at red hat for i forget how many years it was but they're basically a containerization expert from before we called it containerization so back when we were talking about um you know like like, ch roots and things like that, and virtualization, this person is a long timer who just really knows their stuff

is absolutely great article. And they talked about how they've been active with Red Hat, and Docker and all the different changes they brought in, but also the things they didn't like about Docker. And that's really good episode, you You should read it or you should listen to it. But one of the things that they didn't like about it was that Docker has a heavy reliance on daemons or daemons, which are basically these processes and programs that just run kind of in the background and their own threads. And so when you use the Docker CL cli it actually sends a request to this demon to go do in the work so it's it's almost like a a client server model except they just both happen to be on your computer which works really cool for uh cases where you have like a

remote server that you're working with and also a local but for the way docker people end up using docker and um the way things have really gone and I forget the name of Docker. It's kind of Kubernetes competitor that kind of died off. Swarm. Yes, Swarm. So the way Docker was kind of going for a minute, that worked out really well. But for where Docker has kind of ended up in the market now, where it's generally the tool that people use for building these images and containers, it doesn't really make a lot of sense to build things in this way and a lot of the bugs in docker and a lot of things that can go wrong a lot of the inefficiencies of docker

happen because of this daemonization process there's actually several daemons that end up burning now and there's all this communication that is kind of happening uh in a way that just doesn't really make sense locally so podman took a different approach and they said, let's just spawn processes up like a normal computer program would. And so when you tell it to create an image or you tell it to run an image, it actually just does it. It communicates with the resources directly and it's fully compliant, but it's just much more efficient. So it makes things faster.

It uses less resources. There are less problems with it, which is all really great. And one of the things that's different too, and where it gets its name actually, is that Podman was designed in a post-Kubernetes world. So it knew about Kubernetes. It knew about Docker.

It knew how people were using these things. And so Podman actually uses pods for how you run containers. And it has a way of doing this without Kubernetes, but it jives really well with Kubernetes. So you can then take what you're running in Podman and say, generate my deployment files or my Kubernetes files, which is always something that kind of struck me as being weird. I've griped about several times with Docker and Kubernetes where it's like, you go learn Docker and you're like, okay, now how do I run this?

And they're like, okay, well forget half of what you know. And now let's show you Kubernetes. And so it was almost like this bait and switch. Podman didn't do that. Podman said, no, look, you're already most of the way there. Let's add in some tooling to support you taking this to Kubernetes now. And so it provides a more natural path, in my opinion. So I'm really excited about the project.

And it seems like it's already working really well. And the author had some other really cool things to say and just interesting things about open source and the way that companies like Docker that run for a profit have kind of incentive to keep you on their product. And so they said that there were some changes there that they wanted to make the project early on like supporting multiple registries and stuff that docker didn't really want to support because it didn't make sense with their business

plan which is uh you know kind of rough stuff to say and we got to remember too this is coming from red hat who also has their own opinions on you know how things are run their own ways of making money so they've got their own vested interest so nobody's you know, how things are run, their own ways of making money. So they've got their own vested interests. So nobody's, you know, totally clean in this, but it's just a great episode. And so if you are doing a lot of stuff with Docker, you might want to check out Podband because there's, you know, some interesting things you get out of it and it's a drop-in replacement. So it's really cheap to experiment with. Excellent. Now, just to call it out, it replaces the Docker runtime engine that is that is on your computer although probably half of the stuff that you're using out there still pulls from the docker

registry yep so you might still run into some things there but this does at least eliminate one part of that thing right now yep and it also replaces the command line tool too so it kind of bundles those things together locally but it it's still fully compliant with Docker registries and everything else in the ecosystem. It's still fully compliant with literally everything. It just runs more efficiently, and it's got an easier path to get to Kubernetes, and it's got a little bit of extra flexibility,

and it hasn't really lost anything. Very cool. Yep, so it just seems to be a net good to me. All right. So that's my first tip. I got about 20 more. All right. So I'll keep it rolling.

So Unity, I saw a survey recently. I should dig up the link for that. I was talking about games that have been released, video games in the last couple of years. And Unity is just crushing it in terms of like the quantity and some of the uh the games that have come out of unity are just you know essentially really well done kind of professional products and it used to be for a long time that if you wanted a triple a game then you were going to use a different engine like the source engine or unreal engine or or whatever but now unity is increasingly more and more used for uh these bigger games in addition to bigger budget games

in addition to smaller games where it's always done really well and so i've been looking at it again because 2022 is coming up and the uh code blocks game jam is on the horizon so we're planning on doing that again this year or next year so i'm getting ready and i've been uh looking at their learning center and i found they have a ton of free courses that are excellent and so there's one that i particularly wanted to recommend which is called create with code which is kind of like a code focused uh course that actually walks you through through writing five micro games and i think they they estimate it's going to take you about 36 hours to work through, but it slices up really nicely into these five different products.

So it's not like something you've got to dedicate a whole lot of time to, especially if you know code, because you can blaze through some of the things that they want to do. And so rather than having you doing a lot of dragging and dropping and working with these kind of tools that are designed for anybody course this is a course that is designed for coders so it it kind of speaks our language and so it's really nice it's called create with code and i've worked for the through the first uh project and at the end of that they give you a project to download and they say okay now fix the bugs here's a list of bugs that are known in the project.

Figure out how to fix them. And then here's a couple of bonus things if you want to, you know, just kind of have some fun with it. So, like, I opened up the project and it's got a little airplane. And the first thing it does is, like, that airplane, like, flips over backwards and goes the wrong way. And the propeller's not spinning and all sorts of stuff. And so, those are all things that i was like you know as a programmer it's like instantly like oh this is what i need to do this is what i need to do and so it really helped me with the stuff that i had learned earlier in the in the

course so that was really cool so here's a here's a little add-on too is that we've talked about um jason weiman before but he's just got a fantastic Unity dedicated YouTube channel. So we'll have a link there. He did one recently on making a game in 2020 in Unity where he basically made Angry Birds clone. And I mean, when you look at it, it's like, that's Angry Birds. You know, he did it. And I think he talks you through the project

and actually creates it along the way in like three hours. So it's a long video, but it is like soup to nuts easy done all right um so about 50 more tips here uh i'll tell you go faster sorry uh educated that i am all right thank you uh don't worry like then my next five episodes are gonna have like total crap so you could just you don't even need to skip it because the tips will be over so quickly that you just won't even notice these are gold mines right here by the way so no no worries busy uh yeah so uh educative io uh we've talked about several times they've been a sponsor of the show and uh we talked about you know we've heard it in ads before that we really like their approach to hands-on teaching and they

give you these kind of courses that you read through and then they have like playgrounds and challenges and stuff so you can actually do your code and everything all in all in the browser but because it's also text-based you could scroll up or down or skip things very easily unlike a video well remember a couple episodes ago we talked about competitive programming well i happened to do a search for it and realized that they've got a course specifically on c++ for competitive programming so i started working on that thing as well and instantly learned several things about c++ that i never knew even though i had done a little bit in school before and so um it just had some really great tips just out of the box and it was designed for people that already knew how to code but were

interested in this kind of domain so it was so nice to be able to jump into something and not be introduced to like this is a variable this is a type of a variable this is the integer this is a you know it jumped right into here's the types of things that you should uh declare in functions and these are the kinds of things that you should declare locally or globally and i'll just tell you a quick example here uh he recommended or sorry uh educator recommended if the author was a guy but um they recommended declaring uh things like large arrays or other objects as global variables. Because when you do them as a global variable, they end up being stored in the heap. Whereas any variables that you create in functions by default,

any memory that you allocate unless you explicitly go out and do it otherwise, are going to be associated with the call stack. So if you create an array in a function, it's in the call stack because when that function ends, it gets cleaned up, right? It makes sense. But when you're thinking about competitive programming, you've got an array potentially of a million items in it, then it's suddenly very important to know that this memory is in the stack

and this is in the heap. So there's a lot of control over there, but it's just kind of cool to see out of the gate, here's 10 tips for c++ competitive programming that you maybe not have thought about because it's not necessarily relevant in other languages or other types of programming so it's just a really cool way of thinking about things that's actually really interesting so they recommend using the global because if it goes on the heap then you're not having to reallocate and deallocate every time a function call is made right like it's just that and the size so the stack is much smaller remember the stack is like i don't know you'll get an out of memory yeah you

get like one megabyte stack and c c plus c sharp i think and then the heap is like overflow right yeah you'll get a stack overflow exactly and so you're really using a lot of room because it's designed to be cleaned up when the function's over so if you just declare a big int array then you're using up a lot of this really precious space and c sharp it's going to create your array over in the heap just by default because so it's a modern modern language it has these conveniences built in at the lack at the expense of you not being able to have full control over it so it's just kind of cool to see like oh this person's speaking my language and they're telling me the things that i need to know as a language switcher

right which is really cool that is that's neat all right so we got 17 tips left so uh i'll go quicker so the most recent coding blocks mailing list uh contest we did uh we gave away a couple jet brains licenses but uh we asked for uh contestants to send in a summer song i guess this might have been august uh and so if you're in the northern hemisphere we've been experiencing uh summer and uh i just thought it'd be cool to kind of gather up like what people thought of as like the song that makes them to kind of gather up what people thought of as the song that makes them kind of think about all the things they associate with summer. And so I got a big list, and I made it into a Spotify playlist,

and so I just wanted to share that, so I'll have a link to that in the show notes. And don't worry, I did de-dupe it. So we got a few people sending someone named Rick Astley. I don't know what that was about, but for some reason people kept sending in the song don't you don't you regret me or something don't don't you regret about me forget about me something yeah don't you forget about me don't lie it's on his ipod yeah so don't worry it's only on the playlist once uh and you guys are a bunch of trolls. That's a great playlist. Got to say, I've been singing Cruel, Cruel Summer.

Thanks, Carl, for weeks now. All right. So finally, one special recommendation on the Spotify note. I discovered a new band that I really like, one of their albums for coding. And some of their older albums, they had a singer, which is fine, but I can't have vocals on when I'm coding. But their most recent album, which was from 2018, is just exactly what I want for coding music. It's active, so it's not putting me to sleep, but it's not too dynamic, so it's not putting me to sleep but it's not too dynamic so it's not um you know uh driving me crazy it's not irritating me it just fits in exactly with what i want to listen to which i know is you know niche this is what i like to listen to but hey it's my tip of the week right so if you

like bands like russian circles or mercury program i know most people in the world you know don't i've never heard them or don't, you know, don't necessarily like them, but for the people that do, I have a wonderful present for you. And that is night versus the name of the band. I've got a link here to their album, um, from the gallery of sleep. And I just love, I've been, I've seriously probably listened to this album, I don't know, 20 times this week alone week alone uh just coding and it's been fantastic so check that out we'll have a link in the show notes very cool all right so i guess we're down to one tip of the week now uh so mine because i don't know i didn't feel like i accomplished much last week. I don't think I learned anything. But I am stressed out about the Atlantic Code Camp thing coming up.

And I wanted to throw this out there because I know, Jay-Z, you and I both have done this. And a lot of people think that when you go to present somewhere, whether it be a small code camp like what we're going to be doing or at a conference or whatever, that you can't do it unless you're an expert at something. Right. And I want to tell you, if that's what you think, you're probably so wrong that you don't even know it. Like one of the great things about presenting in front of a group of people is you really force yourself to learn something pretty deeply in order to go up and talk on stage about it. So if you have an interest in something, maybe sign up for a talk somewhere. And nowadays, right? Like with COVID and all that, it might even be virtual, right? Like there's still virtual meetups and all that kind of stuff that are happening, but go, go sign up for a talk, learn it. You're going to have to do this talk in 30, 45 minutes or so. And you're going to learn a lot along the way.

And what you'll find that happens is while you may not have been an expert when you started, people will start to view you as the expert because you took the time to learn it and get all the nuances and get something working and present it. And it's a good way to, to grow your presence in your community. If, if you want to get known, like say that you're looking for a job or something, a great way to potentially find new, new job offers and that kind of thing, or to go and present and meet people and talk about these things. So, um, I wanted to share that just as a thought, cause I think a lot of people are intimidated by

it and don't get me wrong. The first time or two that you go up on a stage and you're talking in front of people, like the first, the first few minutes are you're going to, you know, it's going to be a little bit harder to breathe. Oh, you're going to be looking around like, Oh my God, what's happening. But after you get used to it, it's, it's kind of fun, right? It's a great way to meet people. It's a great way to talk about interesting problems in our industry. Like, you know, what do you do when you're dealing with microservices and all that kind of stuff? So, um, I recommend it. And one of the things I wanted to throw out a couple of things here, like meetup.com. If you're not aware,

meetup.com is a great place to find out if there are meetups in your area, right? Usually they can they can range from really small meetups, where if you're talking about something specific, like some machine learning, or they could be really big, Like if you've got a.NET conference or maybe even a Java user group in your area, those can be really good ways to do that. And then I also came across a site called alltechconferences.com. It looks like they've got a pretty big list of tech conferences that are happening globally, right? You can narrow it down to your region of the world if you want. I didn't see everything in there. Like I know Atlanta, Atlanta tech. Oh God, I can't even think

what it's called. Connect tech. Yeah. I didn't see that in there and I know that's coming up soon. So not everything's in there. So you still have to go to other sites, but this is a good place to go and look and see kind of what's going on around the world. so um yeah definitely if you if you want to learn something really well and you want to potentially be seen as somebody in the community that people can go to for information this is a great way to get started yeah i'll say uh the the meetups um the the organizers are often super friendly like i know in orlando like if you if you're interested in the dot net space like talk to santosh tell tell him, you know, you can send a, there's a variety of ways to communicate with the group, but, um, you know, he's, he's the president, but, uh, I think there's a, uh,

I'll find out, I'll put the link of the show notes to like, uh, I think they have a email list you can sign up or you can send it to if you're interested, but they're super, super helpful. You can just say like, Hey, look, I'm interested in talking about this. I've never done it before. I'm super nervous. And they'll say, Hey, well, we've got, uh, you know, we've got something up here. You can give it a shot. We've got another speaker, but there's kind of short and yours is kind of short, you know, it gives you a chance to try it out. Or they'll say, Hey, this conference, you know, we'll put in a good word or we'll get you set up over here, whatever. They'll help you find a way to get your idea out and which is amazing like they're not getting paid either they're just doing this

and they're so good at it so yeah it's fantastic yeah excellent all right and so i think that's about it so when we talked about transactions across microservices uh and we we gave you some some tips lots and lots of tips. Very wordy tips. And with that, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And make sure to hook us up with those reviews, which we tried to make easy by having you a page. If you go up to codingblocks.net slash review. That's awesome. And hopefully we'll have Outlaw back next time

so we can do the tip of the week. I mean, we're going to have to catch, or not tip of the week, God, his favorite portion of the show, Survey Says, right? So hopefully he'll be back soon. And while you're up there at codingblocks.net, check out our extensive show notes, our examples, discussions, and more.

And definitely leave us a comment on this one. If you've got any microservice experience you'd like to share, things that have worked out well for you or not. Send your feedback, questions, and rants to the Slack channel. Or, oh yeah, it's your turn now. Go ahead. Make sure to follow us on Twitter at CodingBlocks or head over to CodingBlocks.net. And you can find the social links at the top of the page. I want to throw one last thing in there, too, which, you know, it's kind of funny.

Someone, Scott mentioned to me, we never really say what the deal is with the surveys. You know, obviously like we talk about the numbers and, you know, what the questions are, but that's actually on the show notes for every episode. So if you go to like episode 168, for example, if you go to CodingBlocks.net slash episode 168, it'll take go to codingbox.net slash episode 168 it'll take you to the full list or if you go to the actual website and click the details button it'll have the question right there for each for each episode and you can click to vote and you also see the percentage that it's going to be too so you can actually get ahead of the game and know what the

results are going to be before we talk about them the thing is we don't go look at them but you can go look at any time and just see how it's shaping up and if your uh if your answer isn't winning then you can go drum up support for it yeah i think it's pretty clear that neither one of us know who's winning yeah yeah