Real World Serverless with theburningmonk

#25: Well-Architected Serverless with Heitor Lessa

• Yan Cui • Season 1 • Episode 25

Share episode

You can find Heitor on Twitter as @heitor_lessa.

Here are the resources that were mentioned during the show:

And check out the episode with Alma Media which was mentioned in this week's episode: 

If you want to learn how to apply the well-architected principles discussed in this episode and build production-ready serverless applications, then check out my upcoming workshops at productionreadyserverless.com and get 15% OFF with the promo code "yanprs15".

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

This episode is sponsored by ChaosSearch.

Have you heard about ChaosSearch? It’s the fully managed log analytics platform that uses your Amazon S3 storage as the data store! Companies like Armor, HubSpot, Alert Logic and many more are already using ChaosSearch as a critical part of their infrastructure and processing terabytes of log data every day.  Because ChaosSearch uses your Amazon S3 storage, there’s no moving data around, no data retention limits and you can save up to 80% vs other methods of log analysis.  So if you’re sick and tired of your ELK Stack falling over, or having your data retention squeezed by increasing costs, then visit ChaosSearch.io today and join the log analysis revolution!

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

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 a good friend of mine, Heitor from AWS. Hey, welcome to the show, man.


Heitor Lessa: 00:25  

Thanks for having me. It's an honour.


Yan Cui: 00:29  

Um, so let's maybe start by just introducing yourself to the audience and talk about what you've been up to and what your career has been like at AWS.


Heitor Lessa: 00:38  

Sure. Oh, that's a long story. Let's start with the first one. I'm a principal solutions architect, focused on developers at AWS. So that's pretty much from serverless containers, to anything that a developer usually use to build their applications on AWS. I've been at AWS for seven years, I think at this point, yes, in seven years in August. But I've been pretty much in multiple roles in the field. I started as a support engineer back in 2013, and then made my way through to a technical account manager, and then in Enterprise Solutions Architect focusing in the retail industry, and then I became the first specialist solutions architect for serverless in Europe, Middle East and Africa, and then you probably saw that close to the end, then I moved to the Well-Architected team to lead the Serverless Lens and get this out of the door. And now I'm back to being a principal solutions architect in a new team that's responsible for enabling developers and customers account.


Yan Cui: 01:43  

We've known each other for quite a while now. And there's quite a number of years, actually, I think, since you are working as a technical account manager at the Just Eat. So I guess I want to maybe talk a little bit about the Well-Architected framework, because it's been something that's really useful to the community. And then maybe let's talk about what it is, and how should customers be using it?


Heitor Lessa: 02:05  

Absolutely. So the Well-Architected framework started as solutions architects, technical managers, and what we call field experts. We're going to customers and meeting them and helping them with their business requirements, how to best use AWS. But all of this knowledge was mostly a tribal knowledge or something mostly available internally at AWS. Fitz, back in the days, Philip Fitzsimons, he had this idea of actually creating a framework that was generic enough that could be used by the vast majority of customers. Since then, the Well-Architected became like the go-to guide, if you will, for anything that as long as you're looking for best practices on how to do the best possible operations on AWS, performance, security, costs, and even reliability. That became both a matter of academic paper on to guide architects, developers, pretty much everyone at the customer and partners how to best navigate AWS, one of the questions and processes they should be thinking, which was something agnostic from the implementation itself, if they were to choose serverless, or containers, or virtual machines, if you will, Well-Architected was there to help them. Two years ago, more specifically 2017, Fitz had this idea of Well-Architected is great, but it's as the platform grows, it's nearly impossible to cater for every best practice every use case, especially places like serverless, where you go deeper into application development. And you have to change your mindset. In some areas, the Well-Architected created this idea called Lens. The idea of Lens was initially in 2017, a project to give specific best practices for an area and that we know it would deviate from the classic Well-Architected. For example, when I started writing the serverless best practices with three other people, we found that the Well-Architected guidance of you have to use availability zones, you have to use EBS, and all those other best practices that are like gold standards wouldn't quite apply to serverless. Because, in fact, there was a funny joke with one of my first customers in serverless in 2016, that he said, the thing I like the most about using serverless to joke with some of my colleagues is I open up Trust Advisor on AWS and it's pretty much green. Serverless takes care of all of that for me, I don't have to think about some of the operational bits. So the Serverless Lens was the idea of let's dive into some of the common challenges people have with serverless, some of the best practices, lessons we learned from this customers, partners and even from ourselves by building some solutions in AWS by building some open source, and try to condense that into a paper. That's how the Serverless Lens kind of started. And then last year as you also helped, thank you for that, we, we got this out to the AWS console. So that's kind of a where Well-Architected and Serverless Lens history in a bit.


