The .NET on AWS Show, Featuring Laïla Bougriâ!

🎧👉 https://open.spotify.com/episode/3aINHtKauEUgqUZdYqvW0h?si=jQ9cHMxKRPGbVrW2ieWZGQ

Brandon Minnick 1:06

Good morning. Good evening. Good afternoon. Welcome everybody to another episode of the dotnet on AWS Show. I'm your host, Brandon Minnick, and with me as always is the amazing. Francoise, Francoise, how you doing? How's your week?

Francois Bouteruche 1:22

I'm fine. I'm ready. Fine. Hello, Brandon. A it is sunny. They're really soon in France. But I have the chance to be in the temperate zone because it's really odd in Europe right now. I've arrived. It's really odd in New United States.

Brandon Minnick 1:44

Oh, goodness. Yeah. This weekend was one of those weekends I'm in. I'm in Northern California in Napa. And it was in the 90s. And what's at 25 Celsius, somewhere between 25 and 30. So it's, it's warm. But yeah, there's places in the southern US especially, like the desert regions, Arizona, Phoenix. It's like 120, which is, okay. We're pushing like 50 Celsius. Like, there's people going this is how crazy it is. And how crazy people are? Death Valley.

Francois Bouteruche 2:23

Yeah, I've heard that this when it was expecting to hit the record,

Brandon Minnick 2:28

like 55. And people are going there. People are going there to just experience the hottest ever temperature recorded on Earth. And like now I'm good. Like my AC can barely keep up here. It's way less hot. Oh, goodness. So back to back to the announcements. We've got an awesome show today with an awesome guest. But But yeah, I first want to share a couple of things that we're working on. I have been recording some some videos for our amazing team, we've got this awesome, awesome tool called the AWS toolkit, that for some reason, seems to be one of the best kept secrets in the ATBS community, because not enough people are using it. I hope we've Francoise and I've been chatting with the product manager for the AWS toolkit. And I guess first I should explain what it is. It's a plugin for Visual Studio, which is Studio Code JetBrains. And it basically allows you to do everything from the IDE for AWS. So if you are wanting to create a lambda function, you can use the ATS toolkit extension and say Visual Studio, it'll give you templates for whatever lambda you want to create, whether that's s3 or maybe maybe working on something with Kinesis. And then from your IDE, Visual Studio, Visual Studio Code JetBrains, you can just right click on your code and say, publish the lambda. So you never have to leave your code. You never have to leave your IDE. And yeah, for some reason, not enough people are using it. We're actually seeing much fewer users of this amazing toolkit that makes our lives easier as developers than we are seeing the uptick of dotnet developers on AWS. So yeah, we're working with that team to create some videos. Stay tuned for those I just recorded my first one last week for working on getting it approved and published. But if you're not using it yet, folks, at verse toolkit, you should try it. You should

Francois Bouteruche 4:44

definitely try it. You are missing something.

Brandon Minnick 4:48

Yeah, how would you first off what announcements do you have today for the folks?

Francois Bouteruche 4:54

Mayans month is about to dotnet entreprise the Ripper day, we are hosting next month. I In August, on August 22. So we co host these events with the developer week, cloud X Evans, hosted by their networks. So it's a free one day virtual conference all about dotnet and AWS, you will get two tracks. One track is about migration and modernization of dotnet applications on AWS. And the second track is about dotnet, developer productivity and cloud native application. So you will learn about the toolkit for example, we will have session about the toolkit, we will have a session about code whisperer or new AI coding companion. And you will learn about several layers computing on AWS and or you can take based off of those competing services to build your dotnet application. We will also have some guest, two guests from AWS community who will share with us the journey with dotnet and AWS. We will have all four guests from JetBrains discussing writer, and we will have also the guest we we have today, sharing with us are experts. So I think it's time to introduce our guests because she will deliver an amazing talk at the private group per day. I can't swith enough, or I recommend to attend this talk.

Brandon Minnick 6:38

Fantastic. And, and by the way, great job. Francois. Actually, the one putting all of this together. You're doing a great job. I didn't even I didn't even know that you recruited so many folks. We have two tracks now. So where to where to go, man, but yeah, we have we have an amazing, amazing guest today. She's a software engineer and a Solution Architect with over 15 years of experience in the dotnet community. She is a Microsoft Azure MVP. She is a frequent speaker at conferences around the world. So without further ado, Leila, welcome to the show.

Laïla Bougriâ 7:17

Thank you. So

Brandon Minnick 7:20

yeah, thanks so much for joining us. So, Leila. For folks who haven't met you yet. Who are you? What do you do?

Laïla Bougriâ 7:28

