Serverless Chats

About Ken Collins:

Ken is a Staff Engineer at Custom Ink focusing on DevOps & eCommerce architectures with an emphasis on emerging opportunities. Custom Ink is approaching its 20th year in business and is entering its second phase of Cloud adoption where he helps a growing engineering team succeed using AWS-first well-architected patterns. Ken lives near Norfolk, VA and organizes the area’s Ruby User Group.

• Twitter: @metaskills
• Custom Ink Tech on Twitter: @CustomInkTech
• Blog: technology.customink.com
• Lamby: lamby.custominktech.com
• Full Stack to Functions and Back Again Talk:
  • Slides: https://speakerdeck.com/metaskills/full-stack-to-functions-and-back-again?slide=2
  • Video: https://www.youtube.com/watch?v=ktDXVn3EPfY 
• Migrate Your Rails App from Heroku to AWS Lambda: https://technology.customink.com/blog/2020/01/03/migrate-your-rails-app-from-heroku-to-aws-lambda/
• ActiveRecord Adapter for Amazon Aurora Serverless: https://github.com/customink/activerecord-aurora-serverless-adapter

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Ken Collins. Hi Ken. Thanks for joining me.

Ken: Hi Jeremy. Thanks so much for inviting me.

Jeremy: You are a Staff Engineer at Custom Ink. Why don't you tell the listeners a bit about yourself and what Custom Ink does?

Ken: Yeah, I think maybe first I'd like to say thank you for inviting me to the podcast, really great to be here. I definitely would like to think that it's not because we both have 38-inch, identical Dell Curved Monitors. A very exclusive club.

Jeremy: It is an exclusive club.

Ken: Sure. Custom Ink, let's see. I'm a Staff Engineer, I focus mainly on the eCommerce side. Custom Ink is about 20 years in business. And, I think we're probably only unique in the fact that we're a successful company that has a long history with Rails.

 We've been going along for those 20 years, a lot of those years have been with Rails. And, we've sort of completed a lift and shift into the cloud since about 2017. And, we've had some interesting things to do with cloud adoption or adoption of serverless and all things basically AWS.

Jeremy: And, what about yourself? What's your background?

Ken: Well, let's see. I'm a self-taught programmer. Used to be a designer, used to be a marketing director. I think at one point in time I was the author for the act of record SQL server adapter. So, represented the Ruby community and Microsoft when they first started doing their transition to open-source.

And, I think I really love open-source. I'm focusing mainly on retooling my personal career and learning everything about AWS. And, that started about last year. And, doing everything I can at Custom Ink to sort of sell the serverless story, and to get more cloud adoption within the organization.

Jeremy: Very cool.

Ken: Thank you.

Jeremy: All right, so I wanted to have you on today because I've had a number of guests. And, we talk about serverless in theory all the time. And, we have all kinds of great ideas of architectures. And, I mean we get into some of the practical stuff. But, the hands on piece of it, and how companies like Custom Ink are actually getting their hands dirty. And, doing the work to figure out how to implement it. Every one of those stories is different, and I just really love the story that Custom Ink has. I think I saw a testimonial on the AWS site about sort of how you started with it.

I want to get into that because I think that's really interesting for people to hear how other companies get started with serverless and Lambda. And, how they start adding that. And again, you've gone through the experience of the lift and shift. I know you have some interesting microservices stories that I think would be great to hear about. But, let's start with that, let's just start ... you started moving to the cloud, you did the lift and shift thing. And, I'm assuming those were mostly monolithic applications, so what was the next step for Custom Ink?

Ken: Yeah, I think our story arc, maybe about 2014 was key sort of monolith. We had a very traditional big Rails frontend and a big Rails backend that sort of shielded us from a legacy Java backend. And, at that point in time, and we still didn't finish our cloud sort of migration until 2017. Which, is basically just a bunch of EC2 instances.

At some point in time in 2014, I think that's when Lambda came out. And, there was a lot of buzz around microservice architectures first. And, we even had a business unit that had started off in 2014. That we sort of gave them this majestic monolith, and the business unit decided to immediately retool that entire monolith into microservices first. It was just the hot thing to do in 2014.

Jeremy: Sure.

Ken: And, I believe that took about a couple of years to really fail miserably. In fact, everything that they went to engineer on, just breaking things apart. Eagerly because that was the architecture to do, versus the success of the company driving that microservice architecture all rolled back. All changed, eventually we got merged back into the core business line. And, that really sort of affected, I think a lot of the corporate memory about how we approached microservices.

Jeremy: Sure. Then after you sort of had this epic failure. And again, I think this is nothing against Custom Ink. Because, I think this happens to a lot of people, who try to do that second version syndrome and say, "we'll just take our existing application, break it up into smaller pieces and everything's going to be great." That typically doesn't work. Sometimes it does, but most of the time I don't think it does. Then you shifted to this idea of a kind of using Lambda functions and serverless in general really to start splitting off, you actually started more with DevOps tasks, right?

Ken: Yeah. I think there has always been a little bit of AWS Glue. I call it, when I look at Lambda I've sort of from my perspective today I put them into three buckets. AWS Glue is when you're just sort of glueing things together, maybe you're popping Kinesis Streams off of a DynamoDB. Or, you're just doing some little small tasks, maybe scheduling the shutdown of EC2 instances. Then there's the sort of microservice architecture of where I think a lot of people have their head space around Lambdas. And, then those are more sort of larger applications.

In, 2017 we had a brilliant engineer named Hunter. Who, took a key part of our design architecture and that really needed to come off of a Rails app, and ImageMagick. And, put it into a Node-based Lambda. And, that's what our customer testimonial on the Lambda product website is about. I think we had 90% in cost saving...

About Aleksandar Simovic

Aleksandar is an AWS Serverless Hero and an experienced senior software engineer at Science Exchange, a biotech company based in Palo Alto, California, that is helping scientists, research laboratories and big pharma companies get faster in experimentation and research. Co-author of “Serverless Applications with Node.js” book, published by Manning Publications. He is based in Belgrade and co-organizer of JS Belgrade, Map Meetup Belgrade and Serverless Belgrade. One of the core team members of Claudia.js, contributor to AWS SAM, AWS CDK, AWS Lambda Builders and many other open source libraries.