Yan Cui: 05:22  

So I guess a common question I've got from people is that how does a practice become incorporated into the Well-Architected framework? I mean, at what point does the practice become considered as a best practice by AWS?


Heitor Lessa: 05:36  

Sure. So where we're connected has a very strict process on getting something should be called best practices. But even back in the days, when serverless we had this idea of, how can we call x best practice. If we don't, we don't know for sure if this is gonna, let's say be timeless, which is one of the main benefits of Well-Architected, the guidance. The specifically for Lens, which I've been involved more closely, we, we have a bunch of rules, but the first that comes to mind is public, and it makes sense is, if it's got to work for 80% of our customers, that's something that has to work for the vast majority of use cases. For the last 20%, we consider them an edge or leading practice, which is, it's something that we know it works for, for, let's say, a large chunk of customers. But it may not be true. As you start applying, what if this customer is an enterprise? What if this customer has a monolith? What if this customer is a startup? Or what if this customer doesn't have a large organisation structure that could deploy some people to tackle this particular problem? So the 80/20 percent rule is something like the top of our heads. As soon as we start something, if it's a new feature, if it's a new service, do we have enough customers using it? Do we have enough stories in customer use cases about this service or that particular feature? Does that.. if we look at the pillars performance, reliability, security and cost, if I do this best practice, does that make me worse off in any of the other areas? Or does that help me get an overall standard or score, if it will? So these are the two public ones that I can say. I'm happy to dive into those, into more specifics on how some of the ones that we use for Serverless Lens, if you like.


Yan Cui: 07:32  

So for customers who are interested in the Well-Architected framework and want to apply that to their existing application or a new application that they're building? What's the best way for them to get started? Are there I guess there's a lot of consultancies that offer that as a service. But is that something that they can do themselves?


Heitor Lessa: 07:50  

Absolutely. There's this misconception that Well-Architected is supposed to use when you go to production, or when you are about to go to production when you have a use case. In fact, we want customers and we want partners as well, to use Well-Architected as an educational tool as well, it can obviously help reviewing what they have. But it could definitely give you some of those practices and tips, design patterns, if you will, very early on. If you go to the AWS console, it will be the easiest way to start. You can search for Well-Architected in the console once you're logged in. And you can define a new workload. And you can select in this case, Serverless Lens. And you can even add a dummy project, if you will, just so you can see the type of questions we would ask, the type of best practices we expect you to implement and you also have a report at the end with links, more details and some videos explaining why is a good idea to implement those best practices. I think that's where I would recommend customers who are even already experts on AWS, but also customers who are beginning in AWS. So they have some good foundations to start.


Yan Cui: 09:06  

And I guess something that's related to some work you've been doing recently is how do we, how do customers then apply those best practices easily? Because one of the common theme we see is that, okay, it's good practice to use, to do custom metrics, for example, for application level stuff. But what are the... How do I do that? There are lots of question marks around, oh, do we make API calls to CloudWatch Metrics ourselves? Or are there some other tools to help us do that, like embedded metric format? Maybe talk about some of the things you've been working on recently, that makes it easy for customers to, I guess, follow these best practices?


