#70: Serverless at LEGO with Sarah Hamilton

In this episode, I caught up with Sarah Hamilton, who is an AWS Community Builder and a software engineer at LEGO.

We talked about her journey into serverless and LEGO's serverless adoption has changed since I spoke with Sheen and Nicole on this podcast. In the two years since they have grown from 6 features teams to over 25, all focused on serverless technologies. We also talked about some of Sarah's previous work, especially a project where she used Step Functions, and her approach towards testing Step Functions.

Links from the episode:

• Sarah's talk on advanced event-driven architectures at LEGO group
• Episode 12: Serverless at LEGO with Nicole Yip and Sheen Brisals

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

Want to step up your AWS game and learn how to build production-ready serverless applications? Check out my upcoming workshops and I will teach you everything I know.

Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Transcript

Yan Cui: 00:12  

Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real-world practitioners and get their stories from the trenches. Today, I'm joined by Sarah Hamilton. Hey, Sarah.

Sarah Hamilton: 00:23  

Hey, Yan, how are you?

Yan Cui: 00:24  

Yeah, I'm good. So you've been really busy on a speaking circuit. I've seen you in London. I've seen you in Amsterdam. And I think we're both doing Serverless Summit pretty soon.

Sarah Hamilton: 00:34  

Yeah, that's right. I've been doing quite a lot in the last three months or so. Everything kind of all came at once. And it's been really exciting, to be honest.

Yan Cui: 00:44  

Yeah, I first saw your talk at the GOTO EDA event, about advanced event-driven patterns at LEGO, which I thought was really well done, very interesting stuff. And also, I noticed that some of the things that you talked about have been quite different from last time, I had Sheen on a podcast to talk about how you guys are set up in LEGO. So maybe that's one of the things we can talk about later on to see, you know, two years on what does the LEGO stack look like, compared to maybe when I spoke with Sheen two years ago. But before we get to that, can you maybe just tell us a bit about yourself, your experience going into serverless and working at Theodo, and then LEGO?

Sarah Hamiltoni: 01:24  

Yeah, definitely. So as we know, I'm Sarah. And I started out I would say, the whole journey started when I was doing my physics degree. I was at Durham University, and I did a master's there. And I was going to continue on to do a PhD at the time. And this was all before COVID hit. And it was around, it was classed as condensed matter physics, which is more hardware kind of dealing with magnetic memory and how we could improve that. And so I was on to do that. But I kind of realise that the achievements were very few and far between with a PhD. So every, you know, it was with research, it's more failures than successes. And I think I found it a little bit slow going in that sense. So I decided to not do that and look for a job. And I wanted something fulfilling. I didn't know what I wanted to do. So I applied to a few jobs, mainly in some kind of coding, which I was familiar with, because I had done Python at university, but more in a mathematical sense. So I didn't know an awful lot about web development. But anyway, I got the job. And it was a very steep learning curve for the first six months, because I was on the client project, doing a lot of front end, just trying my best to learn as much as possible, it was really difficult. But I would say that after six months to a year, everything really started to click, and I was really enjoying myself by about a year in and realise that I loved it really, what what a great place to be. So after approximately a year or so, Ben Ellerby, who is probably the first person who inspired me in serverless, he asked me to join his kind of new startup, which was still within the Theodo group, to specialise in serverless. And I jumped at the chance because serverless was the only technology, backend technology that I had been working with. And that was great. We grew to around six people while I was there, and works on quite a few serverless projects. And then I decided to move to the LEGO Group to work on something more in production higher scale, because at the time in the web consultancy, we would do working a bit more with startups. So a lot of greenfield projects, which I do miss quite a lot actually. And but here I am, I'm at the LEGO Group. It's a really cool place to be, and loving the work that we're doing.

Yan Cui: 04:06  

Yeah, I've had Ben on this podcast before as well. And I've spoken with Ben quite a few times both when he was at Theodo, and now with Aleios. And I guess with Theodo, you guys were working mostly with, I think small to medium enterprises. And I guess LEGO now is a much bigger company. Have you sort of seen any sort of noticeable differences in terms of culture, in terms of things that you've learned in different places? Because I know switching from enterprise to startup or vice versa, the cultural differences are very different, how you approach things is very different. And also in terms of things like the pace of work and all that how you find the transition so far.

Sarah Hamilton: 04:48  