One second, I need to say thank you to Francois for the very kind words, I appreciate that. I no pressure by the way. I will try to do my absolute best to to deliver a great session at the conference. So looking forward to that. So yeah, my name is Leila. Leila Bulgaria. I'm based in Belgium. I've been a software engineer for many, many years. At this point. I don't feel comfortable sharing our money. Let's just leave that for another day. But no, I've always really been passionate about this job about coding about how to code. And yeah, I feel like I'm still enjoying it as much as the first days. I mean, you know, to be totally fair, it's been like in waves as with everything, but yeah, so much enjoy that.

Brandon Minnick 8:19

Right. So some days we hate it. Some days, we love it. Some days, nothing works. Some days. We're the smartest developer in the planet.

Laïla Bougriâ 8:28

That's how we roll.

Brandon Minnick 8:31

It's so great. We see, Martin, our guests, from the last shows in the comments. Good to see you again. Martin. He says that Leila is also just an all around awesome human. And I couldn't do

Laïla Bougriâ 8:42

so kind. And he is too. So if you get to catch a talker of his then definitely go watch that.

Brandon Minnick 8:52

Absolutely. So. So let's, let's let's zoom all the way back. You mentioned you've been doing this for a long time. How did you get into dotnet? How did you get into C sharp?

Laïla Bougriâ 9:05

That's actually kind of a I don't know if a funny story, but it is for me, because I sort of, you know, you listen to other people share their own backstories. Like, I was coding since I was eight. And I'm kind of jealous of that in the sense that, wow, you figured out what you would love to do for the rest of your life at that age. Like really? I cannot say that that was my case. I thought I wanted to be a teacher, which I guess in some ways I am. If you sort of look at speaking, public speaking, and it's also sort of a form of teaching, I guess we could say, but yeah, I thought I wanted to be a teacher. That's what I was going to do. And then I remember that we had a class. It was called it whatever that means, because what we were basically doing is mostly learning how to type how to use Excel and Word and Axis it's time axis. And I remember we had I don't know like four or reeks of a sort of class one hour in which you sort of had to program a little car to move from point A to B without hitting the coals along the way. And I guess I was good at it. My teacher caught it. And he was like, You should be a software engineer. And I was like, What? No. But yeah, that's sort of how I got into it. I was like, let's give it a try. And the rest is history.

Brandon Minnick 10:25

No way. Oh, that's incredible. That's and and I don't know what the what it's like for students nowadays, I've, I've been out of school for a long time myself, as well. But But yeah, I've always said, I strongly believe everybody should learn to program not even to code. So even something like that, where you're programming a car to drive through a maze. Because it, it kind of changes the way you see the world the way you think. And especially nowadays with everything runs on computers. And so to understand, yeah, how a computer thinks and computer solves that, as is super, super important. So, so this teacher noticed you had a knack for it. Where do you go from there? Was C sharp your first language?

Laïla Bougriâ 11:14

Well, actually, no, because my my education was very, very, very Java focused. It was I mean, we did have some dotnet was VB dotnet at the time, which I also, I mean, I'm going to be quoted on this, but I did not hate it at the time. Okay, so. But I did not hate it at the time. But then we had a, we had to do an internship as part of the education. And that was C sharp, I had never written the letter of C sharp, just sort of thrown into this. And I was like, This is awesome. I never want to do anything else. Well, it's not entirely true. But, you know, I just sort of fell in love with that language and the entire ecosystem. And yeah, it's been more than 15 years.

Francois Bouteruche 12:04

What do you love in the ecosystem? Probably the thing you love the most?

Brandon Minnick 12:12

Besides dotnet? Of course,

Laïla Bougriâ 12:16

this was bound to happen. You'll give me that T shirt, though, Martin. No, I get I guess one of the things that I appreciate most, and that's been, I mean, it's always sort of been there. But very, very prevalent the last few years is the community, I feel that we're exposed to like, honestly, a firehose of frameworks, technologies and options. And, like, there's so much out there. And I feel like having a community in which, you know, we can sort of embrace that it's impossible to know everything. And that's always you can always find an open space somewhere where you can come in and say, I don't know how this works. Can someone please figure this out? You know, with me, and sort of being able to do that in a sort of community and learn together? I feel that's one of the things that I appreciate most, I feel it also. Yeah, it keeps us young, in many ways, right? This job just forces us to keep on sort of studying and expanding ourselves how we think in and how we absorb information, which is just accelerating. So in that regards, I feel that the community, and also the work that you guys are doing as well is also helping a lot in that regard. So thank you as well.

Brandon Minnick 13:35

Thank you. Far too kind. But yeah, I feel the same way. It's this this job, this career as developers, even outside of the dotnet world is, yeah, it's something where, if you stop learning, you're gonna fall behind. And it's, it's tough, because you can get by for a couple years. What what you know, today, if we were just to capsulize 2023 knowledge, and we're not learning anything new. Yeah, we could probably still have a job for another five years, probably 10 years, we could keep working on the same stack. But yeah, eventually you get left behind. And, and how do you keep up? And for me, it's Yeah, leaning on folks in the community. Like you said, folks who have done it first written the blog post, make, made the videos tweeted about it, open source projects, and yeah, we have to, we have to lean on each other. Otherwise, I don't know how we'd survive.