Heitor Lessa: 09:47  

Sure. When we wrote the Serverless Lens, one of the pieces I loved about the Lens idea from the Well-Architected was we want to be pragmatic. We want to tell you what the questions are, the best practices are. And we want you to tell you how you could implement that and give you some examples. For instance, when we talk about metrics, before the Serverless Lens, we would say you would need to have some business metrics, some operational metrics, but we wouldn't quite tell you exactly what type of metrics these are, how would you create them if you were on Lambda for instance. When you go to the serverless, when you go to the AWS Well-Architected console, and answer a few questions, there's a tab that says improvement plan, or recommended items, if you will. The improvement plan, as we call it, is basically giving you the “how-to” of these are some examples that are open source that you can use to help you implement a set best practice. Or these are some of the links are tutorials, or even articles that you wrote, Yan, on how to do X best practice as well. I think that's one of the differentiators about the Lens project for Well-Architected compared to the classic one, which is more broad. But that said, there's still actually a big opportunity for us as a cloud provider, and including serverless heroes as well to help customers and guide them in how they can do some of these best practices more easily. So we come up with two things. So one was the wellarchitectedlabs.com, which is a website that you can, if you've done Well-Architected, and you're looking to do the implementation bits, whether you're doing serverless or not. There are, I think, over 30 Labs already, across all of those pillars, security operations, reliability and security, that you can, you can basically even go from understanding how to do best cost optimizations, to do some chaos monkey or chaos engineering, if you will, or even actually creating incident playbooks from security standpoint. Those are great. And that came before the serverless labs actually were available. But one of the pieces I found when I was writing the Lens for the console was we could definitely give you links and give you more content in more which is not a problem of content, I think, at the moment. I think, is the opposite problem. We have a lot of content out there, we just need to make it easier for people to find the content. So what I promised at re:Invent last year was some of those best practices shouldn't be that hard. We should definitely do a more collaborative work with the community on how can we do tooling to empower you to adopt those best practices more easily, especially because we are the ones also telling you what the best practices are. So we started this project called the Powertools, which obviously is heavily, it's heavily, I wouldn't say biased towards AWS tuning per se. I think that's not the word I'm looking for. Sometimes English fails on me. At DAZN, and obviously, you were primarily a big influence to actually, that's a great idea, I was speaking to Simon at DAZN when he was presenting to us internally. And I thought, why don't we have something like this, it shouldn't be that hard for customers to do custom metrics asynchronously on it on serverless applications, it shouldn't be that hard to basically capture cold start for tracing and do tracing annotations or labels, if you will do some of those good operational practices that sometimes you learn them way too late. So that's where the Powertools project came along. And we are obviously just at the very start, we went GA last week. So for customers, we expect them to go either from the improvement plan that we tell them to the console, what are their actions and how to they can do where Well-Architected labs they can have more hands on experience on how to implement those best practices no matter if it's serverless or not. And the Powertools as we started now, specifically for Python, which is the language I love the most, but there's obviously other languages. It implements some of the operational specifically observability best practices. 


Yan Cui: 14:11  

Yeah, I'm really glad that you guys took that idea of having some Powertools that, I guess, implement a lot of these best practices for correlation IDs, for metrics and for tracing and make that open source and available to everyone because that was something that I found that constantly, that when I go into a team that is easy for me to tell them this is what you need to do. But it's quite hard for them, for people to realise how they can actually be able to do it. And it's also a lot of work as well if you don't know what you're doing. So having those tooling that does the right thing for you out of the box without getting in your way has been really, really useful, at least within DAZN to adopt some of these best practices. Another thing I want to mention as well is your airline project. I think that was quite big turning point in terms of the kind of content that AWS puts out there. There's a lot of articles, a lot of blog posts, but they're all quite trivial. And you never quite see how the bacon is made, per se. And I think your airline project was one of the first projects that's available in the public domain that really shows how all these different things that you and I have been, other people have been talking about how they all fit together in the non trivial project.