Yeah, the there's been a big learning curve as well, which I'm trying to see as a really great thing because it's getting me used to kind of do I enjoy working in the startup culture or more. I wouldn’t I don't like to see that LEGO is corporate because I still think it has that very engineering kind of vibe. But there's a few learning curves in terms of technology I would say is big one at the startups, I was kind of implementing perfect serverless, where everything works and scaled really well. And didn't really have to think about some of the shortcomings of an older system. At LEGO Group, obviously, it's a constant evolving website that's been around for many years. And there's many challenges that you have to face in terms of I'm currently working on a migration projects in production. And there's a lot of challenges from unpicking older technology to move it towards newer technology. And it's a much slower process. But I think it's a really valuable thing to learn because it feels like it's this is real life. So that's a big thing. I would say, kind of the culture, yes, at the startups, I would say, I have a very direct approach. And I think that that went down really well in startup culture where everyone's very tight and understand you really well, when you move to a bigger company, and you have to deal with stakeholders, and people who you don't communicate with as much, you have to soften your tone a little bit and kind of put around a bit of fluff around the edges. So that's a big part of learning for me how to communicate in a more corporate way.

Yan Cui: 06:25  

And also, I guess that you have to work with different type of personas, like you've mentioned, sometimes you have to be more gentle, sometimes be more direct. But also, I guess, in terms of working with different stakeholders who may not be as technically minded as engineers, which also have, in that case, you have to learn to communicate effectively to people who don't care about serverless, they don't care about AWS, don't care about Cloud, they just care about, okay, I want to get this thing out the door to the customers and tell me why I should care about whatever it is that you're trying to say to me. Have you sort of had to learn about the communication skills around how to communicate with non-technical users?

Sarah Hamilton: 07:03  

Yeah, definitely. I think it's always been a strong point for me to be able to explain technical issues to non-technical people. That's not something that I find too much of a problem. I guess within a bigger organisation. It's more so how do you actually open a dialogue with people who are making the decisions because where they are in the company can be so far from where you sit, and often that there is more hierarchy. So you might need to deliver that message through your engineering manager because right now, I am an engineer. I'm not in a management role.

Yan Cui: 07:36  

And I guess, are you working in the Sheen’s group as broadly speaking.

Sarah Hamilton: 07:41  

Broadly speaking, yes, we're in the same team in terms of engineering, and it's called marketing channels technology. He works mainly in the loyalty squad but has a more global overview. Because he's an engineering manager. I sit within a marketing team. So we're dealing with, firstly, this migration of going from an older marketing platform to a newer marketing platform, but also dealing with kind of how we use data that users have from the front end, in order to manipulate it to decide what emails users should receive. I'm actually moving teams internally at the end of the month to go into more data streaming roles, or how we funnel that data and then use it for whoever needs that data. So it's something that I'm quite interested in. So and it's also I think, there'll be more learning for me to do as well because it's not even some of its not even serverless, it'll be more browser-based in terms of cookies and how we use those. And I think my mission is just to continue to learn really. 

Yan Cui: 08:46  

Okay, so I guess then maybe this is a good point for us to catch up on what is the serverless stack or the way you guys are organised in 2022, compared to when I last spoke with Sheen, because I guess back then, LEGO had monorepo. And when I was talking to sheen, and they had this, I think things set up whereby they got a monorepo of these different services, and they were using Lerna at the time to work out when a commit was pushed which folder was impacted based on the references so that they know which services need to be packaged and deployed so that you only deploy the services that has been changed by the commits. And from your talk at GOTO EDA, it sounds like LEGO has at least Sheen’s, sort of, your broader engineering team has moved away from this monorepo approach and having, I guess, multiple repos, maybe one per business area as the team has grew. So maybe can you explain how this is set up in terms of you know, how many teams you guys have and do you all work on your own repo? Is that some kind of grouping of different services into maybe not monorepo but kind of group of repos for a particular business area?

Sarah Hamilton: 10:02  

Yeah, I actually listened to the Sheet and Nicole podcast the other day to prepare for this to see how things have changed. And I was amazed to see that, at the time when they were speaking just two years ago, they had, I think they said six feature teams. So now I think that we're on maybe over 25, it's really hard to keep track. So things really have moved. And it's pretty incredible to see. I've been at the LEGO Group for nearly a year now. And so I don't know exactly how things worked back then other than what they've said on the podcast. But right now, we are in a state where a lot of the new teams, they set up their Cloud accounts, and they have their own repo. So I would say it's, it's kind of a domain, so not a business area, just because I would say my business area is marketing. And there are several teams under that. And each one in theory would have their own repo, and they're all decoupled. In reality, we have some teams that have got that way, we do still have a monorepo, which has services within it. So I never know how to classify these things. But the backend services, I would say, whilst they're in a monorepo, they're kind of decoupled, they can be deployed separately. They're not intertwined. The front end is much more monorepo style, I would say. The general theme is we're trying to move towards every team having their own repo and their own Cloud account. It's just a process that I think we're undergoing. And some teams have achieved it. Some teams have other priorities at the moment. Right now I am working in the monorepo. But the general, the general theme, when we set up our team, we did set up this monorepo, this repo for our own team, we just need to move everything out of it. And that's going to be a task in itself to move into our repo. But the general ideas are there and we are moving towards it.

