About Mark Nunnikhoven

Mark 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/marknca
Personal website: https://markn.ca/
Trend Micro website: https://www.trendmicro.com/

Watch this episode on YouTube: https://youtu.be/QXZT-DQwGk0

Transcript:

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, anybody who wants to do business with us, so anybody who wants to take credit cards needs to adhere to these rules. If you don't take credit cards, you don't care about rules. So, that's the different way of looking at compliance. So it's very case by case. If we're building a gaming company, if we're taking in-app transactions like, Fortnite through the App Store, that's a huge bonus they get, is that Apple covers the PCI side of it. If they were doing it themselves, they would then have to be compliant. So if we're not falling under those anythings, if we're just making a cool little...

We're not falling under those anythings if we're just making a cool little game where you upload a photo and we give you back a funky version of that photo, we don't have to comply to anything, right? As long as it's just a promise to our users. So that's the general gist of compliance. I don't know why I did wavy jazz hands, but there it is.

Jeremy: Well, no, I think that makes sense. I mean, you need to do something to make compliance exciting because I think for most people you're right, it's a document they could read and easily fall asleep. If you have insomnia, then compliance documents are probably the way to go.

So the other thing you mentioned, though, is that, again, you are always responsible for your data. And I think up until fairly recently, there were no super strict laws on the book that were about privacy in general. And so obviously we get GDPR, right? What does it even stand for? The General Data Protection Regulations, right? Did I get that right?

Mark: Yeah, you did.

Jeremy: So, that is European, it has to do with the European Union and that came out and that was really strict. And what they said was essentially, "Hey, I don't care if you're hosting in the United States, if you're Amazon or Google or wherever you are, if it is a European user's data that you have, then you are subject to these bylaws." And then very recently, I mean the same type of law, I don't know if they were modeled together, but the CCPA, the California Consumer Protection Act that came out for the United States. And again, it was just for California residents users' data, but also extends and applies all these different places.

So these are very strict privacy control rules. I mean, it even gets to the point where you're supposed to have a privacy control officer and some of these other things, depending on the size of your company. If we go back to this idea of where our data is being sto...

About Mark Nunnikhoven

Mark 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/marknca
Personal website: https://markn.ca/
Trend Micro website: https://www.trendmicro.com/

Watch this episode on YouTube: https://youtu.be/aPg7WE3Q3SQ

Transcript:

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 book, that's an activity just amongst yourself, right? When you come to the digital world, everything we do leaves a trail somewhere. There are tons of exposures potentially. You as a user don't really have a ton of control over your data.

And one of the things that I wanted to do with this video series and with a bunch of my other work was just enlighten people to help sort of expose this so that they're aware, because one of the challenges I get on the security side of what I do, and it directly relates to the privacy side, is that people assume there are correct decisions. And really, the only incorrect decision is one that you are unaware that you're making. So you could make the argument that it's okay that you're tracked everywhere on the internet, and I think the trade-off you get for the free services may be correct, but if you're unaware that that is the trade-off, I think that's the problem. So that's the intention behind this video series, is to look at privacy issues, to look at some security issues, to help people just make a conscious decision instead of just being pulled along for the ride.

Jeremy: Right. Yeah, no, and I think that that's probably something that a lot of people miss, is that people say, "Well, I'll sign up for Facebook, and I will share every photo, every place that I visit, all my friends, all my likes, all my dislikes." And what I think people say is, "Oh, well, whatever. It's free." And they don't realize that they're the product, and most of that is because they are giving up so much of their privacy.

And it's actually funny. This just happened the other day to me, and I didn't even realize. I knew it was coming out, but Chrome just released a new update that blocked third-party cookies if they weren't... I think you had to have like "secure" on and some of these other things. So no user is going to have any idea what that actually means. But what happened for something we were doing is, we were loading a third-party cookie behind the scenes for something, and all of a sudden that stopped working. And so the whole flow of this module or this modal pop-up thing completely broke because of that extra thing of security. And I remember way back in the days of early web development dealing with IE5 and IE6 and the browser wars, like what works on this browser and what works on that browser. Now privacy seems to be the new browser war thing that are conflating those two things.