Heitor Lessa: 15:26  

Yeah, I actually forget that. It's something now that I finished the Powertools at least for the GA, at something I want to get back to it, and implement the other best practices, and even actually do a public Well-Architected, which I never seen it before. And I asked on Twitter, and people were quite happy about that idea. So the service airline was the same idea when we were doing the Serverless Lens, Fitz, who was heading the Well-Architected back then now it's Rodney, also, both brilliant folks. We were coming together into this. We're telling customers on how to do those best practices. But I think getting a reading out 82 pages of the Serverless Lens is definitely like it can help a lot of people understand the mindset we are in had the community serverless and some of those best practices. But as you pointed out, as you try to try to find some of those content and trying to basically find something that's more than a Hello World example, or something that's not specific to an industry per se, that would, let's say, image resizing, if you will, is there wasn't something that you would, for instance, I've been working with, I've been helping customers of all sizes in EMEA way along with my colleagues to basically help them how do you how do I get this monolith and start decomposes into serverless? Or when do I use serverless? When do I not use serverless? How do I use REST vs GraphQL? Should I use Gatsby? Should I use server side rendering? So there's lots of questions that it will be hard to answer in the paper, or in our Well-Architected console, for instance. So the service airline was this idea of I know nothing about the travel industry of some of the underlying pieces. I know it's too complex. But I thought instead of one of the pieces I wanted to prove was serverless wasn't only for the startups likes or for greenfield applications, but there's always this same discussions about how do I structure my code? How do I organise my function? Should I do everything in a single function, multiple functions? What are common best practices when you're using SAM or serverless framework or infrastructures code, if you will? How do I integrate my service application with a containers or an my payment provider or anything else? When do I use synchronous vs asynchronous? Should I use events all over the place? How do I do DDD, BDD, you name it. So the idea was, well, let's create something slightly fancier. And we try to incorporate most of these best practices in one place. Because I thought back then it will be easier to maintain and also easier to show customers that something as mundane and as routine for us get picking up looking up for the flight paying for the flight that can be done in serverless shoe. I just wanted to open people's minds on that piece. And that's kind of how the airlines started. And then we did Twitch with you and many other serverless heroes, like Slobodan, Alex and Jeremy and a few others shall level them all. And I think, like I said, I wasn't kind of expecting to see that much of a jump. We are nearly 1000 stars on GitHub. There's been roughly over 150,000 social impressions on social media, like people. I wasn't expecting their response from the community, Especially because I had to learn design. And most of it was my first time doing something this big, as well as an example. So I was kind of treading carefully on. I don't want to build something so complete that people will think they can just deploy themselves and run in their own industry, which is not the case. But also how do I build something that's attractive enough that you wouldn't think that's something completely serverless.


Yan Cui: 19:30  

Yeah, I thought that was great. And was really nice to see that Nicholas and a few other people have since then, also have done something similar. And I think Nicholas, his project, the showcases of how to use EventBridge to build a really event driven architecture. I thought that was really good demo for people to see what that really looks like as well where you want to go really heavy into event driven architectures and using EventBridge. I think you also touched on earlier that you have spent a lot of time working with different AWS customers, are there some, are there other common adoption trends that you're seeing amongst your customers, things people are building different use cases and so on?


Heitor Lessa: 20:11  

