Episode #136: Serverless Transformation with Sarah Hamilton の全文書き起こし

both in a good way and in a not so good way, it's just like there's both sides of the coin on either side, yeah. Jeremy: Right. And I think that you know an interesting thing moving to a company like Lego and we've talked to Nicole Yip before, we've talked to Sheen Bristles before. And, like, Nicole was working on, you know, sort of a- I forget what it's called at Lego- but sort of that idea of that serverless developer enablement type role, right? I mean, and they do similar things at Liberty Mutual and so forth and putting, you know, boiler plates and constraints and, just to make sure that there are certain like compliance things that are sort of all there, so that there's a standard for when you're building new microservices and adding new new things like that. So I'm just curious cause like you said it's a little bit wild west when you're a startup. It's like, 'oh we can do anything we want right? Put it out there see what happens.' But when you start having actual lawyers and things like that involved in making sure that compliance and all that stuff. So just working in that environment, I mean one thing that's great, sort of, about serverless is there are some constraints that you have to, sort of, follow. But adding another layer of constraints, you know, by following something from, like, a serverless development or enablement team how have you found that to be? Sarah: So I guess one thing, so currently I'm working in like a marketing team. So really much dealing with getting data in from the front end and then customizing emails to the user. And I've never really had to worry so much about, kind of, private personal information but I really have to think about, 'oh we can't be logging that out to such a place because that's going to contain some sensitive information.' So it really is a thought process that you do have to, like, I'll often kind of check with my product manager. 'Do you think this is going to be okay?' Whereas it's not something I've considered as much before. Yeah, but in my two months not too many issues so far. Rebecca: That's always good to hear. That'd be much harder if it was like, 'well in these two months there I can't even have enough fingers to count.' So I want to talk a little bit more about your journey into tech, right? Before that you said before Lego you were a consultant and then you've also worked as a full stack web dev and you're a cloud engineer. I wonder if there are like specific skills that you've picked up along the way that, even if you're working in a serverless paradigm now where perhaps you weren't before, but you find yourself applying them even perhaps more than you thought you would have? Sarah: Yeah. So I guess my, kind of, journey about three years ago was when I graduated from university. And I'd done physics there. So I wasn't really from such a coding background. I had done a little bit of Python for kind of like Creighton graphs and things like that. And then I kind of realized, well initially I was actually signed up to do a PhD in like magnetics, but very much like hardware. But then I realized things are quite slow going and I think the thing about PhD that enticed me was kind of continuing to learn. And I think I didn't believe that you could find that in a job role. But then I think that software development is just that. Like, you learn every single day and you can go as far as you want with it. So anyway I decided 'okay I want something more fast paced.' And decided to basically just try and get a job. So I ended up as a consultant and the first six months were super hard. I was like working all hours to kind of build up the skills and be able to deliver a product. And then things got easier really. I started to realize I actually really do enjoy this and I actually kind of fell into serverless. So it just so happened that my projects were serverless projects. And then at that point I ended up getting quite close to, I think you've interviewed Ben Ellerby, and I kind of worked really closely with him on serverless projects. And I think he really encouraged me to, like, go ahead and be outspoken on social media and blog articles and talks and things like that. So that's kind of how I ended up really in the serverless space. And I think it's just by luck really but I absolutely love it. And I imagine I'll stay in the space hopefully for awhile. Jeremy: Yeah. And so I mean one of the things that you mentioned there was that you're just a few years out of university and the amount that you've been able to sort of learn and accomplish and in the point where you're at now in your career has, I think, has gone very fast. Almost because of serverless, right? Because you kind of, once you start using serverless you're exposed to so many parts of the application stack, right? So you're not just doing just coding and then hoping that somebody puts it on a server and runs somewhere. But you're thinking about infrastructure even though you're not managing it. But you have to think about what infrastructure you need in order to actually run that stuff. So, have you, do you feel like serverless was almost an enabler there to kind of supercharge your career, as well? Sarah: Yeah, for sure. I mean I think, I don't know if I'm lucky or not that I can't contrast it as much to kind of other ways of working. Obviously I kind of know about it but haven't used it so much. But yeah, I mean I think that's what I enjoy most about it. Is more the architecture perspective- how I can get services and create a full application. And I mean it's insane really, how quickly you can just build with those things and each of those services kind of allow you to understand what's going on underneath. But you almost don't need to know too much. So I think it allows you to kind of get a really broad knowledge of the way an application works. And then once you get interested you can kind of like dig a bit deeper. But there's no, I think it's