• Twitter: @simalexan
• Book: Serverless Applications with Node.js
• GitHub: simalexan
• Claudia.js: claudiajs.com
• Blog: serverless.pub
• The Computer/Jarvis Project: thecomputer.ai

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly, and you are listening to Serverless Chats. This week, I'm chatting with Aleksandar Simovic. Hi, Aleksandar. Thanks for joining me.

Aleksandar: Hi, Jeremy. Thank you for having me. It's awesome to be here.

Jeremy: You are a senior software engineer at Science Exchange, plus you're also an AWS Serverless hero. Why don't you explain to the listeners a little about yourself and what you've been doing at Science Exchange.

Aleksandar: Yup. You're right. I'm a senior software engineer at Science Exchange doing serverless a bit more than four years at the moment. Yeah, there's a lot of titles here, AWS Serverless Hero, where I work with other two serverless heroes, Gojko and Slobodan on Claudia.js, one of the first frameworks for serverless. Also co-authored a book, Serverless Applications with Node.js with Slobodan, running many meet-ups on JavaScript serverless Wardley Maps scene, Belgrade Serbia. My main focus is serverless, and business strategy, basically building product with serverless and Wardley Maps.

Jeremy: Awesome, all right, so I want to talk to you about something today that maybe is not going to seem like it's about serverless, but I think you and I will agree that it very much so is. That has to do with voice automation or the ability to use voice integration, I'm sorry, voice interface technology. I think that the ability to control something with your voice is absolutely the future of how pretty much most interactions are going to go. Maybe I'm a little bit crazy here, but I think you sort of agree with me?

Aleksandar: Yeah, this is something that there's a lot of heated discussion about, but I'm going to just tell you a story of this Christmas I saw my seven-year-old nephew, who basically doesn't ... He's Serbian. He doesn't know English. He doesn't know how to type properly. He doesn't know the Latin letters. I saw him using the phone in a very different way than we used to use it. He basically started ... He only uses the phone by using the Google Voice function, so he opens up the phone and he just presses the Google search function and he basically just says what he wants without even typing or anything.

For him, that was the most easy way to interact with technology. And that's something which blew my mind as I saw that the way we are interacting with technology has evolved so much that in our age we sort of ... We started tapping on the iPhones and everything, and now we have a new kind of age slowly creeping in using voice.

What's surprising is that for many humans that are not used to phones, are not used to the traditional ways of using technology, voice has become something as a normal thing, something very ordinary.

Jeremy: Yeah, and promised the listeners we're going to get to why serverless is important here, but I want to just quickly start with ... just sort of lay this out, like lay out the groundwork here and what we mean by voice interface technology. When we started with visual interfaces we were using desktops or computers, and then everything started shifting to mobile, and companies started thinking mobile first. Now there's this thing, sort of voice first, right?

Aleksandar: Yeah.

Jeremy: We've seen this with Alexa and Google Home and Siri and some of these other things. It started very simple, where we were saying like "Oh, Alexa play this song." Or, "Alexa set a time," or things like that, and I hope people aren't playing this over the speakers so that their Alexa devices are going crazy. I should say, "Alex, order a 100 rolls of toilet paper." But these sort of interfaces now have become much more sophisticated.

The technology's much more sophisticated, and now people can do very, very complex things. I want to get into that in a minute, but when I think about voice interaction or this idea of using your voice to control different systems, and of course this home automation and all this kind of stuff, this was sort of predictable right?

Aleksandar: Yeah, so voice ... As you can see, everything that we are ... in technology everything evolves, and everything evolves so fast, and how do we ... The main issue that we have is how do we anticipate change. How do we anticipate what's going to happen? Luckily, maybe around 15 years ago, I know something called Wardley Maps has appeared, some kind of strategic maps developed by Simon Wardley, one researcher at ... one amazing, actually, researcher, and a former CEO. He discovered this way of how can you actually anticipate change and have a situational awareness of how things are going and evolving. Many of your serverless listeners already heard about him, but he basically created this concept called Wardley Maps, which kind of represent the strategic maps of a business landscape.

Which are kind of represented in a form of a value chain of components, which evolved over time. Now that doesn't sound very, like, novel, for some people maybe, I don't know, but basically he created a very visual map, visual way of mapping business surrounding. Based on that, you're able to anticipate how things are going to evolve. For example, we know about the electricity, how electricity was something novel, new, unknown, coming to a point where it's commoditized, industrialized. I mean all of our common lives are kind of pointless without electricity at the moment.

Our technology and the things we do are pointless without it. And as these things, as Simon developed this amazing mapping technique, and basically a structure about our own strategy, he found out different things that were going on. For example, that as new things appear, as things become commoditized, sorry, they become ... you are able to build some things on top of them. We can see that with our electricity we got radio. We got television and we got computers, internet, and we came here to serverless.

So, basically, what happened, I mean what Simon saw 15 years ago, is that there's going to be a ... He actually even created the first serverless technology in his company, and he basically, 15 years ago, he said there's going to be something, such as AWS Lambda. There is going to be something where you're going to have a runtime, a runtime as a commodity, where you won't have to think about servers, where you won't have to think about infrastructure, so basically he developed a way how do you anticipate change and how do ...

About James Beswick:

James Beswick is a Senior Developer Advocate for the AWS Serverless team. James works with AWS's developer customers to understand how serverless technologies can drastically change the way they think about building and running applications at massive scale with minimal administration overhead. He has previously worked as a Software Developer and Product Manager at various enterprises and startups, and has nearly a decade of experience building applications in the cloud.

• Twitter: @jbesw
• LinkedIn: https://www.linkedin.com/in/jamesbeswick/
• Email: [email protected]

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with James Beswick. Hey, James. Thanks for joining me.

James: Hey, Jeremy. Good to see you.

Jeremy: So you are a senior developer advocate at AWS. Why don't you tell the listeners a little bit about your background and what you've been doing on the AWS developer advocacy team.

James: Sure, so I've been working with serverless for about three years now. So I'm really a self-confessed serverless geek. I've used it to build quite a few applications, front to back using only serverless. And then in April last year, I joined AWS in the developer advocate team, and so this is truly the best job in the world because I like talking about serverless to people, so I get to go around doing conferences, blog posts, webinars, applications, and also some other things to show people how to build things. Since then I've just been going all over the place doing these things, but it's been pretty amazing just to see what customers are building all over the place with these tools.