But anyway, so that's one thin...

About Xavier Lefèvre

Xavier 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_lefevre
• LinkedIn: https://www.linkedin.com/in/lefevrexavier/
• Medium Blog: https://medium.com/@xavierlefevre
• What a typical 100% Serverless Architecture looks like in AWS!
• Serverless Cost Calculator

Watch this episode on YouTube: https://youtu.be/pKc2f8Q0PQI

Transcript:

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 of generating your pages for itself, for you, for performance purposes or SU purposes. So that's one capacity in terms of front-end servers.

Jeremy: All right. So, now you've got your front end and you've got it hosted either in CloudFront or maybe even Amplify Console, which is different than Amplify, you can host SSGs there as well, and things like that. So, what about for domains and certificates, how do you manage your domain names and your certificates in a typical serverless architecture?

Xavier: Okay. So, there are two services that are quite famous as well in AWS, you're going to have certificate managers that's going to help you deal with your certificates, HTPS, and you're going to have Route 53 that's going to help you deal with your domains. They play directly, easily with the rest of your serverless architecture and you don't have much else to do. And we're talking ... something interesting as well, we're talking a lot about AWS, because it needs those services and from experience we found the serverless experience more, let's say more fit and more complete in AWS, but of course you can do this kind of stuff in other providers.

Jeremy: All right. So, now we've got all this stuff set up, this is our front end, now we actually want to be able to process APIs, so how do we build out our business APIs?

Xavier: Okay. So, there you have two choices, first about the routes you want to expose through the API, you have API Gateway, even more complicated, you have two API gateways, the View 1 NTP2, which are not named the View 1NTP2, not easy, and you have AppSync on the other side. Okay? So, if the API Gateway is about making REST APIs, AppSync is about making GraphQL APIs, mainly, if I have to just recap really fast. Of course, they have a lot of capacities inside, one API Gateway has an option to use API Gateway WebSocket, for instance to do realtime AppSync as embedded GraphQL substations, with pros and cons. So, we have those two, depending on what you want to do, REST or GraphQL. Okay...

About Alex Casalboni
Alex 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_casalboni
• LinkedIn: https://www.linkedin.com/in/alexcasalboni/ 
• Website: https://alexcasalboni.com/
• Dev.to: https://dev.to/alexcasalboni
• Medium: https://medium.com/@alexcasalboni 
• AWS Lambda Power Tuning Project: https://github.com/alexcasalboni/aws-lambda-power-tuning
• Deep 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/9ce2cef56a7d052d4f5e798b37083525

Watch this episode on YouTube: https://youtu.be/m2NB_0J5fms

Transcript

Jeremy: 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 Lambda Power Tuning evolving into something that would help a development team handle multiple functions I'll build something like a prioritizer error or something that helps you detect those kind of functions more easily or to help you with a batch of functions, for example.

Jeremy: Right. Yeah, no, I think that'd be another very cool project. I think you asked the right question there. And then at least, this is something for me is sort of what are you optimizing for? Are we trying to make the user experience better, so we have lower latencies? Are we trying to get the cost down on the backend, maybe for running ETL tasks and things like that? Those are certainly things where I think this comes in. Really, this is an important thing to consider is to say, "Are we trying to save 10 bucks a month from our front end just so that we're, again, saving $10 a month, but maybe it takes 120 milliseconds for our API to respond. Or are we trying to save potentially thousands of dollars on the backend if we're running these complex ETL tasks. And that brings me to something... So, Joe Emison who runs Branch Insurance, every month he usually post a screenshot of his bill. And running an entire online insurance agency his Lambda bill was $22.65. So is optimizing for cost in that situation something that should even cross your mind?

Alex: Yeah, that's a fair question. It probably isn't. I would still suggest you run Lambda Power Tuning because you might be willing to pay $26, and get a 30% performance improvement. So, it's not like one or the other depending on your scale, depending on the use case, depending on the customer needs you might decide to invest on performance. And with Lambda it's pretty simple. You can visualize it. You have one knob, and it's fairly simple. So, as I was saying, it's almost free to run this power tuning process. I've seen customers who actually run ...

