Serverless Chats

About Anahit PogosovaAnahit is an AWS Community Builder and a Lead Cloud Software Engineer at Solita, one of Finland’s largest digital transformation services companies. She has been working on full-stack and data solutions for more than a decade. Since getting into the world of serverless she has been generously sharing her expertise with the community through public speaking and blogging.Twitter: @anahit_fiLinkedIn: https://www.linkedin.com/in/anahit-pogosova/Solita: https://www.solita.fi/en/"Mastering AWS Kinesis Data Streams, part 1”: https://dev.solita.fi/2020/05/28/kinesis-streams-part-1.html"Mastering AWS Kinesis Data Streams, part 2”: https://dev.solita.fi/2020/12/21/kinesis-streams-part-2.htmlAWS Community Day Nordics 2020: https://youtu.be/gtE2o8qsq-4Watch this episode on YouTube: https://youtu.be/7pmJJcm0sAU This episode sponsored by New Relic and Stackery. TranscriptJeremy: So you mentioned poll-based versus stream and things like that. So when you connect Kinesis to Lambda, this is the other thing too, I think that confuses people sometimes. You're not actually connecting it to Lambda directly for pretty much all of these triggers in these integrations. There's another service that is in between there. So what's the difference between the Lambda service and the Lambda function itself?Anahit: That's a great one because I think it's, again, one of those very confusing topics, which are not explained too well in the documentation. And the thing is that when you're just starting dipping your toes in the Lambda world, you just think that, "Okay, I write my code, and I upload it and deploy it, and everything just works. And this is my Lambda," right? But you don't really know how much of the extra magic is happening behind the scenes, and how many components are actually involved into making it a seamless service. And there is a lot of components that come into ... so you can think of a Lambda function as the function that we actually write and deploy and invoke. But then the Lambda service is what does all the triggering, invoking and batching and error handling.And it really depends on the way the Lambda works, or the way long the service works. It really depends on the invocation model, is you prefer to the poll based, not poll based. So again, one thing that is not too clearly explained, in my opinion, is that there is actually three different ways you can work with Lambda or communicate with Lambda. So you can invoke a Lambda synchronously. So request response traditional way, and the best example, I think, is API gateway, which does that so it requests something from Lambda, it waits for the response. Then there is the async way, which is one of the most common. So you just send something to Lambda and you don't care about what happens next.Jeremy: Which uses an SQSQ behind the scenes to queue ...Anahit: Exactly. Yes. That's also like fun facts that you learn along the way. But the point is that like services like SNS, for example, or S3 notifications, they all use the async model, because they don't care about what happens with the identification. They just invoke Lambda and that's it. But then there is this third, gray area or a third totally different way of invoking the Lambda function, and it's called poll-based. And that's exactly how Kinesis operates with Lambda. And it's meant for streaming event sources, so it's both Kinesis data, DynamoDB streams. Also, Kafka currently uses poll-based model. And it also works with the queue of event sources like SQS.Jeremy: Right. SQS, yeah.Anahit: And Amazon MQ, I think they also use them, the poll-based method. And what poll-based invocation or the component that is most essential in the poll-based model, it's called the event source mapping. One of the misunderstood components or one of the hidden heroes, I would say, we find in Lambda, because it's an essential service or essential part of the Lambda service. And event source mapping actually takes care of all that extra things that Kinesis plus Lambda combination is capable of. So it's responsible for batching, it's responsible for keeping track of this point in the stream and where a shard, where it's ...Jeremy: A shard iterator, because anybody wants to know the ...Anahit: Yes, exactly, shard iterator.Jeremy: ... technical term for it.Anahit: Yes, thank you. And, yeah, the most important for me, it handles the errors and retries behind the scenes.Jeremy: Right.Anahit: And basically, if you don't have event source mapping, you can't have batching. So it takes care of accumulating, or in case of standard, consistent consumer, it pulls your Kinesis stream, on your behalf, it accumulates batches of records, and then it invokes your Lambda function with that batches of records that it accumulated. Again, in case of enhanced fan-out, of course, it doesn't poll, it gets the records from the Kinesis stream directly. But then from the perspective of your Lambda function doesn't matter, it just gets trig

About Anahit PogosovaAnahit is an AWS Community Builder and a Lead Cloud Software Engineer at Solita, one of Finland’s largest digital transformation services companies. She has been working on full-stack and data solutions for more than a decade. Since getting into the world of serverless she has been generously sharing her expertise with the community through public speaking and blogging.Twitter: @anahit_fiLinkedIn: https://www.linkedin.com/in/anahit-pogosova/Solita: https://www.solita.fi/en/"Mastering AWS Kinesis Data Streams, part 1”: https://dev.solita.fi/2020/05/28/kinesis-streams-part-1.html"Mastering AWS Kinesis Data Streams, part 2”: https://dev.solita.fi/2020/12/21/kinesis-streams-part-2.htmlAWS Community Day Nordics 2020: https://youtu.be/gtE2o8qsq-4Watch this episode on YouTube: https://youtu.be/U4snzWHMrtUThanks to our episode sponsor, Epsagon.TranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Anahit Pogosova. Hi, Anahit, thanks for joining me.Anahit: Hi, Jeremy. Thanks so much for having me.Jeremy: So you are an AWS community builder and also a lead cloud software engineer at Solita. So I would love it if you could tell the listeners a little bit about your background, and what it is you do at Solita.Anahit: Right. So yes, so I have been working at Solita for pretty long time. So it's a digital transformation company. It was originated in Finland over 25, 26 years ago, and out of those years, I have been on-board for 11 years. Which sounds extraordinary nowadays, I suppose, because everybody gets surprised. But during those years, I've had several roles as a backend and full stack developer. And then I moved to the cloud, to AWS and started doing all the cool stuff with serverless. And I have been also working as a data engineer for several years with one of our customers, so a lot of different stuff.And we actually have offices in six countries in Europe, of course, they are empty at the moment. And I'm based here in Finland. And yeah, we focus on software development and cloud integration services, analytic services, some consultancy, and service design. So if you're interested, we are hiring. And yeah, that's about Solita and me.Jeremy: Well, any company that can retain someone for 11 years, sounds like a good place to work at.Anahit: Right? I think so too. No, apparently, it sounds suspicious to many people. Why exactly?Jeremy: I don't know. That's a conversation for another podcast, I think, about the job-hopping thing. But anyways, well, I'm glad that you're here. And thank you very much for taking the time to talk to me. I'm super, super excited about this topic, actually, because I came across this blog post that you wrote. Now, this was actually the first version of this that you wrote was, or the first part of this, I think was maybe almost a year ago now or something like that.Anahit: Yeah, something like that.Jeremy: But then you had a second part of it that came out in maybe November. And this was two posts, they were called "Mastering AWS Kinesis Data Streams." And now the cool thing about Kinesis is, it's a super powerful service. I think we learned from a recent outage at AWS that Kinesis, pretty much powers everything, every backend service at AWS is powered by Kinesis, which is pretty cool, but also scary at the same time. But, but it's a fascinating service. And I want to warn the listeners, because I want to get super technical with you. I want to get into some of these different details about how this service works, some of the limitations, some of the use cases for it and things like that.And I would absolutely suggest that people read the two posts that you wrote, now they are very, very long, it took me a long time to get through them. But they are excellent, they're really well written. And it reads a lot easier than the documentation, and you give some good examples in there and some good reasoning behind it, which the documentation doesn't always do. So first of all, I want to start with why you wrote this post in the first place because there is a lot of documentation out there. But why did you write these two posts?Anahit: Yeah, these two very long posts, as you said. So maybe to give some background, I've been working with Kinesis a bit over three years now with one of my customers, who is at the Finnish National Broadcasting Company called YLE. I always bring this example, you can think of it as BBC in Finland, highly respected accompanied with a lot of content and a lot of viewers as well. So our team is responsible for streaming the user interaction data to the cloud. And at the moment, we have something over 0.6 terabytes of data per day. In the moment of writing the first blog, it was half a terabyte, so it's growing constantly.And yeah, so we did with Kinesis. And when I started like three-plus years ago, I basically had no production experience with it, just like the "Hello, World!" kind of a thing. And mos

About Buddy BrewerBuddy Brewer is the Field CTO for New Relic in the Americas. In this role, he helps customers get long-term value out of New Relic. Buddy has over 20 years of experience leading engineering and product management teams building tools to help developers and operations professionals deliver better digital experiences. A former entrepreneur in the observability space, Buddy has helped companies across every geography and industry in the world improve their software’s speed, quality, and user experience.LinkedIn: https://www.linkedin.com/in/bbrewer/ Twitter: @bbrewerPersonal Website: BuddyBrewer.com New Relic Free Tier: https://newrelic.com/signupNew Relic Explorer: https://newrelic.com/platform/full-stack-observability Watch this video on YouTube: https://youtu.be/Y4n3fE8g9Ec This episode is sponsored by New Relic.TranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Buddy Brewer. Hey Buddy, thanks for joining me.Buddy: Hey Jeremy. Thanks for having me.Jeremy: You are a Field CTO at New Relic so I'd love it if you could tell the listeners a little bit about yourself and what's new with New Relic.Buddy: Yeah. Been with New Relic for a couple years now and in this Field CTO role I get to spend lots of time with our customers to help them get long-term value out of our observability platform. I'm an engineer by trade. Started my career as a software developer like many of our customers in New Relic. Spent substantially all of my career in product development in various capacities. Engineering, leading engineering teams, product management. And like I said, now I spend most of my time with customers helping them tackle their own observability challenges in their businesses. We're doing a lot right now with New Relic to help people make sense out of the volume of data and to help people pull all of the different types of metrics, events, logs, and traces that go into all this observability into views that they can actually use to help their customers get better experiences in a world where software architectures are just ... They're just becoming more complex by the month.Jeremy: Right. Well, awesome. First of all, I want to thank New Relic for sponsoring this episode and for the amazing amount of support that they give to us here at Serverless Chats and what we do. So thank you very much for that. Now, you mentioned these tools that you're working on to be able to observe modern applications. And the new tool that was recently launched is the New Relic Explorer. I've looked at this thing. This is absolutely fascinating. It does all kinds of really great things. But I'd love it if you could tell the listeners a little bit more about that product.Buddy: Yeah. It's part of our full stack observability product in the New Relic One platform. So it's an in-place upgrade that everyone who uses full stack observability today gets. And what it does is it takes all of the information across all of the different dimensions that people are used to seeing in New Relic One, it pulls them together into new views that help people make sense at a macro level of what's going on in the health of their software across all of the dimensions that matter today. So infrastructure, front end, the application logic. All of that stuff in single views. And there's another part of New Relic Explorer that helps people understand in realtime what the key changes are that are happening in a way that requires zero configuration, which is really important to our customers today because the software architectures and the underlying containers and everything that serve those are changing so fast that people just don't have time to manually configure things today like they used to be able to.Jeremy: Yeah, right. And one of the things too with cloud infrastructures, you've got all this telemetry data coming in from all these different places and most of the time ... I mean, I know at least what I had been doing is using a bunch of different dashboards and basically jumping between different things trying to figure out what's healthy, what's not healthy. And I love these new views that are in the New Relic Explorer because it actually shows you the changing ... If a problem is getting worse and worse and worse, it gives you this growing bubble. So these visualizations are really, really helpful. So I think that's Lookout right? That does that?Buddy: That's right. Yeah, that's Lookout. The way that I think of Lookout is imagine if you could take something like the Unix diff command and apply it to all of your telemetry data comparing now versus any point in the past. Whereas the Unix diff command is a text console rendering, what Lookout does is it renders all of this in a visual display in a web browser so that you can see ... Like you said, you had these bubbles that really display two dimensions at the same time. The volume of data, whatever it is that you're looking at for a piece of d

About Sarjeel YusufEngineer turned product manager, Sarjeel Yusuf is greatly interested in how the move to cloud computing and the rise of DevOps is revolutionizing the way we manage and release our software systems. Ex Thundra, and currently at Atlassian, Sarjeel is focused on bringing DevOps enabling solutions from the perspective of incident investigation and resolution in Opsgenie. By leveraging his past experience in Serverless monitoring and debugging at Thundra, he believes that there is a great opportunity in how serverless can unlock the potential of DevOps teams. In his free time, Sarjeel loves to write about new advancements in the fields of serverless, DevOps, and more recently, product management strategies. His writings can be found on his personal medium account as well as other publications. He would love to get in touch with anyone who would love to brainstorm ideas in pushing existing technologies to build amazing products. Twitter: @SarjeelYLinkedin: https://www.linkedin.com/in/syedsarj/Website: sarjeelyusuf.meOpsgenie: https://www.atlassian.com/software/opsgenieWatch this video on YouTube: https://youtu.be/T7eUUUBRZQQThis episode is sponsored by Epsagon.TranscriptJeremy: Hi, everyone. I'm Jeremy Daly, and this is Serverless Chats. Today, I'm joined by Sarjeel Yusuf. Hey, Sarjeel, thanks for joining me.Sarjeel: Hey, Jeremy, thank you so much for having me. I just want to say it's pretty exciting to be here. I've been watching the show for quite a while now, and it's just exciting to be here with you and talk about everything serverless, I guess.Jeremy: I'm excited to have you here. So, just to introduce yourself. So, you are a product manager at Atlassian. So, I'd love it if you could tell the listeners a little bit about your background and what you do at Atlassian.Sarjeel: Sure. So, yeah, as you've mentioned, I'm a product manager at Atlassian. Actually, a very new product manager. Just a year ago, I was a software developer within Atlassian, within Opsgenie, and now I'm a product manager at Opsgenie. So, I made the switch to product management very recently, actually.And so, for those who don't know what Opsgenie is, Opsgenie is basically an on-call incident management tool. It allows you to route your alerts to the right person, make sure that everybody is aware of incidents that may occur. And it helps you all the way from incident awareness to incident investigation and retribution. And my specific role at Opsgenie is basically helping DevOps practicing teams to better their entire DevOps flow, especially considering incident management in the DevOps pipeline.Jeremy: Right. So, that's actually what I want to talk to you about today, is just about DevOps. It's such an interesting discipline. And as teams sort of evolve and start using the cloud, it's almost like it's sort of necessary, I think, in order for you to adopt some sort of a DevOps culture.And working at Atlassian, obviously, Atlassian has Jira, and Opsgenie, and all these other services that help with software development, and the software development lifecycle and things like that. But I think there's a major confusion out there about what exactly we mean by DevOps. And especially when you see companies labeling tools as like, "Hey, here's a DevOps tool." Or you've got DevOps engineers and things like that, that just seems really weird to me, because I don't think of DevOps that way. And maybe we could start there and sort of just set a baseline for the listeners here, and have you explain what exactly is DevOps, and what do we sort of mean by as a practice or as a culture as opposed to a set of tools or engineers?Sarjeel: Yes. Yeah, that's it, right? DevOps right now, the reality that DevOps has ... The word DevOps has become a buzzword. Actually, quite interestingly, I think it was yesterday or a few days ago, I saw a tweet by Patrick Debois who was saying that just because ... It goes along the line of something like this. Just because an idea has become a buzzword doesn't mean that you should shy away from it. You should still go into it and explore what it is, and you learn from it.That's the problem right now. The industry has been capitalizing on DevOps. Especially a lot of new startups are capitalizing on DevOps, marketing themselves as DevOps tool. So much so that the promise of DevOps is kind of lost or not fulfilled when you have all of these DevOps tools or DevOps engineers or DevOps certifications coming up in the industry.Let's try to understand what exactly DevOps is. I think the best person who explains this or who captured this is Jez Humble. He basically describes DevOps as a set of practices, a cultural mindset, not exactly a set of tools. Yes, you can have tools to help with your DevOps practices. I'm not saying that, "Oh, any tool that says is associated with DevOps, that's definitely a lie." No, it's not like that.So, you can have tools to help with your DevOps practices, your DevOps culture. Harbori

About Jeff HollanJeff Hollan is the Principal PM Manager for Serverless Azure Functions. He started his career at Microsoft in IT and spent a few years managing and building enterprise applications. He is always developing and shipping solutions on the latest tech and is an active member of the serverless tech community.Twitter: https://twitter.com/jeffhollan Email: [email protected]: https://hollan.ioAzure Functions: https://azure.microsoft.com/en-us/services/functions/ GitHub Durable Task Framework extension for Azure Functions: https://github.com/Azure/azure-functions-durable-extensionWatch this video on YouTube: https://youtu.be/ZDVB0AsYDcsThis episode is sponsored by New Relic. Sign up for free at newrelic.com.TranscriptJeremy: Hi everyone. I'm Jeremy Daly, and this is Serverless Chats. Today, I'm joined by Jeff Hollan. Hey, Jeff, thanks for joining me.Jeff: I'm thrilled to be here. Thanks for the invite.Jeremy: So you are a Principal Product Manager at Microsoft Azure. And I'd love it if you could tell the listeners a little bit about yourself and what you do as a principal product manager at Azure.Jeff: Sure. So I've been at Microsoft now for a little over seven years. About five years ago, I switched to focusing on serverless. So I was one of the original members when Azure was like, "Hey, we want to try to go bigger in serverless." So spent some time in a different product called Logic Apps, which has serverless workflows. And then for the last three or four years, I've been running the Azure Functions Team. And so my day-to-day entails understanding a little bit about how the products being used, talking to customers, and then helping formulate the backlog with our engineering team and deliver features to hopefully make people's lives easier with serverless.Jeremy: Awesome. Well, so I'm super excited to have you here because I think I talked to you a year ago at ServerlessDays Nashville.Jeff: Yes.Jeremy: I was talking about having you on the show because Azure Functions and what Microsoft is doing with serverless is, is absolutely fascinating. If there was anybody else who's in the space race against AWs when it comes to the advancements in serverless, I would think that would be Microsoft Azure. And it's pretty exciting because I feel like you are doing things differently. And I've had a conversation with people from IBM Cloud and Google, and of course, AWS, and everybody is doing things slightly differently. So I'd love it if you could just maybe give a quick overview of what Azure Functions are and the general serverless offering that Microsoft has right now.Jeff: Sure. Yeah, so I guess the best place to start is Azure Functions. And you can in many ways think of it like AWS Lambda. To your point, there are some differences here and there and I'm sure we might even highlight them as we go.Jeremy: Sure.Jeff: But at its core, hopefully it is the same. I want to write some event-driven compute. Here's my language of choice. Go ahead and publish it and have it, do its serverless scale option. I think some of the things that folks notice from the get-go, there's a few application concepts that are a little bit different. We enable you to develop and write in what's called the Function App. And so you can actually create four or five different functions that are one deployment thing. And then those four or five functions can scale with each other.But the other one that I always tend to talk about a lot is just the other supporting products that are around. So you've likely heard, and people who've listened to this have likely heard by CAF, serverless is more than just FaaS. But when you think about the supporting pieces of technology, whether that's serverless workflows with Logic Apps, whether that's Stateful Functions with Durable Functions, going into, I guess the NoSQL database Cosmos DB has a serverless skew. So that's oftentimes where we end up talking a lot more as saying, "Hey, FaaS and functions are going to play a critical role, but it's all these other supporting pieces too that you'll start to see those differences as well."Jeremy: Right. Yeah, and I think that, again, serverless, at least the evolution of it and what I always think about is it's event-driven, like you said. And so you're getting these events. And in a Microsoft Azure or Azure Functions, they're called Triggers. And again, if people don't ... I'm hoping that people listening to this podcast, they know what serverless is. They know event-driven compute. At least they get the idea of that. But basically it's something gets triggered, a queue is written in it. And that the triggers that Azure Function a or database record is written in it triggers that, or somebody uploads something to Blob Storage. So those are your triggers. But something that's really interesting, and I'd love to know more about is this idea of bindings. So what's the difference, because I understand triggers, but what's the deal with bindings

About Nofar AsselmanNofar Asselman is the Head of Business Development at Epsagon, where she initiated Epsagon’s partnership with Amazon Web Services (AWS) and developed growth opportunities for the company. Nofar leads Epsagon’s business development department strategy, through revenue-generating channels and creating new alliances.Nofar is a key figure at the AWS Partner Community and founded the first-ever AWS Partners Meetup Group. The group is focused on sharing joint AWS go-to-market strategies that successfully affect AWS Partners’ ecosystem and growth.Nofar is passionate about her work with AWS cloud communities, organizes meetups regularly, and participates in conferences, events, and user groups. Nofar is a Founding Member of the Multi-Cloud Leadership Alliance (MCLA) and she loves sharing insights and best practices about her AWS experiences in blog posts on Medium.Twitter: @AsselmanNofar Medium: nofar-asselman.medium.com/LinkedIn: www.linkedin.com/in/nofar-asselman-074b8134/Multi-Cloud Leadership Alliance (MCLA): https://www.linkedin.com/groups/13779838/Epsagon: https://epsagon.com/Watch this episode on YouTube: https://youtu.be/FL9XLtW57Ms This week's episode is sponsored by Off-by-none, the weekly newsletter that focuses on the technical details of building modern applications in the cloud, driven by the serverless community. Visit us to subscribe, provide feedback, submit your articles, and nominate people who are contributing to the serverless community to become a Serverless Star. TranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm speaking with Nofar Asselman. Hey, Nofar, thanks for joining me.Nofar: Hi, Jeremy. Thanks for having me.Jeremy: So you are the VP of Business Development at Epsagon, so I'd love it if you could tell the listeners a little bit about your background, what you do at Epsagon, and what Epsagon is all about?Nofar: Yeah, absolutely. So actually I started in my past life, I was an attorney. I work in a big law firm, and this is where I understood that it's fun to work with startups from the legal side, but I wanted to move to the business side. And this is where I start my startup journey and today I work at Epsagon, where we help microservices customers to adopt microservices in confidence while providing them really seamless experience in monitoring their microservices architectures.Jeremy: Awesome. All right. So one thing that's really interesting about what Epsagon does is Epsagon has built a business around sort of the serverless ecosystem providing a solution for people who use serverless or are trying to build things with serverless. And I think that's really fascinating because serverless has become obviously quite a buzzword over the last few years. And a lot of people will stick the word "serverless" in their product title or in their description somehow. But what I would love to talk to you about is this idea of actually building a business sort of for serverless, right? So building something for the serverless ecosystem, whether that's a tool, whether that's some sort of a thing that makes it easier for you to monitor or build new things or whatever it is. But something that is for the serverless ecosystem. And so you have a ton of experience in this, so I'd love to get your perspective, but maybe we could start just sort of like what is the current state of the serverless market from a business perspective?Nofar: Yeah, so I think that serverless is definitely growing. I'd say that it's not growing as fast as we thought it would grow, but I think we see more and more companies are leveraging serverless technologies to really achieve business agility and go to market faster. But I think if 2020 was a year where we did see an uptick in customers that are leveraging serverless, in 2021, we'll see that in a higher scale, just because I think that last year there were still some challenges around tooling and expertise that was still missing from lots of organizations. And there are so many great tools out there now that helping these customers to leverage their technology using serverless and really meeting market demands and meeting their customer's needs smoothly with serverless. So I think this year will be significant in terms of serverless growth.Jeremy: Right. Yeah. And I think that is something that we've seen a lot of is there's been a lot of complaints that serverless is not easy to adopt as sort of a change in the mindset in terms of how you, again, maybe need new tooling, maybe we need new monitoring tools, maybe we need other solutions that help us do serverless. Certainly need education and training. So do you think, though, that with the growth of the serverless market that there are opportunities for tools and solutions and things like that?Nofar: Yeah, absolutely. Absolutely. I do think that building solutions around serverless is super important and if we're looking long-term, that's definitely the technology th