Jeremy: Awesome. All right, so I was talking to Chris Munns when I was out at re:Invent, and I put together a podcast there, and we were talking about all these new things that AWS was launching. And I think what happens with serverless is that it's moving so fast that things are constantly changing. There's always new things being released. What serverless is is still up for debate, right? I mean, there's still a lot of questions around that.

So I wanted to talk to you because you and I talk as much as we can because I love talking to you. You have great insights when it comes to this stuff, and I wanted to talk to you about sort of what are we going to see with serverless in 2020, right? Because this is the year now where all of these pieces are starting to come together. We've got all of these tools, all of these things we've been complaining about like RDS Proxy, and we can't do this, and we can't do that. These problems are going away at a rapid clip. Maybe you can give me your take just on, I mean, what does 2020 look like for Serverless?

James: It's a great, great question. In the last five years, you know Lambda's really five years old, what's been happening is the space has been emerging and developing so quickly, we're simply seeing customers pick up the tools and build things and then find they need more features. So we've been building all these features as quickly as possible. And I think what's different this year is that this whole space is starting to mature very rapidly. And we're seeing customers, both startups and hug enterprises using all of these tools at scale. And starting to see the same patterns emerging from their use cases.

So what we're doing for the next 12 months is essentially looking at the entire list of requests that's coming right from customers where they want certain things and dedicating those resources to building out the features they want. So AWS is famous for listening to customers and building those features, but I'd say in serverless, I mean it really is the case their entire road map is coming back from these early adopters and these users and helping us to find what we now build.

Now in terms of actual concrete things, most of that comes down to improving performance all the time, always making sure we can make performance as good as possible but also improving tools and making sure that we integrate with developer tools that they're using all the time, and just making sure that all features, we sand off any rough edges that we have. So a lot of the time with AWS features, what we're doing is we deploying them out to customers as quickly as possible so that people get the first look at what we're building. And then when we get that feedback, then we build the additional bells and whistles to make sure it's exactly what people want.

Jeremy: Yeah, no that's great. And the other thing that I, I keep hoping for this, right? And maybe we're not there yet, and I ask everybody about this, but I really want serverless to go mainstream, right? Like it's just what you're doing. It's the way to build cloud applications, right? Because I think you have all of these use cases that are out there now, and from my newsletter I'm always trying to capture use cases to say oh someone's doing this with it or someone's doing that with it, and they have these interesting ways of solving those problems.

And like I said, these problems now have official solutions in many cases. What's your take on this idea of it really becoming mainstream and more customers starting to use it for, or just being the first choice of what to use when they're building something in the cloud.

James: So in my career, I've been one of these early adopt people where I was one of the first in the cloud. And I used mobile and got into mobile development very early. And one of the patterns I see over and over is that the tipping point of things becoming mainstream isn't always obvious. You go through this period where it seems like you're always walking uphill to convince people that this is something that's going to become the standard way.

And then magically at some point, it just does, and you didn't notice it happening. And I started to feel that's becoming the way of serverless because many of the groups I spoke to a couple of years ago, who didn't know what serverless was or they didn't think it was a good fit for their use case, are now starting to openly talk about serverless as an option at least and yet discuss how they could use it.

The great example is that last year I went to the DC Public Summit for AWS, where all of the government customers were there, and a lot of people were very interested in serverless. And I've seen the same thing at all the summits and events we go to that even people who haven't actually done anything yet are interested in what it can provide in terms of both agility and scalability for building their applications.

Jeremy: Awesome. So you mentioned tools and giving people tools in order to build stuff. One of my complaints from serverless, right from the beginning, is even though we are abstracting away all of this infrastructure, there's still a lot of configuration that has to happen. And with AWS that comes down to ultimately using either cloud formation or writing complex interactions with the APIs, which nobody wants to do.

So the CloudFormation side of things, there are extractions on top of that. We've got SAM, the Serverless Application Model that is, makes it a little easier. It's very similar in fell to the serverless framework. Then we have the CDK, which is relatively new that allows you to just write code, and that will generate an infrastructure for you. There's Amplify. I just talked to Nader Dabit the other day. We were going through this amazing tool that is Amplif...

Please visit our EPISODES page for links to the full episodes.

About Nader Dabit:

Nader Dabit is a Developer Advocate at AWS Mobile working with projects like AWS AppSync and AWS Amplify. He is also the author of React Native in Action, & the editor of React Native Training & OpenGraphQL.

• Twitter: @dabit3
• Twitter: @AWSAmplify
• AWS Amplify: aws.amazon.com/amplify
• Blog: dev.to/dabit3
• Github: github.com/dabit3 

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with, Nader Dabit. Hi, Nader, thanks for joining me.

Nader: Hey, thanks for having me.

Jeremy: You are a Senior Developer Advocate at Amazon Web Services. Why don't you tell the listeners a bit about yourself and your background, and what you do as a Senior Developer Advocate?

Nader: Yeah, sure. Before I joined AWS, I was basically a front-end engineer, mainly a mobile engineer for the last, I guess four or five years before joining AWS. I kind of come from a traditionally front-end background, but the team that I work on is the mobile team, but we cover Amplify, we cover AppSync, we also cover Device Farm and the Amplify Console. And yeah, we have a couple of developer advocates, I'm one of them. And our role is very kind of lenient in the sense that we don't really have a traditional role as someone might think of maybe a developer evangelist or something.

I think it's really team dependent on what that role actually means. But to our manager, it's a way for us to have a lot of leeway in what we do, so we can write code. Most of the stuff we do is open source so we can contribute to the open source, we can speak, we can write docs, we can write blog posts. Whatever we feel is going to contribute the most to moving everything that we're working on forward, we're able to attack that and work with that.

Jeremy: Awesome. So, speaking of things that you're trying to move forward, you mentioned AWS Amplify. Which is this really cool project that Amazon is working on. Why don't you give the listeners a 30,000 foot overview of what exactly that is?

Nader: Sure. The Amplify was first, I guess, introduced as a client SDK for web and for React Native that basically allowed you to interact with things like API Gateway, things like AWS AppSync, Cognito, much easier I guess, than some of the old way. Before you were using probably the AWS JavaScript SDK, we just added improvements that were really meant for interacting with these services from client apps. The Client was first introduced, that started game gaining steam pretty quickly.

