Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Depending on who you talk to, you might have heard that serverless is facing an uncertain future. Horror stories of cost and complexity may give you the impression that the promise of serverless was oversold and that there was never any problem with monoliths, virtual machines and data centers. Of course, a lot of these stories emerge as soundbites on social media, where there's little room for subtlety, context and trade-offs.
Today, we're talking about serverless in the enterprise. While some startups are struggling with serverless, for sure, larger companies are actually finding enormous benefits. So we're going to talk about where it works and when it doesn't work and what's needed to make it work for you. I'm Eoin. I'm here with Luciano. And this is AWS Bites, episode 135. AWS Bites is brought to you by fourTheorem.
If you're looking for a partner to architect, develop and modernize on AWS, give fourTheorem a call and you can check out fourtheorem.com. As software engineers, we're notoriously hit and miss when it comes to naming things. Serverless is yet another example of a term that doesn't quite capture what it's all about. But when we use the term at a high level, we're talking about offloading as much infrastructure as possible to the cloud vendor so that most of the work you do is focused on the stuff that should be unique to your business.
So when we say serverless, we're talking about architecture and technology selection with a few different traits. And some of these traits are things like no management of servers or advanced container infrastructure. Of course, there are servers somewhere. You just don't need to manage them. Then you're talking about fine-grained scaling based on demand, reducing unused idle capacity, but allowing you to handle significant peaks.
Serverless often goes hand-in-hand as well with event-driven architecture. So serverless architecture has often involved decoupling a system into a lot of different small components with asynchronous communication. Pay-as-you-go pricing is another big feature of serverless. Ideally, you don't pay for idle time. And I suppose as well, what a lot of people would think of when you're talking about serverless is that you're using something like Lambda functions as a service product or even low overhead container services for compute. And focusing on writing the business logic should be the main concern. In terms of AWS, so the first thing you think of when it comes to serverless is AWS Lambda, but other widely used serverless services are widely adopted, including S3, SQS, SNS, EventBridge, API Gateway, AppSync, and a lot more. So given this definition of serverless and some of its traits, Luciano, why are some people getting bearish on serverless and just getting a little bit down? Because maybe you've seen a lot of this commentary on social media as well.
Luciano: Yeah, absolutely. We have seen lots of comments and debate on serverless in a negative way and mostly complaining about cost and complexity. And of course, related to AWS, but even outside AWS, like it's not uncommon to hear bill shock stories about Vercel, for example, or CloudFlare as well. So to be fair, yeah, it's easy to just dismiss this criticism because we like serverless, but it's also fair to say, okay, let's actually have a look at the criticism.
Let's try to understand if it is valid. And I'm sure that some elements of it are actually quite valid. So let's try to have an honest conversation. Let's see what are some of the drawbacks of serverless, if we want to call it like that. And of course, some of these drawbacks are very specific to specific use cases. So it's also important to understand, based on your use case, do you actually suffer from these drawbacks or not?
And just to start, the first one that always comes up is cost. And it's fair to say that there is some element of concern when you think about serverless and you think about the cost that that might involve. And one of the reasons for that is that if you just look at the pure unit of price for compute, of course, you will realize that there is a premium comparing that unit to other ways of doing compute, like more managed services like EC2 or even Fargate will look like it's going to be cheaper to run on those platforms rather than running on something like Lambda, for example.
And while this is true, to be fair, we have seen that lots of businesses are actually finding the serverless approach to be cheaper. And the reason for that is that if you just look at the unit of price, this doesn't make any sense. But then in reality, when you run something on an EC2, for example, you have so much unused capacity that if you actually look at the use capacity, then with serverless, you might end up having a much smaller bill.
So in a way, we can say that serverless allows you to eliminate waste. So if you have very unpredictable traffic, if you have lots of idle time, actually serverless might be a much cheaper solution for you. On the other hand, yes, if you have like 100% utilization on something close to that and you can predict exactly what is your usage pattern and you are using a lot of compute, probably it's worth for you investing on just using EC2, properly configure them, have a good way to manage them.
At that point, it might be much cheaper. In our experience, most of the businesses are more in the category of very unpredictable traffic with lots of idle time. So of course, I'm defending serverless, but just to keep in mind that cost is very subjective and depending on which bucket of usage patterns you are, servers might be or might not be convenient to you. So hopefully that describes some elements of cost.
And actually, there is more there because another thing that it's important to consider is when it comes to cost, it's not just the cost of running the solution, but it's also the cost of building and maintaining that solution. And of course, when you use serverless, if you know how to build servers, this is also very subjective. But what we have seen is that when you have teams that are well-trained to use serverless technologies, they are generally much faster at developing solutions and put them in production.
So in that sense, you are saving cost in terms of development time. And development time sometimes is the most expensive resource, at least in most companies, that's the case. And to be fair, it's not just development time because when you manage EC2, you need to have people that are very experienced with managing EC2, there is time involved in just managing them, like just spending the time to configure them, keeping them up to date and a bunch of other operational things like that.
So that's also another piece that you need to put in the cost equation and consider if everything adds up to something that makes it worth it or not. And leaving cost aside, hopefully we are giving you some factors that you can think about to reason about cost, but there is definitely another element, which is complexity. And one of the reasons why some people say that serverless can be a little bit more complex or significantly more complex, depending who you ask to, is that serverless is by default a distributed microservice base, if we want to call it like that, approach.
So sometimes that might be more difficult to grok, especially if you are coming from a more traditional background where you build, I don't know, something in Rails or Django, where you are just building one monolithic application. That's what you ship to production, and all the functionality is embedded in this one piece that you deploy atomically. Typically, when you build serverless application, you end up easily with hundreds of Lambdas and other services that are all connected together.
And that's even just trying to visualize all of that infrastructure can be a challenge on its own. So I get the point that people say, well, serverless actually is very complex. It's not as easy as people say, but also that's a little bit subjective. Like I was recently reading a LinkedIn post by Yan Cui, where he was saying that in a way it is true that there is this complexity, but on the other hand, this complexity would exist anyway.
It's kind of a nature of your own business. If you have hundreds of Lambdas, probably you have hundreds of processes that are happening as something you are modeling as part of your implementation, and you will just have them hidden in a monolith if you were doing a monolith. So serverless in a way is just making it more evident that you have all these pieces combined together. So take that with a grain of salt.
I actually like that perspective, but of course it's also another bias perspective in favor of serverless. Yeah, I guess there are other resources that are worth mentioning. There is an article we bumped into by Scott Hanselman called "Dark Matter Developers: the Unseen 99%", I think that's the full title. And basically this article says that the vast majority of developers are not sharing online.
They don't read all the blog posts, but they are still doing amazing work behind closed doors. And this is just to say that maybe we only hear about the complaints and we hear a lot less about the success stories. And to be fair, in our work, we are seeing a lot of companies being successful with serverless. They're not just necessarily sharing it online every day and making a case out of it. So just consider that if you read something negative, that doesn't mean that it's represented the entirety of the opinions out there. So what is another thing we should mention? Maybe we should talk about experimentations and the cost associated to that. Yeah, the low cost of experimentation is one of those great understated benefits of serverless.
Eoin: And it's something that you really see the impact of when you're working with larger companies and seeing how quickly they can experiment compared to what their experience was with different approaches. If you want to innovate, whether it's for a new project or in some small area that needs improvement, using pay-per-use managed services means you can quickly try something, delete it, try something else, and continue until you have something that meets your goals.
Let's say you want to do some analytics with some business data. You could go with like a traditional option. Maybe you've got some data analytics platform and BI systems on-premises, and you can request access to existing database infrastructure, get an ops team to provision instances, etc., getting an installation of a third-party platform, security approval, and waiting for your ops team to provision all this stuff for you.
Alternatively, if you've got like a sandbox environment and access to an AWS account, you can quickly assemble a prototype with S3, Athena, Lambda maybe, and use some of the cool latest data science libraries like DuckDB, Interpolers. We're seeing a lot of success in this kind of analytical domain. What may have taken you weeks, then, or months can be achieved in hours or days with this approach. And it's difficult to say sometimes why.
I mean, the fact that these things are pay-per-use, you can spin them up and spin them down minutes later and pay almost nothing or nothing at all and just do it on the free tier. It really encourages this mindset shift where technology decisions aren't made thinking that you have to stick with them for months or years. You have a much more evolvable architecture mindset that comes with all this serverless stuff.
And we've seen this time and time again in enterprise. So it's a really understated benefit because you don't have to spend months and months doing technology selection up front. You can quickly experiment, find something that works, and know that you can iterate on it because you've got essentially swappable components if you architect it very well. Small components that you can replace, adapt, remove as AWS improves is another thing we see quite a lot. So this is a huge benefit, not just for data analytics, but also APIs, front ends, and batch processing. What else are larger companies seeing as benefits of serverless, Luciano?
Luciano: Yeah, I think we should talk again about economics because we talked already about cost as a drawback, but we also say that actually that's very subjective and it could go either ways depending on how your business domain and how you approach serverless. But other than what we say, I think there are a few interesting studies that are worth mentioning because they provide lots of data, so probably a little bit less biased.
And there is one from Deloitte that estimates 45 to 80% reduction in maintenance costs just by moving from EC2 instances to serverless. We'll have a link to that report in the show notes. But again, this is just another example of the idea that, yes, EC2 might be cheaper in particular conditions, but there is a lot of hidden costs with just managing EC2s. So if you put everything in the picture, you try to capture all this hidden costs, doing serverless might actually be cheaper.
And another report is saying that businesses that move to serverless, they will have a 409% five-year return of investment. There is another link to this one. It's actually a research from AWS itself. So again, it might be a little bit biased, but yeah, if you want to check it out, we'll have a link in the show notes. It's just a form you need to fill and you'll get access to the white paper. But if you don't want to go through all that trouble, we'll give you the summary.
And it's basically saying that 89% reduction in time to deploy and 33% increase in developer productivity. Again, check out the white paper if you want to see how they came up with these numbers and get more details. But what I would say is that personally, I have experience. I don't know if I could say exactly these numbers, but I have experienced definitely an improvement in terms of going from an idea to something running in production, not just myself, but also working with a team of people that decided to embrace serverless.
So I have a feeling that there is some truth to this particular statement here. But of course, I also acknowledge that it depends from different teams and there is always a little bit of a knowledge gap that needs to be addressed before you actually start to get the value out of that investment. And I think that the main point here is that if you are not using serverless, what I often seen is that enterprises, especially, they are struggling a lot with engineers that are constantly firefighting because there is just so much infrastructure that needs to be addressed.
One day is a vulnerability. Another day, it's maybe a bug in a system that, I don't know, needs to be upgraded. So all of that total cost of ownership, it's a real thing. Like it's something that you stop for a second and look at it. You will see in a company how much time is being spent by many engineers just addressing stuff that is not the pure business logic of your own applications. So this is where serverless can be a big selling point because, of course, it's kind of a natural shift to let's focus more on the business logic and let's delegate almost everything else to the platform provider. So I think this is kind of the perspective here that we can bring when we talk about economics and what is the advantage that serverless brings to the table. So compute cost is something that, yes, it's part of the equation, but very dependent on the use case, can be very low for certain workloads, can be very high for other workloads. But yes, you need to consider how that compares to the, I guess, human costs and the total cost of ownership. And don't just look at the specific compute costs because that's not going to give you the full picture and you might make the wrong decisions if you focus just on that one. What else do we have? Maybe security is a good point.
Eoin: Yeah, absolutely. When you think enterprise, you always think about security and compliance and they're usually priority number one, especially for financial companies. And there's a huge benefit here, actually, with serverless, the AWS portion of the shared responsibility model is going to be larger. So that means the less work you have to do to meet your security and compliance goals. We talk about, you know, Lambda patching your runtime, but it could also just be, you know, the less you have to do on network level security, patching machines, software that you have to install on those third party software.
So the less custom code you have to write, the less self-managed infrastructure you have, the fewer security issues that are relevant in that picture. If you don't have service to patch, there's a whole set of security responsibilities removed. Also, if we talk about functions as a service specifically, fine-grained units of compute like Lambda functions also have a huge security benefit. And it's one of the things that we don't talk a lot about when we're talking about the 15-minute timeout.
The blast radius of a single Lambda function execution is incredibly small compared to other options, because first of all, it's only handling one event at a time. And also because the timeout is going to be 15 minutes, there's a very limited temporal blast radius there for any attack to take effect. But we also have to consider then the fine-grained permissions you can have if you've got very small units of compute. So if you've got very nice, tightly scoped IAM policies for specific Lambda functions and individual services, you've really reduced your security risk by adopting the serverless approach. And this is something that enterprises take really seriously. And if they see an opportunity to remove a lot of work, because it's a security, it's always a chasing game where you're chasing the latest attack methods, then this is a great opportunity. Yeah, absolutely.
Luciano: And I think the next topic is the idea of evolving your architecture. So we will say, I don't know, we could reference the well-architected framework if we want, but the point that I want to make is that when you build with serverless, you are automatically buy into this mindset of everything is distributed, but most importantly, is event-driven. So it's kind of pushing you to think in a more modern way of building applications, where you have all these small components that are tied together by different events happening.
And again, we mentioned at the beginning that there is a complexity to it, but at the same time, it could also be perceived as an opportunity, because it's pushing you to more modular design, and that might also be considered as a bonus. And the idea is that if you build small decouple components, effectively, that's giving you modular design out of the box. And you'll need to learn it a little bit.
There are some common mistakes that you might be doing at the beginning, but I think once you get the gist of it, and you get enough experience in the team, it's definitely a benefit. And one of the things that I've seen, for instance, in the past is when you build this kind of monolithic applications, maybe, let's say, I don't know, using Django, is that maybe at some point there is a major version of the Django framework that comes out, and you will be resisting for a long time before upgrading, because it might be a lot of work, and it's the kind of work that doesn't give you any immediate benefit to your business. But then suddenly, at some point, you are using a library that doesn't work. Well, maybe at some point, that's some kind of security vulnerability, so you are forced to upgrade that library. But the new version of that library only works with the new version of the Django framework. And that's kind of pushing you to a corner where you are forced to look at the big picture and see, okay, now we need to upgrade this entire monolith, and that escalates to a lot of work very easily. And, of course, this is an extreme use case, but I've seen that happening enough time, even with different frameworks.
Eoin: You see it with Java 8. People still have Java versions or ASP.NET and want to move to .NET Core, etc.
Luciano: So, yeah, it's very, very true. And when you compare that, for instance, with a more distributed approach using Lambda, but not necessarily even if you have containers and they have smaller services, so to speak, the idea is that, well, maybe you have seen that vulnerability. Chances are that you are not using that code in all the modules you have, probably just a few of them. So just thinking of rewriting or doing a massive upgrade, it's suddenly more feasible because the surface is much reduced.
So this is just to say that modular architecture are, by default, more evolvable. So you're kind of keeping yourself a little bit of freedom in the future to address big changes when you need to do those big changes. They're not going to be as big as with a monolith. So suddenly even just trying a new programming language, because, I don't know, maybe you have some benefits, becomes tangible because you can just try that one new programming language with one Lambda, for instance, and not with your entire application. And you might get some benefits just in that Lambda. You don't have to rewrite everything just to keep those benefits. So this is just why I think that there is a benefit there in going with a more modular design once you learn the basics and your team is confident with managing a more modular, distributed, microservice-driven, event-driven, whatever we want to call it, type of design. Yeah.
Eoin: Sometimes we get comments underneath our videos saying we only talk about serverless and don't talk enough about simple EC2-based solutions. And I suppose there's probably validity to comments like that, because we do talk a lot about these more modern approaches to architecture. It doesn't mean that we don't use EC2. We don't use more traditional approaches to architecture. It's really just a question of what fits for the context.
Like it's not definitely, serverless is not an all or nothing thing. And hybrid approaches are often very pragmatic. It really depends on the context. Like if you're in a startup or maybe not necessarily a startup, but just a small company, and you're just more constrained by skills, staff, budget, time to market, or all of the above, then technology decisions and having like a simple set of technologies you work with, that's pretty critical and often not easily reversible, because you don't necessarily have time to invest in learning the next new thing and building these distributed architectures.
So success just depends sometimes on picking a good simple tech stack for the platform and moving quickly with it. But in the enterprise context, you don't necessarily have the same set of constraints. In fact, for larger companies, often they don't want to be limited to one dogmatic tech stack. It might make sense to diversify, try different approaches, and see what works, and think long-term, but always be iterating.
They might have a top-down strategy to adopt cloud-managed services or serverless, but this is often a long-term thing, like a multi-year plan that starts with a subset of workloads. And while this is happening, they can invest in getting help from specialized partners, getting the right skills, and adopting incrementally. So it's not an all-or-nothing approach. You can be pragmatic and go with a less serverless approach when you don't have the time or budget, or just when it doesn't suit.
And we often see partial solutions like that. Sometimes we even have customers who come to us and say, we've got this monolith. It serves our API. We want to move to API Gateway with DynamoDB and Lambda. And we've had multiple cases in the past where we've said, well, we really don't think you should do that. What you have works. It's simple. Your team knows how to maintain it, and it's not causing you any problems.
So you don't necessarily have to go all-in on serverless just because it feels like the right thing to do. So before we wrap up, I mean, I think we're used to thinking of enterprise companies as being slow to adopt new technology and following startup early adopters many, many years later. But I think we're now in a situation where some startups might be justified in steering clear of serverless and embracing the boring monolith.
But plenty of larger companies are actually, they've been there, and they're finding that these days serverless fits the bill and gives them a lot more flexibility and ticks a lot of boxes. Remember that there's no need for tribal all-or-nothing thinking when it comes to solving these kind of problems. If you've got a pragmatic mindset and can evaluate trade-offs, you've got a great chance of success no matter what technology you pick. I'm interested to know, are you working in the kind of companies we're talking about today? Then do let us know if you're bearish or bullish on serverless. Now that we're past the hype, Lambda and ECS are 10 years old, what stories can you share with us from real serverless experience? So let us know in the comments or reach out on social media. Thanks a lot for joining us again, and we'll see you in the next episode.