quite enabling, yeah. Rebecca: So, Jeremy and I, before we start the show right we have this sort of, 'hey we think we'll go here and then here and then here.' Like thematically, topic wise. But since you were talking about the insanity of the speed I'm actually going to switch this up on us, and then we can come back to our previous theme. So, let's talk about that speed, right? You've written a bit on the journey to serverless and serverless transformation. And one of your articles- "Building a Massively Scalable Serverless Chat Application with AWS App Sync"- at the end of it, right you talk about 'Hey why does all this come together and why is it important?' You talked about TCO and you talked about speed and you talked about scalability and then you also talked about teachability to other developers. You're like, you know, 'did we teach this and scale this for other developers to be able to use it?' And you like bold, italics, final word: ABSOLUTELY. Exclamation point. And so I think we hear a lot about TCO and speed and scalability about serverless and what that means to make that journey and choose to build serverlessly. But I don't think a lot of people generally then talk about teachability to other developers. So will you talk a bit about that and how you did that within the organization and why that's also an important part of this idea of serverless transformation? Sarah: Yeah. So, I mean, I think the thing is, like, obviously technology is constantly moving. So with serverless you are going to need to teach it to other people. So if we're going into an organization as a consultant and saying we're going to use serverless to transform what your product. Well, the developers already work that really need to kind of learn and the stuff as well. And so, with the example that you were talking about, we built a scalable chat application for a video conferencing website and it had to be super scalable. I think we needed to have like up to 250,000 users at once. And all talking on the chat. And they needed to be instantaneous. So I mean graph QL seemed like the obvious answer, in terms of like subscriptions and things like that. And then we just went to appsync because then abstract it and make it easier for ourselves. I would say the only slight thing that you know was a bit difficult is the VTL in appsync. And that was something I had to learn myself. It's not like I was teaching that to other people. I was like, 'right I'm going to have to get stuck in there and write these scripts.' But then it wasn't even too bad because you can actually just switch that out for a Lambda. So if we have like really complex logic then we would just kind of stick a Lambda in there instead of using the VTL that's out of the box with appsync. But, yeah, I think because I think serverless really is quite teachable. I mean, I think how far I've come from starting to learn with serverless to now two years later, I feel like I know a lot about it and that I might not have done had serverless not been around. Jeremy: Yeah, no definitely. And VTL, I've been writing VTL since, geez...Apache... Rebecca: 1981. Jeremy: 1927 is when I first started writing VTL. Rebecca: 1802. Jeremy: Um, that's right. No, it was, oh it was a long time ago. Anyways, point is, every time I write it- you don't write it enough, you don't use it enough that it's like something that's always there- so you always have to look things up. So I always reteach myself VTL every time I need to do VTL. But no, so I think that's really interesting too about, like the choice to use appsync, for example. And I think that people who are familiar with graph QL, and you know, when you set up a graph QL server and you go through that whole process. And even if you just use Lambda for graph QL the problem is is that you don't have those subscriptions, right? So there's a whole web socket thing and all that, you know, that you just completely miss out on unless you set that up separately and again there has been a whole bunch of articles lately about trying to scale WebSockets. Which is- everything is moved to this push, you know. Everything's now this constant, you know, constant communication or live communication, real-time communications. So, going to something like appsync and choosing that, just abstracting away, like you said, not only the heavy lifting of setting up the graph QL server but just that WebSocket piece alone, in order to do those subscriptions, is huge. Sarah: Yeah. I mean, I think all I can say is it's pretty phenomenal really. Yeah. Jeremy: Makes sense. Makes sense. You know Rebecca: Ya, this is how we transition. Jeremy: We were talking about speed like, I mean, fast response. I mean that's what we get with serverless, right? That's another terrible, terrible pun. Anyways, so the other thing, the other article that you wrote, and actually gave a talk about this, as well, is your work with EventBridge and a lot of the stuff that you've done testing with EventBridge. That's one of those things where it's like, how do you mock an event bus locally, right? I mean you can, but then it's communicating across services and service boundaries. And so you don't necessarily know maybe it's one team working on this service and another team working on this service. So how do you test that integration so forth? And I know you were at Theodo and you did some work with the SLS test tools, right? Did I say that right? And in there there were some really cool ways to test EventBridge. Could you talk a little bit, sort of what that testing strategy is? Or what you were doing with EventBridge there? We can geek out a little bit on this. Sarah: Yeah, so I guess it all kind of started when we were using EventBridge but we didn't really have a good way to test, kind of, across for it. So especially when we're using a event bus as kind of a bridge between two microservices, which are completely independent from each other except