We then introduced the CLI at the... I think the next reinvents. I think it was actually, I'm not sure exactly when the CLI was released, but it was really after to the Client. And the CLI is something that basically allows you to create AWS resources in a similar fashion as you would do with something like CloudFormation or SAM or even something like the Serverless Framework.

But it gives just a different approach, so instead of having to maybe do it in the way that you're used to doing it, maybe writing some CloudFormation or maybe writing some templates with JSON or YMAL, you can just go to the command line and create an update categories versus kind of having to know what's on with AWS.

If you're coming to AWS as a newcomer, it makes a little more sense based on the feedback that we've gotten to use Amplify, because they can say, "Hey, I want an API," and in the background we'll spin up an API Gateway and point with some configuration around a proxy to pass the event into a Lambda and we'll also generate the Lambda. It's kind of an easy entry point for people, but it also is a very helpful way to generate a couple of things at once that kind of tie together, so the CLI is another part of it.

Then there's the Console, which is something that was introduced, that re:Invent 2018, and the Console is a hosting and CI/CD platform that allows you to just kind of connect to a get-repo, and then we do the build and we deploy to CloudFront with S3. It's a really nice way to deploy your web apps. We also have a lot of stuff that's been added over the last year to improve that. I would say that's the main focus, those three things, the Command Line Interface, the hosting platform and the client libraries.

Jeremy: The purpose though of these three tools sort of working together is to build mobile applications, or web applications using something like React Native or just React, or actually view an angular, like there's plugins for all that. The point though is that rather than you having to go out and use something like SAM or build all these things out individually with CloudFormation, that this is just sort of giving you a unified way to create both the front-end and the backend, right?

Nader: Yeah. I mean, we have a lot of people that are actually... there's two ways to kind of look at it, I guess. You can use the client only and still use CloudFormation and SAM and Serverless Framework and we have a ton of people actually doing that. Or you can kind of buy into the whole framework and then use the CLI as your resource creation platform of choice. You can kind of go at it both ways.

But yeah, the idea though is to build these full stack applications and to kind of, we have a couple of main focus points. One of them is around developer experience and the other is just around developer velocity. And I guess that could, maybe tied to developer experience. We want to be able to allow you to create things, and configure things, and deploy and try things out, experiment quicker than maybe you would have been able to in the past.

Jeremy: I mean, I get that you can sort of break these things up and you can use them individually. But I mean, really what you're building is sort of a philosophy around a full stack development, right?

Nader: Right, right. We think that what we're doing is a little different than anything that's kind of been out there before, I think. And we don't really have something to compare it to, but we talk about it in a couple of different ways. One of the things that we talk about is this idea of a full stack serverless development, where you're a developer, or you're a team, or you're a startup, or you're a company and you want to be able to enable a developer or a team of developers to build the front-end and the back end, versus having the traditional maybe engineering team where you have a backend developer and then you have a front-end developer.

We're looking at it like, what if a developer could just be looked at as a full stack developer like we've seen forever. But instead of the traditional full stack developer where the backend developer might be in charge of creating servers and creating a database and patching and dealing with all of the different backend resources, we could take the serverless philosophy, use that and then apply the front-end developers and merge that together and enable a single developer to build out these full stack apps, or a team.

Jeremy: Yeah. And I definitely love that idea because I do think there's a huge growth in front-end developers that need the capabilities of the backend, whether it's simple crowd apps or something like that, or something more complex. But serverless has always to me, seemed like a reall...

About Ant Stanley:

Ant is a consultant and community organizer. He founded and currently runs the Serverless User Group in London, is part of the ServerlessDays London organizing team and the global ServerlessDays leadership team. Previously Ant was a co-founder of A Cloud Guru, and was responsible for organizing the first ServerlessConf event in New York in May 2016. Living in London since 2009, Ant's background before Serverless is primarily as a Solution Architect at various organisations, from managed service providers to Tier 1 telecommunications providers. He started his career in 1999 doing Y2K upgrades in his native South Africa, and then spent 5 years being paid to write VB6. His current focus is Serverless, GraphQL and Node.js.

• Twitter: @IamStan
• ServerlessDays: serverlessdays.io
• For organizer information: [email protected]

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Ant Stanley. Hi, Ant. Thanks for joining me.

Ant: Hey Jeremy. It's a pleasure to be here.

Jeremy: You're the co-founder of ServerlessDays Global. Why don't you tell the listeners a little bit about yourself and what ServerlessDays is all about.

Ant: Yes, I helped co-found ServerlessDays in 2017. I've been an early member of the Serverless community. I originally was one of the co-founders of A Cloud Guru and helped get Serverless [Consults 00:00:30] off the ground. After leaving Cloud Guru, I took a year off, worked on a few side projects, then joined up with a few folks here in London, and we decided to get a community-based Serverless conference going. It was supposed to be one conference called JeffConf. Then, it took off and became a thing of its own due to the amazing community. That's pretty much, not quite how we got there, but it's the start of how we got to where we are.

Jeremy: All right. I actually want to talk to you about ServerlessDays. So I helped co-organize ServerlessDays Boston, a crazy event. I went to one in New York, and I've seen, basically, these ones all over the place now. I went to one in Milan. This is becoming a pretty big thing. So, there's all kinds of ways people can get involved. There's some really, really great speakers at these events, but I just want to talk about, really, how this got started. Let's go way back to the beginning, understand what the motivation was behind it. Then, let's talk about some of the events that are happening around the world and, then maybe, how people can get involved. Why don't we start with that? What's the history of this whole thing?

Ant: The history, it goes back to April, May 2017. There was due to be a Serverless conference in Amsterdam, run by the then organizers of the Serverless user group in Amsterdam, and it, kind of, fell apart. I think end of April, beginning of May, it got canceled. I don't think they could raise enough sponsorship funds. I think they were trying to go too big, and, at the time, that was going to be the only Serverless conference in Europe that year. So at the time, I ran the... Well, I still do... run the Serverless user group in London, which is the largest Serverless user group in the world at this point in time. I had a conversation with Paul Johnston. He used to work for AWS and he's one of the early the early Serverless bloggers or contributors, and James Thomas is a Developer Advocate for IBM, on their OpenWhisk functions platform. He's also London-based.