About Our GuestsGillian ArmstrongGillian Armstrong is a Solutions Engineer at Liberty IT and an AWS Machine Learning Hero.Twitter: @virtualgillLinkedIn: https://www.linkedin.com/in/gillian-armstrong/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/gillian-armstrong/Luca BianchiLuca Bianchi is the CTO of Neosperience, co-founder and co-organizer of many serverless community events in Italy, and an AWS Serverless Hero.Twitter: @bianchilucaLinkedIn: https://www.linkedin.com/in/lucabianchipavia/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/luca-bianchi/Sheen BrisalsSheen Brisals is the Senior Engineering Manager at The LEGO Group, a serverless speaker, and an AWS Serverless Hero.Twitter: @sheenbrisalsLinkedIn: https://www.linkedin.com/in/sheen-brisals/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/sheen-brisals/Farrah CampbellFarrah Campbell is the Alliances & Ecosystem Director at Stackery, a co-organizer of ServerlessDays Virtual as well as several other serverless community events, and an AWS Serverless Hero. Twitter: @FarrahC32LinkedIn: https://www.linkedin.com/in/farrahcampbell/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/farrah-campbell/Serhat CanSerhat Can is the Technical Evangelist at Atlassian and an AWS Community HeroTwitter: @srhtcnLinkedIn: https://www.linkedin.com/in/serhatcan/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/serhat-can/Yan CuiYan Cui is an Independent Consultant, Developer advocate at Lumigo, Host of the Real World Serverless podcast, theburningmonk, and an AWS Serverless Hero.Twitter: @theburningmonkLinkedIn: https://www.linkedin.com/in/theburningmonk/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/yan-cui/Ben EllerbyBen Ellerby is the VP of Engineering at Theodo, Editor of Serverless Transformation, and an AWS Serverless Hero.Twitter: @EllerbyBenLinkedIn: https://www.linkedin.com/in/benjaminellerby/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/ben-ellerby/Ran RibenzaftRan Ribenzaft is the CTO at Epsagon and an AWS Serverless HeroTwitter: @ranribLinkedIn: https://www.linkedin.com/in/ran-ribenzaft/AWS Heroes Page: https://aws.amazon.com/developer/community/heroes/ran-ribenzaft/Watch this episode on YouTube: https://youtu.be/tENIWFp3uj8 This week's episode is sponsored by New Relic and Epsagon.TranscriptJeremy: Hi everyone, I'm Jeremy Daly, and this is Serverless Chats. Today we have an absolutely amazing episode for you. re:Invent 2020 is finally done. We're in February of 2021 and unless they decide to maybe stick another week of videos in, re:Invent 2020 is finally done. So, I figured why not do an episode where we can get the best input and the best insights from some of the most amazing people in serverless.So, today, I have eight AWS heroes with me, and we're going to talk about all the amazing things that happened at re:Invent 2020. So, I'm just going to go quickly around the horn here and introduce everybody. So, first up, is AWS Serverless Hero, Independent Consultant, Developer Advocate at Lumigo, host of the "Real World Serverless Podcast," The Burning Monk himself, Mr. Yan Cui.Yan: Hey guys.Jeremy: All right, next we have an AWS Community Hero, he's a Technical Evangelist at Atlassian, and the guy who once helped me stalk Werner Vogels, just so we could get a photo with him, Mr. Serhat Can.Serhat: Hey folks, happy to be here.Jeremy: And, next, is another AWS Serverless Hero, he's the CTO of Neosperience, co-founder and co-organizer of just about every Serverless community event in Italy, the Italian Stallion of serverless, Mr. Luca Bianchi.Luca: Hello.Jeremy: All right, next, we are joined by yet another AWS Serverless Hero, he's also the CTO at Epsagon, and way too smart for his own good, the man they call Mr. Obervability, Ran Ribenzaft.Ran: Hey, everyone.Jeremy: All right, moving on, we have another AWS Serverless hero, he's the VP of Engineering at Theodo, editor of "Serverless Transformation," and an excellent Nashville, Tennessee, drinking buddy, Ben Ellerby.Ben: Hey Jeremy, thanks for having me.

About Michael Behrendt Michael Behrendt is a Distinguished Engineer in the IBM Cloud development organization. He is responsible for IBM’s technical strategy for offerings around serverless & Function-as-a-Service. Before that, he was the Chief Architect of IBM's core cloud platform and was one of the initial founding members incubating it, led the development of IBM's Cloud Computing Reference Architecture, was a worldwide field-facing cloud architect for many years, and drove key product incubation & development activities for IBM's cloud portfolio Michael has been working on Cloud Computing for more than 15 years and has 37 patents. He is located in the IBM Research & Development Laboratory in Boeblingen, Germany.Twitter: @Micheal_BEHLinkedIn: Michael BehrendtIBM Cloud Code Engine: https://ibm.biz/codeengineCloud Functions: https://cloud.ibm.com/functions/ IBM Cloud Functions Tutorial: https://cloud.ibm.com/functions/IBM Cloud Code Engine Getting Started: https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedIBM Cloud Free Tier: https://www.ibm.com/cloud/freeWatch this episode on YouTube: https://youtu.be/t3KHoCAVazUTranscriptJeremy: Hi everyone. I'm Jeremy Daly, and this is Serverless Chats. Today I'm speaking with Michael Behrendt. Hey Michael. Thanks for joining me.Michael: Hey, Jeremy. Thanks for having me.Jeremy: So you are a distinguished engineer, chief architect, Serverless IBM Cloud at IBM. So why don't you tell the listeners a little bit about your background and what you do at IBM?Michael: Sure. Thank you. So I've been working at IBM in various technical roles over the last 15 to 20 years. I have been in product development, product incubation, I've been working in the field as a workload architect. And for the last 10 years as well I've been working in the Cloud division in itself, working on various topics, incubating it and so on. And since about six years now, I'm really focused on serverless as a topic as a whole. So that's what I'm doing most of my time. Working with customers, working on product development, making architectural decisions, technology decisions, and so on.Jeremy: Awesome. All right. First of all, I want to thank IBM for sponsoring this episode. So that's great continuing to support the community and continuing to invest in serverless. And when it comes to serverless at IBM, you are the guy. You were there right back in the beginning. I had Rodric Rabbah on the show a couple of weeks ago. And we were talking about how it all got started. But I know you have a bunch of stories as well. So what if we go all the way back and start that sort of six years ago and talk about how did it begin? How did serverless at IBM sort of get kicked off?Michael: There is some interesting stories there. So long a while ago now, I've been looking into the serverless market as it was evolving, what was happening in the field, what customers are doing. And I felt like we need to do something in the serverless space as well. And by purpose, I thought we shouldn't be starting this as a right off the bat product development effort, but rather since it was such a new space do some exploratory stuff first and have it really open-ended in terms of what we are going to end up with from a technology perspective.So I was in Beijing for a business trip and I had a call with a VP for research at IBM for Cloud. And I still remember it was 10:00 PM at night. And we talked about we need to do something in that space. So we agreed on that call, let's do something in that space. And he basically then brought in a team from the research side, Rodric was part of the team to kick off that whole effort.Jeremy: Right. So I don't think I've ever heard a story that starts 10:00 PM in Beijing, ever heard a story that didn't end, or it didn't have an exciting ending to it. So all right. So you brought in this team to kind of start working on it. And so what did you do first? What was the initial goal? I mean, you were surveying the market, doing the research, as you said. So sort of, how did you sort of take those first steps?Michael: So we put together this team of really talented people in research, and we basically set up our goal. It's what do we want to accomplish from a workload perspective? Which kind of workloads do we want to support? We want to allow composition of functions, something we are talking about these days as well, but it was like a new concept back then. We wanted to be able to be very flexible in terms of which kinds of workloads people can run. Should it only be functions or should it be more cost in the workloads as well? So we went into different directions.We looked at non-functionals like, how quickly should it be possible to deploy a new function or update a function to have a very quick interloop development cycle. And that drove lots of technology and design decisions. And we've been running that with playbacks every week I believe, where the team played back t

About Tyler McMullenTyler McMullen is CTO at Fastly, a global edge cloud platform, where he is responsible for evolving the system architecture and the company’s technology vision. He leads a team of experienced technology innovators focused on internet scale, and working on future-facing, ambitious projects and standards. As part of the founding team at Fastly, Tyler built the first versions of Fastly’s Instant Purging system, API, and Real-time Analytics. Prior to joining Fastly, Tyler worked on large scale web applications, text analysis, and performance. He can be found debating about edge computing, networking, and distributed systems all over the world.Fastly: fastly.comEmail: [email protected] this episode on YouTube: https://youtu.be/3F5COSkQlf0TranscriptJeremy: Hi, everyone! I'm Jeremy Daly and this is Serverless Chats. Today, I'm chatting with Tyler McMullen. Hey, Tyler. Thanks for joining me.Tyler: Hey, Jeremy. Nice to see you.Jeremy: So, you are the CTO at Fastly. I'd love to know a little bit about your background, and what Fastly does.Tyler: I'll start with what Fastly does. Fastly is an edge cloud platform. What that ends up meaning is that we help people to move their content, as well as their logic, their actual programs, out to run on the edge of the network. The whole goal of that is to make things much faster for your users, better user experience, as well as much more resilient.It's actually a super exciting place to be, in my opinion. I got into, we founded Fastly, oh, wow. 10 years ago now, maybe more. I can't remember off the top of my head now, but it's been a while. I remember getting into it specifically because Archer, who was our CEO and our primary founder, came to me and he was like, "I have this idea. It's a content delivery network, but it's more like an edge computing network." I was working at a startup at the time. I said, "That sounds extremely exciting." As a distributed systems nerd, that was just, oh, man! It's catnip to me.Jeremy: Right.Tyler: So, for the last 10 years it's continued to be exciting. That's how it got started there.Jeremy: Awesome. What about your background?Tyler: My background is, I was just a kid who taught myself to program, and got started working when I was about 16 years old, and just never stopped. I skipped the whole college thing and hopped from startup to tech company to startup.Jeremy: Awesome. So, I'm a huge fan of serverless. Again, I do a serverless podcast, so it's probably quite obvious to people. But one of the things that I am absolutely fascinated with is the idea of serverless computing at the edge, which is one of these things that Fastly is doing. I think that there's a possibility that this could be the future of serverless computing. No more data centers, or things like that, or regions. It's just right at the edge, and as close as possible, that we could get to the user that is actually interacting with this stuff. So obviously, a huge challenge, lots of things that need to be done to make that happen. But I think what would be great for the listeners is if we just take a step back and explain exactly what we mean by compute at the edge.Tyler: Sure, sure. It's actually a great question, because this is something that keeps coming up. For years, I have been trying to explain exactly what is edge computing. The problem is that everybody has a different opinion as to what exactly it means. I think that the ultimate problem is that depending on who you talk to, that person is familiar with or working on one particular line. One particular edge, effectively, of that network.So, if you're talking to someone who works at a telecom, they're going to talk about 5G, and how it needs servers inside of cell towers, effectively. Meanwhile, you talk to a traditional ops person, talk to an ops person from the '90s. The way that they think about the edge is actually the edge of their own network. It's kind of the border between their autonomous system and the rest of the network, the rest of the internet. You talk to me, we're going to talk about metro area data centers, as well as even more narrow ones.Anyway, the list goes on and on. So to me, I think it's actually kind of, the problem is, in my opinion, in the word. The problem is the word "edge," because it implies a line. It implies a specific point within the network, and I don't think that's actually true. Because if you think about all of these different places that we're talking about having computation, they all have really important similarities in their models. The point is that it's not the client. It's not actually the person that you're interacting with. It's also not within your own specific data center. It's not within your core computing.Everything in between there has a certain set of problems. It means that you don't necessarily have direct access to a database. It means that you probably have to think about doing things in a little bit more of a stablest way. It mean

About Tim SuchanekTim Suchanek is the lead TypeScript developer at Prisma, which makes advanced data infrastructure developed at large tech companies accessible to all developers around the world. Based in Berlin, Tim has been creating web applications for over 10 years, and enjoys great developer experience and cutting edge technologies.Twitter: @TimSuchanek LinkedIn: linkedin.com/in/tim-suchanek-08219346Prisma: https://www.prisma.io/Prisma Client: https://v1.prisma.io/docs/1.34/prisma-client/GitHub: https://github.com/prisma"Generics, Conditional types and Mapped types": https://www.youtube.com/watch?v=PJjeHzvi_VQGitHub: https://github.com/prisma"A Practical Introduction to Database Migrations": https://www.youtube.com/watch?v=xfaps6hgFvI"How Prisma Solves the N+1 Problem in GraphQL Resolvers": https://www.youtube.com/watch?v=7oMfBGEdwscWatch this episode on YouTube: https://youtu.be/Cci65o4IxaUTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm speaking with Tim Suchanek. Hey, Tim. Thanks for joining me.Tim: Thanks for having me, Jeremy.Jeremy: You are a TypeScript lead at Prisma. Why don't you tell the listeners a little bit about your background and what Prisma does.Tim: Yeah. First of all, thanks for having me. It's an honor to be here. I have listened to several episodes already. Prisma is basically a database tooling company, you could say, where our core is implemented as open source. Everything we build is available for everyone, and everyone can contribute. What we basically focus on right now is a database client, database access, but we're also working on schema migrations. What this database client is doing is mostly giving you type-safe access to your database. We do that in TypeScript.The way Prisma is architectured, we can also implement clients in different languages like Go or Java. We have the core of the query engine is written in Rust, and TypeScript is basically a layer on top to give you type safety for your database. With type safety, I mean if you for example say, "I want to select a certain field," then you will also in your types, in your code will have the guarantee that this field will be there. I believe that still until today this is the only client out there giving you really this kind of experience. How this works is through code generation.We employ code generation quite heavily, and you define declaratively your schema. You say, "I have a user. A user has a post and so on or has posts." Based on this schema definition, we then generate the whole client in TypeScript. This is now in GA since 2020. We have been working on this for two years, and in general Prisma already exists for nearly five years. That's what we're doing. Obviously, if you use your database, you oftentimes in 2020 you use serverless, and so we see many users, we see a lot of adoption rising there. While still many users are using this in a containerized fashion, we see a big growth also how this is being used in Lambda and serverless.Jeremy: What about your background? How did you get into TypeScript?Tim: It's funny because I started JavaScript I think nine years ago and did not really besides having had type languages in uni like Haskell and Java, the usual stuff we had to look into, besides that I was really into dynamically typed languages, not really a big fan of anything. The type system was my enemy basically. TypeScript came around 2015, I had the first look into it. Actually, Johannes who's the founder of Prisma, he made me aware of it that TypeScript even exists, so I looked into it.First, I had I would say quite strong resistance to it because once you ... It feels a little bit like it's taking away your freedom. I'm so free in JavaScript, I can just do what I want. If you are looking a bit more into it, if you're reflecting a bit and thinking, "Okay. Where can this really help me?", you are step-by-step understanding that the compiler is not your enemy, but your friend, and just really protects you from your own stupidity basically. We are just humans. It doesn't matter how good of a programmer you are, you will do these mistakes and TypeScript really helps.Since 2015, I have not used anything else anymore. Here, I really have to site a colleague Ryan from Prisma recently tweeted if he is not writing code in TypeScript anymore, it feels like going outside without clothes. It's really like something is missing. It's like the safety net, the safety layer somehow missing. I am basically someone who converted from JavaScript as my religion to now TypeScript, both in nodes and in the front end and using it four or five years.Jeremy: Awesome. I've been programming in JavaScript for 23 years.Tim: Okay.Jeremy: Yeah. It was a very difficult change for me. It was a huge mind shift for me, but anyways, all right. I don't typically fool my listeners here, but I think we're going to fool them a little bit because even though this is a serverless podcast, we're going to

About Nicole YipNicole Yip is an Engineering Manager at the LEGO Group. She has been working as an Infrastructure and DevOps engineer for over 5 years mostly as a consultant helping teams of all sizes get their services into AWS. Her roles have often become the catch-all for everything non-application-developer but that matches her passions for AWS, Infrastructure as Code, CI/CD, and Security. Nicole is a frequent speaker at various conferences, with past events including Serverless Architecture Conference, DevOps Con, and ServerlessDays Virtual.Twitter: https://twitter.com/Pelicanpie88LinkedIn: https://www.linkedin.com/in/nicole-yip-5b792292/Medium: https://medium.com/lego-engineeringLEGO: https://lego.comServerlessDays Virtual 2020: https://www.youtube.com/watch?v=9oYS_5eL610Watch this episode on YouTube: https://youtu.be/_09c6maJ3UcTranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Nicole Yip. Hey Nicole, thanks for joining me.Nicole: Thanks for having me.Jeremy: So you are an Engineering Manager at the LEGO Group, so I'd love it if you could tell the listeners a little bit about yourself and your background and what you do at the LEGO Group.Nicole: Sure, so as you said, I'm an Engineering Manager. I have joined the company about a year and a half ago, as a Senior Infrastructure Engineer and then moved up to Engineering Manager and I've joined in the Direct Shopper Technology Team. So we look after www.lego.com, all of the pages where you're browsing for products, completing your order through checkout, and redeeming VIP vouchers, that's what my team looks after. And specifically, I look after the platform. So I head up the platform squad there where we look after the infrastructure and hosting and developer experience CI/CD, security, and operations of the site. So quite a big remit there and specifically my background as in AWS and managing production workloads and that's really where my interest is and what I'm doing at the LEGO Group.Jeremy: Awesome, well so I am super excited that you are here because I love the LEGO Group, not just because I loved LEGOs as a kid, but also because I started talking with Sheen Brisals a long, long time ago and he was so super excited about the whole serverless process and just building things with serverless. And so it was really interesting to hear the process that the LEGO Group has gone through. And it's been, I think over a year since I talked to him on the show here. And so I'd love to set the stage here because there is this talk that you gave at ServerlessDays Virtual recently about this audit process that you do at the LEGO Group in order to make sure that you're following best practices with serverless and that you're always kind of upgrading. And I wanna get into that but I think to set the stage for everybody to know just how serverless the LEGO Group is, maybe you could give us just a quick timeline of where it started and where you are now from a serverless perspective in your engineering group.Nicole: Yeah sure. So the story starts a little bit before I joined back in 2017 when we had, it was kind of an event that was the last straw, the straw that broke the camel's back, so they say. And yeah, so there was a launch event that was highly anticipated, we didn't survive. And that led to us looking at options that weren't on-premise, that weren't hosted on-premise. So we started back in 2018, actually scoping out serverless and AWS and seeing if it would work for us. So we migrated a single user-facing service and a couple of backend services over to the cloud, got them running and they were handling high season traffic by the end of 2018. And so yeah, fully in production and ready to go. And that then led on to us making the entire lego.com site serverless. So the pages that I mentioned that are within our team's remit, we moved all of them into Fargate instances and serverless Lambda functions. And so the only on-premise system we have is our source of truth, our warehousing system and we've wrapped that up in Lambda functions so we only talk to that asynchronously.Jeremy: Nice, so now where are you now? You've mentioned Fargate, you've grown the number of engineers that are working in serverless, so like where are your just rough numbers, like how many Lambda functions do you have? Things like that.Nicole: Oh, this is fun. So we had four Lambda functions in 2018 during Black Friday, Cyber Monday. In 2019, which was last year, we had just gone fully serverless. The platform was handling high season levels of traffic and at that point we had four Fargate instances and I think it was 36 serverless services. And a serverless service can be made up of many Lambda functions. I think we had around 150 to 200 Lambda functions. No, I think it was around 150 Lambda functions in production at that time. And now that we've gone through another Black Friday, Cyber Monday high season period, we're now over 260 Lambda

Watch this episode on YouTube: https://youtu.be/QVauc83L8WUTranscriptEpisode #30: What to expect from serverless in 2020 with James Beswick Yeah, it's really snowballing in terms of popularity and certainly seeing just the sheer number of people from all these different companies. You have startups and enterprises and so many different types of industry all starting to pick up serverless tools. And a lot of things that we talked about just a year ago, that really seem an incredibly long time ago now, the conversations that don't really necessarily matter that much anymore.There was a discussion about what is serverless and all these sorts of things. And now we're starting to talk about architectural patterns, and starting to talk how it's not just lambda anymore. Serverless is this concept of taking different services from different providers and combining them. So I think, you know, we see people building things where you connect API Gateway, DynamoDB, S3, but also with services like Stripe or with Auth0 and then Lambda is just connecting things in the middle.Episode #57: Building Serverless Applications using Webiny with Sven Al HamadSo when you're a small business, it's the cost of infrastructure that really matters to you because it's really efficient. You don't pay if you're not using it. But for the big guys, it's a combination of factors. And sure your bill might be slightly higher in some cases running on serverless, the cost of infrastructure. But the cost of managing infrastructure will go way down. You will have to hire less people, or the people you have will have to spend less hours working there.But also what that does, it releases a big chunk of the budget or resources or man hours that you can now focus on product iterations. So your product can grow faster. And if your product grows faster, you can out innovate potentially your competitors, which can't afford that same level of innovation. So what I see with enterprises is that they see serverless as a competitive advantage, and that's why they moving to serverless. Although, you see all the blog posts about cost savings and stuff like that. Yes, that's true, but there's that agenda of outpacing my competitor, which serverless actually unlocks. And the moment you migrate to serverless, you can use that potential.Episode #35: Advanced NoSQL Data Modeling in DynamoDB with Rick Houlihan (Part 2)I mean, I get the question of is DynamoDB powerful enough for my app? Well, absolutely. As a matter of fact, it's the most scaled out NoSQL database in the world, nothing does anything like what DynamoDB has delivered. I know single tables delivering over 11 million WCUs. It's absolutely phenomenal and then the other question is is not DynamoDB too much overkill for the application that I'm building?I think we can have great examples across the CDO of services. Not every one of our services is massively scaled out. Hell, I've got services out there, I've got five gigabytes of data and they're all using DynamoDB and the reason why I used to think that NoSQL was the domain at the large scaled out high performance application, but with cloud native NoSQL, when you look at the consumption based pricing and the pay per use and auto scaling and on demand, I just think you'd be crazy.If you have an OLTP application, you'd be crazy to deploy on anything else because you're just going to pay a fraction of the cost. I mean, literally, whatever that EC2 instance cost you, I will charge you 10% to run the same workload on DynamoDB.Episode #44: Data Modeling Strategies from The DynamoDB Book with Alex DeBrieI introduced the concept of item collections and their importance pretty early on. I think it's in chapter two. And it was actually one of the solutions architects at AWS named Pete Naylor that that turned me on to this and really made me key into its importance.But the idea behind item collections is you're writing all these items into DynamoDB, records are called items in DynamoDB. And all the items that have the same partition key are going to be grouped together in the same partition into what's called an item collection. And you can do different operations on those item collections, including reading a bunch of those items in a single request.So as you're handling these different access patterns, what you're doing is you're basically just creating these different item collections that handle your access patterns. And that can be a join like access pattern. If you want to have a parent entity and some related entities in a one to many or many to many relationship, you can model those into an item collection and fetch all those in one request.You can also handle different filtering mechanisms within an item collection, you can handle specific sorting requirements within an item collection. But you really need to think about, hey, what I'm doing is I'm building these item collections to handle my access patterns specifically.Episode #79: What to do with your da