Laïla Bougriâ 14:41

Absolutely. I will say, though, that I think, because I've gone through this throughout my career, where I felt like I was paused for a second, for many personal reasons, but I remember like getting back into it, and it was, it was brutal. But it was brutal. But I also got through it more quickly than I had expected. I was basically working on a project for quite a few years, super interesting projects, actually one of the, one of the ones that I'm most proud of, even in the sense of what we accomplished and what we put together there. But I think technology wise, I wasn't really exposed too much it was there was no learning on the job. Basically, my work was C sharp, like C sharp unit tests. And that was really it. You weren't exposed to a lot. So in case some SQL queries and stuff like that, but let's say like all of the different, you know, frameworks, technologies that were usually exposed to as a full stack developer, that there wasn't much of that, so I felt like, this was five years, okay, this is going to be rough. And it was, it was so but I would still sort of want to share that if anyone finds themselves in that situation, is don't be afraid of putting yourself out there again, because it's absolutely possible for you to sort of relearn and sort of catch up with that. Backlog, if you will of technologies. There's also no need to learn everything, you're going to have to sort of understand of what's out there, sort of be available, like a 360 No know what's available out there. And then again, make some choices on what is going to be most applicable to the systems that you're developing and things like that. So definitely something I also want to share. Because this, I feel that this is something that can scare a lot of people off as well.

Brandon Minnick 16:40

Yeah, and even in the comments, we have a comment slash question here that dovetails nicely with that, where it's as, as dotnet developers, what is your experience with people who have changed careers into AWS developers either as dotnet or Python? As someone who's trying to do career switch? It feels a bit overwhelming. And I'll, I'll start, I'll say I absolutely agree. It's definitely overwhelming. I've been doing C sharp development for, gosh, over 10 years exclusively now. Like I haven't left the C sharp world. And I still feel overwhelmed. And it's what I do every day. It's what I speak about at conferences, we we host this show on Twitch to talk about dotnet at AWS and it's, it's still overwhelming. So unfortunately, that feeling will never go away. You'll always feel behind, you'll always feel like you don't know everything. But that's okay. Because none of us do. If anybody tells you that. They they do know it all. And they're expert. Yeah, they know. So, yeah, Francoise, what do you think as someone who's looking to switch careers and get into developing for the cloud, either dotnet or Python? How would you go about that? What advice would you give?

Francois Bouteruche 18:10

First of all, do it just to share my my, my my personal background, I've been a C sharp developer for nightly news. Let's say six or seven years ago, I started to build a dotnet application for the globe. It was on Azure, it's we are a restaurant, but it was on Azure. I started on Azure. And it was all new. So by the way, we had to learn. It was all new, and three or four years, four years later, I decided to switch to areas because I was afraid to I was oh my god, I'm thinking now it's 15 year arm in the Microsoft ecosystem. And I was afraid for my own career. I still need to work probably 30 years or 35 years to reach out to my retirement. So I was afraid to to be to stick to an ecosystem. So I just decided to okay, I want to switch I want to learn something completely new. So I switched to learn areas. And like when I started I was Oh my God, what did I do? And for nearly four years later now, it is probably the best decision I earn. I've done in my carry some time learning something completely new. push you out of your comfort zone. But for the best. Most of the time when you go outside of your comfort zone. It will end up to be something really great.

Brandon Minnick 19:58

What's that? I love that Yeah. Yeah, it's, it's terrifying at first. Some days, it'll be better than others. But yeah, you learn you grow. Yeah, I've helped mentor folks who did switch careers. And what I try to remind people is, anybody can code. You know, there's a lot of there's a lot of fences we build around. Software Engineering programming, being a developer that imply you need to know math or you know, physics, you know, as a, as an engineer, right? Like, how can an engineer do something if they don't know calculus? And I can't tell you, if I've ever used physics or calculus, and writing my code. So anybody can learn to code doesn't matter if you're bad at math or science. It's, it's almost just like, learning it. It's like, it's like learning a language. I mean, you are you're learning your programming language. But then I realized, I'm the only one here who doesn't speak multiple languages. Laila, how similar is it to say learning C sharp to learning French or learning Spanish or learning Italian?

Laïla Bougriâ 21:20