About Alex Casalboni
Alex 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_casalboni
• LinkedIn: https://www.linkedin.com/in/alexcasalboni/ 
• Website: https://alexcasalboni.com/
• Dev.to: https://dev.to/alexcasalboni
• Medium: https://medium.com/@alexcasalboni 
• AWS Lambda Power Tuning Project: https://github.com/alexcasalboni/aws-lambda-power-tuning
• Deep 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/9ce2cef56a7d052d4f5e798b37083525

Watch this episode on YouTube: https://youtu.be/31LHFQ1lT78

Transcript

Jeremy: 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 throughput on a megabyte per second, maybe.

But for Lambda itself, you don't really have a parameter to increase throughput. All that is managed by the service. What you can do is at the architectural level, maybe if we have a 10 gigabytes of data to analyze instead of doing it in series 10 megabytes at a time, you can do it in parallel. So, that's an architectural change, that pattern change, but it's not really a configuration of Lambda itself. It's more in the way you use all these services together, in my opinion.

When it comes to cost you also have control over that. There are many guardrails you can take to control the span, to control the parallelism of how many Lambda instances you can add. You can set it to zero if you want to stop everything. So, there are many ways you can control costs. What happens usually in the wild, that's what I see is that most developers I meet are more interested in optimizing for performance just because cost itself of Lambda is a relatively small percentage of their bill. So, they're not so much concerned about, "I want to make a Lambda as cheap as possible." Usually, they want to make the overall architecture cheaper. And they are happy to pay a little bit more for Lambda, if they can make it faster.

Jeremy: Right. Yeah. All right. So, let's talk about cold starts because this is the thing that always comes up. I think there's a lot of confusion around how often you get cold starts, how much of an impact they actually have, when they happen and things like that. So, let's start there. How much of an impact do cold starts actually have on your application?

Alex: It kind of depends on the type. I would say there's no typical answer, I know, I'm sorry. But it depends how often you involve your function. It depends how often you're scaling out to additio...

About Austen Collins
Austen 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/austencollins

Transcript

Jeremy: 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 better because you can't just go and do something crazy, like say, well, we're going to set up a K8 cluster because we want to do some type of processing over there. If you ask yourself, how can I do it within these constraints? Not only is it usually faster, it's a lot cheaper. And oftentimes I think you'd get a better product out of it.

Austen: Yeah, absolutely. I totally agree with that. Constraints are super important. And also, I got to say the amount of stuff, use cases, that people were trying to use serverless for, especially in the early days when it really wasn't meant for it, was just so amazing to me. People would try and duct tape together crazy serverless architectures to accommodate a use case it clearly wasn't ready for. There's so much creativity in that area. And it seemed pretty crazy, but it's just people love those serverless qualities. Auto-scale, only pay for use and massive scalability. People want that so bad. The fact that so many people were doing this and they still do it a lot today because there's still not even great serverless database options, right.

The stuff that people are doing to get around that, the DynamoDB movement right now, the popularity and all that I think is a lot of it is due to the pent up demand that is just waiting for the cloud to become more and more serverless and offer more and more serverless options for all use cases. And that's really I saw that early on and I'm just thinking like, everybody wants this, this is going to be table stakes for the cloud. Again, this is not a fad. This is like the next... This is cloud 2.0, that's cliche to say, I hate to saying that, but this is like the evolution of where-

Jeremy: Cloud 3.0 now I think we're already getting towards 3.0. So 2016, 2017, 2018 you're working on building a community which you did an amazing job of. And I know you hired a few people. I know Alex DeBrie, for example, a ton of growth hacking, which is just brilliant by the way. So if you just take your serverless hat off for a second and go back and look at how you built this company and how you built this community, it is like a masterclass in how that worked. Now, I know I'm sure you made a lot of mistakes along the way, like you said, for every one success, there's 100 failures behind you. But again, it was the persistence. It was the approach to it. It was hiring a bunch of great people. And like you said, having some really, really great people working for you and working on the project that I think got it to the success. But now we get into 2018, maybe towards the end of 2018, 2019, you'v...