The three of us had a conversation via a Slack channel. I'm saying, "Well, there isn't anything happening in Europe this year. Why don't we try and organize something?" What became an idea, started to become reality, and Paul popped up, and he said, "I might have a venue that's really cheap." So I said, "Well, I've got a user group with a whole bunch of users, and we don't have anything planned in the summer because that's normally an awful time to run a user group cleanup. So, I said, "Well, let's try and run an event." We decided to call it JeffConf, based on a very bad joke, because of the name Serverless. The in-joke, at the time, was we could've called Serverless anything. We might as well have called it Jeff. So, as a joke, we decided to call this thing JeffConf.

We organized it in six weeks from the point of saying, "Yes, let's do this," to actually running the event. It was a six-week window. We didn't run a CFP. We ran on an absolute shoestring. We spoke to whoever we could. Companies jumped in to sponsor. So the first tweet we put up about it, Chris Munns, from AWS jumped all over it and said, "Hey, can we sponsor?" IBM got involved. A few other companies, local London agencies, also got involved.

Yeah, We managed to get off the ground. We had some great speakers. We had Simon [Woodley 00:04:01], that I've been trying to get into my user group for ages. I managed to convince him to come to London for the day, and he gave our opening keynote. We basically managed to cobble together a great among of local, predominately, London/UK-based speakers to come speak, and it worked. We had about 170 people attend, which wasn't bad for such a short period of time. We somehow made a tiny profit on it because we managed to get a venue, which was the St John's Church in Hoxton, 196-year-old church, where Paul was friends with the pastor who runs it. So we ran it in a 196-year-old church in the middle of Hoxton Shoreditch area, which is the heart of London's tech scene. We had some great speakers and basically had a beautiful day, and it was a great day out.

That was the first JeffConf, and we didn't really think we would go further than that, at that point in time.

Jeremy: But it is sort of fitting that the first ServerlessDays was in a church because Serverless is, kind of, a religion, if you think about it, to some people.

Ant: Oh, yeah. Yeah, it definitely is a religion for a lot of people. Yeah, it is, kind of, fitting, and we've made jokes about Serverless dogma and religion, but it is fitting. Ironically, part of the reason it did take off is, when we announced that two Italians got on a plane and helped us out. Alex Calaboni and .... They came over and helped us out. Then, Alex, at the end of it, said, "Hey, I want to run this in Milan." So, it's like, "Well, we didn't have any plans beyond running once, so yeah, you can go ahead. If you want to run it in Milan, go for it."

Two and a half months later, it was the end of August. So first ServerlessDays was in first week of July, first Serverless JeffConf. Then, it was in September of 2017, Alex ran JeffConf from Milan, copied by my awful, awful website that I'd designed. It was a point where I thought rolling my own single-page app framework was a good idea. It's being used for sum total of three websites, which is more than it ever needed to be. So, he put that together. I think he had about 150, or so, attendees the first one. He had a whole month extra to organize it and that was a great event.

Then, Soenke from Hamburg, was one of the speakers of that ServerlessDays at that JeffConf. He approached Justin and says, "Hey, he wants to run this in Hamburg." So, at that point, he said, "Well, if you want to do it, and you want to put the effort in, we'll help you." So, Soenke decided, with some of his colleagues, at the company he'd ju...

About Chris Munns:

Chris Munns is the Senior Manager of Developer Advocacy for Serverless Applications at Amazon Web Services based in New York City. Chris works with AWS's developer customers to understand how serverless technologies can drastically change the way they think about building and running applications at potentially massive scale with minimal administration overhead. Prior to this role, Chris was the global Business Development Manager for DevOps at AWS, spent a few years as a Solutions Architect at AWS, and has held senior operations engineering posts at Etsy, Meetup, and other NYC based startups. Chris has a Bachelor of Science in Applied Networking and System Administration from the Rochester Institute of Technology.

• Twitter: @chrismunns
• Email: [email protected]
• AWS Compute Blog: https://aws.amazon.com/blogs/compute/

Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week, I'm chatting with Chris Munns. Hey Chris, thanks for being here.

Chris: Hey, Jeremy. Thanks for having me.

Jeremy: You are the Senior Manager of Developer Advocacy for Serverless at AWS cloud. Why don't you tell the listeners a little bit about your background and what you do in that role?

Chris: For sure. Definitely. Going back to the earlier parts of my career, I started as what I guess, I would have considered a sysadmin. Maybe these days, you would call it a DevOps engineer or an SRV or something like that. I took care of servers and infrastructure, a jack of all trades across the stack below the application. Then, just a little over eight years ago, just about eight years ago, I first joined AWS solutions architect, did that for a couple years, actually went back out to a startup and then came back again. Then for the last three years, I have been a developer advocate for Serverless at AWS.

Then, just in the last year or so I've actually built out a team of people that are all over the globe. What we do as a team is we create a lot of content, we deliver a lot of content, we do a lot of interacting with our customers, trying to share the good word about Serverless and get people over the challenges and things that they are understanding the various aspects of our platform, I would say. You'll see a lot of our stuff show up in webinars, and Twitch and blog posts and in conferences, and in social media and all that stuff. I would say the next biggest part of what we do is act as a voice of the customer back to the product teams. We are embedded in the product organization, we have influence over and what product is built and to a degree, how it's built. We want to make sure that our customers, concerns, the things they're trying to solve the challenges that they have are being properly represented back to the product organization.

Jeremy: Great. All right. We are live actually in Las Vegas, we're at the Big Show, as AWS fans, I guess would call it. We're at re:Invent 2019 there have been ton of announcements so far this week and I think we're pretty much done, we've hit the max on cognitive load for the number of serverless announcements that have come out. There are a whole bunch of them that I want to talk about, and we can get into some of these in detail. There were some really great ones that I think solve a lot of customers pain points. What do you think are the biggest announcements that came out so far? Maybe not just that re:Invent, but also in the last couple of weeks? Because the last few weeks, there's been a ton of announcements as well. What are your thoughts on that?

Chris: Yeah, it's been a really hectic period for us in the serverless organization at AWS, in the last two weeks a whole bunch of things. Really, I like to boil it down to four key big things that we've launched in last couple months, announced in the last say three months that I think take on some of the biggest challenges that our customers have. The first was back in September, we announced that we were going to be changing the way that VPC networking worked for your lambda functions. We announced this new concept of what we call a VPC to VPC net, it's built on in a data based technology called Hyperplane, it's part of the advanced part of our networking stack.