Sure, absolutely. And so I think what you just pointed out, and I think Nicholas from AWS, in his example code on GitHub, AWS serverless ecommerce platform, that for me was another breakthrough, because it's another trend that's been happening since last year. But it's actually growing a lot stronger this year. And customers are starting to see, oh, we actually, we were comfortable with REST. But we have this thing called EventBridge, which is, again, helps us with having more events, having a schema registry and having something more managed for us. And, you know, kind of a, what we used to do with message bus back in the days, but something more modern now. So EventBridge, or event driven architecture is something that's becoming a lot more popular now, and more and more trending if you were, if you were in production. Suddenly, I don't have a specific, a bunch of customers I can name publicly. There's one in Sweden that Nicholas has been working on, I forgot the name now is MatHem if I'm getting the pronunciation correct, which basically was what Nicholas got inspired to do the e-commerce platform to showcase all of those good best practices about how do I do? How do I model an event in the first place? We tend to go and shout about event driven architectures and how beautiful this is, and etc. But there wasn't anything that would help customers understand how do I.. how does that look in practice, beyond another somewhat trivial example. And that's what Nicholas did on that one. So, and that brings other questions that Nicholas also addressed in e-commerce platform is, what is the tooling for EventBridge? All those questions are coming, popping up right now? How do I do integration tests for things like events? Do I put a listener into that event, and test if that went through all the way down? So these are kind of a trendy right now and something that I've expect to grow even bigger, as EventBridge keeps on innovating and listening to their customers. Another piece that I was actually took by surprise was CDK. So customers like Alma Media, or even Liberty, specifically Alma Media, they, they showed me what they've been doing with CDK internally. And it was like staggering, and the amount of abstractions and modules and patterns and best practices, they were able to,  basically put together to, basically improve the developer productivity, and fast track all their developers internally, you could think from things like, I need to do some integration with API gateway, and SNS, SQS, Kinesis, you name it, you know, this takes some VTL. And it takes some practice and to get it right. Or you need to get some domain certificates. And you need to do some single page application. And you can choose between single page application or serverless side rendering, or practices like I want you to do ETL on AWS so I need something I can ingest. And a rapid transaction, right, that could be ingested and stored into multiple regions. So Alma Media did most of that, if not more. And I was very surprised by how much CDK enables larger enterprises to basically build those patterns early on, and get to make something more easily available across the entire organisation. I guess, it's, it will be worth mentioning as well, the work that Mark did, and everyone, I guess, at Liberty IT, the CDK patterns.


Yan Cui: 23:55  

Yeah, I actually spoke with Ari recently on this podcast. So I'll put a link to that episode in the show notes as well about some of the things that they've been doing at Alma Media, not specifically about CDK. But I do know, the work that I'm quite familiar with the work that Mark and those guys have done in liberty for the CDK modules is really powerful, what they think what those guys are doing. And another thing, I guess, I wanted to ask about is in terms of the common challenges that you see in your customers when they're trying to move to serverless?


Heitor Lessa: 24:28  