About Austen Collins
Austen 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/austencollins

Transcript

Jeremy: 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 really capitalize on what the potential I first saw when it came out and still until today. And that is like... This for me, it was, I guess, I don't know about you, but I actually never got into this to be a developer. That was not my personal goal when I was just getting started.

Again, I've always felt more like a creative type to be frank and more of an entrepreneur. And the programming, the development was kind of a means to an end, but also felt like potentially the greatest skill set to have at a time where the cloud programming gives you the ability to make anything, to solve any problem almost.

And I think a lot of my story and all the time that's gone into the Serverless Framework the same goes for the community members and whatnot. I think there's something similar where the people who are attracted to this are very much product focused. They really care about making things, they care a lot about the customer experience. And a lot of the technology is cool, but to some extent, we kind of want it to go the way so we could focus on the customer facing experience.

And that's kind of always been a strong theme for me personally. I see that in the serverless community everywhere, we've talked about it a lot and it was the thing I felt when Lambda first came out. I got so excited. It felt like for the first time there was really a technology where I could just put any logic out there and it would run for me, auto scale and charged me unless it was running.

And so that felt like amazing power. And I was looking around, there's definitely some excitement. It was so early in those days. I think AWS, maybe you remember this better than I do, but they were pitching it as like event-driven code kind of glue code. And there was no serverless category. There was no serverless buzzword or anything like that. It was kind of just a stitch together, kind of shuttle some data from one place to another largely from S3 and had very limited use cases at the time.

Jeremy: Right. If you remember all the way in 2015, even once it became generally available, there was no API gateway to connect. So you weren't able to do those web use cases, which again are probably one of the most prevalent things that serverless is doing now.

Austen: Yeah. Very limited. And I don't think all the pieces were there and enough of the pieces were there for people to get kind of the overall vision, maybe how meaningful it was, or at least how meaningful I felt it was. So I went away from tha...

About Holly Mesrobian

Holly 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=xmacMfbrG28
• Under the Hood of AWS Lambda 2018: https://www.youtube.com/watch?v=QdzV04T_kec

Watch this episode on YouTube: https://youtu.be/nBYUh7CVUiQ

Transcript

Jeremy: 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 the learning on that? How do you keep learning and just keep building with serverless?

Holly: Yeah. This is a really fun topic for me to talk about, and as you might imagine, customers find value in the agility and the operational load or the lighter load on operations that serverless brings. My teams are no different nor our AWS teams or Amazon teams. What we have seen over time is teams across AWS adopt and use serverless. Then my own teams over time have also adopted the serverless architecture and they actually want to use it.

Over time, more and more of the Lambda service, in particular on the control plane, because you don't want circular dependencies in your architecture. So we're really careful about making sure that in early design, when we're saying, "Hey, my team wants to use Lambda, is it okay to use Lambda and serverless?" Because it's building serverless underneath serverless and you have to be careful that you're not doing a bad thing. We're really good about inspecting that in the early design phases.

I've seen more and more of my teams picking up and building control planes on Lambda. In particular, they're using the feature that we launched last year at re:Invent called Provisioned Concurrency. What that does for really high-scale, low-latency services is it gets rid of what people have typically talked about, which is cold starts. Of course, we've done a ton of work over the years to reduce cold starts, but they're still not zero.

We're going to continue to do work on cold starts, but for customers who are super latency-sensitive and need that scale and know that they have low latency all the time, Provisioned Concurrency is a great solution. We have used it within our own services as well.

Jeremy: Right. Is that something now where all AWS teams, when they're thinking about building a new service, that they're going to build that on top of Lambda and do that serverlessly?

