#103 - Community building, being an enable, is serverless dead? ft. Allen Helton
01:00:27 Share

Support for this episode comes from HookDeck. Level up your event-driven architecture with this fully serverless event gateway. To learn more, go to hookdeck.com slash theburningmonk.

Hi, welcome back to the end of the episode of Real World Serverless. Today, I welcome Alan Helton, who's the, I guess you're the founder of ReadySet Cloud, a blog post and webinar and podcast. And I really enjoyed your writings and you've been working with the Memento team as well. And I'm a big fan of them as well. So welcome to the show, Alan.

Hey, Jan. Thanks for having me on. Super happy to be here and appreciate all those nice words about ReadySet Cloud and Memento. It's been a lot of work, a lot of fun work and very gratifying experience so far. Yeah, and also I'm a really big fan of the work you've been doing with Andrea and others around the Believe in Serverless community as well. It's a really nice active community that often does a lot of interesting conversations and things like that, which I have really enjoyed being a part of.

and I'm sure others as well. I see Sam and Omid and quite a few other people and even Luke and a few other people as well in that community and always engaging and helping other people, which I really enjoy seeing. So, you know, well done on those things. Thank you. Thank you. That community has been just...

A fantastic time. I can't even tell you, like we started, we started it in January and, you know, it's grown to what it is today. I think it's over 800 members and it has way more engagement than I really could have ever imagined or hoped for in the first six months. It's been almost overwhelming, the community response at how excited people are to engage in there.

Yeah, and I really like the fact that you have not just the conversation on the Discord server. Oh, by the way, for anyone who's listening, I'll put a link to join the Discord server so that you can also join the community as well. But also a lot of events you guys have been organizing. I've been trying to find time to catch up all the backlog of the events you've got, webinars and things like that with different people and sharing a lot of the learnings around the serverless space

Yeah, that one has been fun. You know, we originally started in January with doing these themed months where we would have typically like four discussions a month on a specific topic. And it's really just grown since there. People started asking, can I talk and submitting CFPs to the group, to the champions, the people that basically run the community. And who am I to say, no, you can't talk.

So we grew from these theme talks, which we still do every Thursday. And now we do non-theme talks or essentially like brown bag talks every Tuesdays as well. And then we also do live coding events every Fridays. So really on a good week, we're pushing out three to four videos or talks every single week in that community. And it's from real world practitioners that are offering their advice and insights on what has worked and what hasn't worked for them in industry.

Yeah, I love seeing what you guys are doing over there. And it's something that I kind of model my own Discord server around as well. My Discord server is mostly for my customers and the students and whatnot. I definitely don't have a bandwidth that you guys have in terms of driving all the activities you have going on there. So it's really amazing for me to see what you guys are doing there and trying to take a lot of the cues of what you've done and the things like that and try to apply that to my community as well.

I guess one of the things that that kind of brings me to one of the things that you wrote about, I think it was a couple months ago now, about being an enabler. And that's something that kind of strikes a chord with me because that's something that I've tried to do for much of my career, starting from just being a more hands-on developer, gradually going towards more principles. You become less and less of just an individual contributor.

your value to the organization is more about how much you can enable your teams, other teams to be 10%, 5%, 20% better so that you become a multiplier in that sense. And that field side is something that we can also do and definitely what I've seen you do as well in terms of enabling the community at large, not just community within your company, but also the bigger AWS and serverless community as well. So,

Maybe we can just start by what do you mean when you say an enabler? What does that mean to you? Yeah, it's good that you asked that specifically because at least in the US, enabler generally has a negative connotation. And I wrote this in the article where if I'm just having a conversation with my friends and somebody says, you're an enabler, usually they mean that in a bad way. Like an example of that would be giving a beer to an alcoholic.

that's enabling that alcoholic to have more alcohol. And that's obviously a bad thing. You don't want that. But it doesn't always mean that. And what I mean when I say it is I do my best to help people get out of their comfort zones and act and do those things that they want to do that they might not be able to do themselves or might not have the courage to kind of push themselves over the edge to actually commit to doing it.

So I use the platforms that I have, like ReadySet Cloud and Believe in Serverless, to provide these opportunities for first-time speakers or maybe not even first-time. Maybe it's somebody who's nervous about talking about something specific.

Or writing something. I opened the doors to Ready, Set, Cloud to guest authors this year as well. So if you want to post a blog somewhere that has a lot of site traffic, come talk to me and we'll put something up there. But really what I want to do, and this is something that I'll get to in a minute, is giving the opportunities to somebody else.

who is too nervous or maybe doesn't know how. And that right there is, it was kind of a huge pivotal moment in my career personally from some of my friends who I consider enablers to push me over the edge. And so let me talk about that for a second. So I have had two professional programming jobs in my career. I started in 2012 as

as a, as a programmer. And I started at a company called Tyler technologies. And I was there for 11 years, most of my career. And I was, I was really happy for a really long time. Uh, when I got into serverless and the cloud stuff in general, in like 2017, 2018 timeframe, yeah. And honestly, I was reading your stuff like every day, um, to, to learn all that. I,

I started writing about my journey because your stuff is great, but it wasn't exactly the niche that I was in. You know, I was doing government work and public sector work. So I had a lot more regulations and I didn't have a lot of the options that were available in the commercial cloud. So I started writing about that and really enjoying writing and communicating and educating. And I grew into that for a long time, for several years and realized that, you know what? I actually like that.

