PurePerformance - 083 My career path towards Serverless and what I wish I had known about Lambda with Nicki Klein

Episode Date: April 1, 2019

Nicki (@nicki_23) was bored in finance, started to learn .NET development on the side and eventually won 250k at a hackathon she used for her startup. Now she is a “Digital” Technical Evangelist at AWS and spreads her passion about Serverless through twitch and shares her code examples on githubTune in if you want to learn more about which things you should know about Serverless and Lambda. We chat about IAM permissions, timeouts, API Gateway and how a CI/CD Pipeline for Lambdas should look likehttps://twitter.com/nicki_23?lang=enhttps://www.twitch.tv/awshttps://github.com/kneekey23

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have my guest here with me, Andy, not my guest, my co-host. Sorry, Andy. My co-host, Andy Grabner. I'm a little bit not all there in my head today.

Anyway, Andy, how are you doing? It's been a little while. I know it's been a while. It's always hard to say it's been a while for the two of us, but it's not been a while for our listeners because they get these podcasts every other week. Things have been going good. It's a little strange, though, because we really got used to spring temperatures here. And then last night we had a snowstorm, and it's kind of strange. Oh, and we're set to have a major blizzard here tomorrow in Denver.

It's 60 degrees today and tomorrow it's supposed to be a huge blizzard, so we'll see what happens. Yeah. Which means the skiing season still goes on, which is good. Oh, yeah, it's extended this year. Yep, it's extended. But we're also getting avalanches on the highways. That's not a good thing. All right.

Anyway, would you like to go ahead and introduce today's guest? I would love to. Shall we banter some more? No, I think it's good. So our guest today, actually, I met her about half a year ago in Detroit when she was presenting at DevOne, kind of our first version of DevOne in the U.S. Her name is Nikki Klein, Senior Technical Evangelist at Amazon Web Services.

And she was really, she was amazing on stage. And there's a couple of things that were amazing about her. The reason why we wanted to get her on the show. First of all, the topic she talked about, developing modern serverless applications on AWS. And that was nice. She did a live demo and it was clearly, it's always a tough thing to do something live on stage.

So kudos to her for that. But then I think what's also very interesting was kind of how she got into technology. And that's actually the story that I want to ask her in the beginning before we talk about serverless, hearing a little bit more about Nikki. So first of all, Nikki, hopefully you are there with us. I'm here. I was just quietly listening.

So, well, thanks for joining us today. Thank you for having me. Yeah, maybe I know you are in New York as we speak, I believe so, right? I am in New York right now. But that's not your usual home, is it? No, I am based in Seattle. All right. And for the people that haven't crossed paths with you yet, with your work as an evangelist, can you quickly introduce yourself, what you do right now for AWS and kind of what's your role? Yeah. So I'm a software developer by trade and a developer evangelist, if you're not familiar.

It's just a software engineer that teaches developers how to do things like either on AWS or wherever they work, wherever they're an evangelist. And specifically, my role is digital. So I'm a digital evangelist. So you'll find me on podcasts, on live streams, on YouTube, on Twitch, on Facebook Live, on Stack Overflow, all of our digital channels are where the digital streaming evangelists show up. And that's where I spend most of my time. Cool. I had no clue that you actually differentiate between a digital evangelist and I guess a regular evangelist.

I had no clue, but it makes, I guess, so does this mean, and if I ask this kind of direct question, does this mean in your job role, you actually get, I don't know, rated by the number of blog posts you have and the number of podcasts is this kind of how they i'm not sure if rating is the right term but is this something that you have in your goals yes these are metrics i need to meet so by being on this podcast you are

helping me with those metrics um yeah so me streaming um on Twitch helps drive the metrics that my goals, my personal goals are trying to meet. And regional evangelists is what they're called. Their goals are more related to public speaking. But you also do public speaking, right? Because I saw you in Detroit. Yes. So anytime that I want to do public speaking, because I particularly am in love with an audience or a conference or, yeah, I can say yes. But it's really, it doesn't necessarily help me meet my metrics, but it's up to me.

So that's cool. So you get to do all the fun stuff about speaking and presenting and everything all kind of comfortably from maybe from home or whatever right but whenever you feel like it you can go out and speak as opposed to a lot of these other speakers who spend their life on the road that's correct that's one of the benefits of streaming that's amazing that's pretty awesome yeah and do you want to tell us a little bit before i definitely want to talk about serverless because it is. We had a couple of people on the show in the last couple of months talking about serverless. But I really like kind of your background, like how you got into the position where you are right now, what you did before AWS.

Because I think it's nice to hear people's life stories and how they change paths in their career and how they end up where they end up, how they end up in the things that they're passionate about. So maybe you want to walk us a little bit through that? Absolutely. So I actually had four careers before I became a software engineer. So I dabbled in a lot of different things. I went into the finance industry. I actually worked in hardware for a hot second.

And ultimately, I don't know why I did not like see myself in tech like as a career, but I didn't when I first graduated college. And it's weird because I've been obsessed with technology since I was a little kid. I always had the new hot thing. I had to have it. And I always took apart my mom's computer and put it back together again. And I would do all kinds of weird things that my parents would look at me and be like, what is she doing right now? So, but I never really thought that I could become an engineer. And then I was working in the finance industry, actually at JP Morgan, and I was bored out of my mind, like couldn't stimulate me if you tried.

