Sheen Brisals: Building with LEGO, Starting with Serverless, and Keeping Up with AWS

About Sheen

Sheen is a Senior Engineering Manager at The LEGO Group and is actively involved in the global serverless community. Being part of the LEGO.com team, Sheen mainly focuses on architecting serverless solutions, working with engineers to deliver features, and guiding and coaching engineers with their career progression.

You can find him online on Twitter, his blog, and LinkedIn.

Transcript

Adam: Hey everyone. Welcome to AWS FM, a live audio show with guests from around the AWS community. I'm your host, Adam Elmore, and today I'm joined by Sheen Brisals. Hi Sheen.

Sheen: Hey Adam. Thanks for having me.

Adam: My listeners are going to get tired of hearing this, but I've been so excited about this episode. I realize there's just a lot of people in the AWS community that I just gush over, and super excited to meet, and you've been one of those people for me. LEGO and serverless, two of my favorite things in the entire world. I've been a fan of LEGO since I was a kid.

Adam: I actually, I think last year's reinvent talk, I got out of a call, a work call, to watch your talk at reinvent. I guess I've followed you for a few years. Know your story, know the story of the transition at LEGO. But for those that maybe have joined this, and don't have that awareness, they haven't heard all of your content, could you just maybe introduce yourself?

Sheen: Yeah, sure. Thanks, Adam, for the nice intro. Yeah. Hi everyone. My name is Sheen Brisals. I'm currently a senior engineering manager at The LEGO Group. I've been here with The LEGO Group for over five and a half years, and I come from a very long engineering career. Starting my career early '90s. Been through different technologies, different phases of software engineering industry, and different technologies, and et cetera.

Sheen: And recently for the last few years, since I've been at The LEGO Group, my focus has been on cloud, especially on AWS and serverless technologies. When I say I belong to The LEGO Group, I am part of the organization of or the division that looks up the LEGO.com's e-commerce platform, and all the technologies, and features around the platform.

Sheen: That's where I am. And my day to day job, I work with engineers, and helping them to come up with architecture solutions, and then help them build solutions, and take those solutions to production, to serve customers. That's my role at the moment, and yeah, my journey so far. Yeah.

Adam: LEGO has this well documented transition that you made a few years ago into serverless from an on-premise application that runs the e-commerce. You've talked about that at length several places. Would encourage anyone that doesn't know that story, you can find it pretty quickly on the internet.

Adam: But I would ask I guess in 2021, why does LEGO need serverless today? What you've learned so far, why is it important to LEGO?

Sheen: Different reasons. First thing is, as I always say, journey into serverless is not just getting up there, and then that's it kind of situation. Once you got there, then you need to sustain. Because you see the benefits of features being developed faster, or solutions being deployed quickly. That then opens up more opportunities across business, because there are more use cases and needs for the modern customers. That's always of evolving.

Sheen: Obviously, when you have a technology like serverless in place, then it's just the journey continues basically. I always say that accelerating with serverless, that really happens when an organization successfully moved onto serverless. That's the reason why we're still progressing with serverless first mindset, because we know that that has given us the freedom to innovate, and the acceleration I talked about. That's the way it keeps us going.

Adam: And it's been a few years. I think a lot of the talks that I had heard and followed early on, you were in the thick of it. I feel like now it's been a bit. Are you seeing those benefits? Could you speak I guess to the acceleration within your teams? Is it more are you reaping those benefits at this point in 2021, as opposed to maybe some of your talks a year ago, or older than that even?

Sheen: Certainly we are. Because a few years ago when we were getting into serverless, everything was new. The initial goal at that time was to just migrate this to cloud and serverless. And once we did that, then how can we reap the benefits from here going forward?

Sheen: If you look at say the team structure or the team growth between then and now, we started off with our own 10 engineers, growing into 20 during the phase when we were migrating to serverless. Now, I think we are close to a 100 engineers, and a number of different squads. We operate in smaller teams or squads. From two squads, the typical front end and back end squad setup to now I think 13, 14 plus growing. Now, we have come to the feature squad setup.