for the EventBridge, how do you kind of test all of that? So initially we thought well you can end to end test it. You can say, 'okay, something comes into microservice one, let's check that the outcome happens in microservice two. However, like, if we got a failure in that end to end test, you don't know which microservice the failure has happened in. So we figured that we needed to come up with an integration test. I mean I think that our company we're quite opinionated on let's not test on, let's not use mocks and stops, except for like in failed cases that you can't really, you know, not the happy flow. For the happy flow let's use the real infrastructure because that's, you know, what mimics production the best. But it's quite tricky with EventBridge. You can't just say 'has it arrived on the EventBridge' and ask for that information. So what we came up with is you would trigger an event to happen in microservice one and then to check that the event arrived on the EventBridget we actually set up an SQS queue as a subscriber to that EventBridge. And then polled on the SQS queue to check that the event arrived on the queue. And so that's how we kind of affirmed that, okay the first integration test, to check that the event arrived on the event bus- like check that that actually happened. And so one thing that you have to do with this is in the integration tasks you do need to spin up an SQS queue because that's not part of your original infrastructure. But the event bus is and the microservice one is so overall you are testing that. And then the second integration test it's much simpler. It's just triggering an event to arrive on the event bus and manually doing that, or not manually, but in the test. And then check in that the result happens in microservice two, say that's like an object arrives in S3. So that's kind of the overall premise. And so then you know that if one of those fails, you know where the problem is. Whether it's in microservice one or microservice two. And so that's why I've kind of written my article on and done a few talks about because it was an interesting way of doing it without mocking. Jeremy: Yeah, and I I really loved that way, the idea of throwing that SQS queue in there. And then actually having the test itself spin up the SQS queue. And that's one of the things that I love- again, there's another thing about serverless that's just so interesting is the ephemerality of all of the different services that you can use. Like spinning up an SQS queue and then tearing it down at the beginning and end of a test, you can spin up hundreds of SQS queues if you want to to test all different, you know, but that's just a really interesting way to do it because it does give you a nice sort of way that then you can pull because that's what's cool about the SLS test tools, right? It will pull that SQS queue and wait for the event to come down and assert that it's, you know, that the event was there and so forth. So, yeah that's just a really, really interesting way to do it. And now I'm curious, now that you've gone over to Lego, Lego uses EventBridge quite a bit. Sheen Bristles writes about EventBridge all the time. So have you had a chance yet to translate your EventBridge skills over to your role at Lego? Sarah: So, at the moment, I'm working on a new architecture and it has EventBridge in there. So I'm definitely planning on putting the integration tasks onto the EventBridge. Not yet, but I definitely will do. And I think that once I do it I'll definitely do a presentation to the rest of Lego and try to, kind of, get this in other services as well that people are working on. Yeah, and that's the cool thing as well as is that we ended up open sourcing it into SLS test tools so that people could just really easily put this onto their projects. So yeah, it's really nice. Rebecca: I saw that a few people celebrated on Twitter. They were like, "And it's open source!" And I got to see that a few different times. They were like, "No way they open sourced this!" Which I think is always, it's always great when you make Twitter celebrate rather than really anything else. So, when you were working as a consultant, right, you got to experience likely working with a lot of different clients. And now at LIGO your client is your company, right? You're working for and with eachother on a specific project within Lego, but I'm wondering if working through these best practices and testing strategy takeaways if you've seen, especially of the diversity of people that you've worked with, if there are common mistakes that developers, or companies even, at a decision-making level, are making when it comes to testing. And,, you know which of your like testing strategies are perhaps overlooked the most, right? Or the one that people skip over the most. It's like 'oh we probably don't need that one.' And you're like, 'Ooh but we do need that one.' If there are any patterns that you see where we should be looking out for 'gotchas.' Sarah: Well, I think mainly my experience is that, depending on the client that you're working with, the person who's kind of allowing you to do your work from the client side, they will either love testing and kind of be happy to dedicate the time to that. Or some people will be like 'we're not putting tests in' and you didn't really push back then that's why you have to fight a little bit and try to get your way. And, so I wouldn't really say it's like mistakes that developers are making. It's more so how much does the company care about having well-tested code. And how much can you fight to make sure that you get what you want. Whereas going to Lego, I think that's the main difference between being a consultant and working for like Lego. Lego are always going to know that you're doing it in that best interest, like you're not just fighting for tests for no good reason. It's often not the most fun topic for developers either. So if you're fighting for