I would get in at 6 a.m. and I would finish all the things I needed to do by 8 a.m. And I would sit there from 8 a.m. till 3 p.m. racking my brain for what on earth I could possibly do. I would read every single article online that you could find. I would text every single person on my phone. My mom told me I needed a life. Like it was, it was bad. It was like to a point where I've reached like so, so many low levels of boredom. Like my Facebook newsfeed couldn't update fast enough to entertain me. That's like a serious low by the way. So I was like, okay, what can I possibly do that is a sustainable career that I can do forever? Because my other careers that I had jumped into after college had also bored me, but finance had especially bored me just because I was really efficient and fast.

And like nothing, there's nothing that really changes. Like things go up and down, like the stock market goes up and down and new companies pop up and arise, but there's nothing really different to learn. Like once you understand the concepts, you understand them and you know how things are going to go for the most part. There's always unexpected, but it's not like software engineering where I have to learn something new every day. So I sat there and I'm like, okay, what am I going to do with the rest of my life?

And I thought about when I was a kid, I really loved puzzles and I also loved Legos. So I'm like, okay, I need a job that involves building and problem solving. Because I remember being a kid and sitting in a room for eight hours doing a puzzle and even forgetting to eat. The point where my mom was like, did you eat lunch today? Like, oh, right. I didn't do that. I would just get so invested in completing the puzzle that I would forget all about everything around me. And so I wanted that kind of focus

and excitement in my own career. So I'm like, okay, Google jobs with building and problem solving, coding naturally came up. So I started coding at my desk at JP Morgan during those, you know, six hours where I was doing absolutely nothing. And, uh, and then after four months of coding at my desk, I was like, okay, I have to make this real. Like this needs to be my career because I'm obviously way more invested in this than I am at those two hours I put in every morning. Um, and so then I started looking for like, you know, uh, post-bac programs and like all kinds of things. And bootcamps were not really a thing at that time. So like the word didn't like register to me to Google or look for. And so I

looked for all kinds of like post-bac programs or like how to get a CS degree or how to do this. And one time I did the Google search and the word bootcamp came up and I was like, what is this? Looked into it. There was only one available. It was hack reactor. Um, and which required me to move. Cause I lived in LA at the time and I was like, oh man, I'm gonna have to move to San Francisco and live off my savings to attend this one boot camp. There's gotta be a better way. But I applied naturally. And I had this whole plan of how I was going to move out. And, uh, and then like two weeks later, uh, this bootcamp in LA contacted me and they were brand new and, uh, you know, stupid me didn't ask a

single question. They were like, do you want to, do you want to be a part of it? I was like, yes, normal person would probably have asked like, how many success stories have you had? Like, like, what do you teach people? Like, what stack am I learning? Like, I didn't ask a single question. I was like, yeah, sign me up. Like, where do I sign? So I went to this boot camp and I learned how to code on the weekends, which they don't do anymore at any boot camp I've looked at. And I worked my 40 hour job at JP Morgan, which was really not 40 hours, but I still had to be there for all 40 of them. And then I did 20 hours of coding at night during the week and 20 hours on the weekend. And I got a job a week after graduation as a.NET developer, for which I did

for two years before starting my own company. And then I did that for another two years before coming to AWS. So coding for a total of five years. But the first year was mostly at my desk at J.P. Morgan or at home. It's funny. There's a similar parallel sort of between your path and mine in a bit because I was, as I mentioned before we started the show, a communication major. But while you were working at JPMC, I was working at CNBC recording on all the financial news. I was walking that show every day. Well, yeah. We always used to joke people only had it on for the ticker, right? Because it was a free ticker.

But in a similar way, I felt like I was in a dead-end job. I decided this is not what I want to do. And I had a friend working in some startup. This was in 2000 or 2001, I think. And he was making twice my salary. So my impetus was actually just like, well, if I'm going to hate my job, I should get paid more to hate my job. Yeah. I didn't even know how much software engineers got paid. Like I didn't even do it for money at all. Like there was no... That's all I did it for. That's the only

reason why I did it. Cause I was like, I'm going to hate my job no matter what. Cause I wanted to be a musician. But then I got into QA and then I quickly got into performance and then everything just started taking off from there but yeah i just didn't want to be bored anymore that was my ultimate goal was like i don't really care how much money i make i just don't want to be bored yeah i'll kill myself if i have to work for you know however many years like the next 40 years and be this bored like i can't i won't survive yeah so it's it's important to uh to find that breaking point and and make a change when you need to but anyway um andy you you went straight in right you uh you went to performance right away or uh no i was delighted i attended a high school for software engineering so i finished when i was

18 dang and then uh yeah i knew what i wanted to do and pretty early on and i think that if like my parents had like known anything about like compute like neither of my parents are in software computers or technology at all my dad's an attorney and my mom worked in the oil industry and then became a stay-at-home mom so like neither one had you know the knowledge to direct me towards software engineering but had somebody known that my interest in computers from a young age would make me a lot of money and be a great career for me, like maybe I would have been like on the path from like age seven. But nobody nobody knew to tell me anything. I had to figure it out. Hey, I got two questions, actually.