Yan Cui: 11:54  

Okay, so I guess in that case, you've got a repo for your team. And I guess you've got multiple services still within the same repo. And are you still are you still using something like Lerna or Nx to work out when someone does a commit push a commit, which of the services has been changed and therefore needs to be redeployed?

Sarah Hamilton: 12:14  

I'm going to say we don't use that because I don't I haven't heard of this system. So no, I don't think we do. To me, everything's kind of normal in a sense that, yeah, I'm not too sure about that.

Yan Cui: 12:28  

Okay, so if you were to push a commit to one of the services, does it trigger deployment for all the services in that same repo?

Sarah Hamilton: 12:35  

No. So you would if you push a commit for your service, that it will only deploy that individual service. So all the backend services within a repo are separately deployable.

Yan Cui: 12:50  

Okay, so they must have some kind of mechanism to detect which service has actually been updated by the by the push so that they know which one to deploy.

Sarah Hamilton: 12:58  

Yes, I believe it's done through GitHub actions. But yeah, you might want to remove this different video, because I'm not that sure.

Yan Cui: 13:05  

Okay, that's fine. That's fine. Okay, and what about in terms of the actual tech stack itself? And I guess it's still very much JavaScript everywhere. Do you guys have different languages now? You got 20-something teams, which is a lot easier for you to have, say, one team that want to use Python, because everyone in that team is familiar with that. Or is everyone still so consensus, consensus around using JavaScript for all the backend services?

Sarah Hamilton: 13:32  

Yeah, so in the teams that I tend to work with, we're all in JavaScript slash moving to TypeScript. So that's kind of also a theme that we're moving along with. We're trying to get TypeScript 100% across those JavaScript services. But I do also work with teams who are maybe a bit more distant from me who are working in C#, which is great because it means that their team, that's what their team has skills, then maybe that's what is appropriate for the type of service that they are dealing with. Difficulties from that kind of come when, if different teams have different timelines, and we need something done now, often, I'll offer to kind of come in to the team and say, can I do the work and then that becomes a bit problematic, because I do not know C#, and it's going to be a learning curve. But overall, I think it's a good thing because in theory, I shouldn't need to go and ask to do some work in their repo. So I think it's about smoothing out those processes. But yes, we do have different languages. And from what I've seen, it's Python, C# and JavaScript, but primarily, we're all kind of in JavaScript in my area.

Yan Cui: 14:39  

Okay. So I guess maybe if we talk about some of the migration work you're doing right now because one of the interesting things when it comes to migration, especially when you're moving from say, containers EC2 to Lambda there is obviously quite a bit of rewrite in terms of how you structure application and all that but if you're going to be switching data as well think that is where it gets a bit tricky in terms of that migration without downtime. Have you guys got to that point yet where you've thought about, you know, the different steps you're going to do this so that you don't have to introduce any downtime when you switch from the current system to your new system, using, I'm guessing DynamoDB or something like that?

Sarah Hamilton: 15:20  

Yeah, so at the moment, the process is we're actually switching from a third party to another third party, and then eventually, and that's where we store this data. And eventually, another team is working on switching out that new third party for DynamoDB, which is going to be the ideal situation, because the third party does have limitations that we're dealing around. And I don't know all of the decisions that went into why we use the third party. But that's the situation that I landed in. And that's what we were doing. Luckily, we have managed to break the migration down into steps such that we've gone live with different parts at a time. So right now we're running these two systems in parallel, so that we can flick the switch as we go along. Which is great, because at the beginning, we were worried that it was just going to be one big bang release. And it's quite a crucial system for us. But we have successfully gone live with some of the different areas. So we're we're getting towards the end of the migration, which will be great when we get to switch off the old system. And there's been a lot of challenges along the way, as you can imagine, things that crop up, it's really hard to plan Sprints because things just kind of crop up, and you just have to deal with them as they come. Unknowns that you've yeah, that you basically didn't know about that come. But it has been really valuable to learn this sort of thing, because I imagine it's how every kind of migration project goes,