About Ajay NairAjay Nair is the Director of Product Management at AWS. Ajay is one of the founding members of the AWS Lambda team, in his current role, drives the serverless product strategy and leads a talented team driving the product roadmap, feature delivery, and business results. Throughout his career, Ajay has focused on building and helping developers build large scale distributed systems, with deep expertise in cloud native application platforms, big data systems, and streamlining development experiences. He is also a co-author of Serverless Architectures on AWS, which teaches you how to design, secure, and manage serverless backend APIs for web and mobile applications on the AWS platform.Twitter: @ajaynairthinks LinkedIn: https://www.linkedin.com/in/ajnair/ Serverless Land: https://serverlessland.com Serverless Architectures on AWSBuilding revolutionary serverless applications: https://virtual.awsevents.com/media/1_wrjleiffWatch this episode on YouTube: https://youtu.be/QMOLE2-SUjU Transcript Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Ajay Nair. Hey, Ajay. Thanks for joining me.Ajay: Hey, Jeremy! Finally on the show, yay! Jeremy: Well, I am glad you're here. So, you are the Director of Product Management for AWS Lambda at Amazon Web Services. So I'd love it if you could tell the listeners a little bit about your background, kind of how you ended up at AWS and then what does the Director of Product for AWS Lambda do? Ajay: Okay, first, thanks for having me on the show. I've been a great follower of both your talks and blogs for a long time, so I'm excited to kind of finish what's been an interesting year by spending time with you. I’ve been at AWS now coming up n about seven years; been with the Lambda theme for pretty much the whole time. Tim Wagner and I were the founding folks for AWS Lambda way back when. I spent a whole bunch of time at Microsoft and some other software companies before that in a combination of development and program/product management roles. I ended up at AWS only just looking for an opportunity to go and build a new product or a new service in the cloud space. I’ve done a whole bunch of things with developers in big data platforms so far and they signed me on this top secret effort which they said was going to be a new way of doing compute. Here we are seven years later with me as the Director of Product Management. So my role as Director of Product really is to help figure out the why and the what of what we should be building and evolving Lambda for, so everything that's happened to Lambda over the last seven years is in some way my fault. So, yeah, in all seriousness I get to spend time with customers to figure out what the right thing to go and build for them is and help the team figure out, build it, and then help the marketing and sales team sell it. That's kind of what my day job is and it's been a great ride for the last seven years and here I am. Jeremy: That's awesome. Well, I am super excited to have you here. You know, you said it was an interesting year, that's probably an understatement, but not only an interesting year in terms of everything that's been happening, but also an interesting year for serverless as well. And we just finished, I think it was ... what? ... like week 27 of re:Invent. Oh, no, it's just week 3! But it felt like everything this year's just felt like it dragged on incredibly long. But so there were a lot of really cool things that happened with serverless this year and in your purview is more around Lambda, obviously, you're the Director of Product there, but there's so many services and things that happen at AWS that interact with it. And I think what would be really great to do, and I want to be respectful of your time and of our listeners’ time, because I'm sure you and I could talk for the next ten hours about this stuff and then have to take a break and talk for another ten hours. But so we'll timebox this a little bit. But I do want to start with just kind of a year-in-review of the things that have happened to, you know ... with serverless with Lambda. What are some of the new capabilities, what use cases do those open up? And so let's start with re:Invent. Let's start with the big ones that happened at re:Invent. We can work, sort of work our way backwards and then hopefully you can kind of put all this stuff together. But so let's start there. Let's start with the big one. At least I think this is a huge one because it opens up a lot of, I think, capabilities for other people to get involved and that has to do with container packaging support. So what's the deal with that? Ajay: Yes, the idea behind this, as you said, is allowing you to bring Lambda functions packages, container images, and run them on Lambda. You know, this is an evolution of the team we have seen for a while where there's a set of people who say I like to build my code a certain way, but I want to run it the Lambd

About Angela TimofteAngela Timofte is the Tech Lead at Trustpilot, a global review platform that helps businesses collective and leverage customer reviews. Angela has a proven history of transitioning legacy applications to new platforms and product offerings. She is driven to build scalable solutions with the latest technologies while migrating away from monolithic solutions using serverless applications and event-driven architecture. She is a co-organizer of the Copenhagen AWS User Group and a frequent speaker about serverless technologies at AWS Summits, AWS Community Days, ServerlessDays, and more.Trustpilot: Trustpilot.comTwitter: @AngelaTimofteLinkedIn: Angela TimofteWatch this episode on YouTube: https://youtu.be/jHE0VYfQUaYTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Angela Timofte. Hey, Angela, thanks for joining me.Angela: Hi, Jeremy. Thanks for having me here.Jeremy: So, you are the Data Platform Manager at Trustpilot, so I would love it if you could tell the listeners a little bit about yourself and your background and what you do at Trustpilot and what Trustpilot is all about.Angela: Yes, of course. So as you already mentioned, I work as a Data Platform Manager at Trustpilot and I've been with the company for almost six years. So, quite a long period of time for a company that it's only been for like 11 years on the market. But yeah, I started in the company as a backend developer and then moved to be more of a full stack developer and now the data platform manager because my love for data was always there and I kind of did everything that I could do to move closer to the data. To be honest. no matter where I was in my career it was always data that, like, attracted me the most. Like how do you handle it? And to be honest nowadays, like, data is everything. Like you can't make any decision as a business without data and now everyone is seeing that. So it's really cool the position I am in right now because I can push all these, like, these data meetings that we do so that we take, like, the right decision. And then, yeah, Trustpilot. I mean, hopefully everyone heard about Trustpilot. At least that's what I want to think, but in case you haven't, you should use it. It's an online review platform and I mean our all … our whole mission is to help people to have better experiences when it comes to purchasing online. But of course, at the same time, we want to help businesses to connect with their customers and also improve their offerings and for that we offer all these analytics tools. So they understand better their customers and they know where they need to improve their business. And I mean if you think about, like, the situation now with Covid, honestly Trustpilot came perfectly. Even for me, like, I'm talking from my perspective now, but, like, I had to order everything online, like, from food to, like, toilet paper. I didn't go to the store to fight for it. I went online and fight for it, and fought for it. So, but it came super handy because I'm based in Copenhagen and we don't have Amazon here and then you have to purchase from, like, small businesses and you don't know about all of them. So I had found myself searching on Trustpilot. Okay, can I trust this business because I've never heard about it, right? So I don't want to throw money out there. And yeah, that's what you can use Trustpilot for if you are a consumer, and especially in these times it's perfect because I can trust that what I find there it's real data and real people and I can get their opinions on all of these. So, yeah.Jeremy: Awesome. So I am super excited to have you here because as much as I am a huge serverless geek, I love data; like, I'm with you on that. Like everything that I do, I'm always finding better ways to build or abstract data or interact with data. I built all these open source libraries, and I think all my open source libraries have something to do with data. And what we've seen over the last several years is this move to more and more serverless data, right. Like, capabilities that allow us to use databases that are more and more serverless, DynamoDB obviously being one of the big ones; all kinds of crazy stuff happening with relational databases.So, you're an expert on databases and data and I would love to get some of your, you know, sort of your comments and insight on what are those choices that people have right now for serverless data. And also we're in the middle of re:Invent right now, so just in the beginning of re:Invent there's already a whole bunch of announcements of new things that Amazon has released and more options that are available. So let's start there. What are, you know, what are those serverless options for data that people have?Angela: Yes, I mean you've already mentioned DynamoDB and for me that's like the first choice when it comes to building serverless applications, to be honest, especially when you think about scalin

About Rodric RabbahRodric Rabbah is the co-founder and CTO of the serverless computing company called Nimbella. He is also one of the creators and the lead technical contributor to Apache OpenWhisk, an advanced and production-ready serverless computing platform. OpenWhisk is open source and offered as a hosted service from IBM and Adobe. It is also deployed on-prem in several organizations worldwide.Twitter: @rabbahPersonal website: rabbah.ioNimbella: nimbella.comApache OpenWhisk: openwhisk.orgWatch this episode on YouTube: https://youtu.be/xVZhFHmEuKYTranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Rodric Rabbah. Hey Rodric. Thanks for joining meRodric: Hey, Jeremy. Thanks for having me. I'm really excited about our discussion today. Jeremy: Awesome. So you are the co-founder and CTO at Nimbella and I'd love it if you could tell the listeners a little bit about Nimbella, but I'd really love to hear about your background as well.Rodric: Okay, yeah, thanks for giving me the opportunity. So, I started Nimbella about two years ago, just over two years ago, and it was after a long stint at IBM for 11 years, and IBM Research specifically. And there I did a number of things that touched on programming languages, compilers, hardware synthesis, and FPGAs. And the last project I really did was creating IBM serverless functions offering, which is now called identify functions, but it started as OpenWhisk. And OpenWhisk is now an Apache project that we have donated to the Apache Foundation four years ago and really is what started my serverless journey six years ago. So my background is mixed. It has experience from programming languages, compilers, hardware systems, and I've done a lot of things that I think have a common theme across verticals, or I build verticals that cross lots of different layers of the stack. Jeremy: Awesome. All right, so I want to start with IBM and OpenWhisk because this fascinates me where, you know, six years ago and just recently, I mean, it was a six-year birthday of AWS Lambda and I think it's, that this sort of kicked off a massive sort of investment and maybe almost like a space race except for the cloud, I guess, a serverless race against all these different vendors. So, you were involved with this very, very early on, right? I mean, like I think it was your project, right? So I'd love to hear how this all came about, like, why did IBM suddenly say, “Okay, we need to build a serverless offering?”Rodric: Right. So, before I started working on OpenWhisk, I was doing something completely different, where I was debugging hardware and looking at how to generate hardware from software. And then we saw the Amazon Lambda announcement at the time and it was literally right around this time. And as soon as we saw it, it was sort of one of those moments where you just realize, “Oh, my God, this is a dramatic shift in technology that's coming.” And even though it was basically day zero you could see, you know from the right perspective, you could see what the future is. And now I say serverless is inevitable, because you know, whether you're on the bandwagon or not, you will be in the future because that's the only way developers will want to build. So, in the early days, you know, we saw the announcement we were looking at the project we were doing like they gave us the terminology that we were looking for. It was just take hold and just run it in the cloud and we were trying to do something like that with hardware, you know take software and now we can accelerate for you on an FPGA, which is reconfigurable hardware without you having to worry about compilation running. And so we were doing work in a similar context in a similar area but completely different context, when we saw it. It was like this is it. So we got together as a small team within IBM, six people, and we were having discussions about Lambda and the future. What did it mean for IBM Cloud? And you know from IBM Research our job really was to sort of look at technology that's on the horizon and you know, five, ten years in the future and start thinking about, what does that mean? And after about, you know, a few weeks of just talking about it, I got tired of talking about it and over a weekend I built the first version of what became Apache OpenWhisk.And it started with, you know, a command line tool which is the programming interface essentially to the cloud, allowed me to create functions, run them, get their logs, and recorded a short video by Sunday night and then sent it in, you know, Monday morning it got in front of the right eyes. You know that whole thing about being at the right place at the right time and it started circulating and from there, we're like, okay this is turning into something, and off we went. So it was sort of the Amazon Lambda landed on the scene. There was recognition that this is something really transformative into the future and then the will to ju

About Ryan ColemanRyan Coleman is Vice President of Engineering and Product at Stackery, a serverless platform to design, develop, and deliver modern applications. Ryan is an accomplished product manager and ex-sysadmin who spent the last decade working with enterprise operations teams in the Fortune 100 to automate global infrastructure with Puppet.Stackery: www.stackery.ioTwitter: @ryanycolemanWatch this episode on YouTube: https://youtu.be/tEa2eJLwjZATranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Ryan Coleman. Hey, Ryan, thanks for joining me.Ryan: Hey, Jeremy, good to see you. I'm looking forward to this chat all week.Jeremy: So you are the Vice President of Engineering at Stackery so why don’t you take a minute, tell listeners a little bit about your background and what Stackery does.Ryan: Yeah, so I'm mostly a system-man by trade. I kind of been tinkering with computers most of my life and sort of to pay for my college I started doing IT support that led to more advanced operations roles that led me to some VM automation software called Puppet which led me out here to Portland, Oregon from Pennsylvania to help Puppet grow and be a product manager of professional services and sales and I got to wear a bunch of different hats and more importantly explore enterprise operations that some of the largest organizations in the world and yeah then moved on to Stackery this year to help them with their infrastructure as code platform which focuses on AWS serverless and it’s trying to help people sort of design serverless architectures, express that in AWS SAM infrastructure as code as well as some other languages, and then just provide sort of a workflow for delivering that bringing environments to deliver different changesets over the AWS infrastructure, all that kind of stuff. Jeremy: Awesome. All right, so there's always debate in the serverless sort of ecosystem or peripheral ecosystems to serverless that talks a lot about this idea of no ops or dramatically reducing your Ops. So I tend to believe that serverless dramatically reduces your ops because there's less things you have to worry about but I don't think that reduces the amount of operations work that can be done. And I think you bring a really interesting perspective because Stackery is a hundred percent focused on building serverless architectures, which is great, but it is for operations teams, right? It's not really for your front end developer. I mean, your front end developer can use it or a developer can use it, but it's very much so focused on the idea of bringing a cohesive operations, I guess, I don't know, sort of like Mantra to a serverless infrastructure.And with all your experience, especially with Puppet, which again was also like, you know, automating pieces of the infrastructure and like turning ... saying to ops people, “Okay, we don’t need you to install patches anymore. We don't need you to do this because this can be automated.” I think you're going to bring a really interesting perspective. And I'd love to talk to you pretty much about operations for … you know, that serverless is really for operations right, in a sense. I don't know, maybe that makes sense, maybe that doesn't. But maybe we could start by just going deeper into your background at Puppet. Like what were you finding when you were bringing in essentially an automation software to take some of the operational load off of the operations teams?Ryan: Yeah, that's that's wonderful. I think there's a couple ... there's like two big cultural trends there that I think are worth talking about and I joined Puppet in late 2011. So think like early configuration management movement, early DevOps movement. So everyone was kind of chasing this idea of we can automate configurations on VMs, like it’s very ops-focused, but we can automate everything about the VM provisioning configuration and maintenance process and we're going to reform how we think about these teams. I like to think about how traditional development has this sort of waterfall effect where the business is coming up with why we're doing software, why we're doing IT. Development is getting to decide, well, what are we going to do to solve this business need and operations is that tail of like, well, how do we actually get this in front of customers?And it usually flowed in that direction and dev ops was a lot of saying well, let's kind of get together into some form of a circle but in classic IT operations, ops was always chasing everything even if they were in the circle. They still had to maintain all the infrastructure over time, they had patch cycles. they had upgrades to do so, they were never really participating in that full loop as much as the business and the developers were and so if ... I came into Puppet as a Professional Services engineer during those two big kind of cultural movements, and I got to go to both public and private trainings, and the p

About Matt CoulterMatt Coulter is a Technical Architect at Liberty IT and AWS Community Builder. Matt has a proven history of delivering scalable, serverless solutions on the public cloud, and has crafted CDK Patterns, an open source collection of AWS Serverless architecture patterns built with CDK for developers to use. In addition to his work on CDK Patterns, he shares his passion and knowledge on serverless through events like AWS Community Day Dublin and blog posts on Dev.to.Website: www.mattcoulter.comTwitter: twitter.com/NIDeveloperCDK Day: www.cdkday.comCDK Patterns: www.cdkpatterns.comWatch this episode on YouTube: https://youtu.be/wKvaCsvfJ_MTranscriptJeremy: Hi, everyone. I’m Jeremy Daly and this is Serverless Chats. Today I’m joined by Matt Coulter. Hey, Matt, thanks for joining me.Matt: Hey, Jeremy, thanks for having me on today. I’m looking forward to this discussion so much.Jeremy: Awesome. So you are a technical architect at Liberty IT so why don’t you tell the listeners a little bit about your background and what you do at Liberty IT.Matt: Sure. So I’m in this account enabling architect role now at Liberty IT. What that really means is Liberty is global, it’s huge, so Liberty IT in Belfast and Dublin has about two hundred engineers in my section, but globally there’s over a thousand engineers. And if you Google Liberty Mutual serverless you can see that we have a mission, we have a mandate, we want to be a serverless first company rapidly delivering value in a well-architected way. So my job is to create the environment where our engineers can do that at a global scale, so not just one thing, but do it in a way where we don’t leave everybody behind and everybody feels bought-in and a part of doing that job.Jeremy: Right. And if anybody has been paying attention on Twitter or is anywhere near I would say the CDK space they’ve probably come across CDKpatterns.com which is a site that you put together and I want to talk about that because that is super-interesting just in and of itself. But there’s also ... part of the reason you built this, and we’ll get into this, but is because the CDK is so powerful. And I’m going to do a little mea culpa here. At the beginning of 2020, I was looking at the CDK as, like, “I don’t know. I like DSLs better than this idea of imperative code for infrastructures code.” I think I have completely changed my mind on this just because of how powerful CDK is, especially encapsulating functionality for teams. So, I want to talk about the CDK first then we’ll get into CDK patterns. So, let’s start there; let’s start with the CDK and in case people are not familiar with what CDK is, can you explain that and give us some of the vocabulary that new listeners might need to know in order for us to have this conversation so they can follow along.Matt: Absolutely. So, the first thing is, and I learned this just for CDK Day, CDK itself, which stands for the Cloud Development Kit, is actually not a family of products. So, if you just say “CDK” you’re actually referring to AWS CDK which is the original, the main kit, that is used to deploy resources on the AWS using Python, Java, TypeScript, pretty much they’re working on a lot of languages but there’s also CDK for Terraform which has come up through the community and it’s an officially supported product, CDK for Kubernetes, and I saw CDK for Azure. So, what brings those things together as umbrella products is is a thing called Construct, and Construct is an open source product and that is the magic behind the CDK. That is the thing that allows you to write code in your normal language and it gets converted into DSL that was the original thing that was used in the first place.So, we’re probably going to spend this conversation talking about AWS CDK and what it does is it converts all of your code into cloud formation and that’s the brilliance of CDK. And pairing developers with the languages they know but at the end of the day you can still apply your rigor and compliance and cloud formation knowledge to the full set-up. And just one more term that might come up later, whenever we talk about Construct, we talk about L1, L2, and L3 constructs. So it’s simple-ish to remember: L1 means cloud formation, everything is L1 starts with c and fn. L2 means AWS built it, so that’s their very light opinion on how to make things easier. And then L3 is stuff that we built, that is typically an aggregation of multiple L2s. I think that’s pretty much the vocabulary you need to understand this discussion anyway.Jeremy: All right, well, that’s good. It’s a good place for us to start. And I think this is why things have changed my mind because of that L3 category there, right, and the L3 constructs, and it’s because what has happened is rather than you just defining your infrastructure using code, whatever, TypeScript or Java or whatever, rather than you just defining it that way, constructs are multiple pieces of infrastructure that can be wrappe

About Taavi RehemagiTaavi Rehemägi is the Co-Founder & CEO of Dashbird, a serverless monitoring and intelligence platform for building and operating complex applications on AWS environment. He has over 13 years of experience as a software developer and 5+ years of advocating for the serverless revolution and building Serverless applications at various organizations himself. Twitter: https://twitter.com/rehemagiDashbird: https://dashbird.io/Watch this episode on YouTube: https://youtu.be/xeF19VCuoV0TranscriptJeremy: Hi everyone. I'm Jeremy Daily and this is Serverless Chats. Today, I'm chatting with Taavi Rehemägi. Hey Taavi, thanks for joining me.Taavi: Hey, thank you, Jeremy. Nice to be here.Jeremy: So you are the CEO and co-founder at Dashbird. So why don't you tell the listeners a little bit about your background and what Dashbird does.Taavi: Sure. I've been a developer myself for pretty much my entire life. I started coding when I was 14 and since then, before starting Dashbird, I was an employee in two different startups. The last one I was working a lot on serverless. That was in 2016/'17, which led me and some of the team at Dashbird to found this company called Dashbird. We're an operations platform for serverless workloads. We help companies who are building on serverless to achieve excellence with their infrastructures.Jeremy: Awesome. So we have done a number of shows about observability because observability and serverless seems to be that third-party offshoot that has been missing. There's a lot of things that AWS just didn't really tackle initially with a lot of the observability stuff. Now, they've added quite a few things, but again, it's nowhere near as easy to use as some of these third-party tools like the Dashbird are. So there are obviously constant enhancements.They just launched, and we can get into this in a little bit more detail, but they just launched not too long ago, this idea of the extensions API for Lambda, which allows tools like the Dashbird or whatever, to have more control over the life cycle, if you wanted to have control over the life cycle of the Lambda function being able to get metrics and telemetry data and things like that. But I think there's still a bunch of stuff missing. I think you would agree with me on this, that there's more we have to do in order to understand and observe our serverless applications. So I'd love to get your input because I think Dashbird has sort of a different outlook or I guess a different roadmap for how you want to address the observability problems, and it's super interesting. So why don't we start there? What's missing in your opinion with observability and serverless?Taavi: Sure. So I think first off observability is one thing we do, but when it comes to operating the serverless infrastructure, we're talking about high load like ad scale environments, there's a lot going on there that we try to help companies with. As an engineering team, if you're really building something that has hundreds or thousands of functions, for example, and a lot of different Cloud resources, then the one thing that's really difficult obviously is monitoring data and getting an overview of the activity going on across those resources and across your infrastructure.But there's also, how do you detect failures and how do you get notified quickly and how do you respond to incidents and solve them? There's also keeping up with things like security and Cloud infrastructure for best practices, optimizing for performance and costs. So the monitoring this one part of the puzzle and then having been in this role where we were building a pretty substantial serverless infrastructure, there's a lot going on there. A lot of those things as a team you would have to build yourself and to figure out yourself and to construct strategies around how to improve. So that's really what we're trying to do for our organization. So we're trying to build an abstraction level for operational practices pretty much.Jeremy: I love that because it's a more sort of holistic approach, I guess, to building a serverless. So building and managing a serverless application, as opposed to just sort of being responsible for, I guess, the monitoring aspect of it. Because again operational-wise ... and this is something, I forget who I was talking about this to, but essentially where it's like serverless or monitoring and observability in serverless is great when you get an alert that says something went wrong. But it's also really good and comforting to know that something went right.Right? To know that events are flowing through the system and that the SQS queues are processing correctly and knowing that those things are working correctly and give you that level of confidence. I think that's really cool. From the Dashbird perspective, and again, I want to keep this a little bit more general. We don't want to just decide all about the Dashbird, but I really do love this perspective that you

About Vadym KazulkinVadym Kazulkin is Head of Technology Strategy at ip.labs GmbH, a 100% subsidiary of the FUJIFLM Group, based in Bonn. ip.labs is the world’s leading white label e-commerce software imaging company. Vadym has been involved with the Java ecosystem for over fifteen years. His focus and interests currently include the design and implementation of highly scalable and available applications, container and orchestration technologies and AWS Cloud. Vadym is the co-organizer of the Java User Group Bonn and Serverless Bonn Meetup, and a frequent speaker on various Meetups and conferences.Twitter: @VKazulkinLinkedIn: https://de.linkedin.com/in/vadymkazulkinEmail: [email protected]: https://www.slideshare.net/VadymKazulkin/measure-and-increase-developer-productivity-with-help-of-severless-by-kazulkin-and-bannes-sla-the-hague-2020-238115659About Christian BannesChristian Bannes works as Lead Developer at ip.labs GmbH and has been working in the professional Java Enterprise environment for over ten years. In recent years, he has been working with AWS Cloud and especially with serverless applications. He is particularly interested in distributed architectures, domain-driven design, and functional programming.Email: [email protected] Website: www.iplabs.deWatch this episode on YouTube: https://youtu.be/QoKW1KR7rrMTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I am chatting with Vadym Kazulkin and Christian Bannes. Hey, Vadym and Christian. Thanks for joining me.Vadym: Hi. Thanks for having me.Christian: Yeah. Thanks for having us.Jeremy: Awesome. So you both work at ip.labs in Germany. And so I'd love to talk a little bit about what IP labs does and what you two are about. So let's start with you, Vadym. So you're the head of Technology Strategy. So why don't you tell the listeners a bit about your background and what ip.labs does?Vadym: Yeah. I'm a Ukrainian native, but I live for 20 years now in Germany. I have been working with Java for 20 years but since three years, I'm involved in the migration stuff and AWS as a cloud provider of our choice. And I'm a part of the serverless community since two and a half years, involving me heavily in all this stuff and presenting ideas and our experiences mainly also with Christian. So this is what I do.And ip.labs is software provider for designing and purchasing of photo products like prints, calendars, photo books, just where you can print your emotions. So they are part of the Fujifilm group, Europe. So founded 60 years ago, approximately 80 colleagues, 30 developers.Jeremy: Awesome. And Christian, you are a lead developer there. So why don't you tell the listeners a little bit about your background?Christian: Yeah, right. So I'm a software developer at ip.labs, also working about 20 years, almost only with Java technologies. So I'm working as scrum team. I think about three years ago we adopted serverless and we switched to TypeScript because it fits our need more than Java. And yeah, we are quite happy with serverless.Jeremy: Awesome. All right. So I have seen the two of you give a presentation. I know you've given this presentation a few times, about measuring and increasing developer productivity with serverless. And this is always to me a fascinating topic, because you see a lot of claims, right? And a lot of it is very anecdotal. I mean, it's like, "Oh, yeah. We were able to move faster with serverless." Or you hear things like that. But the two of you actually sort of did some research on this, dug into the background of this and really outlined this well, and I think it should be super important, or it's super important to share with listeners so that they understand why serverless is such a powerful productivity booster for software development.So I'd love to start, like maybe way, way back in the beginning, and just talk about software development in general. So when you're building applications, and you're trying to create whether it's new stuff, and you're trying to build greenfield applications, or you're trying to work on legacy applications, what are the challenges when you are trying to, as a software developer, what are the challenges that you have to face?Vadym: So I think that the best model to explain this is the cognitive load. And this is the term coined by Matthew Skelton and Manuel Pais in their recent book, Team Topologies. And the cognitive load is the total amount of mental effort being used for accomplishing the task. So accomplishing the software development tasks. And then they differentiate between three of them: intrinsic, extraneous, and germane. And probably intrinsic, is very easy to understand, because it's how you write Java class, TypeScript class, or use some framework of the day. So this is something that you can't offload, you have to learn this. So you have to own this also.But then you have this extraneous load. And it's especially important to understand in our d