The first one going back to the boot camp, can you explain that a little more?'s world, like right now, you will be investing usually three months of your time in a full-time boot camp, meaning Monday through Friday. So my boot camp was Saturday and Saturdays and Sundays, and it was 10 hours each day. So 10 hours on Saturday, 10 hours on Sunday. And then that's usually not something that you can find where you can do a weekend boot camp. So now modern boot camps will make you commit to full-time to weekdays. So you have to quit your job and commit to it full-time. They don't want any distractions. You know, that's kind of severe, I think.

I go back to my cousin who, he's a pilot, and he wanted to fly you know for the major airlines and i really think that kind of an approach um that you're describing really fits the airline industry which is a real huge hurdle for people because for him it was a similar thing he could wouldn't be able to work he was gonna have to pay i think 60 grand for the course and then get out and become like a junior pilot for a major airline making 28 000 a year you know so it's one of those situations where with these boot camps, even the way you're describing it, it gives people a really hard choice because how are you supposed to live or pay rent? I guess you have to still be living at home unless you get that weekend option.

Yeah, it is tough, but there are scholarships, especially for diversity that is interested in tech, to go to one of these boot camps. Also, if you are a veteran, there are boot camps on the GI Bill so that when you get back from – Yeah. So there are ways to attend a boot camp without being completely put out. But, yeah, if you don't meet any of those categories, you might have to live off of your parents or have a nighttime part-time job where you just work nights. But it would be very difficult. I agree.

Hey, then. So second question, you mentioned it and maybe you wanted to talk more about it. But you said after the boot camp, you started your own startup, right? Yeah. So I worked as an engineer for two years, and then I started a company. And my company actually started out of a hackathon. So I won a pretty large hackathon in San Francisco where I won a quarter of a million dollars in investment in the idea. And it was called BetaGig.

So BetaGig is named after exactly what it does. So beta test your next gig. It's just a clever way of saying try out your next job. So obviously, I had this really interesting past where I had many different careers before I entered tech. And I would have loved to have been able to try out what it was going to be like before taking a job or entering into a new career. And so the way that beta gig works is that instead of grilling someone, when you hire them, you actually just bring them on for a day and they like incorporate it into your team and their job shadowing. And they can do some work, but whatever work they do, you can't actually use unless you hire them for legal reasons, obviously. But job

shadowing is considered a bonafide education experience. And so it's 100% legal. And then if you liked working with them for the day, and they really enjoyed working with you for the day, then you could move them through the hiring process. So you could put them through any other loops that you needed to make sure that they were a good hire. But basically, you get to see what it's like to work with them. And they get to see what it's like to work with you. And then usually it results in a longer hire and less turnover for both cultural reasons you know job fit career fit mental fit all the things and so that's a great idea yeah thanks so so but but help me help me understand so that meansGig was the platform that you built to provide a platform for companies that wanted to hire people. And you connected them?

So it was like a marketplace platform. So users would sign up like job seekers and then companies would sign up and offer job shadowing gigs. So let's say that DevOne or Dynatrace was hiring a software engineer and you would post your software engineering gig and you would set up a job shadowing day and the platform would actually help you arrange for how to schedule that job shadowing day, like how to create an agenda for the candidate, how to create things that you are, that you're going to get a lot out of and the candidates going to get a lot of out of. And then basically similar to the experience of Airbnb, the, if you accepted a candidate, so candidates would request to shadow at your company for that gig. You could review, you know, who they are, their resume, their skills. You could even set up a phone screen initially if you wanted to. And then if you'd like to move forward with the job shadow, you accept the request and then they receive the agenda for the day.

And then they get the address and the information and then they show up. Pretty cool. Very similar to Airbnb. Well, and so I would assume now you move to AWS. That means you made the company successful and then sold it for... No, I wish. I raised $1.6 million from a VC and they received a controlling stake in my company. And unfortunately, they shut us down without true cause, in my opinion.

But it just was a political nightmare, mostly. And it was very sudden and unexpected. Okay. So a life lesson learned, even not a pleasant one, but at least a life lesson learned how to deal with VCs. A lot of life lessons learned, for sure. I don't regret anything I did. But if I were to do it again, I would do a ton of things differently. I probably would not have a co-founder. I don't

know that I would necessarily raise around even immediately. I might do so like much later on in the future. Unfortunately, the conditions that I started the company in forced me to fundraise sooner than maybe I would have if I had stayed at a steady job and kept working while I built the company. But once I won the hackathon, I was pretty much forced to quit my job because I got into an accelerator and I got all this money. And they were like, yeah, you know, keep my job full time and build the company in the evenings or the weekends until I felt like it was at a place where it was pretty much taking off and maybe I wouldn't need to fundraise. That's the hope. I also probably wouldn't start a marketplace. That is an extremely difficult thing to start, especially for your first company.