Sheen: All these changes of the growth possible because we work with the technology that allows us to keep growing. Okay? Because engineers can think of the business, the value, and to deliver those solutions rather than messing around with the how to deal with the infrastructure side, and this and that.

Sheen: That's the growth and the journey. Same for the service. I say, for example, initially we had probably around 20 or 25 microservices. Now, if you look at the platform and deployments, it probably around 60 or 70 microservices. Yeah. That's the journey. And I would say that now we are accelerating faster than what we did in the past. That's the way things growing. Because as in technology, as in customer demand wise, things are changing all the time, right? The more value you bring out, the better. That's it.

Adam: And would you say over these years that you've journeyed through serverless, have there been surprises? Things that you didn't necessarily anticipate early on, benefits or even drawbacks, things that you've discovered, and that you could share with everyone?

Sheen: Yeah, sure. With serverless or with any technology, when you initially start off with, there are many unknowns, right? You don't know how things going to pan out. My approach or our approach has been don't stress too much about things we can't predict, or we don't know. Let's make a start. And as we go forward, we can always refine and make things better.

Sheen: That has been our approach. Initially, when we migrated to serverless, we build a huge [inaudible 00:07:07] on back of us, because the speed with which we are going, we knew that, okay, we don't have time to look into this, et cetera. Then, what happened was since the migration, the initial migration, we were able to put in place the best practices, and the operational side of things into a bit more a structured way so that we can sustain, even with the growth we see now with the different teams. That really helped since the early days. That then allows us to keep going with a good quality of service coming out of our teams.

Sheen: In terms of drawbacks and things, I can't think of any. For us, it's been good, to be honest.

Adam: Yeah. It's been smooth.

Sheen: Yeah.

Adam: Yeah, yeah. That's great. Going back to you and your career, I think you have this ability to blend this immense knowledge of serverless, but also with this enthusiasm and pragmatism. You're very practical in your writing and in your speaking. It's very obvious. I guess it's the perfect skillset for an evangelist type, but that's not your title, right? I guess my question is have you always been that, evangelizing things that you're excited about in technology, or is that something that came along with the serverless journey that you undertook?

Sheen: I think that's probably my making. Because I've been in the industry for so long, I've been through different technologies. Taking all those experiences into account, I think that comes by nature. Because I never was a theoretical person, so of course we all learn theories, and books, and things. But it matters is how we make it practical and applicable to our needs, right?

Sheen: Back in the day, say, for example, if you maybe talk about all the cloud, and all the webinar, and everything. Back in those '90s, when I was involved with the typical what we used to call the three [inaudible 00:09:16], plans, server, architecture, right? Even those days, we had the separation of front end and back end, the technologies interfaces, [inaudible 00:09:24] and everything. Then, moved on to Java, and gave us the distributed world. And then, the web services evolution changed things are.

Sheen: And then, moved on to the microservices world, okay? Initially, it takes time. And you put in the mix of the [inaudible 00:09:44], and then all the best practices, and things. When you grasp all the different technologies, you come to a realization that, okay, so all these things are good, but now for my benefit, my team's benefit, how can we take it in a more practical and adaptable way? Okay? Rather than stuck with textbooks, or things like that. That's my approach. And I think a few of those thoughts, and things that I recommend teams doing, I think it evolved from that nature of me. Yeah.

Adam: Yeah. Yeah, and I want to talk about your ability to coach. That is something that was in your title, at least at one point. And you talk about the individual serverless engineer, and how you envision that role. You've talked about them taking on more responsibilities, more ownership, getting into DevOps and even architecture. Could you speak a bit to that, and why you think that's important?