About Joe EmisonJoe is a serial technical co-founder, recently launching his fifth company, Branch, in 2017. His previous ventures have been BuildFax, Spacefu, BluePrince, and EphPod. Additionally, he has consulted with many other companies on software development and cloud migrations, including many in the DMGT portfolio. Joe graduated with degrees in English and Mathematics from Williams College and has a law degree from Yale Law School.Twitter: twitter.com/JoeEmisonLinkedIn: www.linkedin.com/in/joemastersemisonBlog: emison.orgBranch Insurance: ourbranch.comWatch this episode on YouTube: https://youtu.be/tGwGxfczaJ4Transcript:Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Joe Emison. Hey, Joe. Thanks for joining me.Joe: Hey. Thank you for having me.Jeremy: So, you are the co-founder and CTO of Branch Insurance. I'd love it if you could tell the audience a little bit about your background and what Branch Insurance does.Joe: Absolutely. I am a serial technical entrepreneur. Branch is my sixth adventure. Branch is a home and auto insurance company and we also sell renters and umbrella. There are two things that make us completely unique in the United States. One of them is we sell the home and auto as a bundle much more easily than anybody else. So really, anywhere else you would go to buy the home and auto bundle, you'd have to buy one and then the other, and it would take you somewhere between 45 minutes and two hours or maybe a week, and you'd get a lot of fake prices along the way. You'd get like, “Well, we think it's about this.” Okay, I need more information. Then, “It's about this.” We will sell you the home and auto together and for most people, we just need your name and address to give you a real price that you can buy instantly.Jeremy: Awesome. Well, the thing I think that is probably the most interesting to the listeners is the fact that Branch Insurance is entirely serverless.Joe: It is. This is actually the third company I've started fully serverlessly. Branch, from the beginning, has been built on Amazon's AppSync service. It uses Lambda, DynamoDB, CloudFront, and a bunch of other third-party services that we love.Jeremy: Awesome. All right. I have been watching your presentations. I've seen you at Serverless Conf. I've seen you at a couple of other conferences. One of the things that I always thought was fascinating is how you're always recommending some third-party service. You've got a third-party service for everything. Now, obviously some of those are our AWS services, but then you use other things like BigQuery and Stripe, and these other ones, and all these other different things. I was trying to think of something clever. We always talk about stuff like serverless first or static first or whatever. I was thinking that your approach was very much so like third-party first, but then after talking to you about it, it's more about optimizing for maintainability than it is just using some third-party service. What is that that you do, especially at Branch, to optimize for maintainability?Joe: We think about optimizing for maintainability having two central categories. The first is the less you have to maintain, the easier it is to maintain and so in that bucket goes things like a code is a liability, so less code to maintain is easier to maintain. Or running VMs and containers and having DevOps as a core competency that you need. If you don't need it, you run serverless or you need less of it, then that's also easier to maintain. Then there's another bucket which is how do we not be blockers for all of the other departments in the company? We constantly ask this question of how do we empower other departments to go do what they need to do without talking to tech, without talking to product.Jeremy: I love that idea of empowering other departments. One of the things that I often see when I'm collecting links from my newsletter is people who write these posts that say they're using Google, for example, I'm sorry, Google Sheets as a backend database for something. Some people criticize it, but for the right application, it makes a lot of sense because then someone can actually go in as somebody who doesn't have the ability to query my SQL database or go into DynamoDB or something like that. Can go in and just manipulate some cells in a database and it gives them the ability to run some business process, which can be really, really effective.Joe: It is fantastic. One of the companies I started, which I did as a weekend project for a friend, was an angular app that sends a bunch of data to a Google Sheet for all these calculations. Since I built that in 2015, 99% of the business logic of that application has been the main founder on that project making changes in Google Sheets. He onboards a new customer. He sets up their logic in Google Sheets and it does everything that they need to do.Jeremy: Which is amazing. Then there's so many other applications

About Mark NunnikhovenMark Nunnikhoven explores the impact of technology on individuals, organizations, and communities through the lens of privacy and security. Asking the question, "How can we better protect our information?" Mark studies the world of cybercrime to better understand the risks and threats to our digital world. As the Vice President of Cloud Research at Trend Micro, a long time Amazon Web Services Advanced Technology Partner and provider of security tools for the AWS Cloud, Mark uses that knowledge to help organizations around the world modernize their security practices by taking advantage of the power of the AWS Cloud. With a strong focus on automation, he helps bridge the gap between DevOps and traditional security through his writing, speaking, teaching, and by engaging with the AWS community.Twitter: https://twitter.com/markncaPersonal website: https://markn.ca/Trend Micro website: https://www.trendmicro.com/Watch this episode on YouTube: https://youtu.be/QXZT-DQwGk0Transcript:Jeremy: Yeah. So you mentioned two separate things. You mentioned compliance and you mentioned sort of legality or the legal aspect of things. So let's start with compliance for a second. So you mentioned PCI, but there are other compliances there's SOC 2 and ISO 9001 and 27001 and things like that. All things that I only know briefly, but they're not really legal standards. Right? They're more of this idea of certifications. And some of them aren't even really certifications. They're more just like saying here, we're saying we follow all these rules. So there's a whole bunch of them. And again, I think what, ISO 27018 is about personal data protection and some of these things, and their rules that they follow. So I think these are really good standards to have and to be in place. So what do we get... Because you said, you have to make sure that your underlying infrastructure, has the compliance that's required. So what types of compliance are we getting with the services from AWS and Google and Azure and that sort of stuff?Mark: Yeah. So there's two ways to look at compliance... Well, there's three ways. Compliance you can look at as an easy way to go to sleep if you're having troubles, just read any one of those documents in you're out like a light. And then the other two ways to look at it are, a way of verifying the shared responsibility model, and then a way of doing business in certain areas. So we'll tackle the first one because it's easiest. So us as builders, building on GCP or Azure or AWS or any of the clouds, and they all have in their trust centers or in their shared responsibility page, they will show you in their compliance center, all the logos of the compliance frameworks that they adhere to. And what that means is that the compliance organization has said, you need to do the following things. You need to encrypt data at rest or encrypt data in transit.You need to follow the principle of least privilege. You need to reduce your support infrastructure like here are all the good things you need to do. And what the certifications from the cloud providers mean, is that they've had an audit firm. So one of the big five, Ernst & Young or Deloitte, come in and audit how they run the service. So Azure saying that, Hey, we are PCI compliant for virtual machines means that they are meeting all the requirements that PCI has laid out to properly secure their infrastructure. So that as a builder means that we know they are doing certain things in the background because we're never going to get a tour. We're never going to get the inside scoop of how they do updates and they do patching. And frankly, we shouldn't care. That's the advantage of the cloud. Right?Is like, it's your problem, not mine, that's what I'm paying you for. So compliance lets us verify that they're holding up their end of the bargain. So that's a huge win for everybody building in the cloud, whether or not you understand the mountain of compliance frameworks, the big ones are basically PCI, 27001 from ISO is basically just general IT security. We don't set our passwords to password, that kind of stuff it's basic hygiene. And then the SOC stuff is around running efficient data centers. Right? So it's like we don't let Joe wander in from the street and pull plugs. We have a process for that kind of stuff so great there. And the others are, if you're in a specific line of business. So if you're in the United States and you're doing business with the government, you need a cloud provider that is FedRAMP certified. Right?Because that is the government has said, if you want to do business with us, here's the standard you need to meet. Therefore, FedRAMP is this thing that vendors and service providers can adhere to, which means they meet the government's requirements to do that. And most of these are set up like that. So even PCI is a combination of the big credit card processors. They've formed this third party organization that said, anybo

About Mark NunnikhovenMark Nunnikhoven explores the impact of technology on individuals, organizations, and communities through the lens of privacy and security. Asking the question, "How can we better protect our information?" Mark studies the world of cybercrime to better understand the risks and threats to our digital world. As the Vice President of Cloud Research at Trend Micro, a long time Amazon Web Services Advanced Technology Partner and provider of security tools for the AWS Cloud, Mark uses that knowledge to help organizations around the world modernize their security practices by taking advantage of the power of the AWS Cloud. With a strong focus on automation, he helps bridge the gap between DevOps and traditional security through his writing, speaking, teaching, and by engaging with the AWS community.Twitter: https://twitter.com/markncaPersonal website: https://markn.ca/Trend Micro website: https://www.trendmicro.com/Watch this episode on YouTube: https://youtu.be/aPg7WE3Q3SQTranscript:Jeremy: Hi, everyone. I'm Jeremy Daly, and this is Serverless Chats. Today I am speaking with Mark Nunnikhoven. Hey, Mark. Thanks for joining me.Mark: Thanks for having me, Jeremy.Jeremy: So you are the vice president of cloud research at Trend Micro. So why don't you tell listeners a little bit about your background and what Trend Micro is all about?Mark: Yeah, so Trend Micro is a global cybersecurity provider. We make products for consumers all the way through to massive enterprises. And I focus in our research wing. So we have a really large research component. There's about 1400 researchers in the company, which is a lot of fun, because we get to dive into the minutia of anything and everything related to cybersecurity, so from the latest cybercrime scam to where I focus, which is in the cloud. So a lot more what I'm looking at is how organizations are adapting to the new reality of things like the shared responsibility model, keeping pace with cloud service providers, adjusting to DevOps philosophies, that kind of thing, which is a lot of fun.And for me, I come from a very traditional security background, if there is such a thing. I've been at Trend for a little over eight years. Before that, I was with the Canadian federal government for a decade, doing all sorts of different security work, a lot of nation state attacks and defense, things like that. And my background in education is actually in forensic investigation, so that nerd in the lab on your favorite crime drama when they come up with the burned-out hard drives and are like, "Fix this," and somehow they do, it's all BS, but that's technically what I do.Jeremy: Very cool. All right. So I have wanted you on the show for a very long time, because I've been following the stuff that you've been doing. I love the videos that you do, the blogs that you write. You're just out there. And I know you're on the edge of the serverless space, I know you do a lot of stuff in the cloud as well, but you're obviously into serverless as well. And just recently I came across this impact assessment video series that you're doing. I don't know if it's a regular series or whatever, but it was really good. And you were talking about Fortnite and Apple, and I want to get into that. But really what made me think about things a little bit deeper that goes beyond just some of these surface-level billionaires arguing with billionaires is this idea of privacy and how important are online privacy is. And I thought it'd be really interesting to talk about how serverless and privacy, since it's in the cloud, is all the stuff that you're sharing, where that kind of aligns. So let's start. First of all, why is privacy or online privacy so important?Mark: Yeah. That's a really broad and great question. So yeah, this new video series I'm doing, Impact Assessment, is going to be regular. I was doing a livestream called "Mornings with Mark" for the last few years, did, I think, like 200 episodes where it was mainly talking about cybersecurity issues of the day, and a lot of those are privacy. And where I wanted to go with this new series was just a little broader audience, which is why Apple and Fortnite and Twitter hack and stuff like that are coming up, because I think privacy is a really important aspect, and it mirrors security. You can't have one without the other. And it's directly related to the audience, to people who are building in a serverless space or in any space.But privacy, a traditional definition of privacy is really your right as a person to not be observed, essentially to be alone and to have control over your data and your well-being. And when you go into the digital world, it's infinitely more complicated than a physical world, right? You can lock yourself away in a room in the real world and be relatively confident that nobody is invading that space, that you have kind of control over that space, so if you want to just sit there and veg out, if you want to read a b

About Xavier LefèvreXavier Lefevre is currently VP of Engineering at Theodo, a web development and product consulting agency. As part of his role, Xavier manages five technical teams and leads the development of the company’s serverless expertise. He believes that serverless is a major breakthrough that will allow the industry to redirect its focus on core business needs, and his specialization centers on serverless and problematic FinOps architectures. Xavier shares his expertise through articles such as with Serverless Transformation on Medium, and various speaking events, including Virtual Serverless London meetup.Twitter: https://twitter.com/xavi_lefevreLinkedIn: https://www.linkedin.com/in/lefevrexavier/Medium Blog: https://medium.com/@xavierlefevreWhat a typical 100% Serverless Architecture looks like in AWS!Serverless Cost CalculatorWatch this episode on YouTube: https://youtu.be/pKc2f8Q0PQITranscript:Jeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today I am chatting with Xavier Lefevre, who I am going to have re-pronounce his name afterwards. Hey Xavier, thanks for joining me.Xavier: Thank you. Thank you for having me. My name is Xavier Lefevre in French, which is not very easy to say.Jeremy: So you are the VP of engineering at Theodo. I'd love it if you can tell the listeners a little bit about your background and what you do at Theodo.Xavier: Yes, so I'm going to start with Theodo. Theodo is a product consulting and development agency, so we work with clients of any sizes, companies of any sizes, to build websites and complete web applications for them for different kinds of use cases. So, it can be a big company, it can be a small company, it can be eCommerce, it can be a big industry, anything. We are in France, UK and U.S.A., London and New York to be exact. And we're doing several different types of web ports, so we do mobile, we do infrastructure, that's something that could be interesting, like Kubernetes a lot, and stuff like that, so that's Theodo.And for me, so I'm a VP engineering of Theodo in France, at Paris. And I have a fun background. So, I went to business school when I was younger and I did business school, but I always wanted to work in tech and when I got out I started to work in tech, but as a business role. I realized what it meant to work in tech and the different roles. And I finally realized that I preferred to be in tech myself, so that's why I'm here today.Jeremy: Awesome. So, you are a bit infamous now, you have this article that you wrote called, the Typical Serverless Architecture, which got a lot of praise and also got a lot of criticism from people who don't quite understand serverless architecture. So, I would love it, just to go through ... and we'll start with this, there's other things I want to get to, but let's start with that, let's start with this typical serverless architecture. Take us back, what does that look like?Xavier: So, from experience, and I don't have ... I have a year of experience in serverless, so I'm still, compared to you, I'm still young. But from experience, I started to of course dig into serverless and understand a little bit everything that's included in the technology. And I wanted to show this big picture and this big idea of what the typical architecture is. So, what can you find inside? You can find ... So, we go through each box. Okay? I can talk about the origin as well, which can be interesting. Which one do you prefer first?Jeremy: Well, so I have them listed here, so let's start with the front end, what does the front end look like in a serverless application?Xavier: So let's do that. So, front end itself, your front end is going to be a FGA, for instance, like Drax, it can be Next for instance, with SSR. What you can find there are two things that are specific to servers, the first is AWS Amplify, which does a lot of stuff, but among which you can find many components in there that help you work faster. And you can find STKs that help you communicate more easily and find pre-made features with AWS services, like Cognito for instance. You can authorize your users and handle your users directly from your front end thanks to AWS Amplify, so that's one piece you can find. The other one is ... if I go a little bit further, when you host your front end. So, you have two steps, first the basic one, if it's a static React you just have to host static files with your JS that's going to be loaded on your product and that's going to run, we know how it works.So, there you're going to use F3, it's going to be exposed by your CloudFront, and that's it. If you want to go further, which happens a lot lately, even more because it's partial, if you want to go into SSR or SSG or a bit both, that you can do with Next for instance. Here you can use ... you can take for instance Lambda at Edge, which are Lambdas that are inside of CloudFront, that run close to the users, that are super, super, super fast and that can take care o

About Alex CasalboniAlex Casalboni has been building web products and helping other builders learn from his experience since 2011. He’s currently a Senior Technical Evangelist at Amazon Web Services, based in Italy, and as part of his role, often speaks at technical conferences across the world, supports developer communities and helps them build applications in the cloud. Alex has been contributing to open-source projects such as AWS Lambda Power Tuning, and co-organizes the serverless meetup in Milan, as well as ServerlessDays Milan (previously JeffConf). He is particularly interested in serverless architectures, ML, and data analytics.Twitter: https://twitter.com/alex_casalboniLinkedIn: https://www.linkedin.com/in/alexcasalboni/ Website: https://alexcasalboni.com/Dev.to: https://dev.to/alexcasalboniMedium: https://medium.com/@alexcasalboni AWS Lambda Power Tuning Project: https://github.com/alexcasalboni/aws-lambda-power-tuningDeep dive: finding the optimal resources allocation for your Lambda functions: https://dev.to/aws/deep-dive-finding-the-optimal-resources-allocation-for-your-lambda-functions-35a6 Test Functions/Patterns for Power Tuner: https://gist.github.com/alexcasalboni/9ce2cef56a7d052d4f5e798b37083525Watch this episode on YouTube: https://youtu.be/m2NB_0J5fmsTranscriptJeremy: if we go back to the sort of the having to run this on every function, and you maybe make a change to a function, you do something like that, it just becomes very, very tedious, and probably a lot of work to run this on every single function. But as you start to see... You run it on a few functions, maybe different types of workloads, those patterns start to emerge, right?Alex: Absolutely. There is not an infinite set of patterns. I have identified about six or seven. Usually, you end up in some of these. There are other patterns where the output is a bit randomic meaning there is either some downstream dependency that is not scaling as well as Lambda is. So you might see some noise in the data. But yeah, usually you end up in one of these categories. I think there is a last category that is a bit spatial where you actually are downloading or uploading a lot of data. I've seen this with S3 maybe you need to download 50 or 100 megabytes of data from S3. I wouldn't recommend you. But if you really have to do that the power tuning implications are very interesting, in my opinion, because if you also change one line of code, and I did this experiment with Python. So, it was pretty easy. I think you can do also the same with Node or Java or other SDKs.So, if you enable the multi threading options in the SDK especially at a high power like above 1.8 gigabytes you get two cores. And so, you just start downloading or uploading using 10 or 20 threads, you actually see a massive difference there. So, you might see 10% improvement for cheaper cost. So, if that's what you're doing with Lambda, you might consider full power. But again, check the numbers.Jeremy: Right. And the other thing too is, again, knowing... You mentioned Python, knowing your runtime is important because node is single threaded. So, even if you do go over the 1.8, you do not get a second core because Node doesn't work that way. All right. So, you mentioned something really interesting. I think this is another fascinating thing about pay per use services is Lambda has a 100 millisecond billing model. So, if you run something for 99 milliseconds you pay for 100 milliseconds. If you run something for 101 milliseconds you pay for 200 milliseconds. So, I think an important piece of this, if you are trying to optimize for cost, is also understanding that billing rounding thing, right?Alex: Yeah, that's true. I've been talking to some development teams. And it's very common that you develop a service application, and you end up as you were saying with 10, or 50, or 100 functions. And one day the manager wakes up and wants to optimize for cost or for performance. And you're like, sure, but where do I start? I have 100 functions. But I think it's also important to know what your functions are doing to detect the right pattern and to know where it makes sense to optimize. There are cases where your team or yourself or your manager may want to only optimize for cost. It's a cost optimization project, whatsoever.And you might end up optimizing some functions where there is no way that you can actually shave off enough milliseconds to go down one level, 100 millisecond level. So, maybe you're just optimizing for the user experience, which is great. Or maybe it's not a customer facing app, so it doesn't matter. But I think it makes sense to understand how cost and performance are related in serverless. Because sometimes they are aligned to each other, meaning you can optimize for both just in one shot. But you still want to be aware, especially if it's about prioritizing between a large set of functions. Actually, I got that feedback a lot. I think if I see a direction of Lam

About Alex CasalboniAlex Casalboni has been building web products and helping other builders learn from his experience since 2011. He’s currently a Senior Technical Evangelist at Amazon Web Services, based in Italy, and as part of his role, often speaks at technical conferences across the world, supports developer communities and helps them build applications in the cloud. Alex has been contributing to open-source projects such as AWS Lambda Power Tuning, and co-organizes the serverless meetup in Milan, as well as ServerlessDays Milan (previously JeffConf). He is particularly interested in serverless architectures, ML, and data analytics.Twitter: https://twitter.com/alex_casalboniLinkedIn: https://www.linkedin.com/in/alexcasalboni/ Website: https://alexcasalboni.com/Dev.to: https://dev.to/alexcasalboniMedium: https://medium.com/@alexcasalboni AWS Lambda Power Tuning Project: https://github.com/alexcasalboni/aws-lambda-power-tuningDeep dive: finding the optimal resources allocation for your Lambda functions: https://dev.to/aws/deep-dive-finding-the-optimal-resources-allocation-for-your-lambda-functions-35a6 Test Functions/Patterns for Power Tuner: https://gist.github.com/alexcasalboni/9ce2cef56a7d052d4f5e798b37083525Watch this episode on YouTube: https://youtu.be/31LHFQ1lT78TranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm chatting with Alex Casalboni. Hey, Alex, thanks for joining me.Alex: Hi, Jeremy. Thanks for having me.Jeremy: So, you are a senior developer advocate at AWS. So, why don't you tell the listeners a little bit about your background, and what you do as a senior developer advocate?Alex: Sure. So, I come from the web development, software engineering, and also startup world. And I combine that and I try to help customers using AWS, discovering all the different services and I used to travel the world. Now I do a lot of virtual conferences.Jeremy: So, as a DA, I know you've been working a lot with serverless. And one of the things that you publish a lot about, you got an open source project that we'll get into about this. But you do a lot with optimizing and tuning the performance of Lambda functions. And I think a lot of people sort of assume that all of this stuff is done for you maybe that it's just a matter of putting your code up there, and it just automatically does what you need it to do. Now, if you look at some of the surveys and look at some of the research data that shows that people just typically use the defaults, I think that people do assume that quite a bit. But there are ways to optimize your Lambda functions. So, what are some of the sort of main things that we have control over when it comes to optimizing Lambda functions?Alex: Sure. So, there is a lot that the Lambda team, and actually the AWS team is doing to optimize the service itself for performance, to make it faster, to make it more reliable, to make it cheaper, eventually. But of course, it's a service and you can configure it. And with every configuration, you can fine-tune it for your specific use case, right? So, whether you are developing a RESTful API, or an asynchronous service for ETL. Whatever you're building, you might have very different needs in terms of performance or you may, you need to bring the cost to as minimal as possible. So, there are many things you can do. And maybe we'll talk about some of those. I got very passionate about this topic because I keep meeting a lot of developers that are just mind-blown when I tell them about the power-tuning side of things, and how they can actually get a lot more performance, and sometimes even a lot less cost. They can make their functions cheaper just by tuning the memory of their Lambda functions. So, that's what I'm really passionate about.Jeremy: Yeah, so I mean, and if you think about building any type of application, I mean, obviously, there's a couple of major components to it. I mean, you have to think about latency. You need to think about throughput, especially if you're transferring large files back and forth from S3. And you have to think about cost, right? Cost is always sort of an important factor. So, what are some of the things, maybe we start there. What are some of those things? Do you have control over those three factors? Are there ways besides just the memory manipulation that you can really focus in on those?Alex: Well, when it comes to the speed itself, the execution time itself, you actually do have control, and there are many things you can do to speed up the average execution. We can talk about cold starts or the large majority of your execution as well when it comes to Lambda. There is also a lot you can do to optimize for throughput. Usually, it's something you do at the architectural level. It's not just like a configuration parameter where you increase throughput. There are services like that. Like, I don't know, Kinesis Streams where you have some configuration that allows you to have more th