and think I could do that as a full-time job. And I was super nervous about it because I had been at Tyler Technologies for 11 years. And I was like, what if I was an architect at the time when I was thinking about leaving? I was like, what if I don't like it? What if I'm going from an architect to somebody who's doing content creation for a full-time career?

And I don't like it. Can I, what happens if I have a gap in my resume for six months for a year where I'm not doing architecture work and I want to come back to architecture work? Is that going to be okay? Is a potential employer going to see that and not

hire me because I had a gap. I decided to leave and then I came back a boomerang basically. I was super nervous and I wasn't going to do it. My wife helped. She was talking me through all that, but I didn't have quite that push because it was risky to me because I have two kids. And I was like, what if I don't like it and I can't get hired again? I'm the sole provider in my family. So if I don't have a job, then we're in trouble.

So it was Andres, who you've already mentioned a couple of times this episode, that was just like, do it, do it. And I was honestly, that was all I needed to hear was literally the words do it from somebody that I trust. And I did. I started interviewing and I'd already been friends with Kawaja, who's the CEO at Memento. And he said, come work for me. Come work. He actually said with me, not for me. He's that kind of guy. And I was like, okay.

Okay, I think I can. It was that do it that gave me that courage to actually take the leap. And it's not just do it like being an enabler is not just saying do it and kind of washing your hands. It's like do it. I'll go with you. I'll help you. I'll de-risk it with you. Or if I'm not going to de-risk it, I will take the risk with you.

And, you know, Andres was there and he was like, I will help you if something goes wrong. And that was what gave me the courage. So that's what I really want to do. I want to pay it forward to as many people as I possibly can, because that's how you grow. You know, I got hired at Memento and I've been there for a year and a half now. And it's been an absolute career changer. I have grown more in the year and a half that I've been there than I did maybe the last five years of my career at Tyler Technology.

because of all the opportunities that I have, because of the different things that I'm doing now, and because of the exposure to the community that I have now, because that's part of my job, versus what I was doing over there. So that, in a nutshell, is what I think of when I think of being an enabler, is providing opportunities to people so they can grow, so they can get out of their comfort zone, but also feel like they're not alone when they get out of their comfort zone.

Yeah, and I think for folks like you and myself who have been helping the community and in return have built our platform, people that listen to us and respect our opinions, I think it's important for us to then make it available to other people so that they can then show off what they're

what they know. And I know there's a lot of people that I have worked with in the past who are great engineers, who's got a lot of experience, but maybe they're not so good at marketing themselves. They haven't spent time engaging the community over their careers, but they haven't got that exposure. So when they talk, not many people are ready to listen. And so for, you know, for you and me to provide them with a voice in the community, to share their expertise and knowledge, I think that's also a big part of

the bigger ecosystem for that ecosystem to survive and to thrive as well. Especially when, you know, in the tech space, there's just a lot of negativity flowing around, especially if you look at the social media. Recently, the whole thing around the bus serverless is dead. That kind of drives me nuts as well. Just everyone wants to take every small little thing and try to, I don't know,

painted in a different way. And like the whole thing about AWS doesn't have a serverless advocacy team anymore. And to me, that just means that the serverless is mature enough that most people are using it. They don't really need to have a dedicated advocacy team for that. But no, obviously other people will be like, Oh, serverless is dead. Even AWS doesn't believe in it anymore. This whole thing around the whole prime video article all over again, it's just really exhausting. Yeah.

Yeah, you got that right. That Prime Video thing, I just feel like isn't ever going to die. People read into that and people are going to see what they want to see, of course, always. But exactly what you said, the serverless dev advocate team going away is what Jeremy and I talked about on my podcast at the beginning of this year. Not specifically that, but

Are we at a point where we can move past serverless? And we've seen a lot of conversations like this recently where we don't need to talk about it anymore. Of course, there's still going to be things that we do talk about, but it doesn't need to be a hot topic on the table all the time because it's starting to get to that point where it's mature enough where people just understand that, yeah, I should be using it for this and I don't need to raise my hand and say, yeah, I'm using it or no, I'm not using it. So I'm real happy about at least about that part of it.

Yeah, it's the same as NoSQL. I mean, I was going through the whole NoSQL movement back in the day, and nowadays no one talks about NoSQL anymore because it's not a useful umbrella or marketing term anymore. People just use the databases that are what we would have classified as NoSQL. They just use it as a memento or

whatever, Pinecone or whatever database, there are NoSQL databases, but people don't need to use that NoSQL umbrella term anymore. And I hope that we are at that point where we don't need to brand things as serverless anymore. People just understand the trade-offs, understand the

the trade-off that comes with individual services as opposed to everything about serverless is not this, whereas there's always been a bit of a spectrum like Ben Cahill kept saying that, yeah, some things are more serverless than others, but it's important to understand what exactly that it is you're looking for and what you need and look for the services that give you those characteristics.

Yes. Yes. And I've gone on record several times saying, you know, when talking about is it serverless, is it not? You know, I say it doesn't matter. Really, I'm not, I don't set out when I build something to make something serverless. That's really not my goal anymore. It used to be. It used to be. I used to take pride in saying this is 100% serverless. Now I take pride in saying this works and it works at any scale. And I don't have to be an expert in hardware to,

to know how to load balance this or to bring up servers. And I don't have to know what my traffic spikes are going to be if anything ever goes viral. So what I care about is it working all the time. And that to me is much more important than saying, yeah, I built something serverless.

