Show Notes:

On event-driven architectures...

Mike Deck: (Episode #5) I think that it's probably easiest to understand it when contrasted against kind of a command-driven architecture, which I think is what we're mostly sort of used to. So this idea that I've got some set of APIs that I go out and call and I kind of issue commands there, right? So I maybe have an order service. I'm calling create order or I've got downstream from that. There's some invoicing service now, and so the order service goes out and calls that  and says, "Create the invoice, please." So that's kind of the standard command-oriented model that you typically see with API-driven architectures. An event-driven architecture is kind of, instead of creating specific, directed commands, you're simply publishing these events that talk about facts that have happened, you know these are signals that state has changed within the application. So the order service may publish an event that says, "hey, an order was created." And now it's up to the other downstream services to, they can observe that event and then do the piece of the process that they're responsible for at that point. So it's kind of a subtle difference, but it's really powerful once you really start kind of taking this further down the road in terms of the ability to decouple your services from one another, right? So when you've got a lot of services that need to interact with a number of other ones, you end up kind of with a lot of knowledge about all of those downstream services getting consolidated into each one of your other kind of microservices, and that leads to more coupling; it makes it more brittle. There's more friction as you're trying to change those things, so that's a huge kind of benefit that you get from moving to this event-driven kind of architecture. And then in terms of kind of the relationship to serverless, obviously with services like AWS Lambda, you know, that is a fundamentally event-driven service. It's about being able to run code in response to events. So when you move to more of this model of hey, I'm just going to kind of publish information about what happened, then it's super easy to now add on additional kind of custom business logic with Lambda functions that can subscribe to those various different events and kind of provide you with this ability to build serverless applications really easily.

On understanding the connectivity of microservices...

Ran Ribenzaft: (Episode #8) We broke them from being a big monolith, a big single monolith, to multiples of microservices, you can call it microservices, service, nanoservices, but the fact that there was one giant thing that broke into 10 or hundreds of resources, suddenly presents a different problem. A problem where you need to understand what is the interconnectivity between these resources, that you need to keep track of messages that [are] going from one service to another, and once something bad happened, you want to see the root cause analysis. This is like a repetitive thing that you can hear over and over. This root cause analysis, so the ability to jump from the error - the error can be like a performance issue or like exception in the code - all the way to the beginning. The beginning can be the user that clicks on a button on your business website that caused this chain of events. So these are the kinds of things that you want to see where, in traditional APMs, in traditional monitoring solutions, you don't have it. And in the future, once you'll find it more and more like that.

On monitoring interconnectivity...

Emrah Şamdan: (Episode #12) In serverless, on the other hand, it is like you have different piles of logs, which it comes out of box from CloudWatch, from the resource that Cloud vendor propose. But these are actually separate, and these are not actually giving the full picture of what happened in the distributed serverless environment. And what you need here is that the problems are different. In a normal environment, the problem, most of the time, was actually about scalability and you were responding to that by giving more resources, by just increasing the power of your system. But with serverless, the problem is about like some problem occurs in any kind of a system in a distributed network and you need some more than log files. You need like all three pillars of observability, which is called traces. In our case, it is distributed traces, which shows the interaction between Lambda functions and the managed APIs and the managed resources and third-party APIs, and the local traces, which shows what happens in the Lambda function, and the metrics and the logs.

On the purpose of AWS X-Ray...

Nitzan Shapira: (Episode #2) You can do it to some extent. X-Ray will integrate pretty well with the AWS APIs inside the Lambda function, for example, and will tell you what kind of API calls you did. It's mostly for performance measurements, so you can understand how much time the DynamoDB putItem operation took or something of that sort. However, it doesn't try to go into the application layer and the data layer. So if information is passed from one function to another via an SNS message queue and then going into an S3, triggering another function - all this data layer is something that X-Ray doesn't look at because it's meant to measure performance. That's why it would not be able to connect asynchronous events going through multiple functions. Because again, this is not the tool's purpose. The purpose is to, again, measure performance and improve the performance of certain specific Lambda functions that you wanna optimize, for example.

On instrumentation...

Ran Ribenzaft: (Episode #8) Instrumentation is the way or a technique which allows a developer to, let's call it hijack, or add something to every request that he wants to instrument. For example, if I'm making a calls using Axios to a REST API for my own code to an external or third-party API. I want to be able to capture each and every request and response that is coming in and out from that resource, from that Axios request. Why would I like to do that? Because I want to capture vital information that I'll be able to ask questions about later on. For example, if my Axios is calling Stripe to make a purchase or to send an invoice to my customer, I wouldn't know how long it takes, because I don't want my customer to wait on this purchase page or wait for his invoice to get into his email. I want to make sure of how long it takes so I can measure that, put that as a metric in CloudWatch metrics or in any other service. And then I'll be able to ask, "Well, was there any operation against Stripe that took more than 100 milliseconds?" If so, it's bad, and this is only accomplished using instrumentation. I mean, the other way around is just to wrap my own codes every time that I'm calling Stripe or every time that I'm calling any other service. But with the amount of annotations that you'll have to add to your code, it's almost unlimited, so you won't get out with it without a proper instrumentation in your code.

On the problems with manual instrumentation...

Nitzan Shapira: (Episode #2) It's not just the fact that you can forget. It's also just going to take you a certain amount of time - always - that you're going to basically waste instead of writing your own business software. Even if you do remember to do it every time, it's stil...

About Sheen Brisals

Sheen is an experienced software engineer, solutions architect and a team coach, currently at LEGO architecting serverless solutions. Previously as a principal engineer, tech lead and development manager with leading organizations such as Oracle Corporation, Hewlett-Packard, Omron, TATA, BAe and others. Sheen is a regular speaker at tech gatherings. He is a keen participant at Serverless meetups, AWS conferences, Serverless Days and others.

• Twitter: @sheenbrisals
• Blog: https://medium.com/@sbrisals

Transcript

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

Sheen: Hey, Jeremy. Pleasure to be here. Thanks for having me.

Jeremy: So you are a Senior Application Engineer at the Lego Group. So why don't you tell the listeners a bit about yourself and what you do at Lego.

Sheen: Right. So, yes, I am a Senior Engineer at Lego. I joined Lego three years ago. And as part of my role with Lego, I I act as a team lead; I act as an architect and also I coach fellow engineers on their career progression. So in terms of my career, I started way back in the nineties as a software engineer. I’ve been through quite a few organizations - both big and small - been involved with number off software development projects all the way through. So I joined Lego at a juncture where when they were thinking of moving to microservices so that's why I came on board with Lego, around three, three and a half years ago.

Jeremy: Awesome. Alright, so you are like jet-setting around the world telling the story of how Lego.com went serverless and I've seen you speak at a number of conferences and I think it's a huge service that you are doing for the serverless community sharing this because it is important, I think, for teams to see how other companies are doing it and how other people are implementing these things because it's very new. Serverless is very new, and even though it's been around for five years at this point, there are still a lot — there’s a long way to go. So I want to talk to you about this idea of the serverless journey at Lego.com. So let's start sort of where are you now? Where is Lego now with serverless?

Sheen: So within Lego, there are different teams or departments embracing serverless. So I am with the team that focuses on shopper technology, shopper engagement technology, that includes Lego’s ecommerce platform and all the toolings around that. So we are progressing well with the serverless approach, so as you know that we migrated the ecommerce platform onto serverless. So we didn't stop here, but our journey continues beyond that because now there are new issues, new developments coming up because we see the benefit of serverless that gives in terms of the speed or the, you know, velocity with which we can bring out new features to customers.

Jeremy: Great. Alright, so let's go back to the beginning, because this is one of those interesting things where I think companies get to this point where they're either starting their cloud adoption or they're running on legacy hardware, and they say, “Okay, we need to now make this move.” And a lot of people go down that container route, but it was a little bit different, so let's start with where you guys were. Where were you a couple of years ago when you came in there? What was the technology?

Sheen: So that time, all on-prem. And so we had Oracle ATG, an old version of Oracle ATG ecommerce platform hosted on-prem and we had an Oracle database talking to, the platform itself talking to a bunch of other services within Lego. And at some point, there was an initiative that happened to make it more API-based and even that time they first APIs around. But still, it was on-prem and a monolith, but the front-end moved on from being a JSP onto a JavaScript based, hosted on Elastic Beanstalk from AWS. That's pretty much what we had two years ago out in that time frame. So we had, you know, they did a number of issues associated with the typical monolith platform maintaining or releasing our new features and fixes and things like that. So that was pretty much the landscape we had at that time.

Jeremy: And then you had sort of a “come to Jesus” moment on Black Friday, right?

Sheen: Yes. So yes. So there are different things. So though I focus on that particular incident, there were one or two other thoughts that were going on. So, first one is the ecommerce platform itself was aging and very old. So we had to move on and then Lego, as a company, wanted to reach out to many children around the world. So that means they need the platform to go out and launch the shop and the availability of the bricks and everything to children around the world. So that was — from the business side of things — that was a need. So we need a platform that can provide us that capability. At the same time, we wanted to migrate from the old platform, so we were not thinking of serverless. So a typical microservice, put everything in a Docker, or, you know, containerize an instance-base — those were the different ideas floating around. Then came this Black Friday. And we had this catastrophic failure of the platform so that triggered some of the conversations internally to get to a point that we must break up things. We can't have everything together as a one-piece. So we wanted to make sure that, you know, we don't fail just like that. If something fails there are stuff the platform should be able to carry on. That's where things got ignited I would say and started the business and the engineering teams started to discuss and come up with proposals and ideas. So serverless was very much new at that time, and no one had any experience or exposure within the team I belonged. So I went out to office while looking at AWS and I'm talking to people, attending different conferences and meet-ups and things like that to gather the idea. Still, not to say where to take the leap to. So that was, at that time, when we had that Black Friday failure. So from then on, based on the technology improvements and the Cloud initiate deals and the organization-wide that the need for our digital transformation initiate too. So all those things came together for us to, you know, take on this serverless journey.

Jeremy: Did you already decide to move to the cloud? Like, basically, you said on-prem is not working for us or we need to be able to scale more. So you decided to move to the cloud and you said you looked at containers. But what was the thing about serverless though, that you said no, we definitely have to go this route?

Sheen: Okay, so there was another factor. So as part of the platform migration or the upgrades, there were a bunch of things that were looked at so either have a platform similar to what we had and everything available within a part of the platform or go the other way around. Look for simple, headless, API-based platform and then we can put our logic around it so we have the freedom to innovate, scale, bring in new features and the all other capabilities from our side. So that was kind of the discussion point. Then he chose that, okay, we need the flexibility because we don't want to be constrained by some of the commerce platforms out there. So we wanted the freedom to innovate, freedom to bring on the features the way that we wanted to bring out to the customers. That was a main shift. That's when we started looking at cloud as a, well, you know, ...

This is PART 2 of my conversation with Michael Hart. View PART 1.

About Michael Hart

Michael has been fascinated with serverless, and managed services more generally, since the early days of AWS because he’s passionate about eliminating developer pain. He loves the power that serverless gives developers by reducing the number of moving parts they need to know and think about. He has written libraries like dynalite and kinesalite to help developers test by replicating AWS services locally. He enjoys pushing AWS Lambda to its limits. He wrote a continuous integration service that runs entirely on Lambda and docker-lambda, which he maintains and updates regularly, and has gone on to become the underpinning of AWS SAM Local (now AWS SAM CLI).

• Twitter: @hichaelmart
• Github: github.com/mhart
• Medium: medium.com/@hichaelmart

Transcript:

Jeremy: Alright, so now we're going to go to the next level stuff, right? So if you’ve been...

Michael: That's not next level enough for you.

Jeremy: Well, that's what I’m saying. If you made it this far, I hate to tell you what we just talked about was kid's stuff, right? We're going to the next level. Alright. So you have been working on a new project called Yumda, right? Tell us about this. Because this thing — this blows my mind.

Michael: Right. So this is basically what was born out of the realization that people have struggled traditionally to get things compiled — native binaries or anything like that compiled for Lambda. For example, if you do want to write a CI system like lambci, then you will need some sort of git binary or a git library. But I would suggest using the git binary because libgit is just not there with all the features, But, you know, you'll need to get binary running on your Lambda so you can do a git clone of the repo that you're then going to do your CI test on, and getting that on Amazon Linux 1 was kind of hard enough. Getting it on Amazon Linux 2 is much harder, because there are so many fewer dependencies that exist there. I think on Amazon Linux 1 already had — it has curl on it. You know, if you're in Node.js 8, you could just shell out to curl, so a git has curl as a dependency. So if you're compiling git for, you know, the older runtimes you didn't need to worry about a curl or anything like that. You just need to worry about git. On Amazon Linux 2, you don't have curl, you don't have some really, really basic system libraries. So if you want to get git running on Amazon Linux 2, you need to pull in a lot of stuff yourself. And I got to thinking, well, what would be the best way to provide, you know, a bunch of pre-built packages out of the box? Yes, you could use layers. And I think layers are a great idea for very high-level packages, very, very large binaries that have a huge tree of dependencies or certain utilities. But it's impractical to be creating a layer for every single dependency that your native binary's going to use. You don't want to be creating one layer for libcurl, and another layer for libssh and another layer for this. Firstly, you're only limited to five layers that you can currently use in your Lambda, so you'd need to be squashing them together anyway. And secondly, it's just layers, certainly as they stand at the moment, they're not — if there's no particularly good discovery around them. It's nothing like doing an `npm install` or a `yum install` or something like that.

Jeremy: Well, and I also think that many of those layers, that if you install five layers, that a lot of those might be sharing dependencies under the hood as well, like they might have shared dependencies and then you might be installing those twice or three times. I don't know if they would...

Michael: Right, right, could they be clashing.

Jeremy: Yeah.

Michael: No, no.

Jeremy: But anyway, sorry.

Michael: No, no. So that's another consideration. So I thought, well, ideally, what people want to do, and this is certainly what people do in the container world, if you're writing a Docker container, you know, and you need native dependencies, one of the first steps you'll do in your Docker file is you'll do `yum install` whatever dependency I need. And that'll go down and pull all the sub-dependencies and then that will be installed in your Docker container. And then you can, you know, run your app from there knowing that this stuff exists. We don't have anything like that for Lambda, so I thought, well, I want to run YUM install essentially and have all those packages — all those Amazon Linux 2 packages that are there — you know why couldn't I just get them and install them for Lambda? And the reason that you can't do that is when you run a yum install, it installs in the system directories; it installs software in /usr/bin, /usr/lib64 if it's a dynamic library. And you can’t install that to those places on Lambda. You can only install to, if you're using layers, /opt so /opt/bin is in the path and /opt/lib is in the lb library path, which is where dynamic libraries get loaded from. So you need to make sure that your binaries in your dynamic library sit in those path. That's where they'll be unzipped to essentially when your layer is mounted or /var/task if you've bundled them up with your Lambda function. So you need to make sure that the binaries that you're shipping and the dynamic libraries that you're shipping are okay living in those paths and there's a lot of binaries and libraries out there that aren’t. You can't just copy them from /usr/bin to /opt/bin because something's being compiled into that binary that is assumed that's living in /usr/bin. There are a bunch that you can just move around  and that is a good first test. You may as well try it out, see if you can move a library from here to there or see if you can move a binary from here to there. But there might just be something down the track while you're using it, where it’s suddenly like, hey, I can't find this file or maybe it's depending on the configuration file in a path that's been hard coded as well, and you can't get your configuration file to that path because it's not writeable by you. So what I did was I took the Amazon Linux RPMs, and you can get, you know, all these RPMs are open source. You can get the source RPMs. RPMs is this sort of Red Hat package manager format for what a native package looks like on Red Hat Linux and all of its various children, including Amazon Linux, which, which sort of stemmed from Red Hat. So RPMs are what yum what YUM Install will use to install. So I pulled all these RPMs down there, and then I just re-compiled them instead of instead of /user being the path they were compiled for, compiled them for /opt so then you know, I had all these packages that I had re-compiled on, and then I created just a little a little Docker container that has YUM on it that is configured to install these RPMs in the right place because you also — the way that you, if you ever do want to YUM install the package in a non-system director, you have to provide a bunch of configuration to it to let it know that you're doing that. So I sort of pre-configured all that and to talk to the YUM repo that I had se...

About Michael Hart

Michael has been fascinated with serverless, and managed services more generally, since the early days of AWS because he’s passionate about eliminating developer pain. He loves the power that serverless gives developers by reducing the number of moving parts they need to know and think about. He has written libraries like dynalite and kinesalite to help developers test by replicating AWS services locally. He enjoys pushing AWS Lambda to its limits. He wrote a continuous integration service that runs entirely on Lambda and docker-lambda, which he maintains and updates regularly, and has gone on to become the underpinning of AWS SAM Local (now AWS SAM CLI).

• Twitter: @hichaelmart
• Github: github.com/mhart
• Medium: medium.com/@hichaelmart

Transcript

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

Michael: G’day, Jeremy, mate. How’s it going? You having a good day? Is everything going alright so far?

Jeremy: I love the Australian. I love the Australian accent. You don't actually talk like that, but that was...

Michael: I don't know what you're talking about. I talk like this all the time. Yeah, I do. I do wonder. I feel like if I did speak like that all the time, people might find me charming, but I don't think they'd have a clue what I was saying.

Jeremy: Exactly. Yeah. No, I actually thought Australians spoke English until I met a bunch of Australians, and I said I don't know if that's English, but anyway, so it's awesome to have you here. You’re the VP of Research Engineering at Bustle. You're also an AWS serverless hero. Why don't you tell the listeners a little about your background, what you do, and what's going on at Bustle?

Michael: Sure. So a little bit of my background: I have started a couple of companies, co-founded a couple of companies, been CTO before, in Australia. This was moved to New York, did a bit of consulting and then joined Bustle as the VP of Research Engineering. So I, you know, do a bunch of interesting research things there. Bustle is a digital media company. We have a bunch of sites, mainly targeted at sort of millennial women, although we've recently been expanding that market.

Jeremy: Awesome.

Michael: And we have, just in the last year or two, I think I think we've sort of acquired or started about nine other sites, so yeah, growing.

Jeremy: And you guys are using serverless up and down your entire stack.

Michael: Yes, serverless across the board. Yeah. Been pretty early on that, yeah.

Jeremy: Awesome. Alright, so I have had a number of conversations with you. We were out in Seattle. We were out in New York City the other day. We've had a ton of conversations about serverless and Lambda and all these things that it can do. I would have recorded the conversations, but usually we're in a bar drinking Old Fashioneds or just being, you know, whatever, and the audio quality wouldn't be that good. So anyways, I want to talk to you about all these cool things that you do with Lambda functions because I have talked to tons of people and I capture use cases in my newsletter every single week and, you know, they're interesting things, but I don't think I've met anybody who has pushed Lambda to the limits like you have. And, I mean, not just like one thing, like multiple things. So I want to get into all of that stuff. But just maybe we could start by talking about, you know, in case people don't know, what is it— The Lambda function itself, it's actually an execution environment. There's an Amazon Linux runtime underneath there, or operating system underneath there. So you know this inside and out. And this will become abundantly clear that you know probably more about this than some of the AWS engineers as we go through this, but just let's start with that. What is a Lambda function? What is it made up of?

Michael: Sure. Yeah, so you're absolutely right. It is the environment that your function is running in is sitting on Amazon Linux, until very recently until the Node.js 10 runtime. That was all Amazon Linux 1, which is getting pretty old now. And then the ruttimes themselves would would sit on top of that just in a directory in the operating system, and each runtime would have, you know, whether it's running on Python, then the Python binary and all the libraries. And if it’s Node, then the Node binary and other libraries so that it'd sort of be the only difference between those two runtimes; the underlying operating system’s still the same. I mean, and these are launched very quickly. Now it's on Firecracker, which is Amazon’s sort of new VM-type technology that sort of provides isolation. But essentially, you know, these isolated environments spin up very quickly and they're running an operating system that runs a runtime that then invokes your function, which is also sitting on the file system.

Jeremy: Alright. So let's get into a little bit more than the details though, I mean, in terms of things that are installed and ready to go. I mean, it's more than just the runtime, right? I mean, there's other libraries, and other things...

Michael: No, you're absolutely right. So, unlike — I'm trying a bit of a good example — unlike if anyone's played with Cloudflare Workers or something like that, that's just running JavaScript. There's no sort of file system that you have access to or anything like that. It's just sort of a JavaScript environment with all of the things that you would have access to if you were in the browser, for example, those so you know most of, or a lot of those sorts of APIs. In Lambda, there is a file system in there. It's a Linux operating system running a process and and then including your Javascript file or Python file and running that. So as well as your file and and the runtime itself, there are, you know, a bunch of base operating system binaries sitting there that you can access as well and Amazon’s pretty cagey about what guarantees they give you about what binaries will be there. They say, “You know if you want to compile something native that your Lambda uses, compile it for an Amazon Linux environment, you know, and that's pretty vague because obviously, you could have an Amazon Linux environment with a whole bunch of binaries or dynamic libraries installed or you could have an incredibly stripped-back operating system that has nothing installed. So in that case, you'd need to sort of bring those binaries yourself into your Lambda. So a good example is if your Lambda function wanted to call out to Bash, do you just assume that Bash is there on the operating system? That's probably a pretty fair assumption. Bash is on most Linux operating systems or certainly the larger ones. So that might be a fine assumption. But then another example might be Perl. You know, maybe you need — maybe your function does something a little bit exotic. Maybe it's doing some cool image manipulation or video manipulation that it needs to call out to a Perl script. Do you assume that Perl is in the Lambda environment or do you bundle yourself or include it in the layer or some...

About Brian Leroux

Brian LeRoux is currently building a continuous delivery vehicle for cloud functions called begin.com on an open source foundation called arc.codes. Previously he worked at Adobe on PhoneGap and Apache Cordova. Brian believes the future will be writ as functions, seamlessly running in the cloud, agnostic of vendors, on an open source platform and it will be stewarded by hackers like you.

• Architect Framework: arc.codes
• Twitter: @brianleroux
• Begin: begin.com
• GitHub: https://github.com/brianleroux

Transcript

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

Brian: Thanks for having me. Excited to be here.

Jeremy: So you are the Co-Founder and CTO at Begin. So why don’t you tell the listeners a little bit about yourself and what Begin does.

Brian: Yeah. Cool. So, I'm Brian. I’m a Webby hacker. I guess you could say I've been building software for a really, really long time now, and my focus has been, in the last few years, the cloud. In a previous life, I used to work in the mobile space quite a bit and Begin.com is continuous integration and delivery for serverless applications — modern serverless applications.

Jeremy: Awesome. Alright, so I wanted to have you on today to talk about the Architect Framework. So this has been out there for quite some time, but just in case people aren't familiar with what it is, maybe you could just tell listeners what the Architect Framework is all about and what you can build with it.

Brian: Yeah, Architect is a serverless framework. It papers over some of the more complex bits of getting up and running with a serverless application. It's sometimes accused of being pretty opinionated, but I think maybe we'll dig into that a bit in this episode and how maybe it's not so much opinionated, just, you know, makes some choices up front for you and saves you time. It's much more convention than it is configuration. And it's really targeted at building super fast web apps.

Jeremy: So let's get into that. So first of all, why did you build this? Because there's Claudia.js and there’s Sam, and there’s Serverless Framework, and there’s — you name it, there's a framework out there that helps you build serverless applications. So what was the reasoning behind it?

Brian: We never actually set out to build a framework. In 2014, I left my role at Adobe. I used to work on the PhoneGap in Cordova projects. And a big part of that was this thing called PhoneGap Build, which is a hosted service that’s part of the Creative Cloud where you can upload HTML, CSS, and JavaScript, and we spit out native iOS and Android apps. And building for Creative Cloud and building a big load-balanced rails application taught me a lot of lessons. One of those lessons was: I'd never want to do that again. And when I came out the other side, Ryan Block and I started the first iteration of Begin, which was a Slackbot, and we didn't really know a whole lot about what we were going to be building or how we were going to be building it. But we knew what we didn't want to do. And what we didn't want to do was take on a traditional load-balanced, monolithic architecture. And this new serverless thing was around and it looked like this was the future. It was 2014 at this time. Lambda was new, but there was no way to do an HTTP call. And then that August, API Gateway was released and I was floored personally. I saw it, and I was like, that's it. It's just got to be the future. So we built the first iteration of Begin, which was a Slackbot, and it had really strong real-time requirements, because it was a bot and had a web app component to it. And at that time, there was only one framework. It was called JAWS and it really was early days. So we built our own thing, but we built a product. We didn't build Architect per se. That project didn't work out, but we extracted Architect afterwards to build our second thing, and we knew we were onto something because, very similar to the Basecamp story, we didn't try and create a framework. We built a thing, and in the process of building that thing, we came up with something that looks a little bit different. When you look at Architect, it's not the same as other frameworks because we weren't trying to build a framework. We're trying to build a product.

Jeremy: And I think that's actually kind of typical of building serverless applications. I know as I started building serverless, as I was working on my first few serverless applications, I built the Lambda API web framework, right, because I just needed a better way to process API Gateway calls using the Lambda proxy integrations. And then,I built the Serverless-MySQL package to deal with the max connections issue. And you start building these components to help you build the products that you want to build, and eventually, you get some really cool tools that come out of it. And that's basically what you did with Architect, and you’ve made that open source, right?

Brian: Yeah. We donated it to the, at that time it was called the JS Foundation. But the JS Foundation, and the Node.js Foundation merged and became the OpenJS Foundation. I've got a pretty long history in open source, and I really believe in foundation-backed governance for projects. And so it was important to me to pull that IP out of a privately-held, venture-backed startup and put it into a place where the commons could contribute back to it. And just as a note, so the listeners understand, I'm not a zero sum thinker. There's going to be more than one framework. Technology tends to be additive, and there's going to be different things that we could learn from each other and build on from each other. So by all means, check out Architect, but, you know, if you're a Python hacker, you would be remiss not to check out Chalice. And if you're deep into AWS, you're probably already using Sam, and I think that's just fine. That makes sense to me.

Jeremy: Awesome. Alright, so let's talk about this opinionated thing because when I first saw this — it is kind of funny — but when I first saw the Architect Framework, I was looking through it, and I'm like, okay, this seems like it is built for solving a very specific problem. And again, I know it can be extended and you've got other things we can talk about, like some of your macros and things that you can build on top of it, but it just seemed very opinionated to me, in the sense that you were enforcing small file sizes, single purpose Lambda functions, that kind of stuff. So what are your thoughts on that? Because you maybe don't think it's so opinionated, right?

Brian: I didn't and Yan Cui from the Burning Monk wrote an awesome blog post where he threw Architect way up in the opinionated corner. And when we first saw it were like, “Oh, weird. Okay.” So we do look different and we do look like we have opinions, but I think most people will share those opinions. So one of our opinions is that we need to be really fast. And we need to be faster both author time and at runtime. So by author time speed, I mean, we need deploy iterations and lead time to production to be really quick. Monolithic apps have pretty poor characteristics for this. They tend to be deployed in minutes to hours, if not days or weeks, whereas serverless a...

About Rowan Udell:

Rowan Udell is Cloud Practice Director at Versent, an AWS Premier Consulting Partner in the Asia Pacific region. Working with customer and internal Versent teams, he helps them deliver change at scale and speed using serverless and AWS native services. He co-authored the AWS Administration Cookbook and has published video courses on AWS.

• Twitter: @elrowan
• Blog: blog.rowanudell.com
• AWS APN Ambassador: https://aws.amazon.com/partners/ambassadors/ambassador-apac/
• AWS Administration Cookbook: https://www.packtpub.com/virtualization-and-cloud/aws-administration-cookbook (2nd edition coming out soon)

Transcript:

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

Rowan: Hey, Jeremy. Thanks for having me.

Jeremy: So you are the technical director at Versent which is in Sydney, Australia. And you are also an AWS APN Ambassador. So why don't you tell the listeners a little bit about yourself, what Versent does, and actually, I'm kind of interested in this AWS APN ambassador thing, if you could tell us about that as well.

Rowan: Yeah, sure. So Versent is a premier consulting partner here in Australia and, you know, we work with a lot of enterprise customers, really helping them do cloud the right way. You know, if I was to describe us to a wider audience, we kind of want to see ourselves as the heart specialists for AWS. You know, when you have a heart problem, you go to see a specialist. You don't just go to any old doctor and we want to be that for AWS. In my role as technical director, I work with a lot of teams that are using Step Functions and other serverless technologies, building out applications on AWS. I'm part of the APN Ambassador Network, which is a new program that AWS has started up for consulting partners. APN Stands for the AWS Partner Network, and what they've done is get together a group of like-minded partners in one room so that we can kind of give feedback to AWS but also help them get new features, services, technologies out into a wider audience, you know. And so a big part of what we do is things like coming on this podcast, but also doing blogs, doing meet ups, giving speaking events and things like that. And so they really kind of encourage us and enable us to get the word out there and try and make AWS easier to use for everybody, not just consulting partners.

Jeremy: Great. And what about your background? Where do you come from?

Rowan: Yeah, So, I mean, I've been working in IT for longer than I'd like to admit now, you know, mainly with AWS, especially over my last four years here at Versent, just working purely with AWS. Before that, I was leading developer teams, working at some startups, things like that. And, you know, when the cloud came along, I really kind of jumped on board because I was sick of administering servers in the first place. And that's probably another reason why you see me online talking a lot about serverless stuff.

Jeremy: Awesome. Alright, so I have had a number of episodes where we've gone down sort of the technical path of some subjects. Some of them we've talked more about the business things, but I know that you do a lot of work with Step Functions, both as obviously as your role as a consultant, but also just I think just what you're doing out there working with teams and what you're seeing. So I want to talk about Step Functions today, AWS Step Functions. I think this is a really fascinating service that they offer. I think it's under utilized by a lot of people. I mean, it certainly has good use cases and use cases that may not be the best for it. But maybe so if people don't know, what are AWS Step Functions?

Rowan: Yes, so AWS Step Functions is the name of Amazon's state machine as a service offering that they have. State machines are sometimes called finite state machines, and this just makes them much more easily consumed and also integrated with your serverless applications.

Jeremy: All right, so let's let's start high level here. What are state machines?

Rowan: Yeah, so a lot of people get turned off by some of the terminology. But I mean, really, it's just a lingo or, you know, some vocabulary that's actually been around for quite a while. State machines are nothing new. State machine’s really just a mathematical way of modeling an application. Most people kind of understand what that means conceptually, but what it means in reality is you can describe your application as a mixture of your inputs, the states that your application can be in, and the transitions between those states. And what this forces an application designer or really a developer to do is to think really concisely and clearly about what their application does and what it could do next, and it kind of forces you to do that upfront, which I think is something that's really valuable and often overlooked.

Jeremy: Yeah, and one of things that I really like about state machines and specifically Step Functions in the serverless world is that ability to do function composition. Because I think that's one of the things that many people are confused about. Like how do I have function X talk to function Y, right? So state machines are the glue in between those, right?

Rowan: Yeah, definitely. And you bring up a really good point because we see a lot of people out there discussing on forums and in Slacks about like, “Should I have one function call another function directly?” and usually someone will jump in and say, “Oh no, you should never do that.” But obviously, then that's going to complicate things a little bit. And in some ways, if you're using Step Functions that problem goes away because you're able to link two functions together, you know, which allows each one of those to do one thing well, and you don't have to worry about calling them directly and coupling those two functions to each other. At the same time, you don't have to introduce things like SNS topics or SQS queues in between those functions. You know, in my opinion, it's kind of the best of both worlds.

Jeremy: Yeah, I mean, and that's where we're talking about orchestration versus choreography, right? So and that's one of the things that if you're using SNS or you’re using EventBridge or using some other communication channel or messaging bus, you can decouple the applications — state functions are a way of sort of creating coupling. But it's a different type of coupling, right? Because a function can run on its own outside of Step Functions or it can be part of several Step Functions, right? Different steps within that could reuse that same piece of logic. It's just a way of kind of gluing all that stuff together, like you said.

Rowan: Yeah, it is a form of coupling, but it's a loose coupling. You know, the function that is calling or being called doesn't know that it's being called by another function, to your point where it might be part of a complicated workflow or it might not. It really doesn't matter to the implementation function.

Jeremy: So what about the visualization of these things, too? That's another sort of important piece, right?

Rowan:...

About Gillian Armstrong and Mark McCann

Gillian works as a Solutions Architect at Liberty Information Technologies. Her team is focused on thinking about big problems, and working out how to solve them using innovative technology in interesting new ways. At the moment she is working on Artificial Intelligence, with a particular focus on Conversational AI design and development. She has more than a decade’s worth of experience in many technologies across the full stack, and loves being a software engineer as it allows her not just to think up big ideas, but also to make them a reality.

Mark is an Architect at Liberty Information Technology that has been developing software and solutions for Liberty Mutual for nearly 20 years. He is currently working on making "Business idea to production in minutes" a reality. Mark holds several AWS Cloud Certifications and has a vast amount of experience with microservices, event-driven architecture, Docker, AWS, and other emerging cloud technologies.

• Gillian Twitter: @virtualgill
• Gillian Web: virtualgill.io
• Mark Twitter: @markmccann
• Liberty IT: liberty-it.co.uk

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week, I'm chatting with Gillian Armstrong and Mark McCann. Hi, Gillian and Mark. Thanks for being here.

Gillian: Hi. Thanks for having us.

Mark: Hello.

Jeremy: So both of you work on the team at Liberty Information Technology, which is a part of Liberty Mutual Group. So Liberty Mutual, if people don't know 100-year-old insurance company, one of the largest here in the US - you have, what - 30 countries you work with, 50,000 employees, something crazy like that. So let's start with Gillian. You’re a Solutions Architect there. Why don't you give us your background, a little bit more about what you do?

Gillian: Sure. So I have worked across a lot of the areas in Liberty, including our emerging tech space, where I was first able to work on some completely serverless-first projects. This year, I’ve been working with the teams in our digital ecommerce space in Boston, looking at serverless, looking at AI, and I've just moved to our Data and Analytics unit. I definitely have a big focus on driving the serverless mindset in the company and also trying to get involved in the serverless community as well. And I'm also looking at AI sort of from an engineering and serverless perspective. So how far can we get using the managed services? How do we bring it into a large enterprise systems? Because, as you said, Liberty Mutual is a huge company.

Jeremy: Great. All right, Mark, what about you? You're an Architect there. Why don't you tell us about yourself?

Mark: Yeah, I’m an Architect with Liberty and similar to Gillian, I have worked across multiple different teams and areas in my 19 years working here with Liberty for everything from C++ mainframe development, the introduction to JavaScript, the introduction to Java and Spring and moving into this sort of adoption cycle. And then now, more recently, moving into microservices, all the good DevOps practices, and ultimately, where we're heading there with this big push to the cloud and serverless adoption. So been through the entire journey from you know, from mainframe to serverless.

Gillian: Yes, so Mark, and I work in very different areas, but we try to be really collaborative across the company and sort of some of these bigger things like serverless.

Jeremy: Well, Mark, it's good to be talking to another developer old-timer like myself. I appreciate that. Alright, so let's start, because again, Liberty Mutual is huge and you are actually part of Liberty Information Technology. So these are separate companies and I'm fascinated by how large organizations work and how all things are distributed and stuff like that. So maybe one of you can explain to me and to the listeners, what's the relationship between Liberty Information Technology and Liberty Mutual?

Gillian: Yes. So we did say Liberty Mutual had about 50,000 employees. About 4000 of those are in IT. And the company we work for Liberty IT is a wholly-owned subsidiary of Liberty Mutual. We have about 600 software engineers based between Belfast in Northern Ireland and Dublin in Ireland. And they are all fully focused on delivering world-class software and solutions for Liberty Mutual.

Mark: Yeah, so we're very much a software house, focus on high performance engineering and really delivering those world-class solutions that Gillian mentioned. So we're slightly different from the rest of the Liberty Mutual sort of area where they may have a mixture of developers and business. We're very focused on software engineering.

Jeremy: Awesome. Alright, so that makes a lot of sense. Thank you. Alright, so I want to talk to you today because you both mentioned a lot about serverless. Liberty Mutual is obviously embracing serverless. So let's talk about that. How is or how Liberty Mutual is embracing serverless? And maybe let's start just by sort of how did the team kind of discover serverless like, what was the point where you said, “Hey, let's start looking into this new technology?”

Mark: Yeah, I think that also goes back to where, in 2014, where we started our public cloud journey, I guess. So the form the public cloud came, and they started opening up the access to AWS and seeing how this whole new cloud thing would work within the big enterprise. And so a lot of that start in 2014 into 2015 was really just dipping our toes in the water and exploring cloud capabilities. Then we had very little workload in there. Coming into 2015, it was starting to get the initial learning, starting to set up the pathways to get to the cloud. Try to build in those capabilities that a big enterprise like ours needs. So real focus on security. Real focus on how do the development teams actually get access to this stuff. You know, what are good practices? And again working with AWS and partnering with them to figure out what that looks like. So our public cloud team did a really great job in starting to explore the space and open up for the enterprise this new awesome capability that’s the cloud. And then into 2015 or 2016, we were into the, you know, starting to really think about what apps we could we migrate to the cloud. What modernization can we do? What sort of approaches could we take so that we can break down our big monolithic applications and break them into things that will actually fit in the cloud. And then all the way through to 2016, we have maybe 10.5 percent of our workload’s in the cloud. 2016-17 we’re in the 12.5%. Then 2018 we’re at 20%, and now we’re up to about 30% of our workloads, plus, in the cloud, and all through that time it’s been around developing the capabilities, developing the expertise and partnering with AWS, and really learning what the cloud capabilities are there. A lot of this was traditional through EC2, RDS-type work, moving the workloads into that. And then we get into containers, we get into the whole DevOps practices, and now ultimately, we're starting to really get after serverless.

Jeremy: Okay, Awesome. Alright, so then let's talk about just your strategy for adoption, right? And we can probably go a little bit deeper into the timeline as we get further into the conversation. But let's ...

About Forrest Brazeal

Forrest Brazeal is an AWS Serverless Hero and a Senior Cloud Architect at Trek10, where he hosts the Think FaaS serverless podcast and contributes to their open source efforts. He understands the challenges faced by enterprises moving to the cloud and loves building solutions that provide maximum business value for minimal cost. Outside of his day job, he interviews the top names in cloud for his “Serverless Superheroes” series at A Cloud Guru and also creates the FaaS and Furious webcomic. He is the co-chair of ServerlessConf and regularly speaks at workshops and other events in the serverless community.

• Twitter: @forrestbrazeal
• LinkedIn: linkedin.com/in/forrestbrazeal
• Blog: forrestbrazeal.com
• Trek10 Blog: trek10.com/blog
• Think FaaS Podcast: Think FaaS with Trek10 Podcast
• ServerlessConf in NYC: nyc2019.serverlessconf.io

Transcript

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

Forrest: Hey, Jeremy. Thanks for having me. It's great to be on the show.

Jeremy: So you are an AWS Serverless Hero as well as a Senior Cloud Architect at Trek10. And I think many people in the serverless community, as well as the underground technology rap scene, know who you are. But why don't you explain to listeners a little bit about your background and what Trek10 does?

Forrest: Sure thing. Well, and I think the underground tech rap community is basically just me. So that's a small pond there, but yeah, so my name is Forrest Brazil. I'm a Senior Cloud Architect at Trek10. Trek10 is an AWS advanced consulting partner. That means we work with AWS Technologies. We focus primarily on the cloud native side of things. So think serverless, IoT, basically anything you can build while using the best practices that AWS wants you to use. I spend a lot of time helping clients put things like that together. I also spend a fair amount of time being community-facing. I love to educate and advocate for serverless technologies wherever I can. That's why I do the serverless hero thing. And it's great to be here with you now.

Jeremy: Awesome. And I think I could probably talk to you about — I think I have talked to you about pretty much everything that serverless has. But I think what I want to do today is focused more on the sort of CI/CD process for enterprises. And maybe I know you've done a lot of stuff in that space, you and Jared Short have, and maybe you can start by telling us, sort of what's the difference between sort of your typical CI/CD process and one that involves serverless now?

Forrest: Sure, Ultimately, there's not necessarily that much difference. I mean, the underlying goal is the same. I've got code. I want to get it off my laptop. I want to get it into production and serving my users as safely and quickly and efficiently as I can. And that goal doesn't change because you're suddenly using different infrastructure, or less infrastructure hopefully, but I think where it gets a little bit interesting for serverless is you all of a sudden start having the cloud become part of your software development lifecycle a whole lot earlier than you may have been used to it in the past. So you don't write this code locally, and then you throw it over the wall and it gets deployed on some infrastructure that you're not thinking about. So much of your development process now actually is tied up in that configuration and figuring out permissions, thinking about latency at the cloud level, right? You're simply not getting a very realistic picture of what your application's going to look like if you're trying to mock all that and develop it locally. So we see people trying to figure out how can I get this app into the cloud tested earlier on in my lifecycle? How can I do that collaboratively? Or how can I do that without stepping on other members of my team who may be working on different features, perhaps in a shared account? That's where we try to put some best practices together that make things easier for serverless developers.

Jeremy: Right. Great. Okay. So why don't we start talking about it specifically with enterprises then. So you've worked with a lot of enterprises. I've worked with a lot of enterprises. We know that there are certainly challenges facing enterprises when moving, just to the cloud, let alone you know, just moving to serverless. But just from a CI/CD perspective, what are some of these challenges that enterprises face?

Forrest: I think any time you're in a large organization where you're contending with multiple teams, teams that have different priorities, different technology stacks that they're comfortable with, the biggest challenge you face is just that. Despite the temptation, there's really not a one-size-fits-all solution that you can impose. So we see a lot of these central cloud teams now, and a lot of times they have a cute name, like the Cumulonimbus team or something like that. You can always spot them a mile away. You see these teams come in and they say, “Well, we gotta solve the CI/CD problem.” They've been given that problem to solve and understandably, it's a problem. Right? Code is not getting into production fast enough or it is, and there's all this shadow IT happening, right? So people want to find a way to get around that. They give this task to a central IT team. They come up with some great solution that involves CodePipeline or something like that, and they put it in production, and they say, “Hey, everyone, come use this.” And they're rather shocked to discover when no one uses it. And the reason for that is, as I said, is that you've got teams that all want to do things their own way and they view the centrally imposed CI/CD standards is being just another thing that are stopping them from getting code to production quickly, which, of course, is exactly the opposite of what CI/CD is supposed to do. And so what you have happened then is the shadow IT problem just gets worse and your development teams continue to work around your central team, and you, frankly, wind up with a worse problem than he had in the first place. So when you're working with an enterprise then, the CI/CD challenge is how do you put something together that solves the centralization problems you have, the governance problems where you really do need some amount of rigor around who can deploy to production, when it can happen and what those deployments look like. And then you marry that to the also very real necessity for dev teams to be able to accomplish their work the way they want to. So that's the problem that we try to solve.

Jeremy: Yeah, and I think you get this other problem where nobody knows who owns the process, right, especially if you have certain teams working on different components, you know that throw-it-over-the-wall sort of DevOps mentality in a fast-paced serverless environment, anyways doesn't really work anymore, right?

Forrest: That's exactly right. An...

About Efi Merdler-Kravitz

Efi is a software expert and currently the R&D director at Lumigo. Over the last 12 years, he has been working as a developer, team leader, group manager and director in the healthcare, mobile, security and agriculture industries. Recently, Efi has been working on developing serverless applications and building tools to make serverless easier.

• Twitter: @tserverless
• Lumigo: https://lumigo.io/
• Email: [email protected]
• Lumigo Twitter: @lumigo

Transcript

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

Efi: Hey Jeremy. Thanks for having me.

Jeremy: So you are the R&D director at Lumigo. So why don't you tell the listeners a little bit about yourself and background and then what Lumigo is up to?

Efi: So as you said, I'm leading the R&D of Lumigo and I've been working on pure serverless applications for the last 2.5-3 years. And on a personal note, I think it's the best technology decision that I ever made. So a couple of words about Lumigo. Lumigo is a SaaS platform for serverless monitoring and troubleshooting. Basically, Lumigo connects to your AWS accounts and alerts when things go wrong and then tells you the entire story of the requests that lead to that issue so you can quickly get the root cause. Let me elaborate a little bit. When you break your application to small pieces following the microservice architecture, it becomes very hard to debug your application, by the way, both in production and in your local dev environment, and it becomes especially hard when using async components like SNS, SQS, Kinesis, etc. And as someone who worked with serverless extensively before, we understood the challenge here at Lumigo, and therefore we developed the platform to help developers like us to understand the environment quickly when something goes wrong.

Jeremy: Awesome. Alright, so we've had a couple of shows so far where we've talked about observability, and we've kind of gotten into all of that sort of stuff that Lumigo, I think, as a product does, which is really interesting. But I actually want to talk to you about this idea of managing a serverless engineering team because one thing that's kind of unique, I think about Lumigo is even other companies that are working on serverless products, they're not entirely serverless themselves. And Lumigo is. You pretty much manage an entire serverless engineering team, right?

Efi: Yeah, we are 100% serverless from deployment, packaging, monitoring. Everything is serverless. We don't use any physical or virtual servers in our back.

Jeremy: Awesome. That's so cool. So alright. So you’re a manager. You've been doing this for a very long time. You've been managing engineering teams. And so I really want to get into this idea of what’s sort of different about managing a serverless engineering team versus managing a traditional engineering team. And I know maybe some people are thinking, “Well, you know what's the difference?” But I think there is. And I think you think there are some differences. So maybe we start first by what we have to do to sort of move our team to serverless. So if we've got, for an established organization, you know, it is great to be a greenfield startup and be exploring new things. But most companies are not. Most companies are established companies with legacy systems and so forth. So how do we go from you know this idea of taking a team that's used to working with all these different services and EC2 and containers or whatever, and moving them to something that's a lot more serverless. So maybe we start with that. What's the first step to getting people to move teams to serverless?

Efi: Great question, Jeremy. So I think that the best advice to any new beginning, especially in the technology world, is to start small. Try to taste the technology before jumping headfirst. So what does it mean in our case? First of all, I think you should ignore buzzwords. You hear a lot about new cool services. For example, AWS have dozens of ways to save data, where you have the ability to run machine learning on it. Try to use simple, trusted, and well-documented services I think services like API Gateway, DynamoDB, S3, Lambda, of course. These are the services that are the building blocks of any serverless application in AWS, and there's a good chance that you use at least one of them in the final solution. Try to use the simple version of services. What do I mean by simple? For example, in AWS, you have six or seven services that provide queuing capabilities. There's a good chance that choosing SQS, at least in the beginning, when you start is good enough. Avoid more complicated services like Kinesis. And you know, in the end, what they say, no one was ever fired for choosing SQS. So I think it's a good choice. And read and learn. Many people think that serverless identical to previous technologies that they use. And sometimes they forget that serverless is not only a new technology but also a different way to approach development. There are many great blog posts, newsletters, and, of course, for specific AWS services, read the AWS documentation. They are a great source of information. Choose a good framework that will help you with the transition. There are many good ones like AWS SAM, the serverless framework, Chalice or Zappa if you work for Python, and don't forget other practices that you used in the past. If you used .Node and Express the past, then AWS released, I think a couple of years ago, a framework called AWS Serverless Express. It's a framework that was released by AWS to help you in the transition. So if you are familiar with Node and Express, it will help you in moving to the serverless world. For example, in the Python world, if you use Django or Flask, then you can use Zappa, which I think is a great choice for the transition. So you don't need to change your methodologies, at least in the beginning because eventually I think, that these frameworks, for example, the framework AWS provides, and the framework that Zappa provides in the end, don't provide the code that should be running in the serverless environment. But at least in the beginning, they remove a lot of overhead from your head.

Jeremy: Right? And so what about the transition? I mean, do you just transition the whole team right away? Or do you pick like a point person to do something like that?

Efi: I think that especially serverless, which is something that is just very new, I think you should lead the way as a manager. As I said before, serverless is not only technology. It also shapes the way you develop software. Therefore, you as the leader has the service responsibility of how your software team works and delivers. You need to master the tools of the trade. So before giving it to anyone in your team, make sure you sit down and learn it on your own. Again, as I said earlier, read the blogs, do the tutorials, read as much information as possible before moving the entire team or transitioning the entire team.

Jeremy: I think also, it's one of those benefits of being an engineering manager where you get to try out some of that cool stuff first, before you let anybody else use it.

Efi: Exactly, exactly. You know, most of the time you do the boring stuff, and now you have a chance to start something new....