About Austen CollinsAusten Collins is the founder and CEO of Serverless, Inc. Austin is an entrepreneur and software engineer located in Oakland, CA. His specific focus is on building cheap, scalable Node.js applications while minimizing DevOps requirements as much as possible. An enthusiastic AWS Lambda user from day one, Austen founded the Serverless Framework (formerly JAWS), an open source project and module ecosystem to help everyone build applications exclusively on Lambda, without the hassle and costs required by servers. Serverless, Inc.: https://www.serverless.com/Twitter: https://twitter.com/austencollinsTranscriptJeremy: Yeah. And I mean, I think that was one of the things that I thought was amazing about how you took the approach to the community, because it was very much so a community driven project. And I think that helped to have AWS who is also very much so like what do they call it? The leisure paths or whatever it is when you basically create paths in a college campus by letting people walk and then you pave over the dirt or whatever it is. I can't remember the name of it, but anyways, that idea of letting people sort of decide where it's going to go and how it's going to develop. And I always remember there being a delay, because there had to be between the framework supporting something new that AWS just came out with.And whether that be and again, I'll use a bad example, but like maybe it's a new event that it supports. And I remember every time that came out that there was always it seemed like there was a lot of debate, a lot of pull requests and conversations about how to abstract that piece of it and fit it into the existing framework. Right. And so you developed this entire plugins community around the framework too, which was really great because that was the other thing. And that has been one of the things that I've had challenges when I work with SAM is that you don't have the ability to build plugins. So you essentially have to write a separate Lambda function that just does a module or whatever they call it there that allows you to do something, a custom resource.But with the framework, you just had that ability to write that, to do things that you to do, to extend it, to fill gaps that you may have had during a certain amount of time until the framework supported it. But I always appreciated that more so after the fact, sometimes I was a little frustrated that there wasn't support right away. But after the fact to say, I liked the fact that you took the time to think it through because abstractions are the hardest thing to build and when you do it wrong and then you're married to it forever you know what I mean? It's really hard to change that. So that was one of the things I always liked was that it was the framework doesn't support this yet, but build a plugin and it can, and then you can always deprecate the plugin and then accept whatever the valid way is or I guess the established way that the framework does it.So I just thought that was a really good approach. And I think really helped with all these people contributing because then also you saw plugins that came up and you're like, we should support that in the framework.Austen: Yeah, absolutely. I'm glad that you brought that up. That was something that I think on one end the hallmark of like a great developer tool often is how extensible it is. Right. But a lot of this just came out of the fact that I started as one person and I couldn't take on this massive project, just being one person in the early days. And those people who've had, like things go viral on Hacker News. I think they have probably been through a similar experience where one day this project is just blowing up, but the next day, the hangover sets in, when you look at the issues in GitHub. And people say this project does not support my use case, this does not support my workflow.This does not support my organization's policies. And then on top of that, the ambitious goal of trying to abstract almost essentially it's just so many AWS services. It was like, okay, how is this ever going to work? And that's where plugins came from largely, and you're right, you honed right into it. People can actually just overwrite any part of the framework, extend it, and it's up to them to figure out what the right patterns are. And once we see those emerge, then we'll just merge that into the framework. So it was a lot of outsourcing product development to some extent, but all goes back to just the fact that we didn't have the resources to do all that in the early days and it's great. That's where creativity comes from a lot of the time. It's just limitations.Jeremy: Actually. It's funny you mentioned limitations because that's the other thing... This has been an ongoing theme with serverless too, is that you do have to work around some of these limitations, but sometimes that's not a bad thing, right? Sometimes when you have constraints, you can build something bet

About Austen CollinsAusten Collins is the founder and CEO of Serverless, Inc. Austin is an entrepreneur and software engineer located in Oakland, CA. His specific focus is on building cheap, scalable Node.js applications while minimizing DevOps requirements as much as possible. An enthusiastic AWS Lambda user from day one, Austen founded the Serverless Framework (formerly JAWS), an open source project and module ecosystem to help everyone build applications exclusively on Lambda, without the hassle and costs required by servers. Serverless, Inc.: https://www.serverless.com/Twitter: https://twitter.com/austencollinsTranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Austen Collins. Hey Austen, thanks for joining me.Austen: Thanks for having me, Jeremy.Jeremy: So you are the CEO and founder of Serverless Inc. The creators of the Serverless Framework. So I'd love it if you could give me a little bit of your background and just in case somebody doesn't know what Serverless Inc is all about.Austen: Yeah, sure. Quick background on us, we make the Serverless Framework which is an application framework that makes it really easy to build applications on serverless cloud infrastructure. That is infrastructure that's auto-scaling. You never have to pay when it's idle and scales pretty massively. And the goal is to help developers deliver software that has radically low overhead and all of these serverless qualities at the application level as a whole.So that's our goal. We make Serverless Framework, that's what we kicked off with. And I was excited to chat with you because I was thinking it might be interesting not to do just such a technical conversation, which I'm sure you've done a handful of already. But maybe talk about the history of Serverless Framework a little bit, because the project is now five years old. I think this is my fifth year of serverless development, which is crazy to think about, because it feels like we're so early in this journey in general. But I was thinking you might be interesting to talk about kind of the history of like how things got started, how we got started and our perspective of just like kicking off the serverless movement and kind of, we know what that looked like in the early days and the crazy days where we didn't... I don't think anyone knew how big of a deal this was potentially going to be, or that this would have become a big category for cloud or maybe even the cloud itself.And when you reached out to me to do this podcast, I thought this might be a great opportunity just to kind of tell that story, at least from our perspective, my perspective. Because I think it's a fascinating one, not just for technical people, but for makers and entrepreneurs, anyone who's trying to get something off the ground. I think there's just a lot of interesting lessons learned along the way.Jeremy: Yeah. No, I think that is something that is really, really important for anybody in the serverless space. And I think anybody who's developing cloud applications today is to look back and see, I mean, where we were five years ago. Because it has dramatically changed in terms of the technology that we have available to us, the building blocks that we have available to us. And also I think, JAWS as it was originally, and we'll get into some of that, the original Serverless Framework, what that was able to do compared to what it can do now, but also compared to what's available now and just the massive explosion of development tools and observability tools and everything else that has kicked off. Open source projects beyond the framework that have kicked off that really have built this amazing community. So let's start there. Let's go way back to the beginning, like this we're talking 2014, right. Lambda is still in preview and then what happened?Austen: Yeah, Okay. Going way back, a lot of the credit first goes out to the Lambda team, the visionaries over there who kind of basically disrupted how they do compute over at AWS. Which I've heard a lot about that story. I listened recently to your podcast with Tim Wagner, kind of talking about the early days of that, but really like a lot of what we're doing here with Serverless Framework and building out our developer tool suite is just kind of standing on the shoulders of the effort that those people did, which I'm sure was hard figuring out what that looks like inside of an organization as big as Amazon. And so our story really I'd say they did a lot of the hard stuff and a lot of the really meaningful stuff and kind of my story starts right out when they did that announcement at re:Invent 2014. Yeah. When it was in preview.Austen: And I was looking around at everybody else and there was definitely some excitement and I was just personally so enthusiastic. There's something, it just hit a note in me that still is driving me to this day and inspiring me to this day to build great developer tools and reall

About Holly MesrobianHolly Mesrobian is a Board Member at Cascade Public and the Director of Engineering for AWS Lambda. Holly has 25 years of experience in designing, building, and managing globally distributed teams in software development, and more than 15 years as a leader of leaders. She has in-depth experience with building services for builders, and for wireless and broadband carriers; online services for direct to consumer offerings; and commercial shrink-wrapped software. With a double Master’s Degree in Computer and Science and Software Engineering, Holly began her career as a developer before holding leadership positions at companies, like Amazon and RealNetworks, and startup Cozi.LinkedIn: https://www.linkedin.com/in/holly-mesrobian-a1b710/Under the Hood of AWS Lambda 2019: https://www.youtube.com/watch?v=xmacMfbrG28Under the Hood of AWS Lambda 2018: https://www.youtube.com/watch?v=QdzV04T_kecWatch this episode on YouTube: https://youtu.be/nBYUh7CVUiQTranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm chatting with Holly Mesorbian. Hey Holly. Thanks for joining me.Holly: Hi, thank you for inviting me.Jeremy: You are the director of engineering for AWS Lambda at Amazon Web Services. Why don't you tell the listeners a bit about your background and what the director of engineering for AWS Lambda does?Holly: Absolutely. Engineering leaders in Amazon are very technical and I think I fit in that class of leader. I've been in engineering for more than 25 years. The first decade that I was in, I was actually an engineer, and then the last 15 years or so, I've been leading large-scale engineering organizations that are also responsible for 24/7 operations. You think about those, they're called DevOps organizations. That's what I've been doing for quite a while now. The Lambda engineering organization is just like that. In terms of my background and how did I get here?I have two graduate degrees, computer science and software engineering, and as I referenced lots of time, designing and building systems. One of the things that's really great about AWS and leading the teams here, I reference that DevOps culture. My teams, they build it, they run it and they have really great best practices around engineering excellence and operational efficiency. If we have an issue in one of our production environments, my teams are on it, and we have great processes around how we do that. We have a really well established COE.Anytime there's a customer-impacting issue that happens in one of our production environments, my team's right. COE, which it means correction of errors, we review it as an engineering team every week. I sit down with my teams, we go through operational dashboards, we inspect our metrics. We look at how we're doing across the availability latency scale. We have ongoing scaling targets and scale testing. We're constantly inspecting how are we running the service? Not just how we're building it and how we're building new features, but how we're running it.We run game days as well, so that we try to break our systems and then see that my team, all my on-calls can recover those systems. One of the things that I really like is we put new people in the team on those game days, because where better for them to learn than we've intentionally broken the system. Get in there and figure out if you can fix it before it's actually fixing something in production. That's really great about Amazon.Then I would say the other great thing about Amazon and Amazon engineering and the teams that I have, I just love what a high caliber they are and how invested the members of the team are, and how hard they will work to try to make the best service for our customers.Jeremy: Awesome. Well, listen, I am a huge fan of AWS Lambda and I love what you do. I love what your team is doing. Everything that Amazon is doing for serverless is just amazing. One of the things though that I'd love to talk to you about today, and we could get into the specifics of Lambda itself and how everything works, but you have a couple of great talks. You and Marc Brooker did these talks at re:Invent in 2018 and 2019, getting into the details of Lambda, Lambda Under the Hood, right? Great talks`.If anybody wants to know exactly how Lambda functions work and how all that stuff works under the hood, definitely go check those out. I will put those in the show notes. What I'd really like to talk to you about today is just this idea of serverless adoption or serverless transformation, because I know AWS talks a lot about how all their internal tools are going serverless, right? Which is pretty cool. Of course there's the external stuff too. There's a lot of adoption from enterprises and small businesses and medium-sized businesses and things like that.I would love to know the mindset internally. How does AWS take serverless or look at serverless and look at Lambda and use that to build their internal processes? What's t

About Raymond CamdenRaymond Camden is Lead Developer Evangelist at HERE Technologies. He’s an expert in web standards, Node, and serverless with a passion for teaching others. He has written about, and presented on, technologies for the past fifteen years, and enjoys helping others become passionate about the web as well. Ray is a prolific writer, as evident from his blog content as well as in industry publications. He has authored (and contributed to) multiple books over the years, such as his book Developing Serverless Applications, and speaks at conferences around the world. Twitter: twitter.com/raymondcamdenBlog: www.raymondcamden.com/HERE Technologies: www.here.com/Watch this episode on YouTube: https://youtu.be/2I3nNsU6HSsTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm chatting with Raymond Camden. Hey, Ray. Thanks for joining me.Ray: Thank you for having me.Jeremy: So, you are a Lead Developer Evangelist at HERE Technologies. Why don't you tell the listeners a little bit about your background and what HERE Technologies does?Ray: Sure. I'll start with HERE. So, we do everything involving location. So, we have a mapping platform. We have APIs for routing, geocoding, reverse geocoding, anything that a developer may need in regards to location or mapping we have technologies and tools for. People are free to reach out to me later to talk to me about it.Jeremy: Awesome. And your background?Ray: Let's see. I've been in web development since '93 or so. So, I've been around for a while. I spent a long time doing back end work. Last decade or so, more front end work. I've been involved in developer relations unofficially for most of that time, because I like to share, I like to give presentations and stuff like that. Officially in DevRel for six or seven years or so.Jeremy: Awesome. All right. So, if people don't know you, if anybody was ever involved in the ColdFusion community, you are a legend in the ColdFusion community. I was looking through my old books trying to find some of the old books that you had written, I think ColdFusion MX 7. You and Ben Forta had so much material out there. I was a huge fan and always fall into stuff that you guys were doing back then. So, I'm super excited to have you on the show.What was kind of funny is I was a ColdFusion guy way, way back in the day, as well. I had a big customer, it was a college that was doing everything ColdFusion. So, I learned ColdFusion just for that customer and I actually fell in love with ColdFusion. I thought it was a great language, it was super easy to use, all kinds of features, but I eventually got away from that and I really wasn't following what you were doing anymore.Then, all of a sudden, I come around maybe two years ago and I see you're working on serverless stuff. So, I would love to get that perspective of how you went from ColdFusion to serverless.Ray: Absolutely. So, I began actually with Perl CGI scripts back in the old days where there were no real defined roles. I would do everything HTML, Photoshop work, and back end work. I discovered pretty quickly that I don't make things pretty. I enjoyed the back end work because back then, having a web page be dynamic was a big deal. I can remember at college finding some random website that would pick three tarot cards and it was random. I was amazed by that. It would take five minutes to load the images. I would sit there and just reload. So, I kind of migrated there.I got into ColdFusion because I had been doing Perl CGIs for a while, but we had a client who had a SQL Server system. I knew that Perl could talk to it, but also knew that it wouldn't be fun to write that code and just randomly discovered that ColdFusion supposedly made working with SQL Server and Access, et cetera, it made that easy. That was right. I kind of fell in love and spent probably a good 15 years doing just ColdFusion stuff.Jeremy: Yeah. No. I mean, it's funny because I have, I think, pretty much the same exact background. I started in college with Perl and CGI. Then, I went to PHP and MySQL and sort of that stuff, but then moved over to ColdFusion. I spent many, many, many years with ColdFusion until I moved back to PHP.So, when you got to the end of that ColdFusion era, what was the next step after you sort of were done with ColdFusion?Ray: So, I remember when JavaScript came in, but it quickly became hard to use. You know the whole browser war type thing?Jeremy: Yeah.Ray: So, not only with me not being able to design well, the other reason I didn't like doing the front end work because it was such a pain to make everything compatible with IE4 and Netscape 4, et cetera, so working on the back end, somebody would just hand me HTML and I'd make it dynamic.What got me kind of looking back is I remember I was bored at work. Ajax had been around. Gmail, I think, had just come out, so the whole Web 2.0 thing was fresh in people's minds. I had only done a tiny bit of JavaScrip

About Paul Chin, Jr.Paul Chin Jr. works in Developer Relations at Begin, a tool that helps everyone build apps fast with cloud native services and open source tools. He previously worked as a Cloud Solutions Architect at Cloudreach, and is passionate about open source, serverless architecture, and making technology more accessible for everyone. Paul’s a lifetime resident of Virginia Beach, VA, and has a special place in his heart for Nicolas Cage, who tends to make an appearance in his presentations and projects. Feel free to talk to him about anything related to tech, food, or business.Twitter: twitter.com/paulchinjr757 Dev Group: meetup.com/757dev/Begin: begin.comBegin Training Resources: learn.begin.comArchitect framework: arc.codesWatch this episode on YouTube: https://youtu.be/L8DkEqgVEBYTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Paul Chin Jr. Hey, Paul, thanks for joining me.Paul: Hey, Jeremy. Thank you so much. I'm really excited.Jeremy: So you are, or you do Developer Relations at Begin. So I'd love it if you could tell the listeners a little bit about your background and what Begin does.Paul: Sure. Well, my name is Paul Chin Jr. At Begin, we are a service to make deploying serverless applications just super simple. Really straightforward. We give the developers everything they need from local development all the way through the CI/CD pipeline, and then we put their app onto live AWS Infra. For Developer Relations, my job is to help developers understand this technology, onboard them and get good feedback from them so we can make the service even better.Jeremy: Now, I noticed you have a sloth hiding behind you. Is that-Paul: Oh, yeah.Jeremy: ... something that basically says, "This is how it used to be. And now serverless is so much faster."?Paul: Yeah. I feel like sometimes we've got to give ourselves permission to slow down a little bit. It's a reminder that says, "It's going to be okay." And even if I step away, it's going to be okay.Jeremy: Perfect.Paul: Yeah.Jeremy: Well, so I'd love to talk to you about Begin. And I want to get into a whole bunch of things with that. But maybe we can begin, I'm sorry, that was a really bad joke. But maybe we can begin by just talking about your path into technology. Because I know it's a little bit non traditional. And this is one of those themes I think, that we see a lot with serverless, is a lot of people from non traditional backgrounds go into serverless. So what was your path like and then how did that lead you into serverless?Paul: Oh, man. This question is always great and I love sharing the story because it's a good example of just where technology has taken us now. I don't have a CS degree. And I was never doing anything remotely technical. I was just always a big business nerd. And I've had several businesses in the past. And then one day I decided, "I should learn how the software stuff works. I use the internet a lot. So I should figure out how it works. Because it's going to help me, no matter what I do."And so I decided to undertake, like, "I'm going to learn how to program in JavaScript and make web applications and do all that stuff." And so I started that and I had a wonderful local community of developers that took me in and mentored me. And from there, I just wanted to find the fastest, quickest, easiest way to build a form or to build a CRUD app. And that always led me to cloud native services. I didn't know it at the time, but not setting up my tooling and not setting up a server, all these things that I would read about, I was like," I don't want to do any of this." And now I'd find a new service. And it would just do it for me. And I was like, "Great, I'll just use this." And they always had a free tier and they were always easy to sign up, you just give them an email or a GitHub or something.And then that's how I continued on this path of, quote, now "cloud native development" to use all the buzzwords. And it was just a very organic thing for me to continue to learn and build and put stuff out. Because none of the infrastructure was in my way. None of the arcana of what it is to be a web developer was in my way.Jeremy: Yeah, no, I think-Paul: So that's how I got to it.Jeremy: Yeah, no, I think that's a common story, this idea of, you look at everything you would need to do in order to build out a full on web application and you're just like, "Yeah, you know what? Maybe I'll take up gardening," or something like that, because it just seems like an easier path. But I agree, I mean, I don't have as traditional as a background or as traditional of background as a CS degree. And some of those things I actually did a split degree and random stuff. But I ran a web development company for years and years and years. And mostly, I taught myself how to program just by reading books and using the internet and things like that. And I went down the deep path of learning how servers work and

About Nica FeeNica Fee is a Serverless Developer Advocate for New Relic. She's worked with and written about serverless for the last two and a half years. She recently spoke at Deserted Island DevOps, which you might know as the tech conference that happened in Animal Crossing. She writes regularly for The New Stack.Twitter: twitter.com/ServerlessMomTwitch: twitch.tv/noctnicaTikTok: tiktok.com/@serverless_momWatch this video on YouTube: https://youtu.be/yM4q0NSFz0MAbout New RelicNew Relic One is an observability platform built to help engineers create more perfect software. From monoliths to serverless, you can instrument everything, then analyze, troubleshoot, and optimize your entire software stack. All from one place.Website: newrelic.com/LinkedIn: linkedin.com/company/new-relic-inc-Twitter: twitter.com/NewRelicTelemetry Data: newrelic.com/platform/telemetry-data-platformBlog: blog.newrelic.com/TranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm speaking with Nica Fee. Hey, Nica. Thanks for joining me.Nica: Hey. Thanks so much for having me, Jeremy. Longtime fan, so it's great to be on.Jeremy: Well, thank you. So you are a developer advocate at New Relic, and I'd love it if you could tell the listeners a bit about your background and what led you to New Relic and sort of what's new with New Relic.Nica: Sure, yeah. That's great. I was actually at New Relic back in the day. I was at New Relic as a support engineer until about 2015 I believe, and left to go and become a full-time developer and full-time coder. And my path took me back sort of... As I was sort of coding full-time and just clearing queues and writing features and fixing bugs, I really started to miss some of the community building that I'd done previously. Especially actually when I was at New Relic back in the day, I was one of the people who was starting meetups and doing that kind of community building. And so I started trying to pursue that as a job which is how I got into dev advocacy. Dev advocacy, you get to tinker and you get to play and build stuff, and you also get to try to get other people excited about it and try to show it to people.So I was doing that for Stackery, which is a serverless deployment tool, for two years, and had some success there and built some skills and really enjoyed it, and that's where I got kind of very into AWS and cloud engineering. So yeah. Now I'm back at New Relic, and it's such an interesting time to be at New Relic, and be looking at how we can go and talk to developers. Something that is interesting about being here is that everybody is talking about the time I was last here. Everybody's talking about, "Hey. There was a time when New Relic was something that lone engineers would install on one server and something would go down." They'd be like, "Well, I can see right here what the problem is." And then some exec was saying, "Hey. Let's go use this tool. It sounds great."And right now, the question is, can we get back there? Can we get back to the place where it's a tool that developers love and that they're the ones saying, "Hey. We got to use this," rather than... As are so many developer tools being something where most people know it from the CTO coming in and being like, "We're using this tool. I met this guy on the golf course. He's told me great things about it. It's got a great spec sheet. We're using it. Everybody's going to use it now," right? So the question is, can we get back there to being in that space? So that's sort of what I'm doing New Relic because I'm trying to go talk to actual engineers about what it does and how it can help them.Jeremy: Awesome. Well, I mean, one thing about New Relic is that they just released the New Relic One platform. I want to say the new, New Relic One platform, but it seems kind of hard to say new twice. But first of all-Nica: We actually do that every year. We should do New Relic but then a starburst at the side. It's new this time.Jeremy: It's even newer. Well, first of all, I want to thank New Relic because they are sponsoring this episode which is amazing, which again shows their incredible amount of support towards the community as well. So I do think that this is a great opportunity.Nica: Can I give a quick shout out on that one, actually?Jeremy: Absolutely.Nica: As a dev advocate, I am actually really actively looking for stuff that is exciting in the community that we can help support. And so, obviously, you were very high on my list. I said, "Hey. We got to do this." But I don't see everyone. I don't know everything. So if you're listening to this and you have either an open source project on observability or you're doing community events or running a podcast that maybe is a little bit less famous than this guy, get in touch with me. Hit me up on Twitter. Show me your stuff. I would love to hear about it. My situation right now is I don't know enough people to support, not that I can't do that. So yeah. I w