Yeah, and it's the funny thing about that as well is that you've also got some vendors like Vercel, which has got a huge markup on Lambda. And because Vercel is kind of the first introduction to this concept of serverless to many front-end focused developers, suddenly when people talk about, oh, this company, this social network got viral and ended up getting a $100,000 bill from Vercel because serverless is expensive.

And again, sometimes putting everything under that serverless umbrella also means that you've got one or fewer companies that maybe are doing things that others wouldn't and suddenly everyone gets labelled in a particular way or seen in a particular light.

Yeah, yes. And when it comes to situations like that, like I read the article and as soon as I read it for the first time, it was before all of those crazy opinions came out and everyone was talking about it on social media, talking about that $100,000 for sale bill. And I always come back to almost like a grassroots thing where think about serverless pricing, like your electricity bill.

It's literally a pay for what you use kind of thing. And everyone says, okay, well, yeah, that makes sense. I get that. But it's still cheaper if I have a container that's a preset cost for the course of the month and I can use it as much as I want. But when you think about it from an electricity bill standpoint, I don't like that because let's just say I pay $200 a month for as much electricity as I want.

And what that's going to end up turning into as far as my behaviors go is I'm going to be much more wasteful. I'm going to leave all my lights on. I'm going to turn my AC down to 65 degrees at night, and I'm going to leave it at 70 during the day. And I'm going to use 10 times as much electricity as I would if I was paying for what I use. I'm going to be a lot less mindful.

And while it doesn't track 100% with the usage cost and software, it does have some of the same tie-ins here where you might be building something, but it's not going to be as sustainable as something in a serverless world. So you have to take it into consideration if you care about sustainability, which hopefully a lot of people do, but I understand that not everybody does. That's something to still take into consideration with the cost it might be worth paying.

paying a little bit more if you're saving the world a little bit more. I pay more for things like that just as for consumer goods all the time.

And I guess people also didn't talk enough about the fact that this social network went from almost no users to 500,000 users in the space of two days and then just kept growing. And they had no scalability problems. Everything just worked. And that's also one of the things that, okay, if you're running a bunch of containers, you probably would have had to do a bunch of re-architecting, maybe some outages because you didn't

you didn't anticipate the kind of traffic spike you suddenly got because your site went on some viral news thing and everyone suddenly just jumped on board. So the fact that they had all that scalability and they would just scale without any problems, that's also one benefit that comes with using serverless, which unfortunately everyone just saw the billing site, right?

not the side of what they actually got from using serverless. Totally. And there's an actual term, it sounds made up, and I learned it for the first time from Reddit years and years ago, is the hug of death, which is essentially something going viral. If you don't have something serverless, let's say you have to provision it yourself or something that has a relatively slow ramp up for scale,

You might get a hug of death in the sense that it's so popular, everybody's hugging you, and they might be hugging you a little bit too tight and choke you out and fall down. With serverless, that's not generally a thing. Obviously, there's exceptions to every rule, but we're getting to a point where that vocab word might just be something we stop using.

Yeah, I mean, it also kind of just reminds me of that Prime Video thing all over again, because it's, yep, Prime Video, they started with a service with no user. They don't know if anyone's going to use it. So they use the serverless and step functions to go fast because it's a faster time to market. But then the ones that after they, I guess they got to scale over the course of several years. And only at that point did they decide, OK, we need to optimize for efficiency and cost.

We don't need agility as much now that we know what people want. The product is fairly mature. So at that point, they pivoted. But I guess for this app, this Kara app, it happened within two days. So there's no chance for them to re-architect quickly. But they were able to, like I said, withstand this hug of death because the server was able to scale to the demands that they had.

But yeah, it's one of those things, I guess, you know, you have to choose one or the other. Well, at that scale, whatever they were doing, it would have been expensive. It's just a question of, okay, if they were building on Lambda, it would be

Expensive but not 100,000 expensive. It would be maybe $10,000 or something like that. But because the seller has got this 7x markup on Lambda and plus they have all these additional charges including now, I think AJ posted about a couple of days ago or a couple of weeks ago that they now also charge you for egress for your logs. If you ship your logs somewhere else, they also charge you on that as well.

So yeah, the seller just feels like there's quite a few traps when it comes to the pricing. And if you're not careful and you suddenly go viral, it can be quite scary. Yeah, absolutely. It's something that you have to watch. Usually I'm all for things that are self-contained.

where it's like they just make it easy for you to build, where I'm concerned about solving business problems. I'm not so much concerned about solving infrastructure problems and negotiating that song and dance that comes with integrating a bunch of different products together.

This is probably one of those times where I would err on the side of, let's not do everything in Vercel. It's, of course, trade-offs. Plus, I do know AWS very well, and I can very easily build it back in AWS and have it be called from a front end that's hosted in Vercel. Yeah. Yeah.

Yeah, and I guess people like DAX and the SST team has been doing a lot of work to enable people to move from Vercel to AWS using SST. They have pretty good abstractions around the NestJS, and so they can take your pretty much existing Vercel application and ship it onto AWS and running on Lambda yourself with SST fairly easily.

So I think that's also an option. I think a lot of people are looking at once they've read about the Vercel stories. Yeah, for sure. And that's something that I wish I could speak better to, like SST and Ion and all the stuff that DAX is working on. I had them on my podcast last year to talk about building serverless the right way.