You have the classic chicken and the egg problem. And it just creates a lot of problems. And it makes you go a little bit slower than you might have liked or that maybe you would have, even with funding. So then did you find the show Silicon Valley cathartic or was it more like reliving a nightmare? I lived that show. Like I would watch an episode and then the next week that thing would happen to me. And I'd be like, oh my God, this is like not happening right now. Or vice versa. I'd watch the show and something would happen. And the next week, the same thing would happen to me. And I'd be like, huh, well, um, let me think back to Silicon Valley. What happened then? What did

the, what did somebody do? What was the solve? What was the solution to this problem? Um, so yeah, I definitely lived Silicon Valley. It's a very realistic show. Yeah. Well, I got to give huge kudos to you because obviously I've never started a company. Don't know if I ever will. But that's amazing that two years after going through that boot camp, you were in that spot already.

So that's that alone. I didn't think I would be there either. It's funny. The boot camp recorded a video of me saying, you know, at the end of the bootcamp, they were like, help us record this video for promotion.

I'm like, sure, no problem. And so they asked me a bunch of questions like, how was your experience? What did you learn? Blah, blah,

blah. And then the last question was like, where do you see yourself in the next five years? And I don't even remember saying this, but I was like, Oh yeah. The next five years I want to start my own company. And then I did it in two and they like sent me back the video.

They were like, do you remember saying this? Like, Oh my God, no, totally forgot. But I didn't have the plan to do it so quickly after it's, it really was, uh, the hackathon that kicked it off. And, uh, I didn't expect to win that hackathon. I don't think anybody expected me to win that hackathon because the audience was definitely almost upset. So anyway, now that brings you to AWS and your really cool digital, what do you call it, digital evangelist? Digital streaming evangelist or digital evangelist. So that was the next step after beta gig, right?

Yeah. So luckily, like the company, I said, ended very suddenly. Like I came in on a Friday morning and at 10 a.m. I was told I needed to fire everyone and that the company was shutting down. So I was not even thinking about the next job, but my advisors had my back and they put out all their feelers. And pretty much within a week, I had every top tech company contacting me for a role. And I went with AWS. I've used AWS since I became a developer in the very early days. And also with serverless, I helped my first company that I worked at just as a developer build like a serverless microservice. And so I was really interested in serverless.

And then obviously my next choice was to come to AWS. And now I'm here a year later. And when did you, at which point did you move from LA up to Seattle? Because you obviously moved. Yeah, I moved from LA to Seattle January 5th of 2018. Okay, so it was basically when you were already working for AWS. Yeah, no, they relocated me. Yeah, cool.

Yeah. I'm actually moving again. I'm moving to the Bay Area in a month. Oh, why then? Two of my shows are streamed from the San Francisco office. One is about startups. So I interview startups building on AWS. So my heart obviously still lies with startups. You know, my first company that I worked for was kind of a startup.

It was just like a 12 year old startup, but still a smaller company. I like the small feel. And then when I started my company, we were definitely a startup. We were a team of 10. And so my heart very much still lies with the startup community. And so one of my shows, I feature guests from the startup community building on AWS. So, Brian, that means we need to come up with a great idea, build a startup in order to get on her show.

Well, my idea for a startup is a reliable podcast remote recording program. Because I'm telling you, the ones out there are not very reliable. Well, if you build it, I welcome you to come on the show and talk about it. Yeah, that's the problem, building it. The show, it's streamed from Twitch Tuesdays at 9 a.m. Pacific time. So it actually was just a couple of hours ago. Okay. Yeah, so you go back to back a lot with these then. And we're going to put the links to

your shows, but just for people who, I think it's pretty simple for the Twitch one, do you want to mention where that is right now? Yeah. So to watch any of my shows on Twitch, you would just go to twitch.tv slash AWS. And I will start streaming on my own channel. I haven't been able to get up the setup yet, but that will start soon. And the channel is just K-N-E-E-K-E-Y 23. So it's just my name as an oronym. I'm a linguist major. So that's my thing. So it's knee and then key. So you didn't buy a Nikki.dev? I didn't. I thought about it. First of all i would have bought knee key like the neat like your knee and then a key because it's just it's my it's my little organ in that i'm obsessed with

um but i i thought about it and then i was like like what is the purpose of this like what would i do with this besides like just throw my resume up there or something basic um but you know it's not too late i could still buy it now. It's probably ridiculously expensive. Yeah. So anyway, go ahead, Eddie. Switching gears a little bit. So obviously you have a lot of experience with serverless

as you've built serverless microservices with your first job, basically after boot camp and since then been promoting it. If people are, you know, getting our listeners, I think we have a couple of those, a couple of listeners that are already familiar with serverless and maybe built serverless applications, microservices, whatever you want to call them. But what can you tell our listeners? And when you got started, what were the things you wish you

would have known, uh, back then when you started? So things like, like, you know, the, the, the classical mistakes that the people should not make when they get started now. All right. Well, the first one you usually run up against, um, is IAM permissions, actually. So the thing about AWS is developers were not first AWS, right? It was, you know, ops, ops, people, infrastructure, people were first AWS. And I feel like a lot of developers became truly interested in working with AWS when Lambda was first released. And that's actually what piqued my interest in AWS and what has consistently piqued my interest moving forward. And because it's just amazing