About Heitor LessaHeitor Lessa is a Principal Specialist Solutions Architect at Amazon Web Services. He has spent the last 10 years in a number of roles, focusing on networking, infrastructure, and development. Since joining AWS in 2013, he’s been helping organizations of all sizes and segments across EMEA to design cloud native applications as well as software development best practices.Twitter: twitter.com/heitor_lessaEmail: [email protected] Application Lens Whitepaper: d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdfWatch this episode on YouTube: https://youtu.be/bFjT3TrpbZgTranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Heitor Lessa. Hey Heitor, thanks for joining me.Heitor: Thanks for inviting me. It is a pleasure to be here.Jeremy: I'm super excited to have you here. You are a principal specialist solutions architect at Amazon Web Services. Why don't you tell the listeners what you do at Amazon Web Services and sort of what a principal specialist solutions architect does.Heitor: I know it's a long title. I guess we can just say I'm a solutions architect at AWS. My day to day is basically working with customers and enable developer teams to find the best solutions on how to either build something on AWS or migrate, let's say a microservices monolith to a microservices or optimize something that they have.But more recently, I'm also working with customers to help them build developer communities' inside. Similar to what we have at Amazon which bring in pros and stuff like that.Jeremy: Very cool. Now I know you're doing a million different things. I don't know how you're not running AWS yet. I think you're next in line, I think. But you're doing a million things there. And one of the things though that you've been working on in the past and I know you're still involved with it, is the Well-Architected Serverless Lens. And I want to get into this because this is one of those things where if you're trying to find best practices and you're reading all these blog posts and you're looking at anti-patterns and good patterns and all this kind of stuff, I think it gets really, really confusing.And your team and a bunch of other people at AWS and a bunch of the community heroes and all kinds of people got together and put together this Serverless Lens. If people are familiar with the Well-Architected Framework, which is talked about quite a bit, there's also this thing called the Well-Architected Serverless Lens. What's the difference between those two things?Heitor: Sure. So the Well-Architected started way back in 2016, even before that to be fairly honest, where customers were looking to use AWS but we have roughly 50 services back then. Compared to today we have a lot more. And basically those customers were asking, "How do I use X service versus the other service? How do I go to production with this critical application? How do I model from my on-premises applications to something more cloud native? How do I migrate?" And things like this. Or even specific questions like, "How do I set up a multi-account? How do I better protect my accounts from a security perspective or billing?"Well-Architected brings all those best practices that are agnostic from a workload perspective that typically applies to many of them, whether using serverless or containers, so usually what would work really well. But the challenge of Well-Architected as the platform evolved, we started to have more high level services like serverless or some service like AI/ML, which you have to treat them slightly different. The best practices still apply on how you set up AWS accounts, how do you do backups, how do you think about relational databases versus NoSQL databases?But when you get to things like Multi-AZ and EBS volumes for serverless, they don't quite make sense. The Lens was a project to say, what are the customers using that Well-Architected actually helped them but they still lack a lot of good practices that are very specific to the technology they chose? So serverless was one of them. IoT was also another one. And more recently, last month we also announced Analytics Lens. If you're interested in big data, AI, those pieces, Analytics covered that pretty well. That's the difference.The Lens is a... It doesn't replace, Well-Architected, it's more as an add on to the all these best practices we've been sharing for the past few years.Jeremy: Yeah, because as an add on, it makes sense. The original serverless or sorry, the original Well-Architected Framework has, I think, 47 questions or so that asked you about specific areas and there's the five pillars and we'll get into some of that because I do think it's interesting to think of it that way. But the Serverless Lens just has more questions. What's the reason for all those extra questions?Heitor: Sure. Well-Architected, when we started the Lens, if I'm not mistaken, again, there was the 47

About Paul Johnston:Paul Johnston is an interim CTO, CTO and strategist who has particular interests in serverless, cloud, startups and climate change. Formerly, Paul served as a Senior Developer Advocate at AWS for Serverless and CTO of multiple startups, including one of the world’s first serverless startups. Paul is also a co-founder of ServerlessDays.Twitter: twitter.com/PaulDJohnstonMedium: medium.com/@PaulDJohnstonProject Drawdown: drawdown.org/Roundabout Labs: roundaboutlabs.com/Leading Edge Forum: leadingedgeforum.com/White Paper: The State of Data Center Energy Use in 2018IPCC Special Report: Global Warming of 1.5 ºCBlog post: To fix Climate Change, stop being a techie and start being a humanWatch this episode on YouTube: https://youtu.be/DTpP7RGXV6gTranscriptJeremy: All right. We talked about the big three a little bit and compared them in terms of their green and stuff like that, but in that paper that you wrote, you have this cloud league table in there where you compare them. I'd love to know more, what about Alibaba and Oracle and IBM and some of these other things, where do they all stack up against one another?Paul: They aren't as big. Let's just be clear on that one. They aren't as big, and their green credentials are less clear. For example, Alibaba is very big in China for obvious reasons, it's a Chinese business and yes, they have a footprint outside of China, but they're a primarily Chinese business. When we looked and researched and were trying to find out about all of their green credentials, we found very little information whatsoever. It was almost non-existent. We found a little bit about efficiency in data centers and putting things in cold regions of China. You're like, "Well, that doesn't actually change anything if you're growing at a massive rate." It changes the conversation a little bit.Jeremy: Can you do that though? Can you pack your servers in snow? Does that help with the cooling bill?Paul: It depends on the server, I suppose. But I'd say you end up with this, not every conversation is equal. This is shown across the political spectrum as well. The conversation in China is very different to the conversation outside, in terms of industrial nations. Industrialized nations such as the U.S., UK, Australia, and Europe as well. You have very different social context. But anyway, coming back to Alibaba, we just found very little information. IBM and Oracle, actually, both had lots of information. IBM has had a commitment to renewables and sustainability for a very long time. I think since the '70s if I remember right. They have good credentials, but they don't offset their renewables in data centers or regions.Paul: I think I remember, from the top of my head, because I can't remember everything, they are renewable in the UK. I think Oracle are renewable in the UK anyway. But some of these regions, they are renewable, but not all of them. But it's not clear unless you dig into the paper and unless you dig into their information. Nobody, as far as I can tell, has a little green dot against a region that says, "This one's renewable." It would be so much easier if they did. These other organizations, none of them, apart from Google and Microsoft have really made a play for being the green advocates in the space. Amazon does, but that's a whole other conversation which I'm not going to go into at this point. But the three lower down, I think, are struggling to be able to play in the same conversation. I think they would like to be seen as green, but I don't think they are really pushing the agenda because they don't see it as a point of differentiation.Jeremy: All right. Then what does the tech industry have to do as a whole? I know you had some recommendations in your paper about this, but just what are maybe the top two or three things that the tech industry as a whole could do to address the climate crisis?Paul: The climate crisis as a whole.Jeremy: Or I guess their impact on it anyways. Let's start with that, we could build from there.Paul: I don't know anymore. I think I've gone backwards and forwards on-Jeremy: Don't give up Paul, don't give up.Paul: It's not that. It's just there are so many things. I think my biggest thing is the tech industry needs to find its activist voice. I think that would be my point. I think sitting there and going, "Oh, everything's going to get fixed by technology," is entirely the wrong approach. I think my personal view, as much as I like Tesla's technology, I don't think Tesla is going to save the world. I'm not an Elon Musk fan, I find him very difficult in a number of different ways. That's as much as I'm going to say, but I find-Jeremy: I don't think he listens to this podcast, so don't worry about it.Paul: That's fine. But I find a lot of people within tech look at techno utopianism, and let's call it that because I think that's a pretty simple way of it. That technology will save us. The more that I look and the more that I look at what is

About Paul JohnstonPaul Johnston is an interim CTO, CTO and strategist who has particular interests in serverless, cloud, startups and climate change. Formerly, Paul served as a Senior Developer Advocate at AWS for Serverless and CTO of multiple startups, including one of the world’s first serverless startups. Paul is also a co-founder of ServerlessDays.Twitter: twitter.com/PaulDJohnstonMedium: medium.com/@PaulDJohnstonProject Drawdown: drawdown.org/Roundabout Labs: roundaboutlabs.com/Leading Edge Forum: leadingedgeforum.com/White Paper: The State of Data Center Energy Use in 2018IPCC Special Report: Global Warming of 1.5 ºCBlog post: To fix Climate Change, stop being a techie and start being a human Watch this episode on YouTube: https://youtu.be/SI2-WU_0zgsTranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Paul Johnston. Hey Paul, thanks for joining me.Paul: Thank you very much for having me.Jeremy: So you are a consultant through Roundabout Labs and a research associate at the Leading Edge Forum. So why don't you tell the listeners a bit about your background and what you have been up to lately?Paul: So, yeah, background's a bit confusing. It's always a little bit strange. I don't have this whole 14 years at any one big company or anything like that. I spent many years in tech, 20 years, working with various different startups from my own business, that kind of thing. Then I worked in a startup in 2015 that effectively started using AWS Lambda.So this is where the serverless comes in. And I was one of the first companies to start using Lambda in any kind of scale in a startup as a kind of first principle. And then I went from there to using it in that startup in 20 countries. Went a bit mad, a tiny, tiny budget from AWS. And I was like, "Well, this kind of worked so I'm going to keep doing it," and started telling people. AWS took notice, gave me a job, that was quite fun. Was a senior developer advocate for serverless at AWS for a while.And then didn't stay there all that long, but it was really enjoyable while I was there. And moved away from there to go and do some consulting, which I've done since 2018. 2018? 2018. And then from there...Jeremy: What year is it again?Paul: Honestly, this year has gone on for a very long time.Jeremy: Right, right.Paul: And since then I have done some consulting in various different projects, tech projects. But one of the things I've done is worked on working out how tech and climate work and how they intersect. And one of the projects I've been working on is a research project for the Leading Edge Forum, which if any of you know Simon Wardley, that's the organization that he works for.And I've been working on a project to look at how climate change is going to affect business over the next 10 years from a tech angle very much, so from a data and a tech angle. And just trying to see what lessons we can learn and what things are going to be coming up in the future. So kind of many and varied, shall we say?Jeremy: All right. Well, listen, I have been wanting to get you on the show for a very long time, because I think this whole climate change thing is hugely important. I have two young daughters. I think about their future. I think about the junk we pour onto the earth, the pollution, the amount of carbon dioxide we're creating.And one of the things that I think really attracted me to serverless in the beginning was not just, you know, obviously not having to manage servers, which is great. But this idea that maybe by sharing tenancy on a big server and only using the compute that we needed to, I was thinking in the back of my head, I'm like, "Well, maybe that reduces the amount of energy we use."And so I know you have dug into this tremendously, and I mean, you're an expert on this stuff. And so I'd love to go through all these things with you, just get your insights, get some thoughts on this stuff. We can talk about serverless and some details of serverless as well. I'm sure that's what the listeners want to hear, but I love this idea of going green with serverless. Because I think it's hugely important. I think it's a step in the right direction.But maybe we could start and just, or start by saying, how does serverless technology compare to traditional technology or traditional servers when it comes to green computing?Paul: So it's a very, very good question. It's almost impossible to answer in some ways, but it's really, really easy to answer in others. So one of the things you want to look at, first place you want to start is, well, effectively you want a definition of what serverless computing is.Paul: So let's just kind of take function as a service is kind of the base enabling technology, shall we say, for most serverless computing. Because I think most people will kind of see serverless and they'll go, "Right. What does that mean?" And so you want to drop it down to something that is kind of tangible.So you want

About Erica WindischErica Windisch was the co-founder and CTO of IOpipe where she helped organizations maximize the benefits of serverless applications by minimizing debug time and providing correlation between business intelligence and application metrics. She is now a Principal Engineer at New Relic.As an advocate and pioneer of cloud computing since 2001, Erica is always pushing forward as technology and the industry adapt. She was an early contributor to OpenStack and maintainer of the Docker project where she worked on hardening Linux containers and establishing corporate and community security policies.Erica is a champion of AWS Lambda and serverless technologies, and she speaks frequently at conferences about AWS Lambda and other AWS solutions. She's passionate about systems architecture, security, and the future she sees for machine-automated, low-code development.Twitter: twitter.com/ewindischNew Relic: newrelic.comPersonal email: [email protected] email: [email protected] this episode on YouTube: https://youtu.be/T1t_P_zqOiETranscriptJeremy: Hi, everyone. I'm Jeremy Daly and this Serverless Chats. Today I'm joined by Erica Windisch. Hey, Erica, thanks for joining me.Erica: Hello. Hi. Thanks for having me. Or thank you for having me.Jeremy: So you are a principal engineer and architect at New Relic. And you're also an AWS Serverless Hero. So I'd love it if you could tell the listeners a bit about your background and what you've been doing at New Relic.Erica: Oh, gosh. Okay, well, my background is pretty deep. So, I'm at New Relic now. Before New Relic, I was the founder and CTO of IOpipe, which was an observability product for serverless applications. Now, I am working as an architect and principal engineer for New Relic. And if we're going to rewind history a little bit. I previously was a security engineer working at Docker, where I founded their security team and their security processes. I was involved in OpenStack from very early, since its founding. And then before that I had actually had my first company and we had built a cloud. We actually had our own cloud services. We were building from 2003 actually, building out horizontally scalable cloud services. And I said, "Well." We bought really early into that pets versus cattle idea.Jeremy: Nice, nice. Well, so obviously you're doing a lot with observability. And you're doing that in New Relic, that's sort of what New Relic does. IOpipe was all about that. I know a lot of the team has gone over from IOpipe to New Relic, to continue to work and expand their services. And I'd love to talk to you about that today. We've done a number of shows where we've talked about observability. But that was probably almost a year ago at this point. And I'd love to get a sense of sort of, where things have gone, where things are going. You know maybe what the future is going to look like. I got a bunch of other things I want to talk to you about. But maybe you could just start, just in case listeners don't know, what do we mean by observability?Erica: Oh, gosh. The way I see it is, being able to really see what's happening in your applications, in your infrastructure and doing that... I would say early monitoring. Things like Nagios was, I would not consider observability that was monitoring. It was very much, very reactive. There was zero product... It was not productive at all using something like Nagios. Logging products give you some ability to start getting into, being able to be proactive. And I think that observability kind of ties in some of the concepts from logging, and ties it in with your metrics and ties in being highly correlated. And also deeper into your application, having traces in your application, having contacts for your applications. For instance, just having a trace and knowing that, say an API gateway triggered a Lambda is one piece of information that you can have, but knowing say, the resource path, the HTTP method, things like that. That's a deeper set of insight that I think is necessary. And definitely fits within an observability picture that is very much say different and distinct from something like Nagios. Or even just plain text logs.Jeremy: Right. Yeah. And we've talked about on the show the three pillars, right? You've got monitoring, tracing and logging. And so monitoring, like you said, is that sort of general like just something goes wrong, maybe you get an alert, something like that. The logging bit is obviously logging data. But let's get more into tracing a little bit. What do we mean by tracing?Erica: Sure. The way I look at tracing as being able to see the relationship between various components, and not just the components. And I think this also where maybe tracing generally... in our industry historically, has been this service talks to this or that service. And that service talks to another service, etc. I think of it as this function communicates to this other function. And that is true, eve

About Sven Al HamadSven Al Hamad is co-founder and CEO of Webiny Serverless CMS. Sven has worked with the largest media and ecommerce customers in Europe as their trusted advisor on the topics of web performance and architecture, and has a proven track record of successful delivery of several multi-million dollar projects for large enterprises. Sven is also an experienced entrepreneur who has acted as a CTO in 4 different startups.Twitter: twitter.com/svenalhamadEmail: [email protected]: webiny.comWebiny Twitter: twitter.com/WebinyPlatformGithub: github.com/webinyWatch this episode on YouTube: https://youtu.be/9TSmOcLBr0kTranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Sven Al Hamad. Hey Sven. Thanks for joining me.Sven: Hey, Jeremy. Thanks for having me.Jeremy: So you are the CEO and co-founder of Webiny. So why don't you tell the listeners a little bit about your background and what Webiny is?Sven: Yeah. So well, in terms of my background, I'm a developer. I started maybe 20 years ago, even more coding websites and many other stuff along the way, but also worked in the enterprise world for several years and decided to start Webiny about a year and a half ago, maybe two years back. But now I'm more focused on the business side. And what Webiny is, it's essentially an open source framework for building full stack applications that deploy to serverless infrastructure like AWS Lambda and similar. So it's all about creating serverless solutions.Jeremy: Awesome. All right. So that's what I want to talk to you about obviously the Webiny platform, what you can do with it. And I'd like to start by kind of going through more of the details, right? Because I think we get confused with maybe what a CMS is versus what a application platform is versus what a cloud provider is. I mean, so I think it can get very confusing if you don't dive deep into the docks and even I was looking at the Webiny site and I was like, "All right, it's a CMS, but it also has a framework for building things." And so I'd love to go through that. And then we can talk about a couple of other things just to get your insight on serverless, but let's start at the beginning. So why did you build Webiny? What was the thing that triggered that?Sven: So I started researching the serverless market in general. That was late 2017 and the more I dived deeper into the potential of serverless and serverless infrastructure, I kind of understood that serverless has such a big potential that actually it can become the standard, how we are building all applications in the future. Essentially, if you want to build an application five years from now, you're going to build it on serverless infrastructure. Serverless is going to become that standard.And at the same time, I looked at the market, in terms of the solutions that are available today to help you do that. Well, there was nothing that I could use out of the box to help me build an application. There are tools to help you monitor and deploy serverless applications, but there are no tools to help you build actually a full stack serverless application. So I saw a big opportunity there, but also at the same time, I had a web design development agency many years back where we were all testing different CMSs and different solutions on building things. So from that learning and that experience, I decided, "Okay, let's take that. Let's take the serverless market, which is new and has great potential. Let's build a solution for that market that also is open source at the same time, so it benefits the whole ecosystem and the community as a whole."Jeremy: Yeah. And who among us, hasn't owned a web development company in the past? I know I did for about 12 years and honestly it's funny because we built a CMS. I mean, CMSs were, this was before WordPress, right? So I mean, WordPress comes along and it changes a bunch of things. But one thing that was always a pain for me, and I know we can get into this as part of what the tool offers. But it was things like building forms. If I had to build one more HTML form in my web development company, I mean, I was ready to just, I don't know, go stick my head in a closet or something like that because it was just, it's so tedious, it's so repetitive. And as one of the things I think we've done really well or we've done a good job of is we've abstracted away a lot of these things and tried to make it so that where we make the undifferentiated heavy lifting, much easier.But a big part of that, and this is something that always scared me, every time you build a new project, it's less about the interface, it's less about, maybe the backend, it's a lot about the data, right? We want to make sure that our data is secure, that our data is backed up. So I'd love to just talk about the data model that you have built into Webiny, because again, it supports a bunch of different things. But could you explain that?Sven: Yeah, so well j

About Rafal WilinskiRafal Wilinski is the founder of Dynobase, a professional GUI Client for DynamoDB with mission to onboard thousands of developers to Cloud-native and Serverless world. In addition to founding Dynobase, Rafal distributes a weekly newsletter “This Week in DynamoDB” and is a Serverless Engineer at Stedi. Prior to his current roles, Rafal got his start in developing mobile games, and is a cloud native engineer, AWS certified architect, and Serverless Framework contributor and maintainer.Twitter: twitter.com/rafalwilinskiDynobase: dynobase.dev/This Week in DynamoDB: dynobase.dev/newsletter/Watch this episode on YouTube: https://youtu.be/41YJAflfnP4TranscriptJeremy: Hi everyone! I'm Jeremy Daly, and this is Serverless Chats. Today I'm chatting with Rafal Wilinski. Hey Rafal, thanks for joining me.Rafal: Hi, thanks for having me.Jeremy: So you are the creator of Dynobase and an independent AWS consultant. Can you tell the listeners a little bit about yourself and what Dynobase is all about?Rafal: Yeah, sure. As you mentioned, I'm founder of Dynobase, professional graphical interface for DynamoDB, and also right now an independent AWS consultant, mostly focusing on serverless solutions. I'm deeply passionate about AWS and mostly serverless, since, I think, 2016, because I attended the first Serverless Conf back in London, and that's why I became so excited about this whole field. I'm running my own blog which is called Servicefull, because we had so many discussions about what serverless is and how bad a name that is for a paradigm of technology.So I decided to actually steal the term coined by Patrick Debois, which is Servicefull, because full of services. I'm writing about serverless, about cloud, and I recently merged that with my own page, but you can still go there. It's going to redirect you. Before going all in into AWS, I was actually making mobile games. I've made a few of them, one of them became even quite popular, which was called Voxel Rush. But my parents were saying that making mobile games isn't a real job, so that's why I transitioned into making web and cloud, and now I'm here. Less than a year ago, I started Dynobase, which was trying to solve my problems with UX and UI with DynamoDB, but I guess we'll talk about it a little bit later.Jeremy: Right. Yeah. And actually, that's why I want to talk to you about today is Dynobase. So you and I have been communicating for quite some time. You know I'm a huge fan of DynamoDB. I love just the scale of it. I love what you can do with it. Rick Houlihan opened up, I think, everyone's mind or minds with what you can do in regards to relational structures in there and how you can access data in different ways in the single table design stuff, which is quite fascinating. But I really want to get into Dynobase, what it does, what's the purpose of it, but maybe we just start at the beginning. Why did you create Dynobase?Rafal: Yeah, sure. Actually, there is sort of I think quite interesting story behind it because it all started more than a year ago when I was working at X-Team. I was working on kind of quite a big project for the educational space. I was working as AWS DevOps engineer, I was setting up infrastructures, it was all set up on containers. But we received a new requirement to create a fully real time community platform. Our architects, Raynard, which is a great friend and also an engineer, approached me and said that, "Hey, I know that you're super interested in serverless. I know that you've contributed some pieces to serverless framework, and you write about it. So maybe we can try evaluating all those new tools that AWS released, like AppSync, Amplify, DynamoDB, and try to create something on top of that."And that sounded super good because I could finally use serverless technologies at my day job. So we immediately rushed into evaluating those tools. We watched a lot of random session including Rick Houlihan about single table design and it was mind blowing and charming at the same time. But when we were evaluating those tools, we realized that if you would like to use AppSync, we probably have to use Amplify and if we go with Amplify, we can't go with single table design, because if you're using Amplify, you're creating graphical schema, which is then translated to separate DynamoDB tables, which is not working with single table design super good. So we decided to use serverless framework DynamoDB single table design to create everything. And we rushed into the implementation without having thought all about testing processes, about debugging because we decided to learn as we go because we had that opportunity.And when we started implementation, obviously, there was a lot of bugs and there was a lot of mistakes. We had our single table design schema, designed very good, but it was a new field for us. So we obviously committed a lot of beginner mistakes. While we were doing that, we started checking a lot of data, a lot of re