Okay, so the interesting part is, okay, I speak about five languages, I don't feel like I've ever learned them. So actually, that is a very tricky question. Question. For me, I was just exposed to them from a very young age. So I'm just really lucky that that's all there is. I was just lucky to absorb them from a young age. And I never felt like I went through the, the learning curve of learning this sort of language, if you will. But I have done that a little bit more with Italian. And that's where I sort of feel like I'm still very lucky, because I can just steal away from Spanish because it's sort of, but I have touched on other programming languages. And one of the things that I feel is that there's always a shared basis that you can sort of draw from, it's, it's not as if you're going to start from zero, because we tend to say that, Oh, but I'm starting from zero, if I switch stack, or if I switch languages, that's never ever really true, you always have a common foundation on which you're going to start building upon. And once you can sort of match concepts that you already know from the language that you that you know very well, and you can sort of start to map them as like, Oh, okay. In, I don't know, whatever other language it is, in Java, this is how we do it. And you know how that's done in C Sharp, and you can make that sort of mental map, it's gonna be a lot easier. Another thing that I would sort of like to add to this is, even if you sort of embark on this experiment, right, and you've gone through that, you're a year in year and a half, whatever it is six months, and you're like, Oh, my God, this was the most terrible mistake, like, I should not have done this, I need to go back, this is not for me, even then I wouldn't consider it as a failure, not ever, because there is so much that in the moment, you will not realize that you are bringing back to the sort of community to the knowledge that you have in that other stack that is going to be useful to you in so many ways. That it's it's, I would see it as a win win either way.

Brandon Minnick 23:30

Well said Well said, first of all, what about you? Did you learn English at an early age? Or did you have to struggle through it like, like some of us here,

Francois Bouteruche 23:43

English, I've learned English at school in France. To be honest, it's not a great experience to be able to really work in English, as I do today. Then a few years, when I've joined areas, I decided to be intentional on this. Learning English. So I've taken some groups. And I think for programming language, I don't know him. A few years ago, I tried to learn JavaScript, because I was not no good at JavaScript. When you listen, people like we all know JavaScript. No, we don't all know JavaScript. I was very bad at JavaScript. So after this, I decided to take some online course on the Udemy platform for me, but you can find many platform to start learning a new programming language with beginning across and I've decided to start from scratch, like if I didn't know at all to program. So it was a really good experience, even if I was were already very skilled with C sharp, it was a very good experience to start from the very beginning to grab the concept of this programming language, to regrab the differences between my knowledge in C Sharp and the differences with JavaScript and like Leila said, very quickly, I realized that there is a lot of shared thing between the two language, but also, it helped me to, to spot the meaningful difference between bits, humans languages. So that would be my recommendation to probably take a new online course, if you you already know how to program. Okay, take a non online course, start from zero, don't try to make if you were already good at no start from zero and learn how to program in this new program with this new programming language. And if you were a beginner?

Brandon Minnick 26:11

Well said, Yeah. As you're both describing your experiences, yeah, something stuck out to me, in my own experience, and I didn't realize how much I lean on prior knowledge in and just everyday life to You know, like, if I'm fixing something around the house. It's like, oh, yeah, well, I did this last time. And so that makes sense that I should do it again, this time. And yeah, I didn't realize it. But yeah, we totally do that with language with programming languages. Like, if I, if I see, and I don't know, Python, and I don't know JavaScript. But if I see it, I can, I can kind of lean on what I do know and say, Oh, that kind of looks like an if statement in C Sharp. So that's probably how this works. And this feels like async await in C Sharp. So that's probably how this works. And yeah, it's funny how we can we can we do? We laid out all that prior experience. Now, Leila, you mentioned there's some really, really cool things that you're working on that we wanted to highlight on the show today. And which one do you want to start with?

Laïla Bougriâ 27:24

Well, there's plenty to choose from. Well, when it comes to the community, I've mostly been focusing on public speaking and tried to sort of share from from my own experiences, probably the biggest challenge for me to start there was how do I say this? So basically, when, when you're, you're building up expertise over multiple and multiple years, and the things that you know, start to become like, common sense for you. And one of the things that I struggled with a lot is, this is common sense for me. And therefore, it is common sense to everyone. So it's kind of like taking a distance from that and thinking about even my younger self, like, how long did it take for me to understand this specific comp concept? How much reading that I have to do for that? How many questions that I asked that I need to ask to basically get to the level of understanding where I am today. And try to even, you know, put myself into that position again, or try to at least it's challenging, and try to say, Okay, what would I What would I have liked to sort of see back then. And I tried to do that as much as I can. And I also sort of really listen to questions from the audience, to sort of see what people are sort of struggling with, and I let that sort of feed into, okay, what can I talk about next? And that sort of seems to happen organically. So that's also really interesting. Very cool.

Brandon Minnick 28:58

And so this is a talk, you're working on a presentation for an upcoming conference?

Laïla Bougriâ 29:05