As of last week, the week here before re:Invent, we got Thanksgiving here in United States, we actually finished the rollout all the public regions that we have across the globe. It's taken some time to get this rolled out. It's actually a really huge infrastructure shift, but basically what this did was it drastically lowered the overhead of having your functions attached to a VPC for cold start, we had examples where it was shaving 8, 9, 10 seconds off of that initial cold start pain. It also reduces the total number of them and so really huge one. That's the biggest one out in all public regions today globally and customers are just seeing the benefits of that.

The next is on Tuesday of this week, we announced a capability in Lambda called Provisioned Concurrency. You and I have some fun history in this that it was almost two years ago at a startup event in Boston, maybe it was? Where I talked a little bit about, some of the pre-warming hacks and then you and I just went through back and forth on it for a while you launched your-

Jeremy: Lambda Warmer.

Chris: Lambda warmer project, which has become the de facto standard. We're full circle here, you and I have this like, I don't know, two years later almost?

Jeremy: Right. It's actually funny because I wrote a blog post like an open letter to the lambda team that was asking for provision concurrency. You and I had this conversation way back when, and you said, "Well, we really don't want to do that. Because, we want to improve the cold starts and get those down." I'm actually really glad that the team at AWS did that because I think if you would have gone with provisioned concurrency before then the need to make those improvements wouldn't have been there. It pushed you and your team to and the engineers there to get those cold starts down and work on that. But now provisioned currency adds a whole new level, which again, I think is great. Do you want to talk about that now?

Chris: Yeah. We'll riff on that.

Jeremy: Okay.

Chris: I saw some commentary that people thought that this meant that we were giving up on continue to improve cold starts. It's like, we want to be really clear that, that's not the case. This is a knob or lever that you can turn that yes, it changes the way that functions are essentially, it's difficult to use the term pre warm, but effectively, they are pre baked up through the init phase of the function lifecycle. What we've done throughout the year, and I've made a couple of tweets about this in the first half of the year of places where we've shaved tens of milliseconds off of some part of the overhead of the platform, or we've lowered jitter on various aspects of it. There's a lot of that stuff that continues to happen and actually, I talked about this at Serverlessconf, New York City back in October.

I basically said one of the key benefits of Serverless is that it just keeps getting better for you. There's basically three ways that happens, one is all the stuff we do behind the scenes that you just never see. The second is the stuff that we launch, that we tell you about but it's just automatic, there's no li...

About Farrah Campbell:

After 10 years of working in healthcare management, a serendipitous 20-minute car ride with Kara Swisher inspired Farrah to make the jump into technology. She has worked at multiple startups in many different capacities, eventually working her way to being the Ecosystems Director for Stackery in Portland, Oregon. As the Stackery Ecosystems Director, Farrah has managed the Stackery relationship with AWS including Stackery as an Advanced Technology Partner, achieving the AWS DevOps Competency, a launch partner for Lambda Layers. Farrah has cultivated the serverless community as an organizer of Portland Serverless Days, the Portland Serverless Meetup, along with numerous serverless workshops and the Portland tech community events from Techfest to bringing multiple luminaries to Portland. She's also an AWS Serverless Hero.

• Twitter: @FarrahC32
• Email: [email protected]

About Danielle Heberling:

Danielle Heberling is a software engineer with a background that includes being a musician and teaching at a K-8 public school. She’s passionate about building things that make the world a better place, whether that be through social change or a good laugh. When she’s not coding, you can often find her reaching back to her teaching roots by mentoring folks from underrepresented groups that would like to make a career switch into tech.

• Twitter: @deeheber
• Email: [email protected]

Notes:

• Translator GitHub Repo: https://github.com/stackery/language-translator
• Translator App: www.serverlessing.io
• Stackery Blog: https://www.stackery.io/blog/
• re:Invent Session: https://www.portal.reinvent.awsevents.com/connect/search.ww?searchPhrase=DVC16

Transcript:

Jeremy: Hi everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Farrah Campbell and Danielle Heberling. Hi Farrah and Danielle, thanks for joining me.

Farrah: Hey Jeremy, thanks for having me.

Danielle: Thanks for having me.

Jeremy: So you both work at Stackery and we can talk a little bit more about what Stackery does in a bit, but I want to start with you Farrah because you are the ecosystems director there and I think it's a really interesting role. Can you tell us what that's all about?

Farrah: Sure. Well, essentially the way I look at it is my job is to connect with people across AWS and other technical partners along with the serverless ecosystem so that we can increase serverless adoption.

Jeremy: Awesome. And Danielle, you are a software engineer at Stackery, and I'm curious what that role looks like when you are building serverless applications to help people build serverless applications.

Danielle: Yeah, it's pretty meta actually. Well, at Stackery we're a small startup. There's only six software engineers total. So I guess you could say we're all technically full stack, so I just jump in anywhere in the stack where I'm needed. And sometimes do customer support too.

Jeremy: Very cool. So I saw the two of you give a talk at Serverlessconf, New York, called Leveling Up Serverless. And you talk about this app that you built and we will get into that in a minute, but what I really loved about your talk was the story behind it. And as you both explained, you have very different backgrounds. Neither of you started in tech, but somehow you sort of serendipitously came across serverless, started participating in the serverless community. And that's what inspired you and enabled you in a way to actually build this application. And I think your story is inspiring, especially to people who are getting into tech or thinking about getting into tech. So I'd love to just talk about your experiences today and we can go through that. So Farrah, let's start with you. How did you get into tech?

Farrah: Well, my intro to tech wasn't like many people's, I hear. In fact, it wasn't until after high school that I really actually explored the internet. My mom had met a new man that she married who owned a computer company called MicroAge and he started a new startup in the back of that where he had multiple engineers working.

And I talked him into letting me work for them to research the horizontal and vertical markets. Multiple years later being a single mom needing to pay the bills, I found a job in health insurance but always really still had that love for working with developers and would always find ways to try to work with the engineering and IT departments, which was awesome because when I moved to Portland there was all these tech companies and there's this very vibrant growing community.