Which, of course, is such an outlandish thing to say. But, you know, when you have DAX on, you have to say things like that. And, you know, I just I love the stuff that they're doing and I love watching the progress and seeing how easy they're making these abstractions. But it's something that I haven't I don't have a lot of experience in yet. And I look I hope that I can get an opportunity to work with that more.

Yeah, and I guess another thing that I think SST has done really well is the whole thing around building the communities around them. They have so many really hardcore fans and it feels like they're almost building almost like a cult, especially around Dex. He's quite a personality. Sometimes he posts on social media a little bit too much for my liking.

But I can see it's working really well in terms of building that community. People are really enthusiastic about SST. Do you see anything that we can borrow, anything that they're doing really well that we can apply to building communities like enriching the believing serverless community?

Oh my gosh. So first of all, they do such a fantastic job on marketing. And I think you're right. A lot of stuff that he says is a little abrasive. And I've called him out on that a couple of times, but in a good way, in a fun, playful way. That's not for everybody, but it's so effective. It's so effective. People love bold claims and just the

The cockiness that comes out of there because people want to prove him wrong, but the community and the product that they've built is so good they can't. So they're driving – he's driving traffic because people want to prove him wrong, but he's right. And that's a fantastic way to market. So I'm not going to steal that because I'm not –

I don't like talking like that. And that's, you know, I'm going to say that's okay. That's not for everybody. It's incredibly effective if you do it right. There is a fine line to tread from

uh you know being able to back that up and and not if he wasn't able to back up the way that he talks i think that wouldn't work nearly as well um but as far as like what we could do to to help with community and and getting people engaged i come back to what we talked about really at the beginning of this episode where it's providing people with opportunity uh you know so what

What the SST team is doing, what you may not realize what they're doing, is they are tricking you into trying it by saying, we do this better than everybody else. And devs, you know devs, they love a challenge. And they love to prove people wrong. That was always my favorite type of proof when I was in calculus, when I was in high school, was proof by...

I don't remember exactly what it was, but it was more or less a disproof. Here's why this proof doesn't work because of this equation. And that's what devs like doing. So they say, okay, well, he says this. I'm going to prove that wrong. And they go and they use it, and there's the best type of marketing. So that's one thing that you could do, but –

I'm much more of a let's get you in the door. The term for this is land and expand. When we're talking about marketing, we're talking about sales. Let's get you in the door here. Here's a speaking opportunity for you. Or here is something that I know you want to do, but maybe you don't have the means to do it like a blog post or a podcast episode. Let's do that. And you provide a really good experience, which you should always do anyway.

But after you get in the door, after you have that first experience with somebody, they're so much more likely to come back and try you again or try, okay, well, I did a podcast episode with you. Can I do a blog post for you now? Or can I go do a talk for the community as well? It's not a completely new experience because I've already been on your platform before. So let's try something else. It was a really friendly and enjoyable experience. I liked it and I want to do it again.

And that's how I see growing this kind of thing. It's one of the reasons why I believe in serverless community does as many talks as we do. I try very hard to get new speakers in, new voices and other opportunities for people to share what they're working on and build diversity of thought, but also provide people with the opportunity to try something new.

So that's my general approach is let's do something that's a low barrier to entry for you.

And then once you're in the door, let's push a little bit more. Let's enable you to, to come in and do more things. And, and I'm not trying, don't, don't listen to this and think that I'm trying to manipulate you into doing things for me for free. Definitely not that really what I want to do is make you comfortable to do more things, to get you out there, to build those experiences, whether you have had them or not. And, and,

make you into the content creator or into the speaker that you want to be. Event-driven architectures is a powerful paradigm for building large-scale systems, but they're also notoriously difficult to test and observe and monitor in production.

With so many independent event publishers and subscribers, there are a lot of additional complexities around error handling, alerting and recovery, and making sure that you have full visibility into the entire lifecycle of an event so that you're able to troubleshoot any problems that you have encountered before.

I have built many event-driven architectures on AWS and these are just some of the recurring challenges that I face. And that's where HookDeck comes in. It's a fully serverless event gateway. There are no infrastructures for you to manage. You can get started in just a few minutes with their command line interface.

Compared to Amazon EventBridge, it does everything EventBridge does. It can ingest events from multiple sources, filter them, route them to different targets, and transform the event along the way. But it also offers a better developer experience, including a local development experience,

and having more detailed metrics and logs to help you debug issues with delivering events, and just being able to query what events you have easily, which makes testing much simpler. You can start a free trial of HookDeck today and support this podcast at the same time by going to hookdeck.com/theburningmonk. Okay, back to the episode.

Yeah, and I have to say, being a content creator myself is also a great way for me to expand my own knowledge and to learn as well. I forgot what was that learning theory about once you can explain to someone else in a language that's much easier to understand.

Was it Richard Feynman that said the best way to learn is to learn something well enough to be able to teach someone else and explain it to them as like a five-year-old? Was that Richard Feynman? I don't actually know that quote. I heard one the other day. I was reading the book, The 5AM Club, and there was a quote in there. First of all, great book. Highly recommend if you haven't read that. But there was a quote in there, much more succinct, that was, teachers learn the most.

Where, you know, if you do have that capacity to teach others about something, chances are you've already learned it backwards and front. So being able to get yourself to a point where you feel comfortable teaching somebody else means you've probably done your due diligence. At least you should have.

