How to build a serverless-first developer experience
Matt Coulter:
Hello, everybody, and welcome to a special conversation we’re going to have today, specifically focused on serverless-first developer experience. The format of this is going to be an informal conversation between me and three amazing panel members who all are people that I respect so much. So, what I’m going to do before we jump into the panel is, I’m actually going to work my way through the panel, and introduce everybody and hype them up a bit so that we all know who everybody is and exactly why they’re here. So, first up, I’m going to introduce you to Jeremy Daly, who is somebody who has been working in the serverless industry for as long as I’ve been in it anyway. He’s currently the GM of Serverless Cloud, as well as somebody who runs the leading newsletter that comes out every week, Off-By-None, and the serverless chat podcast that I myself have been on. So I’m very excited to have you here, Jeremy. And yeah, hopefully you can introduce yourself.
Jeremy Daly:
Yeah. Well, like you said, I’m Jeremy Daly. I’ve been building web and mobile applications for a very long time, since the late ’90s. And then when cloud came along, I started getting into cloud and then as soon as Lambda came out several years ago now, six years ago, I started getting into that and just fell in love with building applications that way, and just thinking about applications differently. So ever since then, I’ve been all-in on serverless. I just love the topic, super excited about it. Huge fan of yours, Matt. So, thank you so much for inviting me and of course, Rajesh and Marcia as well, so I’m really looking forward to being here. Thanks for the invite.
Matt Coulter:
Awesome. Thank you. And then, moving on to our next panelist, then we have Marcia Villalba who, hopefully everybody knows, because she runs one of the best YouTube channels that is out there, FooBar. It is a channel completely dedicated to building serverless solutions on AWS, but in a really accessible way. So I’m pretty sure that every single component that is on AWS is in that channel in some way, shape, or form. And the awesome thing is, as well, she creates original content in English and Spanish. So yeah, thank you for being here and do you want to give a quick introduction?
Marcia Villalba:
Yes. Thank you for inviting me. I’m a developer advocate for AWS. So I’ve been now a couple of years with AWS and before that, I was also a Serverless Hero. So I’ve been doing serverless, I think since it’s early beginning. I got introduced to Lambda before it had API gateway support and I was like, why somebody wants to use this thing? I didn’t understand because I’m a fully developer person, I don’t do any operations. So I learned them with serverless afterwards. So that’s kind of my first encounter with Lambda. But since I moved to Lambda, I never went back. I think I only deploy EC2 instances for showing you in the tutorial.
Matt Coulter:
Yeah, that is awesome. I mean, my first experience with Lambda was definitely whenever API gateway was there. So I can’t even picture what the use case was back then, but that’s fascinating.
Jeremy Daly:
Processing-
Jeremy Daly:
Processing images from S3. That was the primary use case back then.
Matt Coulter:
There we go.
Marcia Villalba:
Turning off EC2 instances.
Matt Coulter:
Well, that is awesome. Thank you for being here today.
Marcia Villalba:
Thank you for inviting me. It’s always fun to chat with you.
Matt Coulter:
Okay. I will move on to our third panelist who’s someone who works with me very closely. So it’s Rajesh Kannan Poraiyan, who is a senior architect here in Liberty Mutual. But he has specifically been focused on developer enablement department, and creating this platform to allow us all to come together and share working serverless patterns to deliver business value. So I’m so excited to see what he can bring to this discussion today. Rajesh, do you want to give an introduction?
Rajesh Kannan :
Definitely. Like you said, I am an enterprise architect in Liberty Mutual. Have been coding since 1990 and I am very much focused on the developer enablement. And my goal is to transform Liberty Mutual into a digital native organization, empower the community to build cloud native solutions, serverless solutions and so on. I’m very happy to be here.
Matt Coulter:
Awesome. And we’re very happy to have you. So, before we get into the interesting topics that I want to go through, given we have this exciting group, I’ll just give a quick introduction of me. So, I’m Matt Coulter. I’m an enabling architect here in Liberty IT or wider, Liberty Mutual. And basically my role has been, over the past couple of years, I’ve been working with technology, AWS CDK, and building serverless architectures open source in CDKpatterns.com in a way that we can teach AWS well-architected learnings. So that, in pretty much one command, developers can go from nothing to understanding a well-architected principle, and then trying to translate that into Rajesh’s accelerator. So that’s me. But I want to kick this off with a really interesting question, because this is one that a lot of people, I think, get wrong. So I’m going to hold my opinion until everybody else speaks, and whoever jumps first can have this one. But how would you describe the serverless-first mindset?
Rajesh Kannan :
To me, serverless is a spectrum, right. You have the far-right, all managed services, find everything that you want, right. You have container management, function management, computer networks, and storage, right. On your far-left, you have to do everything. You have to do all the heavy lifting of installing, patching, upgrading and so on, right. So let’s say I’m a startup and all I have is a dollar. And I just want to focus on delivering business value, maximize the value that I can deliver. So do I focus on building infrastructure? Or do I focus on delivering my business value?
Rajesh Kannan :
So that’s where the serverless-first mindset comes to me. I just want to focus on iterating on my core competency of delivering business value, offload all the undifferentiated heavy lifting to the cloud provider. And so that, to me, is a big enablement. And the other thing is the ability to product price for the value that I deliver. Because with serverless, I can basically get full transparency on how I’m doing from cost scalability and security and so on, right. So being able to put a price product value that I deliver and continue to laser focus on my business value, to me is a critical, serverless-first mindset enablement.
Marcia Villalba:
Yeah, definitely. And I will say that empowering developers is a very important part of the serverless-first mindset, because if we come from this traditional way, that developers, that I was, develop my career in that way that you are doing everything in a little box, and then you ship it somewhere and you don’t know anything else. And that’s not very empowering because something break and you need to involve 20 people in fixing that. Now with the serverless technologies, we empower developers to do their infrastructure, deploy to the cloud, monitoring, knowing how much it costs. And in order to do that in big organizations, you need to have a framework around it. You cannot just put your developers into the wild. Now you have an admin right in, they don’t just consult. You can do whatever you want.
Marcia Villalba:
That’s not empowering. That’s like giving a toddler a knife and let him running around. That’s not what you want to do. So you need to train them, you need to give frameworks, you need to give frameworks like the well-architected serverless lens. And that’s something a lot of organizations are building around when they think about serverless-first, it’s not just, you can only run a Lambda functions that’s our serverless-first mentality. No, it’s about giving a system that gives the best practices and enablement for developers to make, like Rajesh was saying, providing value the fastest way possible to the customers.
Jeremy Daly:
Right. And I would say too, it’s serverless-first, not serverless-only, right. And so if you think about the serverless-first mentality, if you think you can build everything with serverless, a lot of people think they can, that’s not necessarily true. You are going to run into certain limitations here and there and that’s just to be expected. So building anything in the cloud or locally or anything, I mean, building applications is all about trade-offs, right. You sort of have to decide where you can use the tools that exist and where you have to kind of drop down to a lower level. And if you think about that, to me, serverless-first is more about setting expectations that you want to start with the most managed, as Rajesh said, everything way over there on the right-hand side, everything that is as managed as possible.
Jeremy Daly:
But then, if you have to sort of take that step down, and if you think about crossing the chasm, right. If you’re building things with serverless, you get to this point where you’re like, oh, I can do this and I can do this and there’s this peak of, what’s it called? The peak of expectations or something like that. And then you quickly hit that trough of disillusionment, right. As soon as you put something in production. And so understanding that you’re going to have that issue there, that you’re going to have limitations that you have to work around. That’s the idea, is just build as much as you can that’s managed and then drop down, make those choices and those trade-offs when you have to.
Marcia Villalba:
Yeah. And I think it’s also showing, for example, one organization I was chatting with, a Spanish organization called CEPSA. They allow developers to create as many Lambda functions as they need. They have a system, they can do that. But when it comes to create instances, they need to do ticketing and ask for permission and give a reason why they need to do the instances. It’s not that they forbid them to do the instances and to create new instances, that it makes it a little bit harder, and they need to put a little bit more thought and give a reason why they need that. So that’s another way maybe of adding a little bit of effort to go to the comfort way that developers might be used to in the past.
Jeremy Daly:
Right. And there’s one other point that I want to make too. There was a, I don’t know, a meme or a graphic awhile back that was like, it was a flow chart, can I build this with serverless? Yes, use serverless. And then no, it was like, rethink your architecture and then build with serverless. I mean, that’s one of the things too, is I think what Marcia said about that organization, putting that block in place that says, if you really need to drop down, that’s fine. But you’ve got to give us a really good reason. Because I think that’s one of the things where people fall into this trap of they’re like, well, this is how we used to do it, and if I can’t think of a way to immediately do it with serverless, then I’m going to drop down and just use this lower level. But you do have to go back and rethink. So it’s probably serverless-first, serverless-second, serverless-third, and then drop down to that lower level.
Rajesh Kannan :
Yeah, exactly. We have a flow chart where we say, hey, decompose your problem. And then if you keep decomposing, you learn to refine that thing that you can build and deploy independently that can react to something. So decomposition, using domain driven design and so on is very important in this journey.
Matt Coulter:
Yeah, so you all are definitely experts in this area. And you didn’t say what a lot of people say. Usually, whenever I bring this up, people say serverless, yep. That’s AWS Lambda. But the thing that I always like to stress now when we talk about service architectures, we’re actually moving to, we don’t really have a term for it yet, functionless or Lambdaless architectures that are direct service integration. So you can have API gateway directly integrating with EventBridge, which hosts an event that gets picked up by a step function that does some processing that inserts into DynamoDB and you manage none of that code liability. So for me, the serverless-first mindset is about picking managed services that will improve over time without you having to do anything. So what is the least amount of the lines of code I can write to solve this business problem? But it’s also, I like to tell-
PART 1 OF 4 ENDS [00:13:04]
PART 1 OF 4 ENDS [00:13:04]
Matt Coulter:
It’s a business problem, but it’s also … I like to tell people, it’s the hardest way to build something because you have to put so much effort into thinking what the right thing is to do. So, it’s all thinking about the architecture, the upfront design. And once you do that, it’s amazing when it all clicks, but it’s not like back in the day, whenever you could just have something that ran on a server and you could start typing lines of code and significantly refactor it later if it was the wrong thing, because you’ll hit the issues from day one if it was the wrong idea.
Marcia Villalba:
Yeah. I think as developers, we like to jump into the code as fast as possible. And I think that’s a pattern we need to break and we need to think, and think, and think, and then go, and … if we need code. If not, don’t put any code. The least amount of code is the happier the whole system will be.
Matt Coulter:
Yes. Right. So something as well, the next, probably the most controversial item in all of serverless that I want to talk about is how does serverless-first fit into a multi-cloud strategy? Because a lot of people tend to think serverless means multi-cloud is a no, but there’s also opinions out there, like Corey Quinn has an amazing article out there on serverless and multi-cloud. So before me giving an opinion, does anybody want to jump in and take this one?
Jeremy Daly:
I can start. So I think the problem is that there’s multiple definitions of what we mean by multi-cloud. And by multi-cloud, if you mean cloud agnostic, meaning that you can run an application in AWS and then just port it over into Microsoft Azure, and then bring it over to GCP, I think you’re setting yourself up for failure because there is this idea, and I think Forrest Brazeal put this out there quite a bit, is this idea of sort of dropping to the least common denominator of services. And you end up using low-level services and you don’t get the benefits of using something like DynamoDB. Well, DynamoDB is great, but there’s also CosmosDB in Azure … Azure? I don’t know. However you say that … that is also really, really great. Now, they’re different, right. But if you’re going to build something in AWS and you want to use NoSQL, use Dynamo. If you want to build something in a Microsoft Azure, then use Cosmos because that is going to give you the best capabilities as opposed to maybe spinning up a Cassandra Cluster or something like that.
Jeremy Daly:
So I think that as long as you think about it that way, in terms of multi-cloud is more about using different services from different clouds, using the best breed of services, or best of breed, then you’re in a much better situation than you are if you’re trying to drop down to those lower levels. So I think if you take a serverless-first approach, what you’re saying is, as you said, Matt, you’re looking for managed services that are doing all of that heavy lifting for you. So if BigQuery in GCP is a better service than Athena in AWS, or it’s better than using something else in another cloud, then use BigQuery. ship your data, right. And yeah, there’s going to be fees and you’re going to pay for that. But what is the value that you’re getting out of that? What’s that total cost of ownership to be able to provide you with the service that you actually need and be able to solve your business problem? You have to look at those and decide whether you’re going to do that.
Jeremy Daly:
And then just from a broader perspective, I mean, if you think about the API economy at this point, I mean, between Salesforce and Twilio and Stripe, and every … FaunaDB, and now Astra, and all these other services that are all powered by APIs, some of them run in AWS, some of them run in GCP, some of them run other places. I mean, I consider that to be multi-cloud. If I’m going to access data from Stripe or I’m using Stripe to process credit cards, that’s a different service on a different cloud, for all intents and purposes, and so that’s multi-cloud to me. So if you’re building serverless-first in a multi-cloud environment, I say pick the services that work for you. Pick the ones that fit your use case and your business case and require you to basically write the least amount of code to integrate with them. But yeah, that to me is something where as long as you don’t think about it as being cloud agnostic and trying to run your workloads in multiple places, then I think multi-cloud is a really good strategy and something that most people are going to have to adopt. Otherwise they’re going to fall behind their competitors.
Rajesh Kannan :
Yeah, exactly. Well said, Jeremy, because I was in the same boat, right. To me, managed service from anybody, right. If it’s not my core competency, but something like a commodity that I can rent, I don’t care where it comes from. And as long as I focus on my core business logic and data goes with it. And then the other thing is, it’s very difficult for the community to be good at everything in the world. So we have to be really good at one thing. So that means going with a primary cloud file, you recall business logic and data, it’s essential to be successful. So completely agree with you. Like, we use Office 365. It’s kind of like a sub-cloud. We use CRM from Salesforce cloud. I don’t want to be building those things. I want to go and make use of them. So to me, multi-cloud is there already, whether we like it or not.
Marcia Villalba:
And also, I like the idea of focusing on one cloud provider, because you get the volume discounts if you’re a big enterprise. You will get really nice discounts that if you spread all your workloads around different clouds, you dilute that. And that’s kind of a big saving that you can get from a serverless architecture as well.
Matt Coulter:
Yeah. And it’s something that just cuts across because if you have your … say you have thousands of engineers in your organization and do you have a big strategic goal that you want to move to a cloud, or all the clouds, or whatever number of clouds. If you say, I want us to build something that will run on all of the clouds it wants and be completely agnostic, you’re going to have to train all of those people on how to do that. Whereas if you turn around and you, say, you pick a cloud as your primary cloud … Since AWS is the one we’re primarily talking about here, if you say, “For the core use cases, we’re going to go to AWS and for differentiating capabilities, we will use other managed surfaces,” which could be Azure, it could be something like Fauna that’s just a service that’s running out there, it means that you can take advantage of things like the AWS well-architected framework, the open source training. Everything that’s out there in the industry, you can just use it instead of having to tailor every single piece of training and messaging towards your internal implementation.
Jeremy Daly:
Right. Yeah. And I would say too, I mean, I think you’re dead-on with this idea of picking a primary cloud. And I think Marcia is right, too. Like, if you’re doing most of your work in a particular cloud. But it’s funny though, because you also mentioned this point, and I think this is what Corey Quinn had said in his article about this, was it’s less about switching clouds or whatever. It’s more about the people that work for you that are doing the development that you would need to somehow switch over. And I remember I was working for a startup a couple of years ago and the CEO asked me, he said, “Hey, we have an offer to get a $100,000 in startup credits from Google Cloud. So what would it take for us to transfer our services from AWS to Google Cloud?”
Jeremy Daly:
I said, “I have no idea because if you do, I won’t be there. Because I’m not learning Google Cloud. Like, I’m an AWS guy and that’s just what it is.” And I think that’s part of it as well, is that … and this whole idea of, if you will try to do this multi-cloud cloud agnostic thing, then you need specialists in every single cloud. And you need someone who knows multi-cloud GCP, someone who knows Azure, somebody who knows AWS. And it’s much easier to just use the primary cloud provider, as you said. But integrating with some of these other managed services, you just need to learn one managed services or two managed services or whatever it is in another cloud, that you don’t have to learn the entire ecosystem. So it’s still effort that you still have to go through, but the benefit of that is just something you have to weigh as an organization.
Marcia Villalba:
Yeah. And one thing that I think it’s important to address with serverless is that you save so much time by embracing all the managed services that you are kind of saving, in the bank, time, instead of implementing that super agnostic … And this doesn’t apply to multi-cloud, it also applies inside the cloud. So you are kind of locked with Dynamo. If you want to move out to another NoSQL database inside AWS, you will need to do the migration. But Dynamo saves you so much time when starting out, that then if you want to change because you that you have risk or you have a reasons very critical to move, then you can grab that time you put in the bank, take it out, and implement that migration. And it doesn’t make sense to over-engineer it from the beginning, because in most cases, you are not migrating services or migrating clouds or the big cloud providers are shutting down.
Jeremy Daly:
Right. And I would say, too, just one other thing about your point, Marcia, which is great, the idea of saving time and banking that time. The idea of something like Kubernetes or this sort of cloud agnostic thing is the same promise that ORMs made, right. Like, “Oh, you can just switch your backend database. No problem. I have never come across an ORM that allows you to switch your database. There’s too many nuances with the implementation that you have to follow certain things. And that’s the same thing with Kubernetes. I’m not saying anything’s wrong with Kubernetes. I think it’s a great choice for the right organizations. But this idea of thinking that, “Oh, I can just take my workloads and then just port them over somewhere else …”
Jeremy Daly:
It’s like, same thing with containers. Even if you’re running in containers, you can’t just take a container on AWS that integrates with Dynamo and integrates with IAM and integrates with all these other things and just drop it into GCP. That’s not going to work. So the amount of time you save not having to think about some of that stuff initially, if you actually get stuck or have to port things over, you’ve got a lot of time in the bank that you can use to do that and I don’t think that’s as heavy of a lift to port some of these things over as some people sort of make them out to be.
Rajesh Kannan :
Yeah, definitely. Like, serverless versus containers is a very hard conversation. And everywhere you go, like, hey, why do I need to go serverless when I can do containers and be able to port between clouds and so on? You know, we were there. We built containers. We did a lot of heavy lifting. Yesterday it was like, darkest warm. Today it’s Kubernetes. Tomorrow something else. Like, why do I chase this thing over and over? I just want to focus on my business logic and let the cloud provider come up with the best-in-class technology to manage the containers under the hood. Containers are there everywhere, but what do I care about … Let the cloud provider care about it, you know?
Matt Coulter:
Yeah. I love the fact that it always comes up as serverless versus containers, but I’m sure Marcia will have a really strong opinion on this one because I know there’s a lot of container offerings in the serverless spectrum that you can now deploy containers on AWS.
Marcia Villalba:
Yeah. I think it comes up to what is the definition of serverless. That is a very … depending who you ask. And then you can say that running containers, in some ways, it can be serverless or not. So for AWS, it has like … It needs to adhere to four kind of propositions. The first one is scales automatically. Automatically is not the official word for AWS. It’s my word. Pay for what you use. High availability built-in. Basically, you don’t need to find an availability zone. It built the original service. And you don’t have to manage infrastructure. And if you think of that, Fargate is a serverless service. Even if you are deploying containers, the containers are not yours. You cannot see them. You just put your code in there and AWS will take care of everything.
Marcia Villalba:
And in that way, we have this offering and I imagine more things will come in mixing these two spaces. Because at the end of the day, it’s to serve the developers with what they need to run their workloads. What we were saying at the beginning, what Jeremy was saying, is serverless first. And some days, serverless doesn’t fit all the use cases. And containers is something for use, so let’s try to make it as simple as possible for the operations and developers that are building container applications.
Jeremy Daly:
Right. And containers are a wonderful technology that you absolutely should use if you need to. I mean, they’re a great packaging format. I mean, this idea of being able to take dependencies and just package them right in your code and then be able to react to them, it’s just … And again, Fargate and Lambda are moving closer and closer to one another. As soon as you can trigger-
PART 2 OF 4 ENDS [00:26:04]
Jeremy Daly:
… are moving closer and closer to one another. As soon as you can trigger a Fargate container with an event, then things will be pretty exciting, but yeah, I think you do what you need to do, and again, the definition of serverless, it now means anything really at this point, but if you embrace containers and that’s the way you want to do your packaging, that’s absolutely fine. The question is where you deploy those containers to and Fargate is a really good solution for that.
Marcia Villalba:
Yeah. And I think when it comes to packaging, I think that’s the latest launch from Lambda, that now you can package your container image, your Lambda functions as container images. Before, we were using SIPs and now you can use containers, and that opens the door for a lot of organizations that have pipelines for building these container images to start adopting Lambda. So it’s always trying to help as many customers as possible.
Matt Coulter:
Yeah, and whenever the container image support for Lambda was launched, just to give an example of how easy it is for customers to adopt it. I think it was announced at Reinvent. I can’t remember what day of the week it was. I’ll say it was a Tuesday. By the Friday, we had it available in Liberty Mutual in our software accelerator as a pattern anyone could use because we already knew how to build a container. We already knew how to fit it places. So it opened up all these possibilities of machine learning online.
Marcia Villalba:
Exactly. That’s something you could not do before. They make the Lambdas fatter, and now you can put a container inside so you can put a machine learning model into it.
Jeremy Daly:
Right. And with EFS integration too, you have access to massive amounts of storage, and then the other thing too, you were mentioning earlier this idea of functionless, which I think is an important thing when it comes to really well-defined patterns and routing data and eventing and things like that, that make sense, but when it comes to things like machine learning or certain types of business logic, you’re still going to need to write code and have executions that are happening behind the scenes, and that’s one of the great things about machine learning and putting machine learning into something like a Lambda function, is that even if there’s a cold start.
Jeremy Daly:
Even if it takes 60 seconds to run or whatever it is in order to do, not an inference, but maybe just to do some compilation or something, it runs behind the scenes, so who cares? Unless you really have an SLA that says, I need to be able to process this in two seconds, or something like that, for that to run asynchronously, there’s a lot of power behind the scenes and you don’t have to worry about spinning up servers or spinning up extra containers or extra pods or whatever. It just is there. So I think it’s super powerful abstraction, that again, there’s arguments against certain things, but honestly, it’s hard to keep finding them because they’re very quickly going away.
Matt Coulter:
Yep. So the words that we haven’t really mentioned yet, but have been key to all of the conversations prior are the words event-driven architectures, and that’s where serverless and all of these direct integrations shine when we’re talking about, like you said, asynchronous flows. So does everybody agree that event driven is sort of the core of serverless at the minute and do we think that’s where developers struggle whenever they try to move to serverless because that’s traditionally not how we built apps? Even though we all agree it’s a good idea, it is different to what we did before?
Marcia Villalba:
Yeah, definitely. At least personally, my first experience with serverless and the asynchronous world was like my brain exploded. I could not understand how these things flow around and that was the hardest part for me on the serverless learning curve, and I think it’s one of the faults from us trainers. That’s usually when we present serverless, the first pattern we present is API Gateway and Lambda and Dynamo. That is a very synchronous pattern that… We present it because it’s a familiar pattern, but that’s not what it should be in the serverless world.
Marcia Villalba:
We want to make it asynchronous, we want to make it event-driven, and we should present something with EventBridge. Yeah, so we should embrace that more as trainers and try to deliver that and help people understanding event-driven applications with architectures because if you want to do a serverless, maybe you can disagree with me, but if you want to do scalable serverless applications, you need to nail the event driven architecture.
Rajesh Kannan :
Yeah, it definitely changed the game, in our opinion. I think of the days when we used to wait for months for an MQ cluster or a Kafka cluster before you even react to a thing. Now you upload a picture and you can instantly react to it. We can do some machine learning with it. I don’t have to think about the processor. All I think about, say I have a problem and I want to react and I want to take care of my business. Event driven architecture is kind of out of the box in the serverless world, and I agree, the most popular pattern that we have is the API gateway and Lambda, that is your patent, Jeremy. Simple web server.
Jeremy Daly:
It’s not my patent. I just named it.
Marcia Villalba:
You trademarked.
Rajesh Kannan :
We had it. Jeremy’s daily simple web service patent is the most popular patent because everybody is familiar with building rusty APIs and they want to scratch the surface and they want to be able to write a tiny Lambda function and then be able to put a gateway and then go Dynamo DV. It helps them to kind of get started.
Marcia Villalba:
Then the first problem that people face is when the Lambda doesn’t respond as fast as API Gateway to timeout, and then they realize like, oh, there is another way we can do this. We need to increase the timeout. No.
Rajesh Kannan :
Yeah, exactly, but now we are talking about well-architected, just because everybody is deploying simple work service. Now you have to worry about throttling, security usage time, API key, and so on. Now, it’s an eye-opener. Wow. I didn’t know that I could do those things before because we never took time to learn those things, but the AWS well-architected thing kind of outlines, helps you to kind of think about all that stuff. So it’s the maturity level that we are focused on playing the test. Okay. We want to be good at one thing in one cloud and we want to be able to get better at it, follow the well-architected framework, understand, and then continue to decompose the application to event-driven, and even Briggs is kind of changing the game with our enterprise, I would say.
Jeremy Daly:
Yes, absolutely. And I think the other thing too, is that if you just try to get everyone to think of everything as an event. So even an API Gateway request to a Lambda function is just an event. It’s just a synchronous event, but it’s just an event and this goes back a little bit, but when I first started building in the cloud, so it was 2009, I think, and I was working on a startup and as we started to scale, we were running into problems with basically being able to serve up data from the database and caching levels and some of these other things.
Jeremy Daly:
So what we did is we put an app layer in between the front-end web servers and the databases, and we would cache things at the app layer, but in order to make it work so that we weren’t just banging against the app servers, we put a service in called Gearman, which essentially, it was a messaging channel and so we would send messages from the front end web server to the app servers through Gearman, which were essentially asynchronous, they would process and send a message back, and they’re almost like a streaming web, almost like a… What am I thinking of? Web sockets.
Jeremy Daly:
And so it would stream that data back. So there was this event aspect to how this thing was working. This was in 2009 when we first built this and it worked really, really well, and then after I moved on from that startup, I was back at a more traditional synchronous type thing and then when Lambda came out, I was looking at it. I’m like, I feel like I kind of built this already. This was how I was thinking about these things before, and so it immediately clicked with me this idea of just sending these events around, but back to the point I think that you’re all making is, event-driven architectures, I would say serverless is synonymous with that.
Jeremy Daly:
Even the synchronous invocations of Lambda functions or of API Gateway or anything like that, if you’re not thinking about things as events, then you’re thinking about things wrong, and the more you understand asynchronous events and how that works, that is going to help you dramatically to adopt some of these different patterns and different practices. I will say it is definitely a brain bender though, to think about this idea of making a request, and then especially if you start talking about when you’re forking things or things like that, or fan out patterns, you know what I mean, doing that kind of stuff.
Jeremy Daly:
And then having them all come back, add step functions into the mix, you know what I mean, in the orchestration piece of it, do orchestration with choreography with EventBridge and you have different things flying around at different services, having a really good observability system to trace all that stuff and know what’s happening is also absolutely important or imperative that you do something like that, but yeah. I would say that for me, those two terms are almost synonymous at this point.
Matt Coulter:
Yeah. So something I was going to ask then because we all agree, event-driven, it’s another level and we’re talking about, you have to do it on the cloud because these are events that are in the cloud being published, picked up by live services that quite frankly, you cannot make AWS run locally on your machine. I mean, you can get bits of it, but it’s not the same. So we always say do it live in the cloud, and I guess while we have you here, Jeremy, giving you the GM for serverless cloud, I guess, is there anything you’re working on with that that’s going to improve the developer experience in this area?
Jeremy Daly:
That’s what we’re trying to do and one of the things that we’re doing, and I’m not going to spend too much time trying to sell this, but one of the things that we believe in, and this is something I’ve believed in for quite some time, is having high fidelity copies or high fidelity environments that replicate your production environment and your staging environment and your dev environment and things like that, and so what we’re trying to do now is make it very, very easy for individual developers or teams of developers to be able to basically take whatever their code base is with whatever services are running and with whatever multiple services they may have interconnected with EventBridge or whatever services they’re using and be able to spin those up into these ephemeral environments that they can test against.
Jeremy Daly:
So essentially, if you wanted to test what happens when I send this event into the ether, what happens to it, you could test that in a completely isolated environment that’s not going to affect production or data or tasks. You’re not sharing databases. Every single instance that, we call them instances, every instance has its own data base that backs it. It has it’s own DynamoDB table behind the scenes and you can copy data in between it and things like that. So that’s what we’re trying to do because we fully believe that you can’t test locally. You can unit test locally. I can simulate HTP or an API gateway request. I can simulate DynamoDB. I can do some of these things. I can inject an event that says, hey, this is the event that will come from this particular service, assuming that it works.
Jeremy Daly:
But the actual wiring and making sure everything works, that’s something you can only do in the cloud, and there’s no sense of testing whether or not the format of something is right, or whatever because the cloud should have that fidelity for you, but as long as you can test all of those relationships and test all of that wiring, that’s what we’re trying to do. So we’re trying to make it drop-dead simple to do that. It is a huge project. It’s very challenging to do, but again, this is only possible because of serverless infrastructure because everything that we’re spinning up is ephemeral and pay-per-use.
Jeremy Daly:
So we do not need to spin up a database cluster or an EC2 instance or any of these things that you’re paying by the minute for. These things spin up and they’re there and they cost you nothing until you start using them. So this has really empowered us to kind of get to this point now where we can do some pretty exciting things and just I think the precipice for this was EventBridge sort of made a lot of this stuff possible and everything that they’ve started to release against that, including the ability to contact other APIs and build in the circuit breaker pattern into that automatically and some of those things, we’re just at a point now where serverless can do-
PART 3 OF 4 ENDS [00:39:04]
Jeremy Daly:
so much that if we can find a way to make it super simple for developers to literally write a few lines of code, and then they have an application running with all the best practices, with all of the standards in place, all the security they need, and that fidelity of the cloud so they can test it, then, hopefully, that’ll be a hugely productive system for people.
Matt Coulter:
Yeah. It sounds really awesome. And just while we’re here, I wanted to contrast some of the different approach that AWS has actually taken recently to solve this problem. Because a lot of the accusations that I always see go against AWS, for and against, are the Two-Pizza teams operate independently so there’s a lot of different tools. But I’m actually seeing that change recently. So we had Eric Johnson go to CDK day and announce that AWS, SAM and CDK work together now. And there’s serverlessland.com, which has patterns in SAM and CDK right there all in the one place. So I guess, Marcia, has there been a shift now towards sort of like unified developer experience and building that tone to shift more towards what Jeremy’s thinking of?
Marcia Villalba:
I think it’s all about the customer and what the customer asks. I think you have heard 20 million times that AWS is a customer obsessed company. So for example, the marriage between CDK and SAM that’s to allow local testing in CDK, if you want to test your functions, for example. And that’s something that so many people were asking for CDK and it’s already in SAM, so why not to bring them together. And at the end of the day it’s to empower developers.
Marcia Villalba:
If there’s developers that like CDK, go and build your serverless applications with it, if you like SAM and you find comfortable with it, go and build your serverless applications with it. It’s not about the framework. It’s about how you build your applications. The serverless-first mentality and Serverless Land is a place where, as we talk about serverless, it’s not about SAM or CDK or Cloud Formation, it’s about everything that can bring serverless and help developers to put to use their applications in the easiest way. So it’s all about developer experience and that’s something we try to listen to customers and to bring new features and to try to help them as much as possible. Luckily, we have amazing partners like Serverless Framework that are building cool tools as well, and showing us the way in some parts, and we can collaborate building better infrastructure. So there is a whole symbiosis with the partners and so it’s endless work.
Jeremy Daly:
Yeah. And just one thing too about that is, the important thing to remember is all these tools we’re building… AWS is inventing new technologies or they’re building new technologies, and what the serverless framework does, the serverless framework traditional is just this idea of, again, it’s another way to define your resource graph and define your infrastructures that you can deploy these things easily. SAM is the same thing. CDK is the same thing. All of these things get us to the same place. And even what we’re doing with Serverless Cloud, it’s the same thing. We’re just trying to get you to deploy your application in a modern way, in a modern stack, following best practices, following all the rules that we want to do and have the best of breed services in there. So that’s all we’re trying to do is get people to the same place at the end of the day, just different approaches of how you get there.
Jeremy Daly:
Marcia is right, Customers are different and that’s why some people want to use containers and that as a packaging format. Some people want to use something like Architect or use something like SAM or use CDK or use a serverless framework or Palumi, or any of these things, Terraform. I mean, it doesn’t matter. You’re getting to the same place at the end of the day. The question is how much can you build in? How much can you remove the other heavy lifting that’s in there? Because even though you don’t have to manage the service at the end of the day, you don’t have to manage the infrastructure, right now, you have to understand the infrastructure. You still need to know what the limits are. You still need to know what the caveats are. You need to know all those little integration points. So the more you can help people wire these things together, I think that’s the better developer experience. That’s what we’re trying to do. But I think SAM and CDK, everyone does a great job getting there. It’s just depending on what level you’re at, and how you want to implement.
Marcia Villalba:
And where you come from. Because I think, for example, SAM maybe it’s great for people that are coming from the Cloud Formation world, Operation YAML, and CDK syncs very well with developers. It’s very natural if you have been building applications forever, you can start basically doing CDK two seconds after. So the idea is not to have one tool to rule them all, it’s to have different tools to provide solutions for different customers. It’s the only way.
Jeremy Daly:
At the end of the day, get as many people using serverless as possible. However we get them there.
Marcia Villalba:
Or building applications with the best practices and good quality and maintainable and testable and scalable.
Matt Coulter:
I was going to say, Rajesh, do you want to talk about how much all of this aligns with the software accelerator and what you can get from there?
Rajesh Kannan :
Yeah, definitely. Like this is where the maturity comes in, right. Hey, we are all learning. Nobody is a master of everything, right. So if I figure out something, how do I make sure the other person can do the same thing, right. How do I package that thing that I learned and make it available for the next person to get it instantly? So that’s where the accelerator comes in. So we basically want to kind of scratch the surface, enable experimentation because experimentation is key because only by experimenting, you’ll learn something. And then by iterating you kind of innovate something. Right. And when you’re proud of that thing, you want to be able to, “Hey, I have simple web service package that I’m proud of.” Right. And I want everybody to be able to repeat. Right. And I want to have the well-architected things, built in security, scalability, placing and so on.
Rajesh Kannan :
Package it up and then publish it. So the team members can basically say, Hey, I just want to answer a few questions. You know, what’s my service name. And, instantly I have it deployed and all I do is get cloned. Right. And so now I get clone and I’m working on it. And I find the new thing that I want to contribute back. So contribute back, and it becomes the next Wilson pod, the next team. So that flywheel effect is what we try to create within the enterprise. And so far, I think we have been very successful, lucky us. So the teams are building, Matt is, you know, open sourcing the CDK packets and then bringing them into our accelerator. And we are in this iterative loop right now. And like you said, CDK, SAM… And we want to continue to add value, no matter what the next thing is. You don’t want to be stagnant.
Rajesh Kannan :
And that’s where we think, as an architect for Liberty Mutual, I want to make sure I keep my eyes open across the board. Try to motivate, empower the community, and try to experiment things and share the knowledge. Package it up in such a way that it’s consumable. If it’s not consumable… Because one of the problem that we had was, when the newcomer comes on board, by the point they read through all the Wiki pages, tons and tons of them to create a simple pipeline, you’re losing weeks and weeks. So we don’t want that. We want them to be able to deliver on the first hour they are in, right. And they are really good at whatever the language is, whatever it is. And they just want focus on the business problem. And the accelerator is our platform to enable the facilitation, create something reusable, make it available, make it consumable and be able to, kind of, iterate on that inner source model. And thank you, Jeremy, for all your patents, because most of your things, what your work is, all available within the perimeters.
Matt Coulter:
Awesome. So I know we’ve come full circle back round to what is serverless-first and its rapidly delivering business value? But I think, I honestly think I could keep this conversation going all day, but I think we’ve talked for as much time as is reasonable for me to keep all three of you on video today. So I just want to thank all three of you for being here and being part of this conversation because I’ve thoroughly enjoyed it.
Rajesh Kannan :
Yeah, me too. Thank you. You know, I’m first time, I think I’m meeting both Jeremy and Marcia, and thank you for the opportunity. It’s so nice to talk to both of you.
Jeremy Daly:
It’s great to be here. Thanks for having us.
Marcia Villalba:
Thank you for inviting us.
PART 4 OF 4 ENDS [00:48:35]
Your California Privacy Choices