And I wanted so badly to be a part of it, but it took me... Well, I applied for jobs for about a year without any... I didn't get any interviews scheduled, and then started working or volunteering at a conference where I was able to meet a number of people. One who introduced me to a small startup in Portland where I was able to start working for four hours a week and then quickly turned that into a full-time office management position.

And then multiple startups along the way ended up leading me to Stackery. The cool thing about it though is with each one of those startup jobs, I was always trying to really understand the tech and trying to find ways to work and be a part of the engineering teams. They even set up a way for me to update documentation so I would actually have contributions to our source control. And it's been pretty cool to be able to do something more with that at Stackery.

Jeremy: Awesome. So Danielle, I think you and I probably had a very similar start. I went to college with the intent of being a music teacher actually, and instead I ended up switching into technology. But you started with music and you kind of went from there.

Danielle: Yeah, definitely. So I grew up in a small town and in order to keep out of trouble, I just became very active in music throughout middle school, high school, took piano lessons starting in kindergarten even. I just really loved creating and sharing music, and it got to the point where I had to pick a college major to go to college and I really had no idea what I wanted to do.

So I kind of looked at what I enjoyed doing activity wise and gravitated towards music. And I really like helping people out, teaching people. So I decided to go for music education. So I was a music teacher in a public school system for a few years and it took me to a different state, a completely different mindset in that area. I definitely enjoyed my time there, but longterm teaching just wasn't for me.

So I went back in a whirlwind of not knowing what I wanted to do for a career, but I did need to pay my bills. So I just put out a lot of job applications and ended up getting hired in tech support. I really love tech support because every day was a completely new challenge. A customer would write in with a question about how to use the product and it would be like something that I never even thought someone would want to use the product for.

So it really kind of gave me a great lesson in empa...

This is PART 2 of my conversation with Ory Segal. View PART 1.

About Ory Segal:

Ory Segal is a world-renowned expert in application security, with 20 years of experience in the field. Ory is the CTO and co-founder of PureSec (acquired by Palo Alto Networks), a start-up that enables organizations to build and maintain secure and reliable serverless applications. Prior to PureSec, Ory was Sr. Director of Threat Research at Akamai, were he led a team of top web security & big data researchers. Prior to Akamai, Ory worked at IBM as the Security Products Architect and Product Manager for the market leading application security solution IBM Security AppScan. Ory authored 20 patents in the field of application security, static analysis, dynamic analysis, threat reputation systems, etc. Ory is serving as an officer of the Web Application Security Consortium (WASC), he is a member of the W3C WebAppSec working group, and was an OWASP Israel board member.

• Twitter: @orysegal
• Prisma by Palo Alto Networks: https://www.paloaltonetworks.com/prisma
• The 12 Most Critical Risks for Serverless Applications: https://www.puresec.io/serverless-security-top-12-csa-puresec

Transcript:

Jeremy: All right. So let's move on to number four. So number four is over privileged function, permissions and roles. This is one of my favorites because I feel like this is something that people do wrong all the time because it's just easy to put a star permission.

Ory: Yeah. And this is an issue that I've been thinking about a lot of, why is it like from a psychological perspective that developers put a wild card there? So, obviously, we've talked about the very granular and very powerful IAM model in public clouds, and that's very relevant to serverless. You break your App down into functions, you assign each function you need to assign to each function, the permissions that it actually needs in order to do its task and nothing more than that, and that's the point here. How do you make sure that if somebody exploits the function, if somebody finds a problem in the function, they are not able to manipulate that function to maybe do some lateral movement inside your Cloud account, move to other data stores, etc?

So that's very important and we see that developers have a tendency, and this is one of the most common issues, to just use a wild card and allow the function to perform all of the actions on certain resources. And that, as I said, this is something that I've asked a lot of developers, why are they doing that? And I'm hearing different answers. Some are just lazy, I have to admit, I do that from time to time as well. It's much easier than actually having to go to the documentation and figure out the name, the exact name of the permission that I need. The other set of developers talked about future proofing the function. So they said, okay, now the function only puts items into database, but maybe next week I'll need it to read, which by the way violates the principle of single responsibility, but let's put that aside. And so they did just put maybe crude permissions or they put everything.

And then there are those who just either don't care, or don't know, or are not aware that this is a problem. So those are the three types of developers or answers that I've heard. But this is by far the most common and I've seen frameworks that automatically generates wildcards as well, which is also bad. And I've seen some bad examples as well in tutorials, which is the worst thing this can happen because we're trying to teach people how to write [crosstalk 00:48:21].

Jeremy: To go the other way. Yeah. Well, so the example that the document uses is the Dynamo DB star permission. And I love this example because you would think, okay, put items, get items, query items, delete items, that seems like that's what I'm giving it permission to. But, no, when you give Dynamo DB star permission, you're giving it the ability to delete tables, or change provision capacity, and you can do a lot of really bad stuff there. And obviously, this is all predicated on someone actually being able to get into your function, but that is something that is possible ... again, it's limited in how you can do that but it certainly is possible. We'll get into that more.

Just one point about about the permissions per function. One of the things that I like to do is I try to give each function the permissions that I think it needs, then I publish it to the cloud, and they try to run it. And then actually, AWS does a great job of giving you the error saying, this function doesn't have Dynamo: put item permission or something like that.

Ory: You're basically using debug branding to figure out the right permissions, right.

Jeremy: It works.

Ory: It's not nice. But they do have a service I think called, access advisor, and I think Google came out with a much better automated solution for that. Eventually, I think the access advisor would look at historical logs for, I don't know, a few days or a few executions and will tell you, it looks like you have too much permissions, you should probably reduce them. But this is something that we've done in Pure Sec with the there's the OpenSource list privilege plugin that we wrote that you can use for serverless which basically statically analyzes your code, extracts all the API calls and then maps them to the list required privileges, and will actually generate a list privilege role for you. So this is, and we'll talk about the future, but I think this is something that will eventually will have to be solved somehow or Cloud providers will probably produce better tools around that.

Jeremy: Well I think some frameworks are doing work with guard rails and stuff like that too that help a little bit but it's not quite there yet.

Ory: Mostly around the asterisks around the wild card, but actually-

Jeremy: What you actually need.

Ory: Exactly. Yeah.