Right. Yeah, definitely. That's something that I found through my, I don't know, 15 years of blogging that I often find that, you know, when I'm able to write about something, I've learned a lot better than most other people because, you know, I'm writing things, I'm figuring out the gaps in my own knowledge, and then I go away and read some more and learn some more and try a few more things. And then only at the end of that, you know, you can write something that's useful.

that makes sense and that answers the questions that most people would likely to ask. And that's something that I do a lot as well in terms of just looking at the kind of question people ask from students, from clients, from people that are asking questions on the, say, Believe in Server. Those things give me a lot of inspiration in terms of what are the things that people are struggling with and so what kind of content I should create and also helps me create...

I guess, mental models of what things work, what things don't, under what kind of circumstances. And one of the things I think a lot of the new writers struggle with is that they're really eager to just start writing about some ideas or solutions they've got, but don't spend enough time to explain what the problem is,

And so they're not getting the readers invested into the problem before they try to feed them the solution. And that's one of the things that often work with new people who are trying to get into writing themselves and try to get them to think about writing almost like a selling or market marketing. You have to first create a problem before you can provide a solution and for people to care about your solution.

Absolutely. And that's fantastic advice. Just hearing that out loud, sell the problem before you sell the solution. I read a lot of content with that newsletter that I send out that caters subjectively what the best content is every week. I read a ton because I'm always out there trying to figure out what's the best. And that's something that you see a lot from first-time authors is,

Here's what I built. And that's about it. I was actually having a conversation with somebody just yesterday.

that was talking about a project that they were working on that was serving ML models for a multi-cloud platform. And the very first question that I asked was, what problem are you trying to solve? What exists today that isn't good enough, that you have to build this? And that kind of stopped him dead in his tracks. And it's like, let's answer that one. Let's answer that one before we go any further, because if you don't have a reason why,

then why so you know that can absolutely be be applied to all different types of content creation is what's the problem why is it a problem here is the solution to said problem yeah otherwise so we end up with a lot more things like nfts so the technology what solutions are looking for a problem i suppose the other the other way around absolutely that's funny

And going back to, I guess, the building communities and this believing service community, one of the things that Farah talked about on our show last, the last time I did a show with her was that you want to build a community where people want to be there. And just looking at how engaged many of the people are on the believing serverless discourse server, people like Tyco, people like Omid, and people like Sam, whom I've also spoken with previously on LinkedIn, various, you know,

quite often. They're all very engaged, very active on the community. And I can see that clearly people do want to be there. And that's where people want to hang out and, you know, chat with each other. Yeah.

What were some of the things that you guys have done besides making it easy for new people to speak and to join the server? Are there any other tips that you may give to say someone else who's trying to start their own communities and things that they should be thinking about? Yes, yes. This is actually a really good question. And it's some of the things that we struggled with, I think a lot. I almost had like an existential crisis at the beginning of this year.

trying to figure out how to grow this community. A community is not going to grow by itself. You can't just put a platform out there and expect everybody to show up. That baseball idiom, if you build it, they will come, is not necessarily true with communities. You have to be actively engaged and actively involved and not just provide a platform. You have to ask questions, even if you know the answers to them.

ask questions and build diversity of thought. That was one of the things that once I started engaging with the community early on in my career, when I was at Tyler Technologies, I started building a diversity of thought. You know, I built a great team of engineers that I ran for to build all the cloud stuff. And it was a fantastic team because nobody ever agreed on anything. And, you know, we would always have a discussion. We'd have a 30 minute meeting and say, let's talk about tenancy.

And everybody would come armed with their arguments for tenancy and none of us would agree. And we'd come out on the other end of it with compromises because now we've talked about maybe eight different things that could possibly go wrong or eight different implementations of tenancy. And we pick and choose what we like and go with that. And that's one of the things that you really need to provide in a community is diversity of thought, especially when it's in that growth phase. Now,

A community is absolutely going to go through a bell curve when it comes to growth and maturity as well, where it will...

at least as far as engagement goes, growth and engagement is a bell curve where it's slow at the beginning, it skyrockets, it kind of tapers off really hot with high velocity at the top, then it starts dropping a little bit and you have to watch it. You have to have people that are in there that are actively engaging, actively providing opportunities to talk and provide opinions all the time and go. So what we did with Believe in Serverless is, you know, we started with a niche, started with serverless

and started with serverless in the US where all of our sessions were targeted at the US. And we grew.

And then we started inviting people from Europe and we started getting people from Europe involved. But we were still focused on U.S. time zones and everything was optimized for Americans. And so we grew to a point where we're like, you know what? We should probably get the Europeans involved when the Europeans want to get involved. So we brought on James Easton, who worked at AWS for a long time, just moved over to Datadog. He lives in the U.K. And so we said, James,

Help us out with Europe, man. Be online, be available for people that are in Europe, Europe and, you know, Western side of Asia at times that they want to be online. Run talks, do things here, engage, just throw out questions that you may or may not already know the answer to and get them involved and get them going. So when the Americans wake up, they can see this conversation that was had and throw in their hats.

So that was a really long-winded answer, but let me summarize that into stay involved, ask questions, get a wide range of thoughts, and don't let things sit. One of the things that...

that we did very early on was we would huddle and we would say, what can we ask people today? We have all these different channels and Discord, CICD, Event Driven, API, security. What are questions we can ask in there to drive conversations? Because if your community is not mature yet where it's going to do that on its own, you need to do it. A kid's not going to walk without help from their parents.