Sure, um, I think because or because it's quite.. I'm trying to think on how to best explain without visual help. I think one of the ways I like to present your customers is I built a user journey to explain some of the typical enterprise journey as a serverless customer goes through. That's kind of a few experts that we work with customers. And when you divide customers in what we call foundation and reinvention from the classic stage of adoption, that's only available on internet. When you, when their customers aren't at foundation, where they are trying to use AWS, they have a project that they want to use, or they want to migrate. And it crosses their mind that serverless could be a big enabler for them. And when it comes to that, there's, the challenges are not so much on the tech. But it's more around, how do I structure my team to be autonomous? How do I empower these things to make the right decisions? And how do I make sure that these teams are actually doing the best for the company? And how do I more importantly, how do I hire people now, because it's a common thing in enterprise and in certain industries, where it has been for years that you would outsource most of it. So now you'd have partners, consultants helping a lot in their journey to the cloud and modernising or even migrating. But as they try, as they are trying to create a new team and trying to create that structure, like two pizza team, if you will, or tribes and squads like in Spotify model. It's something that they have challenges of trying to hire those people, those talents, who already had experience with microservices, and also want also possibly have experiences with serverless. There's obviously detect mindset change as well, when you are basically used to do everything locally with possibly, not even we're not even going to talk about Docker containers in a minute, but it's more, you were used to do everything locally running a Postgres database locally, or running on an Express, if you will, if you're that modern already. And so moving to the cloud, specifically for serverless, it's, it's a big change of mindset on how you're not gonna, you're not gonna basically do everything locally, but just partially, you also have different tooling as well, which you kind of get used to it. There is a lot of operations and a lot of the learnings you get when you go something like microservices, so customers and their foundation, going from let's say, data centres or a monolith, a reasonable monolith, straight to microservices and serverless. The challenges are mostly around, okay, how do I even operate this thing? How do I structure my team? How do I, what is the tooling? How should I test it? So those questions are very different. When you go to what we call the reinvention phase, customers were under reinvention phase, they have the opposite problem. They sometimes are running containers or running Kubernetes, or you name it, and they possibly gone to the micro, the microservices, two pizza team model, autonomous teams, if you will. And now they're asking the opposite questions. Everyone is making different decisions. We've got Golang, we've got Java, we got JavaScript, Elixir, or Kotlin, you name it. It's just like a lot of languages, a lot of tooling. And we don't quite know how to get it right. There was a customer that I admire, one of the customers I admire the most who've gone through that journey. And it was very public about the whole piece was called Gilt. It's now called HPC Digital. They've, they've gone through that transformation of actually going from a Ruby monolith to microservices, and empowers teams slowly. And they got to a point where back in 2015, when I was working with them, I think they had like seven deployment tools that cause their teams could use up to the point where I remember we had a discussion where teams weren't able to do a rollback because they change between teams. And now they didn't know how to roll back because the tool was different. So those questions are more popping up or challenges, if you will, in that reinvention phase, how do I put some ordering here? And yet empowering everyone to do the right thing? How do I now go from the tooling, I got used to it from containers from Docker, to just serverless. Do I need to change anything? Obviously, you will need to do some refactoring and some pieces would stay in containers. So the challenges would change a bit between this like foundation and reinvention phase. And obviously, the size of the customer and enterprise or a medium size as more medium size, SMB, or startup would change. But typically, that's what I've been saying for the past five to six years when trying to do serverless, containers and all those pieces.


Yan Cui: 29:32  

Yeah, that's very similar to a lot of things that I've seen as well when I'm working with my own clients. And certainly those problems are really really common, especially for large enterprises, that fragmentation of tooling and languages and supporting different runtimes and different systems they have is bit of a mess. I guess one thing I want to also touch on before we go as well is you have this amazing career at AWS, you progress through different teams, different areas. And one question I've been getting quite often from social media is how does one prepare himself or herself to join AWS, there's maybe this misconception that you need to be AWS certified to be able to join AWS. So what advice would you give to someone who's listening and aspiring to join AWS one day?


Heitor Lessa: 31:19  