Yes, I actually have one that is a little bit different, because I think most of the talks that I've been doing are pretty technical, architectural, you know, whatever you will. And now I'm actually preparing one that is, I guess, even outside of my own comfort zone. Because I'm definitely not an expert. Although I would say that I've learned a lot through the years. That is a lot more about how we sort of think critically. Because I feel that that's one of the the sort of most needed skills, it's only going to increase with things like AI and stuff like that is to sort of apply critical thinking, look at a piece of code and try to figure out whether it makes sense, but also look at all of the offering, like we already discussed, there's a firehose of frameworks. It's like which one do I choose and why and because I feel like also as a community, one of the things that we do very well well as to provide documentation, how do you use this and things like that? I feel that one of the angles that I also try to incorporate in my talk is why should you use this? Because that's one of the questions that I asked myself. When I look at it sort of piece of new technology. It's like, Oh, so many tweets and so many blog posts. But why is this interesting to me? How could I apply this to my work? Is it important to me, and it's, honestly a way to keep my sanity, filter information as well, to be completely honest, but definitely working, working actually, at particular software, they have a very structured way around making decisions that have really changed how, how I how I make decisions myself, as well. And that's going to be a topic for one of my next talks.

Brandon Minnick 30:54

Fascinating. Well, without giving away all the secrets, what are some of the tips that particular uses or does to help with that?

Laïla Bougriâ 31:05

Well, it's really about structuring your decision making because I think especially as engineers, we've we've been exposed to a bunch of information. And we don't always realize it, but we come into a situation. And we look into a problem. And first of all, it's, do we really even understand what the problem is because we tend to immediately jump into solution mode and throw technology at the problem. But taking a step back, and really redefining what the problem is, in simple terms, you know, terms that anyone without an engineering background could understand, I think already provides a completely different perspective. So that's usually step one. And then it's about taking a little bit of distance from that and say, okay, so if we look at this problem, so what are the different different ways in which we could solve this? And this is really hard, especially if you already have that. But we should just do this, right? You already have that sort of natural bias, because of prior knowledge, right? I mean, it's all prior exposure to techniques, and whatever it is. So that does come from somewhere. But it's basically about constantly questioning yourself, I tend to compare it with acting like a scientist, because they are very good at questioning their own assumptions, and their own beliefs over and over and over again. And that's I would say, really, the gist of it is to step away from anything you think we should be doing, but question it and say, what are all of the possible options with which we could solve this problem? And then come up with, you know, actual reasoning, that leads to a final decision of and this is the way we're going to go?

Brandon Minnick 32:48

Yeah, not just because I did it this way last time. Exactly.

Francois Bouteruche 32:55

It resonates a lot to me what you just said, because when I joined Amazon, I have learned walking back. Well, sorry, walking back. Yes. And

Laïla Bougriâ 33:12

it's in my resources.

Francois Bouteruche 33:15

It was kind of a blast to me, just not a don't try to think about the solution. First, let's focus on your customer. First, let's really think about, okay, what your customer really needs. What, what are they saying? Okay, what? What are they really expressing about their needs, what they don't express, because sometimes they don't say what they really want, or they, they don't even know what they really need, you have to understand making. And it was blessed me to make this switch and sub being an engineer and stop being a kind of customer research person. Putting customer research in everything. That's the way we do at Amazon. And yeah, completely plead shame to where I think about building software.

Laïla Bougriâ 34:17

I also strongly believe that in the end, it makes us better engineers. I truly believe that. Yeah, definitely. It's also some of the things that I've been reading about. But yeah, I It's, it also is a really good way to, first of all, make sure that you we have because honestly, as engineers, we also just get excited, right? There's some new tooling, and it's like, there's a new project new opportunity or like, Oh, let me just, you know, I could just use this as a playground to and I feel like I mean, we're in an industry where we've talked about this in other contexts as well. But we're in an industry where I think We're lucky right as as engineers, to be in this industry, we have generally speaking very well paid jobs as well. And I think it's, we need to also just be responsible, honestly, at the end of the day, and we can just use a Customer project as a playground. And I truly believe that if we can put customer needs, as you said, from so at the at the forefront, and focus on that, we can deliver better value, which might then you know, open up the conversation with managers or team leads to actually provide time for playgrounds actual playground. So, yeah.

Brandon Minnick 35:41

Well said, and you mentioned, you're working on something called transactional session in service bus. I am. And so how did that come about? did? Did you follow the same process to create this with following those same steps that we mentioned earlier?

Laïla Bougriâ 36:04