About Matthieu Napoli:Matthieu Napoli is a software consultant and founder of null. Matthew has been developing web applications for more than 10 years with PHP and JavaScrapt as a full-stack developer, lead dev, and CTO, while maintaining several open source projects. He’s also the author of PHP-DI, Silly, Couscous, and Bref.Twitter: twitter.com/matthieunapoliPersonal website: mnapoli.frnull: null.tcBref: bref.shServerless PHP Newsletter: serverless-php.newsWatch this episode on YouTube: https://youtu.be/H8tkZcjQxOATranscriptJeremy: Hi everyone. I'm Jeremy Daly, and this is Serverless Chats. Today, I'm chatting with Matthieu Napoli. Hey Matthieu. Thanks for joining me.Matthieu: Hi, thanks for having me.Jeremy: You are a serverless consultant and the founder of Null. Why don't you tell the listeners a little bit about your background and what Null does?Matthieu: Yes. I created Null two years ago. My goal was to be able to both work in open source as well as work for clients. I use that company to do trainings around Bref, around serverless and also to provide consulting services.Jeremy: What about your background?Matthieu: I started as a developer about 10 years ago, and I've been working mostly as a developer. I've been configuring servers, setting up servers for a while. That's why I'm also really interested in serverless. I've been looking at that very closely lately.Jeremy: Great. All right. I want to talk to you today about serverless and PHP and Bref. Serverless is obviously the topic of this podcast. We've seen quite a bit of movement in the serverless space over the course of the last five years or so. PHP sometimes gets some slack on the internet, but can you give me a brief background as to why you chose PHP?Matthieu: Yes. That's a very good question and that's a good way to start, because indeed a lot of people have opinions about PHP, and sometimes for good reason. I started with PHP just because it was simple. That's what I love about this language. At the time, like when PHP arrived, it was about 25 years ago. The web was about creating CGI applications, using C or whatever, and PHP arrived and simplified everything. It made the web accessible to a lot of people. I find that really amazing.That's why I started with PHP as well. I wanted to build a simple website. Yeah. I started with PHP because of that, but I'm seeing the same thing today with serverless. It's making infrastructure, it's making hosting applications accessible again to developers and I find that amazing. Yeah. I started with PHP. I kind of got stuck with this language throughout my jobs and lately PHP has become a very interesting language. To be honest, it's really interesting.If you've used PHP in the past, I really encourage you to give it another look. It's really worth it. While I do talk a lot and use a lot of PHP, I enjoy using JavaScript as well. TypeScript lately. Really, really interesting language. Life is full of things to learn about, I guess.Jeremy: Right. Absolutely. I agree with you on PHP. I started with PERL and CGI way, way back when, and then I think I started using PHP 3.0 or something like that with MySQL databases. You're right. It completely changed things. From that we got WordPress for better or for worse, but I think that like 80% of the web runs on PHP.Matthieu: Yeah. That's a huge market, which is interesting when we're going to talk about AWS Lambda later. Yeah. PHP is huge and I don't think this is something that we can ignore.Jeremy: Right. Right. Okay. Speaking of this PHP, you realized that there was a gap in the serverless ecosystem for PHP, and so you wrote something called Bref. Can you tell the listeners what that's all about?Matthieu: Exactly. Yes. I am a developer. I like writing code, creating applications. I don't like setting up servers and all of that stuff. This is why I created Bref. I wanted a simple way to put my PHP code online. At the time I was looking into serverless, looking into AWS Lambda and I discovered, of course, that AWS Lambda does not support PHP. I created Bref to bridge the gap, run PHP on Lambda and provide a lot of tools, documentation, examples. Yeah. Anything that you may lack to create those serverless applications. I would say that Bref is more than just a runtime. It's a whole stack.Jeremy: Right. There's actually two parts of Bref, right? Why don't you explain those two different parts?Matthieu: Yeah. I realized over time that there are two major use cases when you look at Bref and what you can do with PHP on Lambda. In the first case, you know about AWS Lambda. You know how it works. You know why you use it. The only thing that's missing is that you want to run PHP for some reason. Maybe you want to use PHP and you want to run it on Lambda. The first part of Bref is a runtime that works just like any other language on Lambda.Yeah. You can write functions in PHP, handle queue messages, SQS queue messages, EventBridge messages react to S3 events, API gatewa

About Joe DuffyJoe Duffy is cofounder and CEO of Pulumi. Prior to founding Pulumi, Joe was a longtime leader in Microsoft’s Developer Division, Operating Systems Group, and Microsoft Research. Most recently, he was Director of Engineering and Technical Strategy for developer tools, where part of his responsibilities included managing groups building the C#, C++, Visual Basic, and F# languages. Joe created teams for several successful distributed programming platforms, initiated and executed on efforts to take .NET open source and cross-platform, and was instrumental in Microsoft’s company-wide open-source transformation. Joe founded Pulumi in 2018 with Eric Rudder, the former Chief Technical Strategy Officer at Microsoft.Twitter: twitter.com/funcofjoePulumi: www.pulumi.com/Pulumi Twitter: twitter.com/PulumiCorp Watch this episode on YouTube: https://youtu.be/MYOGfK9PHM8TranscriptJeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Joe Duffy. Hey Joe. Thanks for joining me.Joe: Hey Jeremy. Thanks for having me.Jeremy: You are the CEO and founder of Pulumi. Can you give the listeners a little bit about your background and tell us what Pulumi does?Joe: Yeah, happy to. I founded Pulumi three years ago. Before that, I was an early engineer on the .NET framework at Microsoft. I was actually at Microsoft for a hearty 13 years working in and around developer tools the entire time, managing groups. I actually led the languages team before leaving, helped with the open source transformation at Microsoft, which was really cool to be a part of, and then founded Pulumi. Pulumi is a modern infrastructure as code platform that really brings everything we know and love about application development using great programming languages, great tooling, and actually brings it over to the infrastructure side of the house and really trying to help both infrastructure teams be super productive with great tools but also empower developers to use more of the cloud as part of their application architecture itself.Jeremy: Awesome. You just mentioned there cloud engineers or the infrastructure team and then serverless developers, so I look at this and I tend to think... especially with smaller organizations... they're almost becoming one and the same. But as you get larger organizations and you start to separate that responsibility... and whether you have separate cloud teams and separate developers or different cells that do that kind of stuff, there is kind of this separation between the infrastructure dev ops people and the serverless developers. Can you explain that difference?Joe: Yeah. And I agree. I think developers are doing more infrastructure now than they've ever done in the past and I think serverless is really forcing this issue a bit. Is a serverless function infrastructure or is it code? The line's a little blurry. But there's clear things that are still in the infrastructure domain: for example, setting up a virtual private cloud in Amazon, setting up a network, setting up a Kubernetes cluster. Even if you're going to run serverless functions within Kubernetes somebody's got to manage the cluster. Somebody's got to think about security. Somebody's got to think about monitoring. Some of that actually falls on the applications side. A lot of it falls on the infrastructure side.I think of it as there are deep domain experts in the infrastructure space just like there are deep domain experts in the applications space. I think the magic of what we're seeing with serverless in particular is that the line is getting a little blurry. It's more of a policy decision, I like to say, than a technology decision about who does what. The infrastructure team is going to do the network because that's what they know how to do. They're experts in that. The development team probably doesn't want to become domain experts in how to set up networks. Similarly, the infrastructure team doesn't want to become domain experts in how serverless functions work, so it's better if the developers can be self-serve and really own their own destiny there. I think the tools and workflows really need to support the concept of these two disciplines working closer together going forward and I love that you used the phrase cloud engineering because that's really what I think of. It's the best of developers, the best of infrastructure engineers, really collaborating together.Jeremy: Right. That's interesting, because I totally agree with that. Where, then, are these challenges, or what are these new challenges that you're seeing both sides face? Because as a developer, like you said, you need to get a little closer to the infrastructure. As a infrastructure person, you need to get a bit closer to the configurations that the developers are setting up. What are the challenges for the developers?Joe: Infrastructure's hard. For developers specifically, I think no serverless function is an island. A serverless function is only i

Watch this episode on YouTube: https://youtu.be/hFGrKjtWsQgTranscript:ON BEST PRACTICES...Episode #1: Alex DeBrieAsking about best practices and the reality of implementing them...@4:24Alex: I think it's pretty fascinating to see. Like you say, if you're on Twitter and you're following a lot of the big time people doing serverless architectures in this space, they have a lot of great tips around best practices, and this is what you should be doing, all that stuff. But I find, as I'm building serverless applications or as I'm talking to customers and users that are building serverless applications, there are times when there's tension between what the best practices are and what their circumstances are. This could be because maybe they're not coming in with a green field application, or maybe they have a data model that doesn't fit DynamoDB or something like that. It's difficult on how you sort of square that with recommending something that you know isn't the best practice or the most pure serverless application, but you also gotta help people ship products, right? I think balancing that tension can be tough at times.Episodes #18 & #19: Michael Hart@30:25 (Ep. 19)Michael: There's nothing special about Lambda in this respect. It's like, this is just sort of best practices if you were calling any API or if you're writing any API that if you're waiting for many, many, many, many seconds, then you might want to deal with that. And those are the sorts of use cases where I think, okay, fine, that's perhaps not a good practice. You actually, you asked me. We use this at Bustle. So we have a Lambda that renders our frontend HTML code. It's a preact app. It does service side rendering of the HTML, but it delivers to the, you know, to the browser via API Gateway and a CDN and things like that. But it calls our other Lambda directly, which is a GraphQL backend. It calls that to pull in the data that it needs to render the HTML page. Now in the browser, it also will call that GraphQL backend , but it will do it via API Gateway. Because it's coming from the browser, so it needs to make some an authenticated HTTP request into the function. But when you're in the Lambda world, well, that Lambda can just call that Lambda directly, and call the GraphQL Lambda, and that goes to Redis and Elasticsearch wherever it needs to pull the data and send it back. And we just make sure we have the timeouts tuned such that, you know, I mean it responds within milliseconds. It’s not even a thing we would really run into.ON INSTRUMENTATION...Episode #2: Nitzan ShapiraAsking about the need to automate instrumentation...@29:35Nitzan: Yeah, by the way, it's not just worrying. It's not just the fact that you can forget. It's also just going to take you a certain amount of time - always - that you're going to basically waste instead of writing your own business software. Even if you do remember to do it every time, it's still going to take you some time. Some ways that can work [are] in embedded in your standard libraries that you work with. If you have a library that is commonly used to communicate between services, you want to embed that tracing information or extra information there, so it will always be there. This will kind of automate a lot of the work for you. That's just a matter of what type of tool do you use. If you use X-Ray you're still going have to do some kind of manual work. And it's fine, at first. The problem is when you suddenly grow from 100 functions to 1000 functions — that's where you're going to be probably a little bit annoyed or even lost, because it's going to be just a lot of work and doesn't seem like something that really scales. Anything manual doesn't really scale. This is why you use serverless, because you don't want to scale service manually.ON APPSYNC DATA OWNERSHIP...Episode #3: Marcia VillalbaAsking about what service owns the data when using AppSync...@36:20Marcia: Well, then, it's the question on who owns the data, and that's something, at least with AppSync, I'm still trying to figure out how to really architect my application, my graph qualifications, because I've been using GraphQL with microservices, and usually I do the filtering in the microservice because the microservice knows the data, knows who can see it, and I don't want to leak that information out. But with AppSync, at least applications and have been building, they are mostly contained into Dynamo tables and Lambdas. So I think when I'm coding this that AppSync is the owner of this data and, then I do the filtering in the resolvers. So I think it's always a question of who owns the data and who is able —where is the level that you want to leak the information out? I don't know if it's clear.ON WORKFLOW COMPLEXITY...Episode #4: Chase DouglasAsking about the complexity of the development workflow...@6:35Chase: Yeah, for all the benefits you get from serverless, with its auto scaling and its capabilities of scaling down to zero, which re

About Tim Wagner:Tim Wagner is known for starting the serverless movement with the original business plan for AWS Lambda, and served as general manager for three of their central serverless offerings: Lambda, API Gateway, and the Serverless Application Repository. After AWS, Tim helped lead another bleeding-edge movement, driving forward blockchain innovation as the VP of Engineering at the digital currency exchange platform Coinbase. Tim is currently working on a new stealth startup, Vendia, with more information to come on June 26th.LinkedIn: www.linkedin.com/in/timawagner/Twitter: twitter.com/timallenwagnerMedium: medium.com/@timawagnerVendia: www.vendia.net/Watch this episode on YouTube: https://youtu.be/M6I0ay5R884Transcript:Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats today. I'm chatting with Tim Wagner. Hey Tim. Thanks for being here.Tim: My pleasure. Thanks so much for having me.Jeremy: So you have a lot of history. There's a lot of stuff that we're going to get into today, but right now you are the CEO and the cofounder of Vendia. So I'd love it if you could tell the listeners a little bit about your background, your history, and then what Vendia is all about.Tim: Sure, sure. So last few jobs here. I mean, I started what eventually became AWS Lambda at AWS. Joined there back in 2012, we launched that in 2014. And that taught me a ton, not just about how to run a business in the cloud, but also about how you build these massive horizontally scalable cloud services. Then I spent some time down here in San Francisco at Coinbase, a US-based cryptocurrency exchange. And I learned a lot about a different kind of scale, which is how you run these massively scaled ledgers that can hold really important information, for example like somebody's bank account. And then Vendia is in some sense kind of the combination of these two things.I took everything that I've learned over the last seven years and my cofounders Shruthi Rao and I have brought that together to create a business to help companies break down some of the data silo and information exchange problems that they've got today. So we're still in stealth mode for a few more weeks, but I can tell you a couple of things about it. For one, when I sold AWS Lambda, customers were always excited about the product, but they also always had two concerns. First, it was an inherently proprietary technology specific to AWS. And then secondly, while it was this awesome solution for compute, it didn't kind of come preset for data solutions or a solution for state. And so with Vendia, we're trying to reimagine how companies can go serverless and then at the same time solve some of the biggest baddest challenges they've got around data silos and vendor lock in at the same time. By the way, speaking of serverless, Vendia's also proudly server and container free.Jeremy: Awesome. So that's awesome first of all, and I'm excited for Vendia. I really am interested. Anything that you do is just gold. So I think that this is going to be pretty exciting and I can't wait for it to come out. But what I'd really like to do today since I have you, I mean, for all intents and purposes and I think you always say this lovingly, but you're really the father of serverless, right? I mean, Lambda is what kicked off this whole thing. And I know that there were other companies that this sort of like a fast type thing, but not anywhere near to the scale that that Lambda did. And I would love to hear that story. As a fan of serverless, as a fan of AWS Lambda, could we go back to the beginning and just maybe give me a little, some insights into how this all started?Tim: So a little bit of the Lambda origin story, huh?Jeremy: Yes. Please.Tim: Yeah. So we roll back the clock. It's 2012, I get hired into AWS and it's my first day there. And my boss Alyssa Henry, who at that time is running all of storage, so S3, EBS, like the whole storage division for AWS sits me down at lunch and says, "Okay, Tim, so here's the deal. We heard from customers that they love S3. It's simple, it's easy to use. It's a different kind of way of thinking about the cloud. They love all of that, but it's just a storage solution, right? There's no way to ... Let's say you store an image, there is no way to make a thumbnail of it. You pull out a compressed file, there's no easy way to decompress it on the fly plus the other million things developers might want to do with the stuff that they're storing in here.So they've told us this in customer advisory meetings and one on ones, see if he can do something with that. Okay. I'm busy, got to run. Good luck." So this is day one for me at AWS. This is literally my very first conversation coming out of the sort of the onboarding and signing up all the paperwork. So I'm like, "Okay, grow a business in the cloud. Make it easy and think about S3 as a kind of inspiration." And it's funny because a lot of people think that Lambda grew out of EC2 and it's obvious

About Adrian Hornsby:Adrian Hornsby is a Technical Evangelist working with AWS and passionate about everything cloud. Adrian has more than 15 years of experience in the IT industry, having worked as a software and system engineer, backend, web and mobile developer and part of DevOps teams where his focus has been on cloud infrastructure and site reliability, writing application software, deploying servers and managing large scale architectures. Today, Adrian tends to get super excited by AI and IoT, and especially in the convergence of both technologies.Twitter: twitter.com/adhornMedium: medium.com/@adhornDev.to: dev.to/adhornWatch this episode on YouTube: https://youtu.be/6o2owe2VHMoTranscript:Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Adrian Hornsby. Hey, Adrian, thanks for joining me.Adrian: Hey, Jeremy, how are you?Jeremy: So you are a principal developer advocate for architecture at AWS. So why don't you tell the listeners a little bit about your background and what it is you do at AWS?Adrian: Okay, cool. So first of all, thanks for having me on your show. I'm a huge fan of your show. As for my background, it's a mix of industry and research. Actually, I started my career at the university doing some research, and then moved to Nokia research and eventually some startups, always around distributed systems and real time networks and things like this. And then let's say the particular things is much of the work that I've done was always on AWS since the very beginning. So it kind of felt very natural eventually to join AWS, which was about four years and few months ago. And I joined as a solutions architect, and then quickly moved into an evangelist role. And mostly doing architectures and resiliency and a lot of breaking things kind of chaos engineering type of things.Jeremy: Awesome. Well, speaking of resilient architectures, that's what I wanted to speak with you about today, because you have on your Medium blog, which is awesome, by the way. I mean, I go there-Adrian: Thank you.Jeremy: Every time I go, and I read something there, you think you know it all, and then you read something by Adrian, and you learn something new, which is absolutely amazing. But so I want to talk to you about this, because this is something I think that ties into serverless pretty well, is this idea that I think we take for granted, especially as serverless developers, we take for granted that there is a bunch of things happening for us behind the scenes.And so we get a lot of this, infrastructure management out of the box, we get, some failover out of the box, we get some of these things. But that really only scratches the surface. And there's so much further we can go to build truly resilient applications. And you have an excellent series on your blog called the resilient architecture collection. And I'd love to go through these because I think that this is the kind of thing where if you start thinking about global distribution, you start thinking about latency. You and I have been having a lot of latency issues trying to record this episode, because you're all the way in Helsinki and I'm over in the United States. These are things to start thinking about.So I want to jump in first with this idea of embracing failure at scale. And I love this idea because when we build small systems, we think about reliability, right? We try to get as many nines as we possibly can. But when you get to the level of global distribution, distributed systems that are sending messages between components, that are sending messages across the Atlantic Ocean or the Pacific Ocean, this data is going all over the place, this idea of failure, or at least partial failure has become the new normal.Adrian: Yeah. So yeah, I think it's things have changed a lot in the last few years. I mean, before you were on the monolith application, and you were trying to make sure your monolithic application was always up and running, right? I think there was even some competition into uptimes it was very popular back then to look at uptimes of servers and say, "My server's been up for 16 years, wow, awesome." But now, we've moved away slowly from monoliths to micro service architecture, and especially I think as we move even to the cloud, and we use more third party services, systems become naturally more distributed, and they go over the internet, which is everything but a reliable source of communication.So, you have network latency, you have network failures. So there's a lot more things that can go wrong. And I think understanding and accepting that anything, at any time can fail is actually a very important thing. Because it means that you accept failure as a first class citizen for your application. And then you need to write code and design applications so that at any moment in time, there can be failures, and that's called partial failure mode, as you said. And it's very different concept than what it used to

About Guillermo Rauch:Guillermo Rauch is the CEO of Vercel, but before starting the company in 2015, he was CTO and co-founder of LearnBoost and Cloudup, acquired by Automattic in 2013. Guillermo is also the creator of several popular Node.js open source libraries like socket.io, mongoose and slackin. Prior to Node.js, he was a core developer of the MooTools frontend toolkit.Twitter: twitter.com/rauchgVercel: vercel.comNext.js: nextjs.orgWatch this episode on YouTube: https://youtu.be/iRNxV9vRg6oTranscriptJeremy: Hi, everyone. I'm Jeremy Daly, and this is Serverless Chats. Today, I'm speaking with Guillermo Rauch. Hey Guillermo, thanks for joining me.Guillermo: Hey, thanks for having me.Jeremy: You are the CEO of Vercel, which was formerly ZEIT, so I'd love it if you could tell the listeners a little bit about yourself, your background, and what Vercel is all about.Guillermo: I'm the CEO and co-creator of Next.js, which is the React framework for front-end development and JAMstack development. Vercel is the platform for deploying projects like Next.js and many other frameworks. Vercel focuses on making the lives of front-end developers really, really easy, allowing them to push their pages to our edge network, and have a very delightful serverless development experience.Jeremy: That's what I want to talk to you about today. The last time, I think, we saw each other in person was back in... Was it back in Milan, I think, right? Almost two years ago at this point, maybe it was last year. I don't even remember. Quarantine has lasted so long at this point that I can't keep track of time. The last time I saw you, I was speaking about this idea where I felt like serverless was getting harder and harder and harder.That was or it seems to be the wrong approach, right? We want serverless to become easier. This is something where, I think, this idea of maybe I think you call it front-end serverless or serverless front-end is where you're trying to go with Vercel. I'd love to just get your thoughts on that, just that complexity that we're now pushing towards the back end, and where you're trying to go with the front end.Guillermo: I think you nailed it. I think the serverless world is big and complicated. I think when we first met, we really connected on this idea of like, "What is even the right definition of it?" We were both presenting at Milan trying to give a definition for it. It's a pretty silly game to play to try to even fight that fight. When I think about serverless, I think about wanting to give people a very good recipe for leveraging that kind of technology.I think anything that relates to serverless or infrastructure really needs to disappear. It has to be all about letting people focus on their products, focus on their pages, focusing on the things that they're publishing to the internet. That's why front end really is the place where, I think, all the serverless action is happening, and the techniques and technologies that we're using in some ways are the original serverless because much of what we're doing today is this idea of taking pages, generating them statically and putting them at the edge, which means...To me, the most fundamental serverless technology out there is CDN. They've been around for a long time even they predate a lot of the serverless movement. Yet, they had that critical idea that there is no management to do, that it accelerates you, obviously, because it's putting your content next to your customers. The very technology that this accelerates is the front end. I think what we're about to see is that a lot of what we've been advocating for in the serverless world is really starting to become much of a reality with front-end developers.Jeremy: I think that actually makes a ton of sense, because whenever I was thinking of serverless, I would always think about the actual computations that were happening behind the scenes, so whether that's something where you're running a Lambda function, and it's pushing it into SQS, and you're connecting to DynamoDB, and you're doing all these different things with the data. A lot of that is still necessary, right? There's a lot of complexity that has to happen behind the scenes in order to make a full-fledged serverless application run.But I think the funny thing is that a vast majority of the applications you see out there are just a collection of static pages. That's, I mean, with a little bit of API happening in the background, but that shift, that thinking of compute versus static pages, isn't that really where we want serverless to go to is just this super easy precomputed system?Guillermo:Yeah. I think a lot of people in the industry have over focused their attention on computing on demand, which is what Lambda enables, right? You're literally firing up a VM. It's amazing how easy AWS made it. It's almost like a miracle that you deploy your function so quickly, and it executes so quickly, and it's secure and in a VM sandbox, and their unde

About Jared Short: Jared has been building and operating serverless technologies in production at scale since 2015, and is laser focused on helping companies deliver business value with a serverless mindset. Jared is currently Senior Cloud Engineer, Developer Accelerator, at Trek10, Inc. but was formerly Head of Developer Experience and Relations at Serverless, Inc. and an early contributor to the Serverless Framework. In his current role, Jared's day-to-day is serverless all the time, as he helps people build and operate cloud native architectures.Twitter: twitter.com/ShortJaredEmail: [email protected]: jaredshort.com/3 Guiding Principles for Building New SaaS Products on AWS: trek10.com/blog/guiding-priciples-for-building-saas-on-aws3 Big Things I Wish Someone had Told Me When I Started Using AWS: dev.to/trek10inc/3-big-things-i-wish-someone-had-told-me-when-i-started-using-aws-2d0nWatch this episode on YouTube: https://youtu.be/rA4eVtpFnVsTranscript:Jeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Jared Short. Hey Jared, thanks for joining me.Jared: Hey, pleasure to be here. Thanks.Jeremy: So you are a Senior Cloud Engineer and Developer Accelerator at Trek10, Inc. So why don't you tell the listeners a little bit about your background and what you do at Trek10, Inc?Jared: Sure. So my background, I think starts similar to a lot of people, where I dabbled in the basement on the all the Apple II, I learned how to program actually from a book from the library on that Apple II. And then throughout college... Well, high school and college kept keeping up with technology and building things and exploring and learning. And eventually that led me to kind of the cloud back in 2014 or so. I was big into Docker in the early days, in the cloud, and eventually found serverless while I was at Trek10.So Trek10 is of course an AWS consulting partner. And as part of that, I get to help companies design and build serverless and cloud-native systems, with different kind of verticals all over the world. SaaS companies, enterprise companies, all of that kind of stuff. So that's where I'm at today. And I'm mostly focused on helping people learn and understand the cloud through our developer acceleration program. So taking all of those things that I've learned while helping people build things, and now helping people just learn what all they need to learn to build successfully in the cloud.Jeremy: Awesome. Alright, well, so I've been following you for a very long time. I mean, you and I have known each other now for a while. Met up at a few conferences and so forth, and you always do great stuff. So I love the Trek10 blog, love the stuff that you've been working on. You've done a lot of stuff I know with Forrest Brazeal and some other things that have been very popular. There's a whole bunch of great stuff out there by you. So definitely search for Jared Short, serverless and go check out your stuff.But I saw an article from you a couple of weeks ago. That was the three big things I wish I knew before I started working with AWS, or something like that. And that just struck a chord with me, because as I was reading through these things, I was like, "Oh man, this was the article I wish I had when I started working with the cloud way back in 2009." And since then, it's like exploded a thousand times over. So this is a great article and I'm going to put the link in the show notes, because I do want people to go read it. But I think it'd be awesome to just go through and talk about this article and kind of hit on some of these points.The article is very in depth that goes deep into some of these things, but this is something that really warrants a conversation. So the first point that you made, the first learning or the thing that you wanted to that you wish you had known, was this idea that AWS is just this massive ecosystem and it's basically pretty much impossible to understand all of it.Jared: Right. Yeah. It's a massive ecosystem that shows no signs of slowing down. It's pretty similar to the ever-expanding edge of the universe, it just keeps growing and consuming.Jeremy: It's like, S3 was the big bang and then it just kept growing from that point. Right, right. So you point out a couple of things though about this that I thought was sort of really interesting. Where it's like, there are all of these different services and you had said, you could explain what most of these services do, at a high level. Like what is Amazon Sumerian or AWS Sumerian, who even knows the names of some of these things. You can explain that at a high level, but then understanding the nuances and the limits. And that's like a graduate level course in and of itself.Jared: Yep. Yeah. Right. And in fact, the fact that I can't even tell you how they name Amazon versus AWS in front of something tells you a little bit of something. Right? I think I would guess it's Amazon Sumerian I have no idea. And the f