So that was the stance that we took in growing the community was let's let's be the questions. Let's just ask. We don't even have to contribute. This being the champions of the community or the community managers. That's me, Andres, Ben Pyle.

Danielle Heberling, Quata Shams, we would all just figure out like what can we ask today and get things in there. So just like a constant flow of questions of engagement. And from there, things will start to grow legs and walk on their own.

You know, every now and then when I wake up in the morning and I go and I see Jan, you're in there and you're talking with people and engaging with people on questions. It's like, yeah, I didn't ask Jan to do that, but he's in there and he's engaging with people. And it's a fantastic conversation between people who are doing things in real life.

So, you know, it's been fun, but it's also, this is my first time building a community. Really all of us, me, Ben, Andres, Kwaja, Danielle, we've never built a community before. We had a ton of missteps at the beginning. Trying to figure out how to host all these talks was, honestly, it was a nightmare. We went through a lot of different types of streaming and video hosting. We did Zoom for a long time. I tried to run OBS.

on my machine and had some catastrophic failures on there where my machine overheated in the first five minutes. It completely shut down. We know we've tried, failed, learned, adapted. And, you know, just...

being willing to admit that something's not working and letting it go and continuing to have that engagement, it means a lot because people are seeing that you're being honest with them and they feel comfortable in that environment. They feel like they can trust you. They can trust the people that are around them. And if people have a sense of trust in the community, they're significantly more willing to engage.

Yeah, I think Farah also talked about that. I was at one of her talks at the 80% Community Day in Turkey, where she talked about the building community. And one of the things, the top things she talked about was being authentic and just being yourself and building trust. And I think that's so important when it comes to things like communities, online communities, where

Everyone's coming from different backgrounds, coming from different places, they don't really know each other in real life. And so a lot of that is about, oftentimes, just about how you come across in those conversations. And it's easy for us to make assumptions and just be very judgy. And I think oftentimes, maybe social media is just full of that, you know, you say one thing, and then people just take it all kind of different wrong ways.

uh just be very judgmental and that's the opposite of what you want in a community you want people to be open-minded um and oftentimes the people not maybe not always the best when it comes to asking questions and for framing their questions so they just don't come across as uh okay uh sometimes i see a question from a student i think okay that feels like an obvious thing why is he asking me this and then that's where you know you kind of once when one side of my brain i'm thinking

that's silly. Why is he asking this? On the side of my brain, I have to kind of check myself and just think, okay, there must be something else that he doesn't realize that I don't know. There's some context that he's not sharing yet that I have to use my job to then figure it out. Okay,

Ask the right questions to find out what is the context, why are you asking about this, and maybe at that point you find out, okay, the real reason why he's asking about this is something other, some specific thing that you haven't thought about. It don't come up all the time. So, you know, don't be so judgmental right away. People are not idiots. They may not always ask the right questions or frame it the right way, but...

But oftentimes, that's just a thing that you have to figure out. You have to find out from whatever asking questions. But yeah, I totally get it. You always have to be just be open-minded and mindful and trying to figure out, okay, what is it that you actually need help with? Sometimes they ask for a solution, whereas, like you said, you should be asking, what is the problem you're trying to solve in the first place, rather than just providing a solution?

Yeah, I used to work with customers a lot at Tyler Technologies and they would say, can you put a button here?

And my answer every time was no. What are you trying to do? What's the problem that you have? And I will tell you how we're going to solve that problem because you're not the only people that use this software. I wouldn't say that, but in the back of my head, you're not the only people that use the software, but also you're not a designer. You know the business problem really, really well. I am. I am a designer. I know how to do these things and I know how to scale features. But kind of like what you said, yeah,

you know asking why and getting to that problem is really important but as somebody who's asking why you need to be really conscious of how you ask you can't just say why

developers are really good at asking why, but they're also really good at being abrasive. And if you're being abrasive to somebody that you're trying to figure out kind of the root of a question, they're going to shut down the people that you're talking to, depending on their confidence level. If it's somebody new, they don't have a whole lot of confidence in the area. They're just going to shut down. They might just say, I don't know, nevermind. And then that is left and you've missed an opportunity to educate somebody. So,

Don't just ask why, but frame it in a different way. Even just saying semantically, saying why and what are you trying to solve mean the same thing. But one is much more abrasive than the other one, and you're going to get significantly better answers, and you're going to get to the actual root of the problem by being nice and building that trust with somebody and that rapport. So making sure that you're conscious of that is super important.

Yeah, that's one of the things I had to learn as a consultant as well, that dealing with clients, dealing with people who maybe have some preconceptions about what it is that they're trying to do, but maybe they don't understand the whole picture of all the different possible solutions and they're trying to figure out what it is that they're actually trying to achieve and maybe helping them find a more efficient solution as opposed to just giving them what they ask for literally. It's probably the number one thing you learn as a consultant. Yeah.

And I guess another thing that I wanted to also mention as well is the thing you mentioned earlier in terms of lots of people coming to a meeting and all come away with different arguments. And one of the things that I also find quite useful, at least for my previous employments, is that when you've got situations like this, I always like to also just start with why. But in terms of, OK, can we all agree on not a solution, but all agree on what are the criteria that

we should be looking for in a solution and how much do we care about each one of them. Obviously, you've got to think about scalability, cost efficiency, performance and whatnot, but can we all at least agree on what are the priorities? So that way, when there's two solutions that are all kind of ticking all the different boxes, but it may be different, maybe it's a three for cost efficiency, but five for scalability and for us,