Yan Cui: 16:42  

Yeah, there's always going to be some things that you don't know until you start digging into that part of the project. And then halfway, you realise there's some problem, you guys just haven't thought about it at all. But I guess that's what Agile is supposed to do, right, gives you that ability to react to changes quickly without having to focus so much on, you know, this is the plan, you can just do it without thinking about all the things you're going to learn along the way and how we should pivot and redirect our efforts. So in terms of the stuff that you were doing before you joined LEGO, I know Theodo has some really interesting projects. And you mentioned that you have some fully serverless projects that you can just go be crazy in terms of, you know, all the fancy tools, we can, we're building something from scratch. So there's no legacy systems you have to worry about. Are there some projects that come to mind as as being particularly interesting or challenging?

Sarah Hamilton: 17:32  

Yeah, I think that was a platform that Ben may have spoken about before. It was a video conferencing platform. And it was kind of, well, there were two projects, actually, there was a gaming platform, which I was really new to tech. And it was a bit of a struggle. But now I appreciate just how cool it was. There were a lot of Step Functions and all serverless, very cool, but I think I was still learning a lot then. But my kind of love for serverless came from when I went on to this video conferencing app about a year in. And that was also a migration project from an older system that didn't scale to a new one. But I was mainly working on the greenfield work that it was going to be switched over to. And we were essentially just using all the new cool tech. So we had like micro front ends because we were switching out the legacy front end for different new front ends so that we could release really quickly and incrementally. We had Step Functions and EventBridge, you name it, we had it. And that was when I built my chat application with AppSync and kind of started to understand GraphQL as well and how powerful it is. And I remember doing a hackathon where just for fun, the company allowed us to for three days, do basically whatever we want. And I built the, you know, emoji react on messages in that hackathon, just with AppSync and DynamoDB and it was so quick and I just kind of realised the power of serverless and how quickly you can build things. So yeah, that was awesome. And I really enjoyed that project. And that's probably where I started to gain momentum.

Yan Cui: 19:11  

But that's great. Yeah, AppSync is, is by far my favourite services on AWS right now. It just gives you so much productivity. Okay, so that's, that's interesting. And I want to also pivot a little bit as well because because you are part of the Community Builders program at AWS. And there is a program that I've heard about for a while, and I've known quite a few people in the Community Builders program, and a few of my students have asked me about, you know, is this something that's worth applying to? What’s the criteria for getting into the program and also, you know, what's, what do we actually get as part of the Community Builders program? So, you know, seeing as you've been there for a while, maybe can you talk through maybe the process of applying, what do you need to do and also, what has been some of the biggest benefits for you as part of the Community Builders program?

Sarah Hamilton: 20:02  

Yes, I applied over two years ago. And I remember the criteria was you needed to have written at least two pieces of content or any kind of content, not necessarily written, it could be videos, it could be anything that contributes to the community. So you'd provide a couple of links to those. And I think I had to write why I'd like to be part of the journey. And I don't remember exactly what I wrote, to be honest. But obviously, I got in. I don't think I actually knew exactly what it meant at the time. I think it was something that I was encouraged to apply to, and it worked out for me. And for me, I would say the benefits may be different to others, I would say it provides me with a lot of motivation, I think, for me, to continue learning. It's nice to have something to aim for, that's not necessarily just completely linked to the company that you work with. So it's more of a personal achievement. In terms of especially the certifications as well, I love that style of learning. It allows you, you know, what you're working on within your company might be quite niche. And so it just gives you a much broader understanding of what's out there. For others, it may be that the benefits come from communicating with other community builders. We have a Slack channel where you can post questions and post content. And I don't use that quite as much. I think I tend to resort to Twitter for my information and questions. And but I think there are many different benefits. And of course, you do get the free swag. And I got that in the first year and the second year, which is always really exciting. So that's a big part of it.

Yan Cui: 21:36  

Yeah, and I guess you get some briefing sessions from AWS as well, in terms of some of the newer features that they just announced. And I think I saw there is there is… some stuff are happening around the re:Invent. I think you guys may be getting some heads up about some services as well. Because I think you also have to sign an NDA as part of the program if I recall.

Sarah Hamilton: 21:59  