About Linda Nichols:Linda Nichols is a Cloud Solution Architect at Microsoft. In addition to creating software solutions, she has a passion for community involvement and education. She is a co-founder of Norfolk.js, NodeBots Norfolk, and RevolutionConf. She also enjoys teaching local classes and workshops.Twitter: twitter.com/lynnalooLinkedIn: linkedin.com/in/lynnaloo/GitHub: github.com/lynnaloo Watch this episode on YouTube: https://youtu.be/e5oFSIMuvcMTranscript:Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Linda Nichols. Hey, Linda, thanks for being here.Linda: Hello.Jeremy: So you are a cloud native technical specialist, and a member of the global black belt team at Microsoft. So why don't you tell listeners a little bit about your background and what you do at Microsoft.Linda: Sure, sure. So first of all, I have like the most awesome title at Microsoft. And most people don't understand, but it sounds great. Especially you join a call with a customer and they're like, the global black belt is here. But, essentially, we're problem solvers. If someone has a problem, or they want to know how to build something, or they want to have a conversation about maybe like, something that's out of the norm, like, it's not your typical service that a lot of the cloud architects within Microsoft know, or it's something more in the open-source side, something that's heavier into serverless or Kubernetes, or just something that's maybe out in the community. There's a lot of open-source tools and things that we talk about, we could be just the open-source blackbelt team. And my background is development. I was thinking about this today. Like, I'm not afraid to say I'm in my early 40s. And so now, half my life has been developing.I've had a professional job as a developer for half my life. So it's really like kind of ingrained in me being a developer, even if I'm not coding every single day now, because I'm on the phone a lot, just like chatting with people, but I still, like really enjoy kind of hacking at things and thinking about methodologies. And, that's part of what we do too on our team I mean, maybe someone calls us up and says, I just can't get this working and we help them through it. But also, maybe we just kind of talk about, like why are you doing this this way? And, what you think about this? And how about these tools? And that sort of thing.Jeremy: Awesome. Alright. So I've seen you give a number of presentations actually in a lot of the presentations that you give are around DevOps and serverless, right? And kind of how those things connect. And speaking about being in your early 40s, one of the things I love about your presentation, I'm in my early 40s, as well, I love your, like 80s and 90s References because I get all of them and it is absolutely amazing. So, but your talks usually are around DevOps and how it kind of intersects with serverless. And a lot of times about the serverless developer themselves. And I remember back at Serverlessconf, it was like serverless developers are developers or something like that and it was great talk. So I kind of want to talk to you today, though, about the culture, right? Like this culture around the serverless developer. Because, if you look at people using things like Amplify, there's this whole new thing like a full-stack serverless developer.And then you've got some people who are kind of focused more on the, I guess, on the infrastructure side of serverless, which is maybe a bit of an oxymoron, but maybe understanding at least how some of these configurations work. So maybe you just give us a quick overview like, what is the overall culture look like for serverless developers?Linda: Sure, sure. Well, first of all, you threw like an AWS term at me. And I was like, Amplify, which one is that? But, yeah, I mean, I think what I keep trying to kind of drill in, is it like, yeah, serverless developers are developers. And I keep saying too, serverless was made for us, right? I mean, serverless wasn't really it didn't come out and become popular because ops people were like, "No we don't really want to do our jobs." Like we hate infrastructure. No, no, they love it, they've been skeptical this whole time. They're like," Oh, so the developers are going to push to production now. Okay, have fun with that." so I mean, it's essentially for us, so we shouldn't be the ones that are distrustful, we should be the ones that are saying, okay, here's our process, which is what we love to do. These are the things that we've done to be really successful at development all these years. And now we're carrying it over into this ecosystem where we have a little bit more control, but also less control kind of. I mean, we're not having to hand as much over to the ops people. But we don't have to worry about things.Like, I think there was a period of time there for a while, where I started to have to care about Docker containers more than I w

About Mike Roberts: Mike Roberts is a partner, and co-founder, of Symphonia - a consultancy specializing in Cloud Architecture and the impact it has on companies and teams. During his career, Mike’s been an engineer, a CTO, and other fun places in-between. He’s a long-time proponent of Agile and DevOps values and is passionate about the role that cloud technologies have played in enabling such values for many high-functioning software teams. He sees Serverless as the next evolution of cloud systems and as such is excited about its ability to help teams, and their customers, be awesome.Twitter: twitter.com/mikebrobertsLinkedIn: linkedin.com/in/mikebrobertsWebsite: mikebroberts.comSymphonia: www.symphonia.ioSymphonia blog: blog.symphonia.ioProgramming AWS Lambda: Build and Deploy Serverless Applications with Java book: shop.oreilly.comWatch this episode on YouTube: https://youtu.be/16en-TTGNhkJeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. This week, I'm chatting with Mike Roberts. Hey, Mike, thanks for joining me.Mike: Thank you very much for inviting me, Jeremy.Jeremy: So, you are a Cloud Architect and DevOps Consultant that specializes in serverless and AWS, and you're also a partner at Symphonia. So, why don't you tell the listeners a little bit about your background and what Symphonia does.Mike: Yeah, that'd be great. So, I've been in industry now for 21 years and in that time, I've been an engineer or a senior engineer, manager or CTO, sometimes consulting, sometimes working for product companies, so a whole mixture and sort of up and down the manager versus technical ladder.About four years ago, I was a VP of Engineering at an ad tech company here in New York and we started using a lot of sort of much higher level AWS technologies and especially at the end of that year, we were using a lot of Lambda, so I really thought that serverless was really interesting and so I wrote an article four years ago now about serverless. That proved to be really popular and I was like, "Oh, wait, other people like this, too. Maybe I should start a company about this kind of stuff." So myself and my business partner, John Chapin, we decided to start Symphonia as a consulting company to help people with the kind of technologies and lessons that we'd sort of seen over the last few years. And that's what we've been doing now for three and a half years.Jeremy: Awesome. Alright. Well, so recently, you and your business partner, John, wrote a book called Programming AWS Lambda, and great title, right, there it is. He's got it. Okay. Now, the thing that struck me though about it was about Java. And so I'm just curious, it's 2020 and so, why would you write a book about serverless programming in Java?Mike: Mostly because my writing is terrible and I didn't want anyone to actually read the book. No, that's not the reason. It is weird and a lot of the things that you read about Lambda, the examples are in Python or JavaScript or Go and then there's this Java thing. And who actually uses Java with Lambda? Well, it turns out a lot of people use Java with Lambda and the other thing was, it's how we got started with Lambda. So when John and I started using Lambda, which was about three and a half years ago, the Java support has just come out and we were working for a Java shop, so we had a lot of engineers who were very Java savvy. We had all of our Java tool chains all sorted out and so we decided to use Java and Lambda and see how it worked and it worked brilliantly.And one of the reasons it worked brilliantly was that the system that we were building was pretty high throughput, like we were processing millions of messages a day with Lambda and so we never hit, and even back then, any of the concerns with cold starts or anything like that, and so yeah, it really just fitted in like a glove for us and. And so, when we decided to write the book, we knew that we weren't unique and we knew that there were a lot of other people out there who have built up this knowledge in Java and the ecosystem that surrounds Java and we wanted them to have a book for Lambda, just like JavaScript developers and Python developers and all that kind of thing.Jeremy: Awesome. Well, so the funny thing is, is that I saw this book come out and I immediately was like, "Oh, no, it's a book about Java." And I haven't programmed in Java, and I don't remember how long, but I said, "I know Mike and I know John." I've been following your work for a couple of years now and I know you produce good stuff. So I said, "I'm going to look at it. I just want to give it a look." And what I found was that it's not really a book about Java. It's really a book about building serverless applications with the examples in Java and there are a few very Java specific things in there, which I think is actually great and we'll get into some of those reasons why.But yeah, but I mean, the book covers everything. All those core concepts like the execution environment a

About Gareth McCumskey:Gareth McCumskey is a web developer with over 15 years of experience working in different environments and with many different technologies including internal tools development, consumer focused web applications, high volume RESTful API's and integration platforms to communicate with many 10's of differing API's from SOAP web services to email-as-an-api pseudo-web services. Gareth is currently a Solutions Architect at Serverless Inc, where he helps serverless customers planning on building solutions using the Serverless framework as well as Developer advocacy for new developers discovering serverless application development.Twitter: @garethmccLinkedIn: linkedin.com/in/garethmccPortfolio: gareth.mccumskey.comBlog Posts: serverless.com/author/garethmccumskey/Watch this episode on YouTube: https://youtu.be/5NXi-6SmZsUTranscript:Jeremy: One of the things that I know I've seen quite a bit of is people using just the power of Lambda compute, to do things right? And what's really cool about Lambda is Lambda has a single concurrency model, meaning that every time a Lambda function spins up, it will only handle a request from one user. If that request ends, it reuses warm containers and things like that. But, if you have a thousand concurrent users, it spins up a thousand concurrent containers. But you can use that not just to process requests from let's say frontend WebSocket or something like that. You can use that to actually run just parallel processing or parallel compute.Gareth: Yeah. This is one of what do they call it, the Lambda supercomputer.Jeremy: Right.Gareth: You can get an enormous amount of parallel... Try to say that three times quickly. Parallelization with Lambda. I mean, like I said, by default you get a 1000 Lambda functions that you can spin up simultaneously. And if you ask nicely... Well, you don't even have to ask nicely, just ask them and AWS will increase that to 10,000 simultaneous. And it's really impressive how much compute you can do, to the point where, at one point I was working with a company looking to try to do some load testing of an application.They had an instance where, on Black Friday, the tech kept falling over. They wanted to try to get some load testing in beforehand to make sure that it can handle at least a certain amount of volume. Because you can never entirely predict what your traffic patterns will look like. But at least let's try something. And they spend a lot of time looking at commercial solutions out there because there are a few of them out there that try to help with that.And they normally try to do about 500 to maybe a 1000 simultaneous users or simulated users, which is impressive but not quite good enough when you're an organization that's going to be having 10,000 to 20,000 simultaneous users on your site at a time. That gets a bit rough. So the move was then to try and build some load testing application ourselves. And this was initially tricky to do because we were trying to do this using the traditional VMs, virtual machines, and containers in some way, try to get EC2 instances up and running to try and run multiple simultaneous users at a time, in a single VM, using essentially a combination of these end to end testing tools where you can simulate a user flow from loading the homepage to going to a product page, adding to cart, going to checkout. Doing all of this on a staging environment so that you could simulate the whole user for all the way to purchase, the sort of main line to purchase as it were, make sure that you could get a few thousand users all the way to there without issue.And what ended up happening was these virtual machines just couldn't cope with the load of all these simultaneous users running on a single machine even with inordinate amounts of CPU and RAM on them. So the idea came to us to try and do this with Lambda instead. So what ends up happening is, because you have a thousand simultaneous Lambda functions, AWS also architects this in a way that the noisy neighbor effect of all of these Lambda functions is almost nothing. You can't say nothing.There has been some research I've read that shows there is a bit of a noisy neighbor effect between Lambda functions. But one interesting thing that we found was this is reduced when you increase the size of your Lambda functions to the maximum memory size, which is pretty cool. Because then uses an entire machine essentially or virtual machine as it were. So now you're limiting the effect of that noisy neighbor effect happening. Which means you can then also run 10 to 20 simultaneous users on that single member function with that enormous amount of size.And if you have a thousand of those, well now you've got a thousand Lambda functions with 10 to 20 users per Lambda function, running an end to end test, pointed at a single staging environment. That's a pretty powerful bit of load testing you can perform there. And Lambda being as flexible as it is, we needed to

About Gareth McCumskey:Gareth McCumskey is a web developer with over 15 years of experience working in different environments and with many different technologies including internal tools development, consumer focused web applications, high volume RESTful API's and integration platforms to communicate with many 10's of differing API's from SOAP web services to email-as-an-api pseudo-web services. Gareth is currently a Solutions Architect at Serverless Inc, where he helps serverless customers planning on building solutions using the Serverless framework as well as Developer advocacy for new developers discovering serverless application development.Twitter: @garethmccLinkedIn: linkedin.com/in/garethmccPortfolio: gareth.mccumskey.comBlog Posts: serverless.com/author/garethmccumskey/Watch this episode on YouTube: https://youtu.be/Q3tbdlHH0MgTranscript:Jeremy: Hi everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Gareth McCumskey. Hey Gareth, thanks for joining me.Gareth: Thanks so much for having me Jeremy.Jeremy: So you are a solutions architect at Serverless Inc. So why don't you tell the listeners a little bit about your background and what you do as a Solutions Architect?Gareth: Sure. So, going back a bit, I mean I've been a web developer for a few years now coming up to 15 years. It doesn't feel quite as long as that, and I actually started back in the days of building a PHP web frameworks and so on. And my first start with serverless was back in 2016 where I actually, was taking over the lead of a team at the time.And part of my job there was to try and help modernize this aging WordPress monolith that had been the company's entire online presence at the time. And the company, they sold tours online. And online was the only way that they sold their product. So it was quite important to have this product working well. And then I was going through the usual steps, just taking a look at how we could potentially modernize things, looking at the Laravels and Symfonys of the time.And I was chatting to one of the guys at Parallax Consulting who had helped this company set everything up on AWS. Get all the VMs up and running in the load balances and so on. And one of them suggested that I take a look at the serverless thing that one of their team had spotted. So I thought, well, let me give it a try. Let me give it a... We see what this thing is.And that really ended up being my road down into serverless, because the moment I picked serverless up and started looking at potentially building a RESTful API out of serverless to help modernize the architecture for the company, that was me. I was down the road and started building a POC. And the POC we had was just to take one small portion of the existing stack and replace it with something completely based off of serverless.Something that received reasonably high traffic that wasn't super critical for the running of the organization. So if it failed, it wasn't a train smash. But if it succeeded, it would give us a great indicator that this was something we could definitely move forward with in the future. And ultimately the POC was a raging success.Everybody in the organization was incredibly impressed with how well this serverless tech that we built. And to be perfectly honest, it wasn't even the best architect serverless tech in the world, but it still performed incredibly well, which was quite impressive at the time. So yeah, we were really happy with that. That essentially solidified serverless for me and the way forward for me in the future.Jeremy: Awesome. And so then you started working at Serverless Inc as a solutions architect. So what are you doing there now?Gareth: So now I'm involved with the growth team and being a startup the roles are quite mixed, so I'm called a solutions architect. But I end up doing a lot of different things. One of my main roles is involved in support of our paid product. Serverless Framework Pro dashboard, I help users who are using our product and helping them deploy it and set things up. We have a number of users who need support and help and assistance in setting up their serverless architectures and designing those sort of architectures around their use cases.That's a really interesting job where you get to see quite a variety of ways that organizations are using the Serverless Framework. And it also means I'm working on content all the time, so I'm writing blog posts, producing videos, talking to the community, doing talks, all the usual sort of developer relations side of things as well. Keeps me quite busy.Jeremy: Awesome. All right. Well, so since you are so deep into this stuff now, and again, you're working with a bunch of different clients with Serverless Inc, you're writing these blog posts, you've been doing this for quite some time now. I mean, I think you started what? Around 2016 or so working on serverless. Is that about right?Gareth: Yeah, I started in 2016 building se

About Alex DeBrie:Alex is a trainer and consultant focused on helping people using cutting-edge, cloud-native technologies. He specializes in serverless technologies on AWS, including DynamoDB, Lambda, API Gateway, and more. He’s an AWS Data Hero and recently published author of The DynamoDB Book and the creator of DynamoDBGuide.com. He previously worked at Serverless, Inc., where he held a variety of roles during his tenure, helped build out a developer community, and architected and built their first commercial product.Twitter: @alexbdebrieBlog: https://www.alexdebrie.com/DynamoDB Book: www.dynamodbbook.com (Discount Code: SERVERLESSCHATS)DynamoDB Guide: www.dynamodbguide.comWatch this episode on YouTube: https://youtu.be/GZTLFWlEnawTranscript:Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Alex DeBrie. Hey, Alex, thanks for joining me.Alex: Hey, Jeremy. Thanks for having me.Jeremy: So you are actually returning to Serverless Chats. You were my first guest, and you are also my first returning guest. So I don't know if that's an honor, but thank you very much for being here.Alex: Yeah, it was an honor to be here the first time and honored to be back as well.Jeremy: So a lot has changed since you were with me almost a year ago. You went out, you used to be working at Serverless, Inc., where they created the Serverless Framework. You went out you started doing some consulting, you were named an AWS Data Hero. So why don't you tell the listeners a little bit about yourself and what you've been doing over these last few months?Alex: Yep, sure. So as you mentioned, I used to work for Serverless Inc, creators of the Serverless Framework. That's how you and I got hooked up initially. Worked for them for about two and a half years. And then last fall I was named a AWS Data hHero specifically focusing on DynamoDB which was a big honor for me. And then in January I left Serverless Inc to go on my own to do a few different things, some consulting, some teaching and also finished up this book I've been working on.Jeremy: Yeah and so speaking about this book, I'm super excited about this because I remember we were out I think in Seattle at one point several months ago and I looked over your shoulder, I saw you typing and I asked, "What are you doing?" You're like, "Oh, I'm writing a book on DynamoDB, of course."And you obviously you created the DynamoDB guide at dynamodbguide.com which is a really great resource for anybody looking to get familiar with DynamoDB. It's much more approachable I think, than the documentation on AWS. It's really well written and there were a couple of modeling strategies in there and things like that but this new book, which I've had a chance to read which is awesome, by the way, so congratulations really, really well done. But this new book, just you know it is not DynamoDB guide repackaged.This is a whole new thing with tons of strategies, tons of information. So why don't you tell us a little bit about this book?Alex: Yeah, sure thing. So as you mentioned, I created dynamodbguide.com. That was about two and a half years ago now. And it was basically, I'd watch Rick Houlihans re:Invent talk over Christmas one year, and just had my mind blown and rewatched it so many times, and scribbling it out in Notepad on how it all worked, and then wanted to share what I learned. So I made this site DynamoDBguide.com.That did pretty well. And I've stayed in touch with the DynamoDB team since then. But I really wanted to go further than that. Because I think like you're saying there are some missing stuff out there. So I've been working for the last almost about a year on this book.I started I think, last June or July. And really, we just want to go deep on DynamoDB and not just the basics, all that stuff really introduce this idea of strategies, introduced some data modeling examples to show that you can really handle some complex access patterns. It's not just about key value storage, you can do complex relational data in DynamoDB.Jeremy: Yeah, definitely. And so just in case somebody doesn't know what DynamoDB is, let's just give them a quick overview of what exactly that is.Alex: Yep, sure. So DynamoDB is a NoSQL database offered by Amazon AWS. It's a fully managed database. I'd say, it got started where amazon.com their scaling needs just you know, they were out scaling their relational databases. So they built this underlying storage mechanism that... they built this underlying database to replace their relational databases. That was used internally at Amazon. They released some of the principles behind it in this DynamoDB or this Dynamo paper.That eventually became a service in AWS called DynamoDB. Fully managed service, works really well for highly scalable applications. In fact, all the tier one services at Amazon and AWS are required to use it. So if you think about the shopping cart or the inventory system or IAM or EC2, all that stuff that's all u

About Stephen Pinkerton:Stephen Pinkerton is a Product Manager at Datadog. Stephen has also held roles in product strategy and software engineering, working with teams at Google's Nest Labs, Facebook, Cloudflare, Square, and Monzo to ship products, build distributed microservices, debug real-time embedded devices, develop features for modern frontend apps, and create data pipelines.Twitter: @spnktnSite: pinkerton.ioLinkedIn: https://www.linkedin.com/in/spnktn/About Darcy Rayner:Darcy Rayner is a Software Engineer at Datadog, and previously worked as Lead Software Engineer at at Two Bulls, a boutique software development firm, running the front-end chapter. Darcy’s projects boast clients like Disney, PBS, LIFX, Verizon and the Linux Foundation.Site: www.darcyrayner.comLinkedIn: https://www.linkedin.com/in/darcyrayner/Datadog’s Research Report: The State of Serverless: https://www.datadoghq.com/state-of-serverless/WATCH THIS EPISODE ON YOUTUBE: https://youtu.be/VC1CjUsKqBITranscript:Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week, I'm chatting with Stephen Pinkerton and Darcy Rayner. Hi, Stephen and Darcy, thanks for joining me.Stephen: Hey, how's it going? Thanks for having us on.Darcy: Hi.Jeremy: So Stephen, you are a product manager for Serverless at Datadog, so why don't you tell the listeners a little bit about what Datadog does and a little bit about your background.Stephen: So Datadog is a company that lets you monitor all of your servers, all of your application performance, if your website's up or down, all your application logs in one place and it joins all these disparate data sources together, so that whenever you need to explain something or debug something, you can join all of this different data and really figure out root cause quickly. So I've been working here about a year, focusing on our serverless integration, so that's helping our customers running products like AWS Lambda, to be successful in deploying new services built on top of serverless and then debug issues with their applications.Jeremy: Awesome. Darcy, you are a senior software engineer for the Serverless Team at Datadog, so why don't you tell us about your background and what your role is at Datadog.Darcy: Sure. So I've been at Datadog about a year in the Serverless Team, before I joined Datadog, I was working at an agency. So we were massive serverless adopters in everything we did. Everything was about getting stuff off the ground running very quickly, and low cost to our customers. But while I was there, I realized that there was still a bit of a gap in terms of the monitoring story. So I joined Datadog about a year ago to work on some of the integrations that we're building here with services like Lambda or Azure Functions or GCP Functions.Jeremy: Awesome. So a couple of weeks ago, Datadog came out with this very, very cool report called the State of Serverless. You basically looked at a bunch of your clients, went through and figured out how they were using serverless, broke it all down. This is really great, can you, maybe Stephen, can you give me some background on what was the reason for running this or for putting this report together?Stephen: So we're in a unique position where customers of all different sizes, with all these different use cases are sending all their data to us, and we frequently get questions when we're on the phone with them of, "How do I run serverless successfully?" So this is from customers who are moving workloads into serverless, or they're 100% serverless and they're asking us, "Which metrics do I pay attention to, or how do I get data out of serverless, or how do I run this in a cost efficient way?" So we frequently get these questions, and the report was a way for us to look at data across all of our customers, across all these different data sources that we have and say, "Here's exactly how people are running on serverless." Which technologies are they using, what are they monitoring with it? So it was a really interesting opportunity for our customers to see how other people are using serverless really in a data driven way.Jeremy: It's interesting, because you do mention in the beginning of the report that you're saying "Serverless," but you are just focusing on FaaS. So actually, I'd love to get your thoughts on this, Darcy. Just considering what serverless is as a whole, what do you consider that to be, because it's more than FaaS.Darcy: In terms of the things we're looking at specifically in this report, it's very focused on Lambda. I think in general, we have people who come to us asking us for solutions for things like ECS, Fargate, things like Knative or Google Cloud Run, which they're not necessarily following the pair invocation model in terms of pricing and cost structure. And they're not necessarily building containerized services directly around functions, but they're adjacent. They have some of the pieces. The ability to very quickly on