that I can just run something without touching the ops. Like I am not an ops person. I'm a developer. And while I've learned my basic set of op skills to do a lot of things like deploy and CICD, I truly love the ability to just write code and not worry about it and run it serverlessly. And so the first thing you run up against is something that if you've never used AWS before, I see a lot of developers run up against it because they just are not familiar with AWS. And that is IAM permissions. And so having an understanding of IAM roles and how they work and how to give them permissions to execute your Lambda or even give your Lambda role permissions to do something else inside AWS.

So typically when you write a Lambda function or a Lambda serverless app, you are probably using other services in conjunction with Lambda. So maybe you're hitting Dynamo, you're depositing data in DynamoDB, maybe you're putting data in a queue in SQS, maybe you're sending out a notification with SNS, you could be doing a lot of different things, and you're most likely using it in conjunction with an AWS service. And so you need to make sure that your IAM role that is running your Lambda function not only has permission to execute your Lambda function,

but also has permission to do the number of things that you've written the code to do. So maybe you've used the SDK to deposit something in Dynamo. You need to give the IAM role permission to insert something in Dynamo, for example. So that's usually the first thing that I see developers run up against. The next thing would be timeout. So if you're not familiar with serverless, you definitely should not be writing a serverless function for a process that you need running for like an endless amount of time. Like that you should still spin up a server for. The timeout limit is 15 minutes. but when I started developing serverlessly, it was five minutes. So it was even less time. They did up the timeout, but the concept of the timeout is more of

a mental concept than it is anything else. Because if I need a process running for three hours, then I am not going to choose a Lambda function. That is the wrong way for me to go. And so understanding just that not only do you have a limit to how long your function. That is the wrong way for me to go. And so understanding just that not only do you have a limit to how long your function is going to run for, but just from an infrastructure standpoint, picking and choosing the things that should run serverlessly to reduce costs is a really, really smart move that you can make. So if something you only need it to run when basically when something else happens, that is a great use case for Lambda. So when somebody clicks this button, I need X to happen. And only when they

click this button, and it is not a three hour running process. It is just a, you know, two minute thing that I need to happen when somebody does X. That's a great process for a Lambda. So another great thing that I like to use Lambda for is APIs. So, you know, I have a bunch of API endpoints and each endpoint does something specific to data. Maybe it's an insert, an update, a get. Those processes are all definitely under five minutes. And so I definitely am going to use Lambda for my API endpoints. Well, most likely they're under five minutes if you're not running like a super long query to a SQL server database. Most likely it's a great use case for serverless.

So those are the top two things I see like new developers with serverless run into. Trying to think about what else. Sometimes memory issues come up so you can change the memory on a Lambda. It's default set to like, what is it? Like, I think I forget the default. I think it's like 15 megabytes. It might be less, but yeah. So if you, you'll, you'll see the errors come up in the console, usually when you run into these first few errors and you might not know what they mean if you haven't seen them before. But usually those are the first three. And sometimes even I run into them because I forget and I'm like just writing code and I push

it and I'm like, what is this error? Oh man, I forgot to add permissions. So it just, it's one of those things that happens even if you've been coding with Lambda for a long time. So, so in terms of the, you know, you don't want it to be a long running job and you don't want it to be a long running job. And you don't want it to be being invoked so many times that it might be cheaper to just have something up and running all the time for it. But we've talked to some people, and I kind of want to get your take on this, where if it just runs once every now and then, right? I forget what the keep alive of the Lambda component is. But, you know, first time it runs, it's going to take a little longer to start up and kick in. Cold start.

Yeah, the cold start. Thank you. There's a balance between having it up and running and being able to serve people, but if you're running too often, you might as well just have something. It might be cheaper to just have a container up and running the whole time. Do you have any thoughts on how you figure out that balance? That's a tough balance, but I actually have created serverless applications that I need running the whole time because you can host like an entirely, like for example, I'm going to use.NET.

You can host an ASP.NET web application on Lambda. So like when you pull up, you know, a URL, it displays a.NET application. And the first time you load it, you might hit run up against that cold start. But the way to avoid the cold start is to just set a CloudWatch event to retrigger your Lambda like every five minutes so that you never run up against that cold start. But obviously, if you have a really long running process and it's very memory intensive and you know that it's going to take this X amount of time that's way longer than a Lambda should be running, then you should definitely just spin up a container. If you also would like to be able to control the host, that is a really good instance when you're going to want to pick a container over serverless because serverless is serverless for that reason. It means I'm not touching the host. I am not controlling the host. I'm not setting it up. I'm not patching the host. I'm

not doing anything to the host. I'm just giving it some code to run. But if I need to control the host, if I need to install specific things that I need to be able to control every ounce of my host, then I'm going to want my own container and I'm going to want to write a Docker file so that I can control every last ounce of it. So really, AWS is all about granularity of control. And most of the services are either I want a ton of control. I want to control every last ounce of this, or I don't want any control. So serverless is on that other end, which is like, I don't want any control. Like, give me the basic things that I need to select.

And that's it. And, you know, all the way up to a virtual instance is going to be, I want, you know, that granular level of control. I want to control every single thing down to the last byte. So that's really the difference. And I would say when you're picking between containers and serverless, keeping that in mind is probably the biggest factor beyond just, I have a long running process. I don't know how to keep it running without dealing with a cold start. Right. Hey, I got two questions here on something you said earlier.