Holly: Yeah. One of the ways that people look at it is it's that operational model and where are you sitting in that? Of course Lambda's pretty high. We do a lot more of the shared responsibility on behalf of customers, and so teams like that and they say, "Oh, well, this is going to be easier to operate. We're going to get more agility out of it, so let's go there as a first stop." It's only when they say, "Well, may...

About Raymond Camden
Raymond 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/raymondcamden
• Blog: www.raymondcamden.com/
• HERE Technologies: www.here.com/

Watch this episode on YouTube: https://youtu.be/2I3nNsU6HSs

Transcript

Jeremy: 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 JavaScript over the years. I thought, "Let me look at it some more," now that supposedly things are a little bit better. And I found out that, yeah, things were a bit better. Browser dev tools were around.

And so, I just started doing more work on the client side and I began to realize that having the app server there, primarily because browsers were so horrible, wasn't necessarily the case anymore. There was a lot more that I could do on the front end and without an app server.

Jeremy: Yeah. No. I mean, I think that was one of the things that was the biggest pain for all of us that were ... I mean, I owned a web development company for 12 years. So, battling with IE6 and all the different browser compatibilities was definitely a huge problem, which is why one of the things that I think we did or we did well was build back end applications that would completely render the pages.

And as you said, as we move towards this more of an Ajax, sort of filling things out, and of course now, we're into a whole new era with single page apps and React and Vue and things like that, but what was it, though, that once ... So, once you started building some of these more interactive JavaScript side of things, were you still using ColdFusion or did you move to something else for your back ends?

Ray: Well, so it's interesting. Yeah. I was still using ColdFusion, but what I began to notice is that ColdFusion began to get more and more dumb in terms of what it was doing, whereas before, I was rendering entirely the entire site. It began to be just a JSON provider.

One of the things that kind of got me off ColdFusion is that, at the time, it did JSON very badly. It would have this wonderful feature where, because it was typeless, it had to make guesses in terms of what your data was. If you would try to take someone's name, let's say possibly an Asian person who's last name was No, Dr. No, maybe. It would, in JSON, convert that to false. You had no control over that at all. So, both seeing how small I needed ColdFusion and seeing it kind of fail in terms of generating JSON, that began my migration to more Node.js development.

Jeremy: Yeah. And so, when you started using Node.js, were you still setting u...

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/paulchinjr
• 757 Dev Group: meetup.com/757dev/
• Begin: begin.com
• Begin Training Resources: learn.begin.com
• Architect framework: arc.codes

Watch this episode on YouTube: https://youtu.be/L8DkEqgVEBY

Transcript

Jeremy: 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 how networking works and all that kind of stuff. Which I'm glad I did. But for somebody new it just seems like if unless you're getting specifically into that business, if you just want to learn to build applications and develop in the cloud, then that traditional experience I think, is not necessary anymore.

Paul: Yeah. And it changes so fast.

Jeremy: Right.

Paul: I got started right when the MEAN stack was a thing. Everybody wanted to build the Angular, Node, Express thing. And I recently, as part of my job at Begin is to take these example apps and make them better and make them more accessible. And so I recently just took one of the first sites I ever made. And went to the Free Code Camp resource that I had used five years ago, when I first built it. And I go, "Man, none of this is actually deploying anywhere." And I was trying to remember, "Well, how did I actually deploy this thing? I must have done it on Heroku or something." But there was no instructions for it.

Jeremy: Right.

Paul: And I remember, that was a friction point. I was like, "Okay, I've gone through this tutorial. I've built this thing. It works locally, on localhost only. Now what?" And what Begin does is say every time you push to GitHub, your stuff is live. It's just automatic. It's just a given. We think that it's just table stakes now like, while you're building and prototyping, and developing, you should be able to see it on live resources. And so I've updated the Express app. I even threw the entire Express server inside of a single Lambda, and it works just as a proof of concept. But splitting them off and doing more event architecture with it is the next level. And it's just as straightforward. Because if you're pushing to GitHub, you can push to the cloud. That's it.

Jeremy: Right. Yeah. No, that's awesome. So let's talk about Begin. Because I think that's one of those things where if you think about serverless development, and you're thinking of SAM,...