Sheen: Yeah, yeah. Before I get to that, answering that, one thing I would like to highlight from our current team setup, the squads and things, of course each squad has a product [inaudible 00:10:52] engineering manager, and we have director of engineering, et cetera, et cetera, all this hierarchy. But one thing we were so particular, we don't have an architect titled person sitting in our team. Okay? We don't have. When it comes to architecture, if it's a new initiative, say, for example, we are building a serverless payments platform, for example, so that stage, probably people like me and other will work with engineers because they need more support.

Sheen: Once that's in place, then when it comes to adding new features or adding new services and things, it's mostly the engineers who carry on doing the design or architecture work. And they discuss with others in order to perfect the solution. Bouncing ideas and raising questions. That's how we encourage everyone to come up.

Sheen: Taking that approach into individual teams, and that's why I always say that the two things I always say that serverless engineers or serverless engineering teams should get closer to DevOps, and also should get closer to being architects. Because if they can impress these two aspects of software engineering, then they don't see themselves as programmers. Rather they are more than programmers, they are capable of doing many things.

Sheen: That's one of the reasons why been promoting. And in order to put these ideas in practice, you need to have a supporting backup team and others around you, right?

Adam: Sure.

Sheen: For example, when it comes to DevOps, my colleague, Nicole, she's been instrumental in getting this across. Though she owns a platform score, looks after the infrastructure, and things like that, her ambition is that, okay, we will set these guidelines for everybody, but we are not going to do everything for you. Okay? Her team will push out these things to individual teams so that everyone then takes ownership of those kind of things, and they put those in practice.

Sheen: Similar thing when it comes to architecture. Once there's something to build, it's the individual squad's responsibility to come up with the initial architecture or the idea. Of course, they will be discuss [inaudible 00:13:13] many around the other squads and experts, but that's how we start to evolve the culture and things.

Adam: Yeah. And you mentioned Nicole. There are more and more LEGO engineers that are becoming prominent within the community, and I feel like there's clearly, you've got your technical things that you're trying to guide your team into, there's clearly also an emphasis on sharing with the community. And could you speak a little about where that comes from? Is that just a value of LEGO's? Is that something you've driven internally?

Sheen: No. I think that comes from the corporate culture I would say. I wish there were more engineers coming out and sharing, but interests differ, right? Engineers to engineers. That's fine.

Sheen: The culture from the top comes down because within The LEGO Group, we have this culture of sharing with the community. That means not necessarily tech community. Many LEGO employees, they have, a few days in a year, they go out to schools and to local communities, helping children and others to build things, play things with the LEGO, okay?

Sheen: And the same way, they also invite community schools and others across the country onto the LEGO hub, our offices, wherever it's feasible and all, and have a good fun day with building things and things. We're taking that into the technology world basically. That's all we are doing. Of course, when I started to evangelize the serverless, and talk about what we do, The LEGO Group of course gave us the attraction to take people notice of, "Whoa, this is coming from this place, so there must be something good."

Sheen: That really helped. But otherwise, internally we do push. Initially, when I started talking, and sharing, and writing, then I encourage others. I mentioned Nicole, and she now encourages fellow engineers to as co-speakers or authors. And so, that's how it evolves and continues, the sharing culture I would say.

Adam: Could you speak a little just about life at LEGO? What is it like working for LEGO?

Sheen: It's fun, play, because, yeah, play is the main thing in The LEGO Group. That the reasons I mentioned earlier. That comes down. If you come to a team environment, or culture wise, there are so many things happen, apart from technology, behind the scenes. They are engaging the community activities, or the personal developments, and so many other activities happening within The LEGO Group.

Sheen: That helps engineers to not only focus on pure technology stuff, and also develop their own career, and to become good at certain skills, or whatever they want to be. That's always there. That helps both ways, right? When you have technology teams with that the sharing and playing mentality, so that means they are up for challenges, or new things, or finding out things as you prompt them to go and look over. That really helps. That I would say is probably the reason why we have this vibrant engineering culture within us.