it there's probably a good reason. And they're probably going to allow you to go ahead and write and come up with those tests, yeah, to make sure that it's good. But in terms of mistakes I can't think of any, actually. Rebecca: I feel like there is a bumper sticker there where it's like 'must love testing.' Like even if you don't want to do it you gotta love it. Must respect Testing. Testing must be respected at all times. Jeremy: Well testing is another one of those things, too. Especially with serverless. You have to write your serverless applications a certain way to really enable testing. If you just bury all your code into a Lambda function and you're not thinking, you know, hexagonality or whatever, right, you tend to embed too much code. And it's hard to test those things independently. So it's good to think about testing right from the beginning. And again, if you're working quickly, like, 'Hey how fast can we get this prototype up and running?' It's very easy for you to, sort of, forget about writing those tests or to not write those tests. But when you, I think you move into an organization like Lego, you know, again, having those tests are certainly in their best interest. And being able to have those repeatable deployments and make sure that there's no regressions and things like that. But the other thing about testing- and this is something you mentioned when we when you were just talking about the EventBridge testing- is you can't mock EventBridge, so you have to test those things in some sort of a, you know, a live environment with live infrastructure. It's, that's the best way to test it, at least in my opinion. But so talk a little bit about that in terms of other things as well. So even testing individual services like, how much do you favor and maybe what Theodo did, maybe what Lego is doing now, how much did you favor writing local mocks versus really just pushing it into the stack or into the cloud as quickly as possible? Sarah: I mean, I think my experience is has always been just putting it on the real infrastructure. So I can't actually say much about mocking because I just haven't done it that much. But in terms of tests on the real infrastructure we came up with a really nice flow to do that. So the way that we would, kind of, make sure that these integration tests run on the real infrastructure was in our CICD pipeline. So at the beginning of our CICD pipeline, we'd spin up a stack that would just be uh a unique one based on a PR number. And then the whole stack would be deployed. You'd run all the integration tests on it and then you would tear it down at the end because obviously you can't, I think there's like 500 max stacks open in cloud formation because, yeah, we generally use a cloud formation for this stuff. And we just, we came up with a really nice way of doing it because as well you could work on that stack as well when you were developing. So rather, I remember when I started my serverless journey, I would have like a stack called [inaudible] and then the stack would always end up in a mess and you'd spend half your day trying to kind of get the stack out the mess. But actually you just, at the beginning of every ticket you just spin up a fresh stack, and then run all the integration tests on that. It just made the serverless site development cycle a lot nicer. Rebecca: That's one of those moments where you thank your past self, your current self thanks it's past self to be like, 'oh man thank you so much for thinking of this like pre conceivably.' Sarah: Yeah, sure. Jeremy: So let's talk a little bit about the community builder program and just how you, sort of how you get out there and started talking on Twitter. You mentioned Ben Ellerby. He and I have hit a number of bars in Nashville. That's actually, we've hit a number of bars all around the world I think, actually. But, Ben is a great guy and he's done a tremendous amount of work with Theodo and now Aleios, I think is what it's called now, right? So, he's done all this great stuff. So, you said he sort of encouraged you to go out and start speaking. So what, besides that, what did you start with? Like how did you just start putting yourself out there? Sarah: Yeah, it's an interesting one. Actually I'm not sure how it happened. I think that at the beginning, I wrote an article- I say a long time ago, we're talking like two years ago. When I didn't know a lot and it's not on my, like, medium page but I think it was about kind of creating sticky stickers like front end something or other I can't remember. And I just quite liked it. I think that there's some, I guess it's just exciting to kind of put content out there, see what people are feeling and like what they think about what you're working on. And then, I just started working more with Ben. I mean he's a real role model to me, you know. He became a Serverless Hero and that's kind of like the trajectory that I'd like to take. And so I just started working closely with him and it was kind of like, when I would hit an interesting topic in what I was working on, 'Okay, let's get an article out.' And he would just kind of encourage me, read over my work, and, you know, proofread things before I'd release them. And when I spoke at serverless days in Paris, that was my first in-person conference. He really encouraged that and came along and watched me speak there as well. So I think was kind of having that person who's just kind of encouraging you along the way and kind of showing you the ropes of how to kind of get involved. So that's where it all started really. Jeremy: So one of the things about, sort of putting yourself out there and making, you know, giving talks or writing articles is, you kind of have to take a stance on something, right? You kind of say like, 'This is the way that I do it, and I do it this way because of whatever.' One of the things I noticed is I went and I watched your talk from serverless Paris. And the