The first one, coming back to the permissions, I assume the permissions, like allowing my Lambda function to, let's say, call DynamoDB, that's not enforced within the SDK, but it has to be enforced on a different level because I can either use the SDK or I can just call the REST APIs from DynamoDB. So I assume it's enforced somewhere else. What do you know that? So what do you mean by enforced? So if you're using the SDK, so if you wrote a Lambda function and you are writing code in your SDK to hit Dynamo and you're deploying that to Lambda, your Lambda IAM role has to have permission to hit Dynamo because the way it works is that once your code gets into

Lambda, it pulls the credentials from that IAM role. And so then it's only allowed to do things that the IAM role is allowed to do. And so if the IAM role is not allowed to insert to Dynamo or update to Dynamo, then it's going to give you an error message of permission denied. Does that make sense? That makes sense. I was just thinking, I think there's two ways of calling, let's say DynamoDB, right? I could either use the SDK or I could, and maybe I'm wrong, but I assume I could also just call the rest endpoints of DynamoDB. Yeah, no, you absolutely could. But in both cases, the credentials.

Yeah, you're right. So you don't add any credentials, right? When you deploy your code. So if you're testing serverless code, you need local credentials so that locally you could test. But once you deploy it into Lambda, Lambda doesn't need your credentials because Lambda already has them, right? It's already in the cloud.

And it's basically pulling the IAM role to say what permissions those credentials have. And so whether you're hitting the API endpoint or using the SDK, which is essentially the same thing, just one is easier, you still need to have permissions on that role to do that. Okay. Makes sense. Another thing, and I'm not sure, I think we had somebody on the show a while ago. He was a consultant and has built several of his applications in the past.

And I think he brought up an interesting point in terms of costs, because we always say that Lambdas are fairly cheap per invocation. But then he said, if you're exposing Lambda endpoints to the outside world through the API gateway, then obviously you have to pay for the API gateway as well. And he brought up a point saying that the API gateway is X times more expensive than Lambda. And therefore, per Lambda execution, it's a factor in the additional cost of the API gateway. And then he said they have models where they actually calculate at each particular point. Is it cheaper to take all your Lambda logic and actually put it into a container and then just expose that to the outside world versus going via the API gateway? So my question to you is, is this still accurate? Is the API gateway still, let's say, a cost component we really have to look into when exposing serverless to the outside world? Yeah. So if you need your Lambda

to be exposed to the outside world, there are two ways to do it. You could use API gateway. You could also use Elastic Load Balancer, ALB now, to hit Lambdas. So if you have an ALB, or no, sorry, I said EL, I said Elastic Load Balancer, but what I really meant is Application Load Balancer. Yeah, ALB, yeah. So if you have an ALB, you can now use it to hit your Lambda as of reInvent last year. And so that might actually be different pricing. What I do know about the free

tier though, is that Lambda is you get 1 million free requests per month in eternally, like indefinitely, like till the end of time, like there's no, the free tier for that does not end ever. So it doesn't matter how long you've had your account. So let's say you had a website that was hosted on Lambda, You would pretty much only be paying for your API gateway usage if your website was hit less than a million times a month. Yeah, makes sense. Cool. Last question that I have is nothing to something you said earlier, but just in general, because we are talking with our customers a lot about doing blue-green deployments, canary releases,

you know, then, you know, testing obviously their code in CICD and then using automated quality gates to, let's say, stop the promotion of a container into the next phase in case we see, you we see bad performance behavior, for instance. How does this work with Lambda? What are the best practices there in terms of pushing it through different stages in terms of blue-green deployments or canary? Is there any best practices around that? Yeah. So, Lambdas have versions. So, most likely what you... I mean, I'm not actually familiar with how you would do this. Let me just preface by saying that. And I'm sure that there's a ton of people on the internet that have an opinion one way or the other. But what I would do if I was doing this is I would deploy a new version of my Lambda and then I wouldn't let it go live until I tested it using any number of testing tools. And then I would basically set the newest version to go green. That's probably how I would do it. And you can update versions

of Lambda layers as well as Lambda functions and only send that version to be the one that's displayed. Okay, so you just brought up Lambda layers. i think that's also a new rather than the layers is really cool yeah yeah it is something new um if you have not heard of it it launched at reinvent um so with lambda layers you can also bring your own run times now so if we do not support the language that you would like to write your lambda in you can now write a runtime in a Lambda layer that you can reuse for all of your Lambdas. So I know that Stackery actually wrote a PHP Lambda layer. And so now if you wanted to write a Lambda function in PHP, you could actually just reuse their layer. They've made it public. They just hand out the ARN, the Amazon resource name on their GitHub.

And all you have to do is drop in that ARN. When you say add a layer in the Lambda console, it's a very, very easy GUI. And then you've added that layer, and then you can now write a Lambda function in PHP. But another use case for layers would be for libraries. So you have a you have a custom library that you're creating that you want to use on all of your Lambdas, you can create a layer for it, and now you can reuse code. So the best way to think about layers is just like reusable building blocks. That's funny, Andy. That reminds me of, I think it was the same person we were speaking with about the