Yes, absolutely. I think all of our major decision making goes through a sort of structured process like this. But so to give a little bit of context, right, transactional session is one of the features or one of the recent features that we introduced in service bus and I was lucky enough to be part of the group that worked on this. And basically what it does, is it sort of maybe I should take a step back and explain what the outbox is, right. So we have a concept, which is more, I think, widely known, at least in the messaging community, that is a sort of pattern to try to create consistent consistency across message operations and database operations. Because if you sort of consume a message, almost always you're going to be changing something in a database, you know, because otherwise, what are you doing with that message, so there's always something going to be happening, and it's almost always going to involve some data changes. Now, the thing is that creating consistency between those two types of separate infrastructure, without distributed transactions is kind of a challenge. And one of the patterns sort of battle that is the outbox pattern, which creates sort of consistency across those operations. Because there's basically two things that can go wrong. If you let's say that you are handling, you know, consuming a message that's coming off a queue, and you want to send another message, for example, publish an event, something happened, and you want to update some data in a database. So for example, you want to set an order to shipped, and then publish the order shipped event, for example, right? The thing is that if you commit the data to your database first, and then sent, publish the event, if succeeding if the database operation succeeds, but then sending that message fails, and you're unable to rollback that database transaction, then you have data in your data store that is not reflected to the rest of the system, because nobody ever received that order published, sorry, order shift effect. But if you sort of turn those around, and you say, You know what, I'm just going to send that message first, or publish that message first, to ensure that the system knows about it, and then I'll go in modify the data, then you might be publishing a message, and then later failing to update that information in the database, which then means that you've told the rest of the system that you've shipped this order, but you were unable to reflect that in your data store. That's sort of what we call the zombie records and the ghost messages. And that's one of the things that the sort of outbox, solves for you. Now, the thing is that we've had this concept in in service bus for years, but it only works in the context of, I'm taking a message off a queue, and I'm doing those operations. And then you are sort of safe, with the outbox, assuming you have that enabled on all of the endpoints in your system. But if you're in the context, where you're just, you know, web controller, there is no incoming message, you're just at the beginning of your sort of business transaction, as I like to call it, you know, this is where you send the initial message that is going to kick off that entire workflow, for example, then you could still be, you know, making some changes in your database. And we've been telling, you know, users and customers for years, like don't do that, you know, if you're in the context of a web controller, the only thing you should be doing is sending out that message. But as we were talking about listening to customers, they're telling us while you know, I'm in this legacy application, and I can't really make that decision. I'm trying to, you know, incorporate messaging step by step, but I can just go in and rewrite all of my controller methods. And then that's where we started thinking, Okay, is there a way that we could sort of bring those same consistency guarantees to basically outside of the scope of an in incoming message. Does that make sense?

Brandon Minnick 40:04

Yeah, I was gonna say to zoom out a little bit, I realized we never introduced particular we never introduced in service bus. It sounds like in service bus has something to do with databases. For folks who have never heard of in Service Bus. What is it? What does it do?

Laïla Bougriâ 40:24

Right. So I would describe Well, we basically build a whole platform, right. But then Service Bus is a messaging abstraction framework library, if you will. And the idea is that we will try to make it as easy for you to build a message based system without having to care too much about all of the intricacies of how a messaging system works. But baby basically make it easy for you to focus on your business code. That's the main goal. And then we also have a bunch of platform tools that are also going to help support run that system in production environments as well.

Brandon Minnick 41:01

Got it got it. So so if we're building, let's see, a system that has multiple inputs, multiple outputs, there's multiple, we'll say actors in the system that need to know what's going on in service buses are tools that right?

Laïla Bougriâ 41:20

Well, you will still need a queueing system. So for example, that could be Azure Service Bus, but it could be AWS SQS SNS as well, it could be there are so many rabbit MQ, and many options. And the reason I was talking about a database is not because that's our core business. But because we realized that, you know, in order to build a system, you need a data store, right? So it's just a, it's just a small detail that you can't get rid of. So that's why we also have a sort of what we call persistency. You can plug in whatever data store that you're using. And that could be anything from SQL Server DynamoDB, Cosmos dB, there's plenty of options that we support there as well. So you basically look at your tech stack. What are you using? And most of the time, you'll find something that matches that. And if not, you should reach out.

Brandon Minnick 42:23

Got so I want to circle back. You mentioned the outbox pattern. And as you were speaking to it, I was specifically thinking about my outbox, you know, if I have if I have an email that's going out, and for some reason, my email client on my computer can't connect to the email server, this email lives in or stays in my outbox and never actually left my machine. Nobody's gotten it yet. And I know I can rely on my email client to retry again later. And sometimes it does, but it still fails. And then that it yells at me, and I get a notification letting me know that, hey, you tried to send this email last week and nobody got it? What happens in the tech world, so if we send that message out, and we had that failure, like you mentioned, maybe the database or we couldn't update the database, but we've already sent the message. What happens then what's that failsafe to alert the user to alert the developer that, hey, maybe something's going wrong here.

Laïla Bougriâ 43:33