Adam: Yeah. I know I've been on teams where we use a LEGO brick metaphor for architecture. That we're trying to move into these services that are composable, and we can glue them together. Is that a metaphor? I'm just, this is a curiosity of mine. Do you guys use LEGO metaphors in the LEGO engineering group?

Sheen: We do. We do. But not specifically like that, but of course walk around to any LEGO office, you would find plenty of LEGO bricks. And if you go to any meeting room, at the center of the table, you will have boxes of LEGO, and people start building things.

Sheen: But when it comes to technology, there is always this the comparison, right? Say we talk about microservices, and decoupled the nature of things, they can be taken apart or [inaudible 00:17:43]. That resembles to how we build LEGO.

Sheen: I also have this out of my own way of saying, set piece architecture. That's, again, LEGO bricky version of my way of building or visualizing microservices, for example.

Adam: I've read some of that, and I'll say there's the metaphor there ties into a lot of things. It was soccer, and theater, and all these things. Could you expand on set piece services? Just that whole idea.

Sheen: Yeah. So interesting. My main purpose at that time was I wanted a simple way of communicating this break things down culture across engineers, okay? Because thing is, and when it comes to software engineering, not everyone comes with 10 or 20 years of experience knowing microservices or domain [inaudible 00:18:44]. People never heard of those things, okay? But they're still capable of building serverless services.

Sheen: When it comes to architecture or visualizing things, you need to help them to understand. Okay? That's how the whole set piece mentality came in. The point is because when you start a feature, often engineers get confused. "Oh, how am I going to build the whole stuff? It looks huge, and complex, and things." My advice is try and find an entry point somewhere. And from there, we can always grow.

Sheen: That's how the set piece came in. Say initially, I picked from my English soccer or football. There is this term called set piece play where it's not running around with a ball all the time, it's like a free kick, or something that happens there and then.

Sheen: Now, if you take that particular thing as one piece, that can be practiced, that can be trialed in your practice session and things, and then you come here and execute. Okay? Same with the, I talk about music or film, for example, they shoot in sequences, right? They then bring everything together.

Sheen: This is the metaphor I try to convey to engineers. Okay. When you see a big thing, it could be a typical textbook style microservices. For example, say payments domain. Don't just think the payments domain as a big microservice, look inside and identify those pieces, right? Then, because with serverless, you have that capability to even break the big microservice monolith down into smaller services.

Sheen: That's main reason why this set piece architecture mentality I was trying to build, and I then started to talk about it, and I also wrote a blog post or two to give you examples of how we can think that way and develop. It's all about break things down, make things simple. [inaudible 00:20:30] make us start, and keep going.

Sheen: Technologies help us with, say for example with CICD pipelines, or even driven model, and APIs, and everything help us to achieve that. When you have all these technologies available, why build a monolith microservice? Break it down. Make it smaller. Yeah.

Adam: Yeah. You've also talked about this idea of the serverless mindset. That serverless isn't just a collection of services within AWS or other cloud providers, but it's a mindset. Could you speak a little to that?

Sheen: Yeah, sure. I think when I started to talk about serverless, I think people in Liberty Mutual, they were talking about serverless mindset, and serverless first approach, and things like that. They're all valued things. I added on to say that you need the mind shift from your current way of thinking to a new way of thinking, because that's what serverless requires.

Sheen: That's when I started to talk about don't see serverless as a bunch of functions, or functions as service. Serverless is more than that. Serverless is an ecosystem where you can have many serverless managed services come together to provide a solution. You may not even have a Lambda function, or a function as a service within that particular service, right? That's perfectly possible.

Sheen: Once you have that the mindset or the mind shift, then it becomes easy for engineers to visualize that way, when they sit down, and to start architecting solution for their needs. Yeah.

Adam: Serverless and AWS move extremely fast. And one thing I've noticed about you is that you are always staying on top of the latest, and it seems that you guys incorporate that at LEGO. How do you stay up to date with this very fast moving landscape? Are you just following the RSS feed like us? Are you one of us?