Sure. Funny enough, that's what I've been doing the most recently, and that's definitely a misconception. I remember, I'm not sure how funny it is, I think, I think it might be a bit of, a little bit of overexposure on the personal piece for me, but when I did the first interview, it was, I think I did roughly seven hours of interviews of AWS. Back in the days was actually a phone screen, and then they have an onsite loop, which was still kind of have the same practice. But for me, who never done something like that was, oh my God, I've got to prepare all Linux, but I was a networking guy, infrastructure, whatever you want to call it these days . But I remember I was like, I was studying every possible configuration management tool, getting into the… I was even studying Linux, Linux kernel networking to understand some of the frames, and deep down in the socket level and some of those pieces, because I thought, well, they could ask me anything. And turns out that when I got there, people were so friendly to me that I felt, okay, maybe I've got maybe I, maybe I possibly got it all wrong. Because everyone's been so friendly. Everyone's asking me questions around random questions, from operating systems to architecture to some software design, if you will. And what turns out was actually I passed, obviously, so I was super lucky and super happy back in the days. But what I found was, uh, the interviews obviously change. And there's so many departments or so many different roles across AWS, that we ended up even hiring a lot of people back in Brazil, when I told them, you know, you actually don't really need to know all of these pieces only to be an AWS cloud expert. Because if we were looking for AWS experts, only then it would be, we will be in the same position as other companies are having difficulties to hire as well. In fact, we can, we have a pretty comprehensive training package to enable people when they get in. What we actually care is how do you think, how do you, how do you behave. Our leadership principles are super important for us, we live and breathe this thing. So if someone was trying to join AWS today, I would first try to understand what is their dedication, where are they coming from. Some people are looking for software development, jobs like SDEs, that's definitely much harder, because it's a very specific type of job. So the interviews are quite different. But if you're looking for more customer facing roles, like in the field, like I do, like solutions architect, or technical account managers, then the interviews are slightly different as well, the process is slightly different. So obviously, if you're coming from a technical manager job, ideally, you should have a lot of experience with operations, dealing with some customer management as well. Maybe you have a sysadmin background, but you've also been speaking publicly about processes or improvements reliability, if you will. That's kind of a perfect for technical manager because it's a blend between a customer facing role and someone who's deep into the operations and stability like SRE type of thing. Support engineer or the support organisation, you have a mix of backgrounds you have both people who are sysadmins in the past, and they're specialised into, let's say Linux or certain operating systems or deployment tools. If you will think about Ansible, OpsWorks, Beanstalk, you name it, code deploy, if you will, which actually if you know deployments quite well, the tooling, the acquisition and the process, it's not that hard to map that into, say CodeBuild, or Beanstalk because you already know the essence of it. And then solutions architect is a blend of you could be either someone who comes from an operations perspective, consultancy, or even software. And you already have the background on how to build solutions. But you also have the customer facing aspects, like consultancy, if you will, where you wouldn't only talk to developers, but you also you will basically talk to anyone inside the business to and you would have to change your tone, and your messaging depending on who you're talking to. There's obviously more roles into it. But these are the three main areas that I think people typically start at AWS.


Yan Cui: 35:50  

And another thing that's really differentiate, I think you talked about the leadership principles quite often. And certainly that is something that Amazon is constantly talking about. And one of the things that really differentiates AWS compared to other cloud providers is how much you guys interact with the customers base directly and how much the feedback actually goes back into your teams. In fact, I was talking to someone yesterday about AWS and one of the things that he said was that it's crazy that all these different things he talked about on social media in terms of your AWS wishlist items is crazy how often they just suddenly get announced as a new feature? Certainly, I mean, a lot of my AWS wishlist items that I outlined the last year or even year before has now been announced as the features which is amazing. So how does the feedback, that is external feedback gets actually fed into the team within AWS and how do they become reality? 


Heitor Lessa: 36:53  

Sure. It's a very elaborate process, I think, I think there are many AWS product teams and you already are aware of people like Chris Munns, and he's brilliant, amazing developer advocacy team. I can specifically talk about the serverless pieces, but others are quite the same. So you have multiple people at AWS interacting with customers, you have people who are more vocal in social media, for instance, my role is not so much about the social media aspects. But I'm there, I love it. That's what I like to do. I like the community aspects of it. But I also spend, the vast majority of my time is spent with customers, and helping them navigate AWS, the challenges that we've discussed, how to go through how to improve from hiring, tooling, etc. And as you're working with customers, from the solutions, architects perspective, you typically raise those feature requests with product teams directly but there's also because of the leadership principles, and the big focus we have on writing, we also end up creating documents to say, these are some of the trends we've been seeing in the field, working with business development managers, and even internal communities where we say, we've been seeing this trend. And these are some of the customers that actually have been asking, and this is exactly the feedback they've been sharing with us. So that is actually very well respected. As you already pointed out. AWS cares a lot about the customer's feedback. And that has a tremendous weight, which is something I normally tell people, please be more vocal, sometimes you are complaining about something that you think you're rumbling, but write that down, share that with any AWS people, and they will definitely get to the right place. From that external piece, and not dealing with customers on a one to one basis, you have evangelist, you have developer advocacy, you have even product, some of the product managers go out to speak as well. You have even solutions architect and some other specialists to go to speak at public conferences, or because they're on social media, we have hashtags like AWS wishlist, which is also monitored by the support engineers and the customer, the customer service folks, so all of this gets fed into the product teams through our systems that we use, so they can do, they can make the right, they can make informed decisions. And oftentimes, they would say, like EFS for instance that just came out. That's been like in the pipeline with multiple customer feedbacks on why they need it. And, and product managers would often go and talk to these customers or even us maybe we need more details. Maybe we're not so sure yet that this will work for the vast majority of customers. So we go back and forth. But this team of the two pizza team model of teams are very nimble, and very agile. It makes it easier as well. If you have all of this like people and roles, fitting those feedback to you in a way that you can easily consume and make decisions. It definitely makes the wheel spin faster.