first thing I noticed was that you said GIF instead of JIF. And I was like 'okay perfect. She's my best friend now.' Because so many people keep saying JIF and I don't care, it's GIF. I I'm gonna, I'm taking a stand Rebecca: I'm a JIFer. Right now I don't care what the creator of it said, it's GIF. Hard G. Sarah: I've never heard anyone say JIF, so I feel that this is an American thing. Rebecca: I'm a JIFer all the way. Jeremy: You're a JIFer? All right, so Sarah, how would you like to be co-host of Serverless Chats? Sarah: Oh yeah. Rebecca: I knew I was about to give that up. I knew this was the moment that was coming. I was like 'oh I this would be what tore us down is JIF versus GIF. I should have known.' Jeremy: Right, right. So anyways, so the AWS Community Builder program. How did you get into that? Sarah: So I think I can't remember what the requirement was but I remember Ben kind of saying like 'oh you know you should apply for this because you've created quite a lot of content and it would be cool.' And I just went ahead and applied for it, listed all kind of the different things I had done- my articles, my talks. And I got in there. And it's been pretty cool actually because they have like a slack channel where you can kind of find out a lot about what the community builders are up to. And, yeah, get a lot of content from the community. And I think that's the nice thing about serverless. I mean the Community Builders isn't just serverless. There's just one section of it that is about serverless. But I feel like the serverless community is just kind of something special. Like people are so invested in it. People love it. So it's just a cool place to be really. And with the AWS Community Builder program like I'd like to kind of go on for that for a second year and kind of stay involved and keep creating content really. Rebecca: Yeah. As someone who selected the first cohort of AWS Community Builders, Sarah, I bet something that you did which you might not even remember doing is we say, like, 'Hey why are you interested in this program?' And let's say, roughly, we had a thousand applicants the first year for the first cohort. And probably 5 to 600 of them did not answer that question. And for us that was like a first indicator of like, 'okay if we have to, if we can only take 200 folks then we have to have, like, some simple ways to get the number of smaller. And if someone didn't answer why it was important to them or why they were interested or what they were looking to learn then that was actually one of the first things that we said 'okay if they didn't answer the why then we're probably not ready and they're not ready for us to, like, we want someone- at that time at least I can't speak for AWS now- but it was really important to us to have someone who could articulate, like, why that the program would be something that they were interested in being in. So I'll just add to that I'm sure you had created great pieces of content. That's always really helpful to see how someone is active in the community and looking to build their skills in the community and showing that by sharing their expertise with others and their learning journey. But another big part was the why, which I'm sure you had probably filled out quite eloquently. So just hot tip for the future. But, as you said you might be looking at being in the program for another year and something that's really cool about the program or, at least I think, or that's what we thought, right? Is that we would hope that when people were in the program and they got to have access to some really interesting internal teams like some roadmap conversation, some feedback sessions, and then some career building types of sessions, right? Like how to give a great talk. Like what is the best way to structure a presentation. What's interesting about writing a blog post and how to bring your audience with you. So I'm wondering if there are any topics or technical pieces that you've grown since you've been in the program and what makes you want to stay for a second year. Sarah: Yeah, so I think at the beginning when I joined the builder's program I watched quite a few of the, I think there was some content around how it's like 'yeah give a good talk and kind of speak publicly which is really helpful for me because although I think I've got a natural ability to kind of come out and talk, but I also do that but nervous about it and like it's always good to kind of try to improve. And so that was one part of it. And then I do remember, It was quite a while ago actually, I went to a talk given by some people within AWS. And it was about a fairly new service and I can't remember the name now because I haven't used it. But it's about how, I think it's like locator or something, I probably shouldn't say if I don't really know. Jeremy: Is it location services? Sarah: Is that the one way where you could like make a delivery app basically? Jeremy: Yup. Either AWS or Amazon location service. I don't know if it's AWS or Amazon but it's one of Rebecca: those. We have a one and 262 chance of getting this right. Sarah: So I went to this talk and it's something that really I probably wouldn't have looked into myself because I haven't really been doing any work like that. But actually it's really interesting to know AWS to have this service that if one day I decide I want to create that delivery app or something like that, then you know where to go. And it it's kind of just, really it's about having that knowledge within .AWS And that's kind of where I see my career going and having a wealth of knowledge to help. And, at the moment, I'm working towards my professional solutions architect certification. And I think having that community to be able to kind of bounce ideas off and find out new things and kind of get on top of the game, it's just really helpful really. And also having that kind of title allows people to