Yeah, that's true. I think that we are allowed some early access to ideas that are coming about and then I think that one step ahead of that is heroes maybe get even more access to that. So yeah, we do have to sign the NDA, I haven't been keeping up with the Slack channel so much recently. But in terms of re:Invent, I know that we are offered maybe a half the cost off the total costs. And we're informed about things like I know a few people who have gotten into re:Invent fully paid through being from a diverse background. So we were informed about all those sorts of things. So I think in that sense, there are a lot of benefits. And generally, contacts within AWS are always handy to have when you're working with those services. So yeah, it's a nice community. And I think that's a big part of why I enjoy being in the serverless community, not because of just the technology, it's the people who you meet, and everyone's really passionate. So that's cool. 

Yan Cui: 22:57  

Okay, speaking about the community. I remember the GOTO EDA, there was quite a well-attended event, and there were a lot of people there. And your session was very well attended. And I had some questions, I guess, about the talk you gave, because you touched on some of the integration patterns that you can use Step Functions to integrate with other services, either in your own domain, your other microservices, or third-party systems. And one of the things that I'm quite interested to find out in terms of how you approach this in terms of the sort of testing side of things because that's always been a bit tricky with Step Functions. They introduced Step Functions Local a while back, but you know, so you can set multiple responses and all that, but that is still just for local testing. Have you guys, is that what you guys are doing for testing these Step Functions? Or are you doing something more sort of end-to-end, you know, triggering events that trigger your Step Functions? And you know, which depends on the payload, it does different things, and how do you approach testing?

Sarah Hamilton: 24:00  

So I don't know why. But I tend to stay away from these like local testing packages. And maybe that's really bad of me. Maybe they're really useful, but for some reason, I've just never quite lived with them. And so generally, it is testing on kind of the real architecture and with Step Functions, yes, it has been tricky. And that kind of started when I was at Aleios. We had an open-source repo called serverless test tools. And I worked on I think S3, Dynamo, and EventBridge testing, but Step Function was always a bit of how are we going to do this? And I knew that Joel Hamilton, who now works at Aleios, works on the serverless test tools for Step Functions. And I knew that what he did was essentially to trigger a Step Function in the test and check for its output. I don't know too many more details than that. But I think we're doing a similar thing at the LEGO Group. And I've seen one of my colleagues implement tests where essentially he is calling the Step Function and then checking to see what the outcome of the Step Function was. In terms of testing what happened in between in the Step Function, I'm not exactly sure. I think we decided to do more of I don't know whether you'd call it an end-to-end test or an integration test. But we would start at the beginning and check the different flows that we went down. So if the payload was this, did we get the right output based on the different journeys it can take? I don't think I personally have done anything where I've tested that individual steps. But how about you? I was wondering because I know you're quite in Step Functions. Do you have any testing tips for serverless Step Functions?

Yan Cui: 25:46  

Yeah, I've used different techniques in the past, Step Functions Local is one of them. Because mostly because some of the branching conditions doesn't base on your payload, based on responses from third-party APIs, I think that's where being able to use a mock response with Step Functions Local becomes quite useful because it's really hard to get, say Twilio, to send as a particular response or a particular error or to test some of the things like timeouts, things like that which, again, you know, if you're building something. I think when I was at the DAZN, we were using Step Functions a lot in the sort of payment processing side of things, you know, getting credit card payments back and all of that. And we want that process to be really robust and easy to debug. So we decided to go with Step Functions. But then trying to get the credit card payment systems to to throw errors, it's just not easy and to test those scenarios. So we ended up writing a mock service that we can say, when you call this endpoint with this payload, respond with 502, or respond with a particular payload, essentially just like a mock service, so that we can test the Step Functions end-to-end. But have it hit that mock endpoint, as opposed to Twilio service endpoint, and then we can use that to trigger the Step Function to go down a particular path. And then we can test okay, at the end of that, does it do the right thing? And then we can test that, you know, how are we handling timeouts if that service takes more than 10 seconds to respond? How do we then handle that timeout scenario, which is, is not great, because we have to basically maintain this mock service ourselves? And there's also a lot of, I guess, hackery that we have to put into the Step Function definition itself so that we can swap out the URL that uses to call the third-party integration. So there are a lot of things that you have to kind of do to make this kind of testing work. So it just wasn't very satisfying, which is why I think a Step Function Local, even though like you, I don't use local simulators just at all. Try local stack multiple times, they always get burned, they always break. And then it takes a week to figure out what's going on and eventually just restore fresh, and then spent a couple of hours just configuring it to get it to work again. But yeah local simulators, I've never had a good experience with them. But I think Step Function Local kind of just kind of pushes you in that direction because the alternatives the alternatives all seem to be worse. So, unfortunately, with Step Functions, there are just, there are just a bunch of limitations that make it difficult to to write tests easily.

