Episode #76: Building Well-Architected Serverless using CDK Patterns with Matt Coulter

About Matt Coulter

Matt Coulter is a Technical Architect at Liberty IT and AWS Community Builder. Matt has a proven history of delivering scalable, serverless solutions on the public cloud, and has crafted CDK Patterns, an open source collection of AWS Serverless architecture patterns built with CDK for developers to use. In addition to his work on CDK Patterns, he shares his passion and knowledge on serverless through events like AWS Community Day Dublin and blog posts on Dev.to.

Website: www.mattcoulter.com
Twitter: twitter.com/NIDeveloper
CDK Day: www.cdkday.com
CDK Patterns: www.cdkpatterns.com

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

Transcript

Jeremy: Hi, everyone. I’m Jeremy Daly and this is Serverless Chats. Today I’m joined by Matt Coulter. Hey, Matt, thanks for joining me.

Matt: Hey, Jeremy, thanks for having me on today. I’m looking forward to this discussion so much.

Jeremy: Awesome. So you are a technical architect at Liberty IT so why don’t you tell the listeners a little bit about your background and what you do at Liberty IT.

Matt: Sure. So I’m in this account enabling architect role now at Liberty IT. What that really means is Liberty is global, it’s huge, so Liberty IT in Belfast and Dublin has about two hundred engineers in my section, but globally there’s over a thousand engineers. And if you Google Liberty Mutual serverless you can see that we have a mission, we have a mandate, we want to be a serverless first company rapidly delivering value in a well-architected way. So my job is to create the environment where our engineers can do that at a global scale, so not just one thing, but do it in a way where we don’t leave everybody behind and everybody feels bought-in and a part of doing that job.

Jeremy: Right. And if anybody has been paying attention on Twitter or is anywhere near I would say the CDK space they’ve probably come across CDKpatterns.com which is a site that you put together and I want to talk about that because that is super-interesting just in and of itself. But there’s also ... part of the reason you built this, and we’ll get into this, but is because the CDK is so powerful. And I’m going to do a little mea culpa here. At the beginning of 2020, I was looking at the CDK as, like, “I don’t know. I like DSLs better than this idea of imperative code for infrastructures code.” I think I have completely changed my mind on this just because of how powerful CDK is, especially encapsulating functionality for teams. So, I want to talk about the CDK first then we’ll get into CDK patterns. So, let’s start there; let’s start with the CDK and in case people are not familiar with what CDK is, can you explain that and give us some of the vocabulary that new listeners might need to know in order for us to have this conversation so they can follow along.

Matt: Absolutely. So, the first thing is, and I learned this just for CDK Day, CDK itself, which stands for the Cloud Development Kit, is actually not a family of products. So, if you just say “CDK” you’re actually referring to AWS CDK which is the original, the main kit, that is used to deploy resources on the AWS using Python, Java, TypeScript, pretty much they’re working on a lot of languages but there’s also CDK for Terraform which has come up through the community and it’s an officially supported product, CDK for Kubernetes, and I saw CDK for Azure. So, what brings those things together as umbrella products is is a thing called Construct, and Construct is an open source product and that is the magic behind the CDK. That is the thing that allows you to write code in your normal language and it gets converted into DSL that was the original thing that was used in the first place.

So, we’re probably going to spend this conversation talking about AWS CDK and what it does is it converts all of your code into cloud formation and that’s the brilliance of CDK. And pairing developers with the languages they know but at the end of the day you can still apply your rigor and compliance and cloud formation knowledge to the full set-up. And just one more term that might come up later, whenever we talk about Construct, we talk about L1, L2, and L3 constructs. So it’s simple-ish to remember: L1 means cloud formation, everything is L1 starts with c and fn. L2 means AWS built it, so that’s their very light opinion on how to make things easier. And then L3 is stuff that we built, that is typically an aggregation of multiple L2s. I think that’s pretty much the vocabulary you need to understand this discussion anyway.

Jeremy: All right, well, that’s good. It’s a good place for us to start. And I think this is why things have changed my mind because of that L3 category there, right, and the L3 constructs, and it’s because what has happened is rather than you just defining your infrastructure using code, whatever, TypeScript or Java or whatever, rather than you just defining it that way, constructs are multiple pieces of infrastructure that can be wrapped up together especially when you start building these level 3 ones and that allows you to wrap up all your compliance, all of your observability, and all of your metrics, all of your alarms, everything wrapped into one. And so you can do similar things with serverless or with … even with SAM, so why did you choose to do the CDK at Liberty Mutual if it’s kind of possible to do some of these other things, I know you have to copy and paste a lot, but why is the CDK so much more powerful? Why did you choose that at Liberty?

Matt: Yeah, so, I’ll tell you a story. So, a while ago, a few years ago, I had this awesome team. And we were known as a team that built a suite of microservices to support the insurance app, so multi-billion dollar apps were reliant on our services. And that meant we were specialists in Spring Boot and as well as Python for deploying machine learning models and Docker. And so there were five of us on the team, I think, and we were supporting and maintaining roughly thirty microservices. Now this was a high-performing team but I spent way too much of my time talking to our business partners saying we need to do ops. It was a case of, “Okay we need to upgrade this service from Spring Boot 1.x to a higher version or … you know, I was talking to our senior architect at the time who challenged me on a project we called “Deploy with Confidence” and he had said, “I want you to tell me if the system breaks before a customer calls you.” So, it was that point in time I had this brilliant idea of, “You know what, guys? Let’s go serverless.”

And I remember calling the team into the room and I said, “It won’t be that bad; just put in a couple lines of code in the Lambda function and we’re good. We can get rid of all the Spring Boot, we can get rid of all the frameworks, it’ll be easy.” It was not easy. It was challenging to say the least. Because our first piece of code that we put out there was an API gateway and one Lambda function and nothing else. And that Lambda function just made a call to a third-party API. That took us months to get working and that was because whenever you’re deploying code into our cloud in particular, it’s very locked-down. We have these tools in place that if you try and deploy cloud formation that isn’t up to our standards, it just gets deleted, it’s just gone. On top of that you need to know what various AWS components you’re a...