cost is more important than scale, then maybe we go for the other solution. I find that to be quite a nice, quite useful technique to get to ward off, to mitigate some of the confirmation bias you often get with these kind of conversations. Everyone's got different arguments and they're all valid, but how do we then, from those arguments, find a solution, a common ground that everyone can agree to?

Absolutely. And hopefully these conversations are being had with non-technical people who know business really well, because that's where a lot of, that's where all the business requirements really should come from. So not only do you need to get on that level playing field with the priorities and the outcomes, but establishing that ubiquitous language where nobody's using words that

Nobody knows like acronyms, you know, making sure that everybody understands what all the acronyms mean. Everybody understands all the business terms mean from the very beginning is going to help build that level playing field. So you can come up with an answer that is the most meaningful.

I'm so glad that you mentioned the ubiquitous language. It's one of those DDD things that I guess everyone read the DDD book, at least maybe the first half of it, and only got to the things like the repository patterns, the value objects, but never got to the really good part, which is the ubiquitous language and how that translates to working within the organization. And also really enjoy some of the archetypes that you've within the paths around the event-driven design architectures as well.

I really enjoy those. So yeah, thanks. Thank you for those. What's been like for you working with the Carragher and Memento team? How have you found working with them the last, I guess, 18 months? Yeah, it's been great. I really like... So I went from large enterprise, 10,000 people company to startup. When I was hired, I think I was employee number 22.

And it took me a long time to adjust to the speed. At a 10,000 person enterprise, you have pre-planning meetings before your planning meetings. Then you have your planning meetings and then you have one person that has an action item. And then six weeks later, you have an action meeting to actually do something about the plan and the pre-plan that happened before. And then six months later, you actually do the thing and then everybody's forgotten what it is that you're doing in the first place. And then it's just a whole thing.

At Momento, when I started, somebody would have an idea on Monday and it would be in production on Thursday. And it's so crazy to see how fast everything moves and not being reckless, but

You know, as far as like the AWS leadership principles go, there's a very clear bias for action at Momento, which I love. I had to get used to it. You know, I am always biased for action, but I wasn't actually used to moving that fast. And I loved it. And one of the things that Quadra would always say at the beginning is if we release it and it doesn't have a typo in it, we spent too long on it.

you know, just as a joyful kind of air to let's not overthink.

So it's been so cool because I classify developers more or less in two groups, service developers, so the people that actually build services. So that could be just I know the audience here is AWS centric. So people that build things like DynamoDB or Lambda, those are service engineers. And then there's app builders like me.

who consumes said services to solve various business problems. Not to say that service teams don't have business problems they're trying to solve, but it's very different than app builders. And I've only ever worked with app builders in my career.

So going and working with service builders was amazing for me. I was hired as an app builder on a service team as a developer advocate. So I build with our services to say, here's how you would do the things that you're trying to do. And talking with the engineers at Memento every single time for like the first six months, I was like, you guys are the smartest people I've ever met in my entire life.

Just thinking, like listening to how they think about problems is so different than what I think about. And, you know, cause they're, they're focused on, well, maybe we should use a networking load balancer versus an application load balancer because the network, the NLB doesn't have the delay for a handshake that an NLB does. And we're trying to get, you know, the,

microseconds of latency milked out of this thing. And I'm like, I had, I didn't even know that was thing. Honestly, you know, I, I can use your stuff. I can use what you're building to make other things, you know, and I'm pretty sure they have similar opinions, not quite the same, not quite the wonder that I have when I look at them, but you know, they look at me and see what I can, you know, mold out of the services that they're building. They're like, Oh wow. I didn't know that things could do something like that.

So it was a really cool experience. So not only moving fast, but also looking at what service teams focus on as far as scale, as far as performance, you know, being Memento started as a as a caching service. And if you're your cash and lightning fast, what's the point?

And, you know, that latency, that focus on latency and getting things as fast as possible has been a driving force with everything that we work on. So the topic service that we have, the real time messaging, has the same latency requirements as cache or pretty close to it. And because of that, we've built an amazing product that does real time communications in what feels like actual real time. So that's

Seeing how fast things move, seeing how service teams work, looking at how much the product team, I'm on the product team at Memento, looking at how much we care about building experiences that developers want to use and care about and find easy has been really, really enriching. And this makes me feel good as an educator and a content creator that we're doing things that make

people's lives easier. As a quick anecdote, I was building an app at my last job that used DynamoDB as the backing store. And I had a sprint, a research sprint for adding a cache into there to make things a little bit faster. And we were looking at ElastiCache. This was in probably 2019. And

We were still focused on let's make it 100% serverless. So we were looking at ElastiCache, saw that it had VPCs. We spent a full two weeks on it, building up a proof of concept for an actual ElastiCache instance. We did cost modeling on it. We did disaster recovery and everything that you would do in an enterprise when it comes to adding a piece of infrastructure into your application. And the end of it,

really was this is too much for the benefit that we get on top of DynamoDB. We have to learn how VPCs work. We have to figure out how we need to adequately scale this. This has a non-insignificant pricing cost, a provision cost every month.

And so what we did, and I think what it still does, I don't know, I haven't been there in a while, is just use DynamoDB. We just opted to ditch the cache. Now, if Memento had been around at that time, that would have been a super easy sprint. And I probably would have been done with it in like two days where I could say, yeah, we have an auto-scaling lightning fast cache that you implement with one API call, get or set Memento.