reach out to you as well. I'll often get messages saying you know 'I see you're a community builder. Let's let's get in touch.' kind of thing. So I think it's about networking as well. Jeremy: Yeah, so in terms of like giving talks and stuff like that. So it's super helpful to have a community to lean on. And actually one of the things that, when I first started doing talks, I had a couple of people that I would send them to or I would, you know, sort of do them- you used to be able to actually see people in person- which you're starting to be able to do again, which is great. But I'd actually just gives somebody the talk and get some feedback on it. So I'm curious for you, that process. Like getting getting to speak at a conference. Because I know so many people who are like I keep submitting RFPs and and they just never they never select me or whatever. What was that process like for you, maybe for Serverless Days: Paris. Or or any of the other talks that you gave. Like what is that RFP process like or what, did you do anything, you know, sort of to try to make your talk stand out? Sarah: So I think for the Serverless Days: Paris, I did spend a while writing my RFP. I was kind of like, 'oh I'm just going to write this down.' And I wanted to make sure that it was interesting and unique. So for me I spoke about the EventBridge integration testing. And I was pretty confident about this actually because I felt that it's something that's interesting to most people who work with serverless. And it's quite novel as well. It's not something that people have really done before. So I think that's it and this is kind of what I'm, not struggling for, but one thing that- I really do want to do another conference soon- but I want to have a good topic. I want it to be interesting and something that I feel really comes from me rather than just regurgitating the docs. So I think this is kind of what I'm hoping for from Lego is that I'll work with some really cool architectures and have some inspiration. So I think that's the thing .I think having something that you know people are actually going to be interested in. And something that they couldn't just suddenly look up on Google. Cause that's probably easier than watching a talk. But then other talks have been online because of COVID and I can't remember whether they had an RFP process but I think I've been quite lucky. It's kind of have the contacts with, like Ben, to kind of get in there. So I think that's the thing about the community: if you start reaching out and speaking to people that everyone's happy to help. I've never met anyone who's kind of rude or anything like that. Everyone kind of wants you to succeed. And everyone just seems really passionate about serverless. So if you want to give a talk then I think if you reach out to the right people then they're going to be able to help you. Jeremy: Yeah I think a next idea or idea for your next talk could be 'GIFs JIFs and You.' I don't know maybe.