Sheen: Yeah, yeah. Absolutely. As a serverless hero, I may get some sort of insights before certain services come out of AWS, but the challenge is there for everyone, whether we're already into serverless or not.

Sheen: The challenge is there are two things, one, knowing what is coming out, and the second thing is knowing what is best for you. Not necessarily a service comes out of AWS, that means that we need to put that in practice. If it's not going to be of any use, if it's going to complicate things, which we can just ignore, right?

Sheen: That needs to be there. Knowing it, and assessing the suitability or feasibility of a service. The other thing I would say is that if something, you find it suitable, and it enables the existing services what better, just refactor it. Don't just stuck in the past like refactoring only happens every 10 or 20 years, keep on doing. That way, the serverless instead becomes fresh all the time.

Sheen: Now-

Adam: And ... Oh, go ahead.

Sheen: Now, so in order to do that, you need to be continuously keeping an eye on how [inaudible 00:24:07]. You need to learn yourself. Keep yourself and the team updated. And I would prefer, rather than me asking engineers on these things, I would rather prefer them coming to me, "Hey Sheen, have you seen this coming out? And do you think we can use this in this particular situation?" That's the sign of a well-built serverless team.

Adam: And you kind of already answered this, but it was one of my questions that, so just wondering how LEGO handles, how your teams handle refactoring? And just the idea that you've spoken about functionless, and about it's better to not write code when we can avoid it. AWS is always coming out with changes where they've got direct integrations that didn't exist before. And I wonder does your team have dedicated time that you spend? Is it some fixed amount of time? Is it just ad hoc depending on the needs? Where you go in and you say, "We're going to remove some old way of doing things. Replace it with this new integration," or something, just to improve on the maintainability or whatever of the application.

Sheen: I would say it's spontaneous. Because when you have these many services, and so many engineers and teams working, you need to have a bit more thought out methodological approach [inaudible 00:25:22]. One way we approach is that across the different scores, because these scores, they own their own services, right? Identify a sprint or two, or some time, as part of their development work, assign to such improvements.

Sheen: It can be a challenge if they're already ... First thing I heard with a tough [inaudible 00:25:47] or something. But always there is always a gap comes around between these feature releases and things. That's probably the right time for teams to engage in such activities. I ask them to keep collecting your ideas, and time will come, and you can do that. That's one way to one way to attempt it.

Sheen: The other thing is sometimes as you go through, say for example, we have this extensive observability of monitoring set up, and things like that. When someone say on the on-call team or otherwise, they say that, "Oh, there was some problem with this service, but we didn't get these alerts, or alarms, or anything. Why is this so?" And someone would say, "Oh, because it was built two years ago. He didn't have that sort of things." Okay. That means, oh, okay, that's something we could improve.

Sheen: That happens. This is how it goes. It's funny because a new technology like serverless, we're already talking about refactoring and doing things. I know my colleague, Nicole, when she called two year old serverless service, she called us legacy service. It was a big joke, but it was reality, real, right?

Adam: Yeah. Yeah.

Sheen: Yeah. That's where we move forward. Things like EventBridge, a beautiful example. A great service. I love it. And when this came out, I could see the use cases and possibilities where we could use, but it had to be a well thought out approach. Because we couldn't simply put even [inaudible 00:27:28], unless everyone talked to EventBridge. No, no, no. That was not going to work, because you already had a bunch of SNS topics, and things going around. It takes time, but you need to be patient, and you need to know what you are getting to, what's your end goal is. That way, you can slowly put things in place.

Sheen: To give you an example of where we are not using something new, awhile ago, remember Lambda Destinations came out?

Adam: Yep.

Sheen: I even wrote a blog post about debating Destination versus SQSQs and things. My initial reaction was probably this is something we could use, but upon experimentation [inaudible 00:28:12] places, we've realized that it's becoming the event structure a bit messy. Okay. Let's not spend too much time there. If I thought there is a way to do that, let the Lambda function send out a custom event onto the bus, and we can deal with that. There are cases.