Jeremy: All right, so let's move on to number five. And this is probably tied to number 10 in a way. So number five is inadequate function monitoring and logging. And I think this extends a little bit to number 10, which is improper exception handling and verbose error messaging. Whereas logging is a good thing [crosstalk 00:51:04] but can be a bad thing, right. So let's talk about inadequate function monitoring and logging first.

Ory: Well, I think looking at this issue now in hindsight and seeing that there's an entire industry of serverless monitoring vendors and solutions, I think, we already see that this is a real need. And it becomes more critical for security, not talking about performance and tracing and things like that, but being able to properly monitor your functions to log the right thing is critical. And if you look at this, for example, if somebody runs a sequel injection attack and triggers some exceptions, where would you even see that? I'm not even sure you would see that in the default logging facilities that the cloud providers give you.

So it goes back to the fact that developers have to worry about application security specific logging. And, yeah, so you have to write more into Cloud watch and if it's related to IAM and things like that, then you would see that in cloud trail, I'm talking AWS of course. But yeah, without t...

About Ory Segal:

Ory Segal is a world-renowned expert in application security, with 20 years of experience in the field. Ory is the CTO and co-founder of PureSec (acquired by Palo Alto Networks), a start-up that enables organizations to build and maintain secure and reliable serverless applications. Prior to PureSec, Ory was Sr. Director of Threat Research at Akamai, were he led a team of top web security & big data researchers. Prior to Akamai, Ory worked at IBM as the Security Products Architect and Product Manager for the market leading application security solution IBM Security AppScan. Ory authored 20 patents in the field of application security, static analysis, dynamic analysis, threat reputation systems, etc. Ory is serving as an officer of the Web Application Security Consortium (WASC), he is a member of the W3C WebAppSec working group, and was an OWASP Israel board member.

• Twitter: @orysegal
• Prisma by Palo Alto Networks: https://www.paloaltonetworks.com/prisma
• The 12 Most Critical Risks for Serverless Applications: https://www.puresec.io/serverless-security-top-12-csa-puresec

Transcript:

Jeremy: Hi everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Ory Segal. Hi, Ory, thanks for joining me.

Ory: My pleasure.

Jeremy: So you are a senior distinguished research engineer at Palo Alto Networks. So, why don't you tell the listeners a bit about your background and what you're doing at Palo Alto Networks?

Ory: Sure. First of all, congratulations for managing to actually say it, it's a mouthful. So yeah, actually I got this title after a PureSec, the company that I co-founded and was the CTO of got acquired in June of 2018, by Palo Alto Networks. So, as I said, I used to be the CTO and co-founder of PureSec a small vendor, actually the first vendor to offer a serverless security platform. And my current role at Palo Alto is mainly to oversee the research for the security algorithms and the product features for serverless security within the Prisma brand, which is the cloud security brand in Palo Alto.

Jeremy: Awesome. All right, so I want to talk to you about what you've been working on for, I don't know, how many years now it seems like, but serverless application security. And I want to start by discussing what's different about traditional security and why serverless security is a bit different.

Ory: First of all, I think it's important to get some background. I've been doing application security for I guess, over 20 years since the end of the 90s. Starting with Sanctum, which was the first company that that built the world's first web application firewall and later on Apps Scan, which was the first DAST scanner, which was later acquired by IBM. And after doing that for a while, I worked at Akamai for about five years leading the threat research for the cone and cloud security product. And at some point, somebody approached me and started talking to me about severless security. I can already tell you, that was one of the other co-founders. And the story or the technology behind severless sounded very interesting both from an innovative aspect but also from security. Everything I knew about application security seemed, at least from a protections perspective, seemed to be sort of irrelevant or not exactly fit the serverless model.

So obviously, and we'll talk about that later, you still need to do input validation, business logic enforcement and all of those things, but the form factor and the way you deploy serverless applications made it very challenging to the point that it was mind boggling and interested me very much and I started thinking about, okay, how can we apply runtime protection to serverless applications? And that, I guess, got me interested and eventually I left Akamai to join Pure Sec.

So, and back to your question, serverless security, should actually refer to this as serverless application security is indeed application security. The same old application security that we know and some of us love from other places like mobile and web apps. So input validation and configuring the platform and hardening and all of those things, but it has some twists, some very interesting twists that you definitely have to keep in mind when you're building those applications. It's a different way of performing threat modeling and different methods of input validation that you need to think about, where inputs are coming from.

Obviously, configuring the platform is very Different, we're talking about cloud native environments, usually public cloud. And again, we'll get back to that a bit later. So that twist is what I think makes it more interesting and obviously more challenging.That's a high level overview.

Jeremy: So let's get into a little bit more of the details there. So I think one of the things that changes quite dramatically, and I know you've written about this, is that shared responsibility model that the cloud gives us, right. So what changes with that shared responsibility model?

Ory: That's actually one of the topics that I really love talking and just discussing this offline, not always in conferences because this is something that I usually bring up when I talk about serverless security. So in every public cloud scenario, there's a shared responsibility model between the customer and/or the App owner and the cloud provider. And there's a line at some points, and really that line or where the line is drawn really depends on the type of cloud model or public cloud model that you're using. And so we start to think about infrastructure as a serverless, then the cloud provider is responsible for the physical infrastructure but any anything above that is your responsibility. So the VM, the host, the hardening of the operating system, and the users and everything, that's the responsibility of the cloud provider.

And in serverless that line reaches new heights, which is something very interesting, because for the first time you're really not responsible for the majority of security requirements or demands. If you look at PCI compliance requirements and you compare, and I have an article about that as well, between infrastructure as a serverless and functions or serverless, you see that your role is reduced or your responsibility is reduced to even less than half. Which brings me to the next point that's, theoretically speaking, serverless applications actually are a terrific enabler for application security. Takes away a lot of the things that we usually miss or we usually screw. So patching that we all know is a very tedious task that you have to constantly be on top of.

So in serverless your starting point, from a security perspective, is actually much better off. Somebody else is responsible for almost everything except for the application itself, which is, I think, the future of what I was hoping for application security to see all those things patching, and OS updates, and physical infrastructure taken care of by somebody else and leaving you to deal with the things you actually understand about, which is your core business and the business logic that you own.

Jeremy: Right.

Ory: I recently heard a very cool analogy about serverless. Somebody was comparing it to transportation or automobile industry where, when you own servers, it's basically like you own your own car. And then Infrastructure as a service is more like ...