Right. So to zoom into it a little bit into the difference between, you know, the scenario that you suggested, and the way that it sort of we implemented the outbox is what we're basically going to do is, say, you want to send messages are published doesn't really matter for the sake of this discussion. But you also want to save data. That data store probably has some kind of transactional mechanism. So what we're going to do is we're going to store those messages on that database. So piggyback on that transaction will be done in the same transaction. And then in a sort of mechanism that is backed up by a failsafe loop, which I'll get, I'll get back later, we're going to try to dispatch those messages. So what happens in in Service Bus is that there's an sort of automatic recoverability mechanism, actually multiple recoverability mechanisms, depending on how you configure it. And what basically what we'll do even out of the box without any configuration is that will immediately immediately retry a couple of times. And if that doesn't work, because like you said, the mail server is unavailable or the broker is unavailable, or whatever it is, then we will wait for a while, like, what we call the delayed retries are a backup mechanism, if you will, and it will pause for 10 seconds, 20 seconds, and we're basically going to increase that sort of backup mechanism and say, okay, it didn't work in 10 seconds this time. So maybe let's wait 30 And then sort of build that up. And at some point, we'll say, you know, we've tried this a couple of times, maybe you should look at this. And at that point, we'll basically send that message to the error queue. And yeah, it pops up in our tooling, if you have that setup, or if your managed manually monitoring your error cues, and which I wouldn't suggest, but yeah, then then you have to sort of look at that and say, Okay, why is this message failing? Is there a piece of infrastructure available? Is there a bug in the system that needs to be fixed? And when that is done, you can just sort of, you know, drag it back into the input queue? Simply said, yeah,

Francois Bouteruche 45:45

just to be sure to, to understand, because I'm learning while you're speaking. So I tried to get what you are describing. So you are completing the transaction transaction of the method with the transaction of the database fee. So if one of one of them the database, or all the methods fail, the the transactional session, we'll film and we've been notified that, okay. Whether the database, you couldn't change the data in the database, or whether we couldn't send a message to notify the rest of the system. So both couples?

Laïla Bougriâ 46:35

Yes. So actually, if you look at the documentation that we have about that, it means that we basically assume that whatever queueing mechanism that you have, has higher availability guarantees, because what I explained this, the outbox to transactional session works a little bit differently. And actually, I can share some documentation with a sort of visual graph on how that works. as well. I think it's the link you shared earlier as well, Brandon. But I'll post it in here as well, no, that's not a one. But basically, it gives you a sort of view of what that would look like. But what is going to happen is we're going to send a message immediately to on that queue. So what we're basically doing is we're assuming that the brokers there, if we can't even reach the broker that were originally told the user, you know, sorry, we can't really get anywhere with this, then we'll commit the database transaction. And there's a message sitting on the queue, it's empty, it just has some headers that we can sort of recognize. And then we'll try to process that and say, okay, the messages that we that you, as a user intended to send out or publish, those have not been sent out yet. They're stored in your database as sort of pending messages to go out. Right, but we'll get that sort of what we call a control message on the queue. And what we're going to do there is check, do we have the data? Like, do we have some pending operations stored in that database that we need to dispatch, and we'll do that. And there are some sort of failsafe mechanisms that we've built into here to make sure that we look out for all of the possible things that can go wrong. And actually, that takes me to another interesting story is the way we went about this was super interesting, because we use something called TLA plus, for this, which is a kind of model checking mechanism. I don't know if you heard about it, it was completely new to me, my mind was sort of blown throughout that whole thing. But basically, what it allows you to do is think of the the feature that you're building in this specific context, as a sort of model. And what we're trying to do is execute that model independent of the code independent of any infrastructure that you have set up. And you're just going to, yeah, sort of, what's the word? I can't find it? You're just going to sort of frame frame that in a different way. It's it's super mathematic. Actually, since we're talking about math. This is proof people that you don't need to know math because it's completely new to certain mathematical model that it was really exposed to. But yeah, that was super interesting. It was a whole different way about thinking about this. But yeah, it was really a challenge. It was basically introduced by Leslie Lamport, who's known, quite well known for his work in distributed systems, especially around concurrency distributed systems and those types of problems. And, yeah, that helped us sort of verify What if the data is not in the database? What if you have your endpoint scaled out? What if there are errors occurring? What if the message doesn't arrive? Or what if the data is not there, but the message arrived? Or what if the message arrived five days later than the data was put into the database, like all of these applications, that would be like, impossible to write, you know, tests for it's like, it's too wide, like all of the possible things that could go wrong. This sort of model checking mechanism was a completely new way to sort of look at this problem. And that's where one of my colleagues toMac did actually a webinar about this, as well. And he goes into a lot of detail on how to do this. That's exactly the one thank you. So and how to do this, and how to build such a model how to execute it. And I mean, it's still blows my mind, I still don't think I fully entirely grasp every angle of that. But it was definitely a great learning experience.

Brandon Minnick 51:08

I love how how perfectly that ties into what we were talking about earlier, when we were saying, there's, there's always more to learn, you'll never be an expert in everything. And this is so true, because I all the time, I lean on people who are way smarter than me, that have figured out the math and figured out how to do it and created these frameworks. And we're able to leverage those and build on top of those. So our stuff works great. But like really smart people like your like you mentioned your your coworker, Tomek. He's, he's already figured this out. He can teach us how to do it. We don't have to know the math underneath it. But it helps build better more resilient systems. And then our boss thinks we're the smartest people in the world, because we did it.