Sheen: That's what I was saying earlier on, not necessarily we should jump on the bandwagon because there is a new service from AWS. It's all about suitability, fit for purpose.

Adam: Yeah. I love that you always blend that pragmatism, and you bring it back to just not getting too carried away, and too ahead of yourself.

Adam: But I do wonder, is there, now in 2021, something that excites you, or something you're learning? Whether that's serverless, or whether that's organizationally how to teach other engineers, how to share. Just what's on your mind these days?

Sheen: Oh. In terms of serverless, I think I touched upon sustaining the pace. How can we keep going with this? Without burnout and getting bored. For that, you need to blend new things, and also adds values. As always, on the look out for such things. And so, EventBridge I talked about, so that's something I'm glad that most squads are now using EventBridge, and they see the benefits I'm getting good at it.

Sheen: The other thing is experimenting new ideas. If, for example, with step functions, the call back task token came up. Was exciting. Immediately, we didn't have any use kit, but then eventually it was a use case. Feeding those ideas, and let engineers develop on those kind of things.

Sheen: On the other side, on the team side, obviously helping engineers to get certifications, or directing them or guiding them I would say onto the different approaches they can take when it comes to learning things or doing stuff. Yeah.

Adam: Yeah. And you've been a part of guiding a lot of engineers there at LEGO through their serverless education, if you will. I wonder how you view serverless as an entry point for people that are new to the cloud. That they're a traditional software engineer. They want to come into cloud engineering. They're interested in AWS, or that's the direction they want to head. How do you view serverless as a first entry into the cloud?

Sheen: It's easy entry I would say, compared to a few of the technologies we've been through. Because if you set up a framework, few lines of code, hit a button, and you get deployed, and running on the cloud. But the important thing to remember for anyone who is coming new to serverless is that's just the beginning. Okay? Don't take it for granted that you just hit some deploy, and it's all there. Try to understand what goes behind the scene.

Sheen: I think I tweeted awhile ago, and also I always talk to engineers. When you deploy something from your framework, open up the cloud formation console, and see how the stack gets created, right? And there are so many things. Because engineers, they have the AWS console access all the time. Go and have a look at [inaudible 00:31:51] console. People say that it's so hard. Try and understand why it's hard. What is hard? If you find anything hard, discuss with others and understand.

Sheen: And same with [Cogniti 00:32:01]. We use Cogniti for AP authentication stuff. There are so many different things that it could do. Yeah. All these little things, and encouraging them to go beyond the scenes. That's important because just writing fee functions, and deploying, and saying that, "Oh, I'm so good at serverless." And that's good, but that's not the end of it. That's just the beginning. You have a stepping stone now, but now you need to climb the steps up to go up. Yeah.

Adam: Yeah. And for those that follow me on Twitter, I brought this question up because I had written something. Oversimplified serverless as an entry point, and Sheen corrected me. If you ever see Sheen on the internet correct me, just know that Sheen is right. I can tell you.

Sheen: No, no, no, no.

Adam: I oversimplified and said, "Serverless is a great entry." But my thought process being you don't have to necessarily have a background in some of the things that maybe you have to have a background in if you're deploying more traditional app architectures in the cloud. I think that's really exciting to me, that you can have this focused. If you don't know SQL, maybe you don't need it. Maybe you just you're going to use Dynamo, and you don't end up needing it. There's just a lot of things that excite me about serverless in terms of narrowing our focus on actual problems. But it is a long journey, and I miss that part.

Sheen: Exactly. You are right, because we need to make things simple for someone new to adopt the technology, right? But it's important to make sure that they continue the journey, learning more things.

Sheen: You just talked about Dynamo, right? It's so easy and simple to create a table, dump a few values there, do a query, et cetera. But the reality is understanding the indexing aspects, and if you get into the single table design, or this or that. And then, you would be able to extract the power, and understand the enormity of DynamoDB as a database solution. That's where they should get to once manage to deploy or create a table, for example.