Sarah Hamilton: 28:35  

Yeah, I definitely liked to give that a go then now that I've got a recommendation for it. But I agree with the local testing packages I've struggled with. And to be quite honest, I know that deploying things often takes a lot of time with the local testing. But sometimes I kind of liked that time, it gives me a bit of time to think in between just makes things a bit more slow and steady.

Yan Cui: 28:58  

Yeah, I mean, usually I don't mind waiting for a minute kind of a couple of minutes for a deployment and then run some end-to-end tests. But when I'm just making small code changes, I do still like to be able to iterate things quickly. So I do still write a lot local test that runs the code, but not using any simulators or any mocks or local local simulators for AWS services. A lot of time I write tests that will just run my code locally, but talk to the real DynamoDB table. And I can just… so my feedback loop is still quite fast for those tests. But then I still have the end-to-end test to make sure everything's working. So writing different layers of tests, some targeting just your domain logic, some targeting just how you're calling DynamoDB or other services, but then I always have end-to-end tests that test the whole thing anyway. Because that's the main that's the most important thing, I think, having the customer basically simulating a customer user case, make sure that that's actually working. And I think the official line from AWS is also to test in the Cloud, but I think for a lot of developers it’s hard to give up that feedback loop speed. And they shouldn't have to, I think in an ideal world, they should, they should be able to have both have a fast feedback loop and have something that works really well. And as I see AWS has been doing some things like Sam has got the sync support so that you can make changes and it gets deployed by the Lambda API, as opposed to CloudFormation so that you can hopefully improve the deployment time so that you can rely more on testing the Cloud. But that's one specific to a lot of people who use CDK or use a serverless framework or something else, so you know, something that supports a broader range of use cases.

Sarah Hamilton: 30:48  

Yeah, for sure, I think it'll be interesting to see what comes out because I know it's a pain point for quite a lot of people. And speaking on that topic, I'd say what I'm trying to get better at is making sure that I've written all of my Lambda unit tests upfront. So using Jest, we, I'll always write the tests so that I mean, usually, the bulk of my errors comes from Lambda logic where I've just messed up. So making sure that I've written all those tests and then you don't have to go through deploying every time you make a little incremental change to the Lambda to get to where you want to be. But definitely in terms of plugging in new services, I'll always deploy really, that's kind of how I go about it. I'm trying to go about it.

Yan Cui: 31:28  

Yeah, I think that's a good strategy. That's the that's the pretty much the same strategy that I use as well. Even though I'm probably not as, as, as disciplined as I should be when it comes to writing tests first. So I guess that's all the questions that I've had in mind. Is there anything else that you want to sort of touch on before we go? Any sort of things you are, you know, doing soon, I guess, like the Serverless Summit? Anything else that you're working on that you'd like to talk about?

Sarah Hamilton: 31:54  

Yeah, I suppose I'm excited for the Serverless Summit. It'll be my first online conference in quite a while, which is probably a good thing that I've been doing some in person, which has been really fun. But I think over Christmas, I'm taking a little bit more of a what's the word kind of a backseat approach in terms of I am going to be working on my AWS Professional Solutions Architect certification, which I've just been struggling to get the time to do, although I've had a few free weekends recently. And I think it's just the style of learning that I really enjoy. But I knew myself and a colleague at the LEGO Group. We're going to apply for a conference next April. I'm sure that I'll be doing some more things in the meantime because that sounds like quite a long time away and I want to keep up with kind of my speaking skills. But right now, I'm excited to get on with this certification, hopefully, pass it. It's the one that I've been working towards for a while. So that yeah, that's mainly what I'm doing at the moment and just kind of getting on with the work that I'm doing at the LEGO Group.

Yan Cui: 32:58  

Sounds fantastic. That's actually one of the more difficult certification exams I think on AWS. The Solutions Architect Professional, I think that's one of the most, most difficult one I think, from what other people have told me. I haven't done that myself either. But yeah, good luck. Hopefully, you will pass. And hopefully, see you at other events next year.

Sarah Hamilton: 33:20  

Yeah. Thank you very much for having me.

Yan Cui: 33:21

Take it easy. It has been a pleasure.

Sarah Hamilton: 33:23  

Yeah, thank you. 

Yan Cui: 33:38

So that's it for another episode of Real World Serverless. To access the show notes, please go to realworldserverless.com. If you want to learn how to build production-ready serverless applications, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time.