Francois Bouteruche 52:00

Abused and service booths in the past. And they never thought about all this before. Our that's, that's really easy to use. Yes. That's a good way to abstract my my messaging. Yeah, that's fine. I never sought about all this complexity when I've used in service visa. Anna, that's probably a good evidence that, okay. It's, it is really a good developer experience, it is a really good framework to use because it's hide all the complexity to the developers. So that's, that's my take.

Laïla Bougriâ 52:37

Well, I do believe that and I'm not saying it because I work there. I used to use them surface buzz before I worked at particular. And one of the reasons I joined particulars, because I enjoyed using and surface. So in that regards, I'm there perfect demo developer. That's good. I'm not by the way. I'm just kidding. But yeah, it's it's sort of Yeah, you like a product, you start working on it. And you can sort of think of ways of how to make it even better. That's super cool. But you're absolutely right. I mean, so Mike and Shimano, as well, both of them are, you know, like, really in depth experts when it comes to like the outbox and how that works. And we can basically, yeah, piggyback on their knowledge and sort of learn with them. And that's one of the sort of things that I really appreciate as well, about how we work is that it's all super collaborative. There's no sort of, oh, you should know this already. It's like, you know, a very open environments where, you know, any knowledge that you have any background is welcomed in any knowledge that you don't have is like, okay, cool, then you can learn something. And that brings all the fun back into the work, especially given that we realize that we can know everything in it anyway. Right. So

Brandon Minnick 53:55

I love that. Yeah. I love when we can introduce something new to a fellow developer because, yeah, like you said, it's, we could just be all smug and be like, Wow, well, I had to do it the hard way. And I had to learn it. But when somebody comes to me, and it's like, what is this? I don't know about them. Like, you haven't heard about this yet. Oh, like, you're in luck. Because this is super cool. I can't wait to tell you about it. That's, that's where I get my excitement and my passion from is doing that teaching that sharing. And, and yeah, it's you'll, it'll never stop. Something new is gonna come out somebody smarter than all of us will make a improvement to a tool or make a better tool that will make our lives easier, and we'll get to learn about that feature. Later, we've only got a couple of minutes left. But there's something else you mentioned to us before the show about open telemetry, as a project you're passionate about. have is two minutes or less? What is it? And why should we all be using it?

Laïla Bougriâ 55:08

Okay, two minutes or so the reason I love open telemetry so much is because it, it brings all observability, basically to distributed systems. It's definitely a project that I'm passionate about, because one of the things, I really love building message based systems, I absolutely hate the bugging them like to the core. That is also what my session at the dotnet enterprise developer day we'll be about. So if you have the opportunity to look at that, definitely join it. And I will take you through horrible experiences of mine. But But yeah, I think building distributed systems, which we are confronted with more and more, you know, because we're just also using different components, more and more different services, to build our systems on mixing and matching, debugging through that is just horrifying. And having something like observability, which brings back the sort of control, if you will, about what is happening in my system? And in which order is it happening, and what is leading to what in what context basically happened. And each of those steps is really, really powerful. opentelemetry also sort of introduces three types of way three signals that can improve the observability of a given system, which are logging metrics and traces. And Martin will tell you that locks don't exist anywhere, but that's a different discussion. But yeah, definitely, I see the value in all of them personally. And yeah, they can basically just bring back that visibility that we give up when we start to decompose enticer systems into individual autonomous components like we like or we aim to build them if you will.

Francois Bouteruche 56:51

Yeah. So just routing in the chat. And if you want to know more about observability and opentelemetry, you can watch back the show we had two weeks ago with him. We we've discussed observability. From telemetry for one hour with Martin so you can catch up on the on the dotnet resource collection on our Twitch channel.

Laïla Bougriâ 57:20

And in case you didn't share it, Michael house on blasts has a has an open cemetery on observability newsletter that is definitely really cool. And he shared some really good resources in there if you want to keep up with what's happening in that space.

Brandon Minnick 57:36

Fantastic. I see Martin sharing it in the comments. So oh, one one wide dot news is where you can find that. Little thanks. Thank you so much for coming on the show. I feel like I've learned so much about you and service bus and just the community in general. For those who want to keep up with you and all the cool stuff you're working on. Where can they find you? Well, you

Laïla Bougriâ 58:03

can find me both on Twitter and Mastodon at an octopus. I think Mastodon is attacchi term.io And LinkedIn just by my full name, Leila Bulgaria. And feel free to follow her connect, and we can continue the conversation.

Brandon Minnick 58:18

Well, thanks again. Thanks so much for joining us. Hopefully, we can bring you back for a round two. And thank you for having me. Yeah, thank you for watching. Thanks for joining us. Don't forget to subscribe to the AWS Twitch channel so you never miss us. We'll be back here on the first and third Mondays of every month. And we'll see you next time.