Sarah: Yeah Rebecca: And Rebecca's not invited. So, before the show you had hinted at the idea of ideal ways of working versus reality. And I was like 'man, there's so many ways to interpret this.' And instead of me trying to make conjectures about what this meant I was like, 'Jeremy we should just ask Sarah.' So, open blue sky: when you were like 'Hey let's like, as a topic, there might be some ideal ways of working versus reality. I don't I was like this might be professional based. It might be within like you know, the code base. It might be depending on the scale of organization. It could be personal. I don't know. So I wanted to open that up here to say like, 'Sarah, school is a little bit.' Sarah: So I think when I kind of mentioned that I didn't know what I was alluding to but then I had to think about it and I thought okay here's an interesting one: So, generally when I kind of talk about how we ideally set up serverless teams, we'll say 'okay we're going to have event driven microservices.' And in an ideal situation you'll have decoupled services. Maybe they've all got their own repo. And you have a team on each one. And you can train developers up really quickly because they only need to know about a small amount of the code. We get events coming in from EventBridge. We do something with them and you don't need to concern yourself with the whole architecture. And this all sounds great. And it is the way that I think we would all like to be have small teams that decoupled and maybe only the engineering manager needs to concern themselves with the other team's work. Now I feel that in reality, I've never quite managed this. Like managed to be in a team that perfects it. So I've been in a startup where we've had the microservices And to be honest that's amazing. If the teams, so the thing was that the we weren't big enough to have a team on each microservice as a situation. So actually I did need to concern myself with the whole of the system really. And then coming to Lego, we do have our separate squads set up. So I am very much in a squad and I don't concern myself too much with what other squads are doing. But it's obviously, it's been in production for a long long time. And it's kind of a movement, this way of working. And within our team we're going to have our EventBridge that's going to fire off events to other teams. But we're not there yet as a whole company. And another thing is kind of the market for developers right now is insane. So actually being able to fill these squads up with the people that you need, it's not necessarily at Lego but actually just forming independent squads can be really hard. Because you'll often end up with one person with all the expertise who needs to end up on different projects. So I think, I guess my point was kind of there's these ideal ways of working but I've never quite seen them to perfection. I don't know whether you guys have but.... Jeremy: Yeah, no that that's actually the whole

idea of saying like we're gonna have independent teams on each microservice- like at AWS: absolutely. They do that, right? And some of the larger companies, they certainly do as well. But I think you're right. You get people who sort of know the whole system and they kind of want to be involved in everything. And I will say, and this is something, and again as a younger developer who, as you get more experience, the best thing you can learn is to be able to develop trust in other people. And as soon as you can trust somebody and you just know that that person's going to do their job or that team's going to do their job or whatever, it's sort of a magical feeling, right? Because then everything just works better, Then you can stay focused and hyper focused on a specific thing. You can get that EventBridge testing and you can do those sort of things knowing that it's like 'I'm not also responsible for the payment service , I'm responsible for these other things. So I think that's just sort of a magical place that that you can get to. So yeah, so very much so, I totally get what you're talking about and it is definitely ideal versus reality is very different. But anyways, the reality is is that we're running out of time, and another terrible transition. Rebecca: Look at that transition. Jeremy: All right I guess that was good. That was good. I don't know why we're being so upfront about our segues. But we are running out of time and we're super happy, you know, that you were able to come on the show and share your journey with us. I think it's super inspiring for other people who are getting into this space. You said it: there is a lack of developers right now. And I think there's a lack of developers in the sort of cloud space, even though there's already millions of us. We need more. Who did we talk to the other day that was telling us, it doesn't matter -Oh we were talking to Merritt Baer- it doesn't matter who you are, whether you were a teacher or I don't know what the other professions were, but come and work in cloud security. Like, we need more people in this industry and more people working with serverless. You know and if you've got the brain for it, then you should be able to learn this stuff pretty quickly and get up to speed and be able to do some amazing things. So, it's awesome hearing about your journey. We wish you luck on your continued journey. But if people do want to get in touch with you and reach out and find out more about you or maybe reach out to you because they want to offer you a spot at a conference, so you don't even have to fill out the RFP, how would they how would they do that? Sarah: So I'm on Twitter and fully enough my Twitter handle is @serverlesssarah. So that's a pretty easy one to remember. But also LinkedIn. Just find Sarah Hamilton. I'll be there. So anyway but yeah, Thank you. Jeremy: I like the Twitter handle but when I read it I want to say serverless ss sarah, cause there's so many s's. Rebecca: Same. Yeah, yeah. It's like parsel-tongue from Harry Potter. Jeremy: There you go. Sarah: Yeah Jeremy: All right ,well we will put all of this stuff in the show notes. Thanks again, Sarah. Sarah: Yeah. Thank you so much for having me.