API endpoints, where they've seen people kind of go to an extreme with Lambda, where they've seen people kind of go to an extreme with Lambda where they're basically recreating every single JVM function or every single Java function in a Lambda where, you know, this was kind of humorous, Nikki, where it was all of those built-in functions of Java were being created as Lambdas instead of just saying, hey, let's go back and use the actual JVM because we need all these components anyway.

So some people went overboard because they wanted to do lambda. It sounds like you could obviously get into that kind of trouble with this, but it also just seems like if I try to understand this, it's just basically reusable functions that you can share. Is that kind of a very simplistic way of saying it? Yeah, and we also support Java, so you wouldn't actually need to do that because we will run the JVM.

So yeah, but layers are a really, really neat thing. Like if you haven't checked them out and you've been in the serverless world for a while, I highly suggest you check out layers. It's really, really great for libraries, custom libraries, even other libraries that you're like, I'm going to use this library on every single function I write, you know, for the next 10 functions.

And so then you can just write one layer and install that layer on every single Lambda that you write. So you can reuse your own code. You can reuse other code. So if somebody else wrote a layer and you already need that exact same piece of code and they made that layer public, like Stackery, for example, you can just use their layer. You can take their ARN if they're handing it out and just basically add that layer. I think there's also a GitHub that was made.

So my one probably complaint about layers would be that there's no one place to find all the public layers that people have created. Because obviously sharing code is just, that's what we do. That's what the developer community does. We just share code. Who wants to reinvent the wheel 17 million times? Definitely not me. So there's not one place where you can go and find all the public layers right now. I'm hoping that there will be soon, but there is a GitHub called awesome lambda layers. I think that's what it's called. And it lists all the layers that are public with the Amazon resource name. So you can just pull any one of them and drop it into your Lambda console.

Pretty cool. I think we are our Dynatrace agent team for Lambda monitoring. I think they also consider layers in order for us to get our agent in there. Because we have different, we had Lambda monitoring for a while, and I think we proposed different options on how to get our agent injected into your Lambda code. And I think layers is something we're now looking into already, maybe have done it. So that's pretty cool.

It's definitely really cool. Yeah. Hey, I still have one more question on the whole CI, CD because you mentioned this earlier. If I start from scratch with a new Lambda function that I'm going to use for my Angular apps and it just does some business logic, what's your proposed pipeline? How does a pipeline look like for you when building

Lambda functions that are exposed to the outside world? So what kind of phases does a pipeline entail? What type of tests do you run? And just out of curiosity. Yeah, I would probably use AWS CodeBuild just because I'm going to use AWS anything. But there are plenty of other build tools that you could use like Jenkins. But my tests, they'd probably be pretty basic. I'm not a huge fan of writing unit tests. And mostly the code I write these days is demo code or how to do something really quickly. It's less production code.

But if I were writing production code, I would obviously have my code in GitHub. And then I would have a code build project that gets the source code from GitHub. And then there would be a SAM template included in that repository. And then basically, that would be the deployment configuration for code build to be able to deploy that Lambda to production. So if you've not heard of AWS SAM and you just started writing serverless applications or you've been doing it for a while, I highly suggest you to take a look at SAM. SAM stands for the Serverless Application Model, and it is essentially an extension of CloudFormation. And if you've never heard of CloudFormation, CloudFormation is just infrastructure as code. So imagine your Amazon Web Services resources written out as a big JSON object or YAML file. So you know,

in the console, you set a bunch of properties that you want. So in the JSON file, you list out those properties as key value pairs. And SAM is an extension of that. And so it is a specific JSON object that you can write for serverless applications. It is expecting, you know, certain things like API gateway, if you're going to set up an endpoint, it's basically the parts of CloudFormation that you would have wanted for your serverless application, because we pretty much know which services you're going to use in conjunction with Lambda. And so it's really easy to set up a serverless application using SAM. And there's another part of SAM that's not just the template.

It is the CLI. And so I would use the CLI to actually deploy. And so I can tell AWS CodeBuild. I can give it commands, you know, in a build file. You know, SAM deploy. Basically, I can give it commands, you know, in a build file, you know, Ada or SAM deploy, basically, I can write a SAM deploy statement, and I can actually use SAM CLI to run my code locally. So before I even test it, I can do SAM local start API or invoke function, depending on what it is that I'm invoking. And I can give it you know, an object if I needed to give it an event, I can do a whole

host of things with the SAM CLI locally, and also in code build if I'm ready to deploy. And then once I do that with SAM, it basically is just going to pull that template and provision those resources or update those resources if I'm redeploying. And that's basically it that's essentially what i would do um so i would just use github and code build and sam pretty cool awesome um nick is there anything else that we missed i think we talked about your career in the beginning which was very cool and very enlightening on kind of path you took and then about so is there anything missing on serverless or anything you want to add on the career path that we may have missed i guess what i would say with serverless if you are listening and you haven't built a serverless application before um i do a really cool show with my colleague am called build with am and nikki and we have