Yan Cui: 39:59  

That's Great, that's definitely one of the most important differentiators when it comes to AWS and I guess, I guess, why we love working with AWS so much as well. So probably the last question, what's next for you? I hear you're coming to Netherlands soon.


Heitor Lessa: 40:16  

Sounds like we're breaking this to public now for the first time. Yes, I'm moving to Netherlands. It's gonna be next, end of next month. I'm super looking forward to it. Have you, have lots of friends. I’m really excited. And actually I don't know if everyone knows but back in the days when serverless started like 2015ish, 2016, the biggest community we had in serverless from the meetup perspective was actually Amsterdam. And it's kind of a fun fact, and Netherlands is definitely a place I've been looking forward to go, to basically live there for quite some time. But it was trying to figure out which teams are going to be and trying to settle down in some of those work life decisions if you will. So that's definitely one. Another one that's next for me is you. It's been very subtle but I changed my Twitter profile to back to Principal Solutions Architect, at Developer Acceleration. It's a new team that we're creating focus on those developer experience and basically work with those developers at the customer, basically what we've been doing for the past few years, but more formalised now, so basically how customers build developer communities, enable their developers from design patterns to serverless containers from anything you can possibly think of from a more long term engagement, then obviously there's some open source stuff as well, like the Powertools I was so excited to get this out. And now I should be coming slowly back to the airline to implement some of those best practices now. I guess for now, as a lot of ready for what's next. 


Yan Cui: 41:58  

Yeah, I'm looking forward to seeing you here in the Netherlands, especially now that I can't fly. But yeah, looking forward to that. So I think that's it. I guess, one last thing, how do people find you on the internet?


Heitor Lessa: 42:12  

Yeah, they can find me on Twitter is heitor underscore lessa (@heitor_lessa). That's where I spend most of my time publicly. I sometimes check LinkedIn but Twitter is where I spend most of my time. Twitch is something I'm planning to go back either this year or next year for some live coding. There's something I've been cooking with my team with all of this on how we can do something like that again, like to build on serverless series I typically do every year. But Twitter is actually what I am. My direct messages are open. If you're looking to join AWS and if you are having those questions, I can’t promise I'm going to answer to everyone, but I'm happy to give some advices if you will. But yeah stick to the leadership principles and you'll be mostly fine. I think that would be for me, ping me on Twitter. I'm always there. If I can help with anything or if I can introduce you to some of those great developer advocates we have or evangelists, or, you know, product teams, I'll be happy to do too.


Yan Cui: 43:07  

Excellent. And Heitor, thank you very much for taking the time today to talk to us. Stay safe. And I'll see you in the Netherlands soon.


Heitor Lessa: 43:15  

Yeah, looking forward, man. Thanks again for having me. It's such an honour. Thank you.


Yan Cui: 43:20  

Take it easy, man. Bye bye.


Heitor Lessa: 43:21  

Bye bye.


Yan Cui: 43:35  

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 and how to apply some of the Well-Architected concepts that we’ve discussed in this episode, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time