Adam: Do you have any stories, or have you seen other organizations adopt serverless, following LEGO's lead?

Sheen: Yes. I can talk about quite a few. When you say taking as an example, I must also say that when we started to experiment serverless, there were other companies already onto serverless. Okay? Say for example, we spoke earlier about [inaudible 00:34:50] [Keho 00:34:50], and Keho, his organization, they were already doing serverless. And I came to know the guitar company, forgot the name. They were into serverless. But many organizations already into serverless, obviously.

Sheen: Since we've gone into serverless, and started to evangelize, I've had so many, so many people reaching out to me on serverless. Still do. I was at a conference last week, and spoke to [inaudible 00:35:22] people, and they were appreciating how they got the ideas and things.

Sheen: Also now, community's vibrant. There are many people [inaudible 00:35:31] doing it. I think you're going to have a guest from [inaudible 00:35:34] soon, right? Luke is going to [crosstalk 00:35:37]-

Adam: Yeah. Yeah.

Sheen: Yeah. He messaged earlier, a while ago, three days ago, where he [inaudible 00:35:45] event patterns from us, and how we use them. And his use case is a brilliant use case. Billions of humans flowing through EventBridge. Looking forward to that show actually.

Sheen: Yeah. There are so many use cases. And for example, Ben [inaudible 00:36:04], he's ... I think you should get him on the show actually.

Adam: Yeah, absolutely. Would love that.

Sheen: Ben [inaudible 00:36:11], he is at Theodo, and he has a great team. And he's basically helping many clients on their serverless journey. That's completely different. Whenever I talk to Ben, he tells me different stories. Because for me, everything is from one source, whereas people like him, it's from different sources. Many people have successfully adopted, and still learning, and going through the journey as well.

Adam: I did get one question, and I'll see if you have any thoughts on this question. And it was someone that said they're finding it difficult to understand API gateway, Lambda, and step functions. Do you have any recommended tutorials that teach those in depth?

Sheen: Yeah. There's so much there online. If you follow Yan Cui, The Burning Man, he's a master of step functions, right? So many patterns, so many things he talked about. And if you follow [inaudible 00:37:07] Johnson from the DA team at AWS, he's the AWS gateway, sorry, [inaudible 00:37:12], right?

Sheen: I remember [inaudible 00:37:16] awhile ago, there was a course focusing purely on APA gateway, Lambda functions, and DynamoDB. I think it was titled as a serverless course. These sort of things help. If someone wants to start from the basic, to get a good understanding of how these different core serverless services work together. Otherwise, there are plenty of blog post, and AWS has tons of, yeah, materials as well.

Adam: Yeah. We're not hurting for content within the database community. There's so many good resources out there. I do get that question quite a bit though, people wanting to know what's the best. What's the best article or tutorial?

Sheen: No. I wouldn't say there's a best or anything. It depends on each one's level of knowledge, right? Something I consider is best may not be best for you, because you are on a different grade, or level, or things like that. Yeah. Just make a start. Just go to the APA gateway console, and create an APA, and connect with the Lambda function, and do something, and just start from there. Don't get scared, just make a start.

Adam: Sheen, again, thank you so much for coming on. It's been so great. You're one of my heroes within the AWS community, and obviously an AWS hero. My heroes line up pretty well with the AWS heroes I think. There's a reason you are a hero.

Sheen: Thank you.

Adam: Thank you again so much for coming on.

Sheen: Thank you, Adam. [inaudible 00:38:42] hero, but there's so many heroes I interacted with, and I still look up to learning. Helped so, so much. And I know [inaudible 00:38:52] on your show, and probably more coming up.

Adam: Yeah. It's a great community to be a part of. Thank you again, Sheen, and-

Sheen: Thank you. Pleasure.

Adam: ... thank you everyone for joining.

Sheen: Thanks everyone. Bye.