basically built uh two serverless applications at this point live on Twitch. And then the VODs are available on YouTube and our site afterwards. So if you go to aws.amazon.com slash Twitch, you can find the show there with all the links to watch any of the episodes. Most recently, we have been building a mobile application in React Native with a serverless backend in Node. So that's probably relevant to a lot of audiences, I hope. And then previously, we built a.NET serverless application in the first season, also with a container as well, a.NET container. So that was a little bit of containers and serverless for you. And then I'm also working on a serverless Twitch extension.

So if you're not familiar with Twitch extensions, if you watch Twitch frequently, Twitch extensions allow you to interact with either the player, the hoster, the broadcaster. They let you do a lot of different things on Twitch and you can build one, um, with a backend. And obviously I, I always choose serverless. So I'm currently building one with a serverless backend. And that show is live on Wednesdays at 10 AM Pacific time on twitch.tv slash AWS. That's really cool. Live coding.

I've never heard of it all the time. Who would have thought, right? Live coding is an art. There's actually a way to perfect how you live code. Yeah. Well, we're seeing more people do that, right, Andy, in some of the presentations I know. Who's the guy from Pivotal?

Tosh Long. What's his name? Yeah, he loves to do actual live coding during his presentations, his live presentations, which what can go wrong? Like eight, nine things. Right. So it's kind of fun and exciting to see the live coding going on. Also because the one thing I love to point out is you see as someone who might be a developer or who's learning, you see the experts up there, live coding. I'm not a big fan of the word expert, but that's how you feel. You're watching these pros do the live coding, and then something goes wrong.

You're like, oh, wait, it happens to everybody. It's really cool from that point of view as well. I love pair programming with my audience, too. It's really fun to get like the audience really involved. And so like I think the art to live coding is finding the balance between real life coding where you run into like 100 roadblocks and then like robotic coding where you run into no roadblocks. So like somewhere in the middle there. So like if you go through it one time, you might have seen some of the roadblocks and you might only hit two or three the next time you go through the same activity. And that's like the exact amount of roadblocks that the audience is like, hey, try this.

Hey, try this. And they're really invested and really involved. But if you hit too many roadblocks, the way you would do it is if you first time were coding something, then they get really uninterested after a while. Yeah. All right. Andy, did you want to shout out something in the subreddit or is there anything else you wanted to add? No, I think we should. Come on, do it!

All right. Well, Nikki, thank you so much for being on the show today. And it's been quite fascinating to hear your story from being completely bored with a financial institution and therefore on the side. I think I wrote it down correctly.

Hopefully, code naturally is what you found and then started getting into coding. Then thanks to the boot camp in LA, getting you to work for an organization, writing your first Lambda functions, then winning a 250K pod at Hackathon, which allowed you then to start Beta Geek, which obviously didn't turn out quite the way you wanted it,

but still life lessons learned, which ultimately then brought you over these many, many steps to the job you have right now at AWS, where you're promoting AWS Serverless as a digital evangelist, also something that I learned new, what that is, the difference to a regular evangelist. Now, what I can say on the Serverless side, I really like the things you brought up because I asked you things I wish I would have known in case I would start with serverless from scratch. Definitely the IEM permissions.

People have to figure out what the whole permissions are all about, especially when you come kind of fresh as a developer into a world that was initially intended for more operations folks and where security and permissions are obviously a big thing. So try to get into and understand IAM permissions. I also like when you talked about the timeouts, not everything that you think should be a Lambda function might be suitable for a Lambda function. I think you mentioned, you said something like the timeout is more like a mindset, but still you need to break down things into smaller pieces.

And if it cannot be broken down into a smaller piece, then Lambda is just not the right thing. And there's obviously a lot of great content you have out there. So check out your shows on Twitch. If you want to see some live coding, your show with, I think it's called Build with AM at Nikki. And we'll post all the links also on the podcast summary page so people can definitely find it. And it was just enlightening and inspiring to hear that you always knew that you want to do probably something with technology. Once you started disassembling and then reassembling the computer of your mom until years later,

you actually got into engineering. And then now you are teaching others how to build cool stuff. And I think that's inspiring. And hopefully our paths cross again in the future, maybe at DevOne, at another version of DevOne or at the conference like the Lakeside Hackfest that I want to forward to you, that could also be a great opportunity. And yeah, thank you so much

for being on the show. Thank you so much for having me today. It's been a lot of fun. A lot of topics we covered. This is my job. Excellent. And yeah, that's it, I guess. So thank you.

And one thing, Andy, obviously, I think this digital evangelist might work out for you better in the future once you start getting tired of traveling. They're hiring another one right now, actually. No, no, you can't take Andy from us. Oh, I didn't say that. He'll have to start it for Dynatrace. So it's awesome. That's a really awesome gig you have there.

Thank you for coming on the show. And thanks for sharing the information. If anybody else has any questions or comments, you can reach us at pure underscore DT on Twitter, or you can send an old-fashioned email to pureperformance at dynatrace.com. We'd love to hear from you, especially if you have any stories and you want to be a guest on the show.

And I guess from me and from Dynatrace, thank you. And thank you, Nikki, Andy. Thank you guys so much. My Twitter, by the way, is just Nikki underscore 23. You can also reach out to me if you have serverless questions. Happy to help.

Awesome. Thank you very much. Bye. Riverless questions. Happy to help. Awesome. Thank you very much.