And that's it. It scales up, it scales down, it's pay for what you use. And it is in many instances faster than DynamoDB. So it is actually a good cost saving and performance saving on top of that. So it's been fun. It's really cool. It's also opened my eyes since I get to work with the community all the time. It's really opened my eyes to taking a look at

other third-party serverless vendors more meaningfully. Like right now, before you and I were on this call, I was messing around with Neon, a serverless Postgres service, trying to get back into the relational game and making sure that I remember how to do it. But they build on top of AWS. There's a whole bunch of different providers that are using AWS as infra that are building these meaningful abstractions to make

building an application easier. So I am a lot more willing. It feels like people these days are a lot more willing to use third-party vendors as well. And it's just a really cool, it's been a really cool experience to get a lot more well-rounded as an application developer and also get all that education from a service engineering standpoint.

Yeah, Kamal Jainan, his team is really amazing. I had a really good time speaking with him quite a while back. And obviously, you know, his experience working on the DynamoDB has come in really handy when it comes to building something like a mentor.

But you're absolutely right there in terms of the skill sets for building an application, gluing together multiple services to building a service where there's much more focus around the optimization, around the scalability, thinking about the minute details in terms of every single step and trying to make performance as good as possible while keeping costs in check. It's a very different kind of skill set, a very different mindset. And

I've been quite lucky to work with, I guess, on both ends of that spectrum and have to work up and down the stack. And it requires a very different mindset and a very different perspective. And the same as working for a big enterprise versus a startup. Again, very different mindset, very different approach. You have to think about...

even in terms of architecture decisions or how you organize your solutions, things like event-driven architecture and DDD, a lot of that makes absolute sense when you're at enterprise level. 10,000 people, how do you make those systems with...

At Conway's Law, we know that the organization is going to build systems that reflect its communication model. So a 10,000 people company is going to create much more complicated applications just by default. So how do we enable everyone to talk safely and have a built system that is robust and resilient?

Whereas for a small company, like a few people, you can probably do away with a lot of the things that comes with DDD. You may still borrow some elements of it in terms of how you design those things.

the service boundaries, how to find the right places where, you know, okay, this is one service versus another. But some of the things like, okay, having distinction between domain versus integration events, and some of the minute details around the language, where do you draw the boundary of the boundary context, those things are probably less important. They're still useful, but you know, getting it wrong is not as costly as it is in a large enterprise.

So yeah, definitely a very different mindset. And whenever I'm talking to someone about anything technical discussions, you always have to keep in mind that, okay, whether or not they're working for enterprise or working for a startup, the answer is probably going to be very different. What works for one probably not going to work for the other. Absolutely. And I forgot,

But probably the most important thing, in answer to your original question, what's it like working with Quaja and Memento? So all the things that I already said, everything that you just said. But from a personal standpoint, Quaja, the CEO, is about the nicest person I feel like I've ever met in my entire life. He just has an air about him where he cares about people.

And to bring the mood down just a little bit, just for a minute, in May, my daughter was diagnosed with leukemia. My three-year-old was diagnosed with leukemia, which for people that don't know, that's cancer of the blood. And she was set up immediately with a months-long treatment plan. And I called Kwaja. We were diagnosed on a Wednesday, and I called him Wednesday afternoon. And I was like, hey,

I can't come into work this week. Can you just work with me on a few days off while I figure out what's going on? I told him the diagnosis and told him everything. And his immediate response was, don't come into work. Take leave. We have medical leave for a reason. And this is one of those reasons. I don't want to see you at work. I want you to focus on your family and focus on getting your daughter better.

And that was really the end of that discussion. It was, I don't have to go in. I am focusing on her and the treatment and everything there. And that's something that I just don't think I would get anywhere else. I definitely wouldn't have gotten it at my last job. There's very few places that would immediately, without any hesitation, say, take it. Take it, focus, you can come back when you're ready.

And I'm super grateful. Quadra, hopefully you're listening. Thank you again. I've told you so many times. And he messages me a few times a week. He doesn't want to inundate me with messages, but just asks, how's she doing? And I'll tell her he just cares. So super grateful for that opportunity.

Yeah, I saw your personal update and wish you best of luck with your daughter's treatment and I'm sure everyone who's listening, most of them probably have seen your personal update as well in your newsletter. And I'll put a link to the GoFundMe page as well for Olivia and hopefully everyone would help you guys out as well. But yeah, Alan, thank you so much for your time today and I'm

And I'm really grateful that you take your time out from working, from being with your family to come and share with us some of your experience of building communities and working with Memento. Yeah, no, thank you for having me. I appreciate it. You know, you and I were supposed to record this episode the day before I got the diagnosis. I had to cancel it because we were in the hospital. We didn't have a diagnosis yet, but it was still scary. So thanks for working with me on finding time to get this in.

No worries. I hope to catch you sometime in person. Hopefully, maybe I'll reinvent. Yeah. As of right now, I am planning on going to re-invent this year. You know, pending everything goes well. So I am day by day at the moment. So you ask me on a Tuesday, I might give you a different answer than Wednesday. But right now I am planning on going. So I hope to see a lot of the community there. Great. Yeah. Hope to see you there and hope everything works out well for Olivia. Thank you. I appreciate that very much. Take it easy, guys. Okay. See you guys next time.

Thank you to HookDeck for supporting this episode. You can find out more about how HookDeck improves developer experience for building event-driven architectures. Go to hookdeck.com slash the burning monk.

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.