Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: The definition of serverless has already changed in a few years since it first emerged. There have been many success stories using serverless in startups and in the enterprise. But what comes next? By the end of this episode, you'll have heard our thoughts and predictions on what serverless 2.0 will look like. We'll also reveal who we think will be the main challenger to AWS for domination of serverless as it goes mainstream. I'm Eoin, I'm here with Luciano and this is AWS Bites. There are a couple of ways to look at serverless today and the term itself is a bit problematic. But you have to say that the trend towards serverless is very real. Luciano, what are some of the ways that you can define serverless? Yeah, you're absolutely right.
Luciano: One of the problems with serverless is that there isn't really a clear definition. There are many definitions. So I'm going to try to summarize all the definitions I know and maybe come up with a somewhat useful definition of serverless. But yeah, the first one that at least historically has been around is the concept of function as a service. So that whole idea that you can just write a function, it's event based, somebody is triggering your function, you run some code, you get stuff done that way.
For a long time at the very beginning of the serverless trend, that was serverless in itself. That's what people associated when they were talking about serverless, they were immediately thinking about function as a service. But in reality, I believe that there is a lot more to it. Like it's not just function as a service. Even though function as a service is probably one of the biggest part of the serverless revolution.
So I suppose in a more generical sense, you want to focus on trying to reduce the amount of code and the amount of operations and maintenance that you are doing when building something. And you can do that by using more managed services. So basically you want to try to stay as close as possible to the business needs and delegate all these concerns that are more on the infrastructure, on the scalability side, on the security side.
And that's not just from a development perspective, but also from a cost perspective. Because you want to pay for what you use, you don't want to pre-allocate a bunch of money somewhere in a pool and just say, okay, this is going to be there for my cloud spending. Or you actually want to organically grow your spending as your business gets more and more successful. So that's another very important idea for serverless.
Giving you that elasticity in pricing, you start very, very low, possibly zero when you are experimenting with a new business idea. And then as you grow and as you are more successful in the market, there should be there the opportunity to grow your cost organically with your success. Other than that, in general, when we talk about managed services, we can distinguish that in different areas. We can talk about compute, databases, file storage, event API, scheduling and orchestration.
All these things are at the end of the day tools that you need to build your applications. And cloud providers should kind of lower down the barrier to entry in this concept of serverless. Because again, the definition is that you focus on building things that the business needs, not necessarily on the how and supporting that. But more on let's serve the business, let's make it grow. Everything else is something that we just buy when we need it. So that would be my definition of serverless. It doesn't really mean that there are no servers, but it's what we don't think as much about servers. We think more about business capabilities and how them support the business. So what do you think are the challenges that serverless is facing today? I completely agree with your definitions there.
Eoin: I think some of the challenges we see today are not everything is available in proper full serverless mode. So if you look at AWS, we can still see that with serverless search, we don't really have a good solution. Databases are getting there, but sometimes it's more of a miss than a hit. Aurora serverless isn't quite there yet fully. Neptune, the recent announcements, kind of frustrated people because it doesn't seem very serverless.
Things don't seem to scale to zero in terms of cost. We could really do with an elastic cache serverless version or some sort of cache that's fast and serverless. And Kinesis, although we have Kinesis serverless, it's still not quite there yet in terms of scaling to zero. So you kind of have to look to third parties for things like that. And it's kind of early days, but there's a lot of third parties trying to fill the gap there.
So that's one of the challenges. Now, complexity. People talk a lot about complexity with serverless, especially when you start out thinking it's simple. You dive straight into it and all of a sudden you realize there are wires all over the place and you don't really understand how things are connected together. So you have to realize that with serverless, you're building a decoupled, scalable, on demand system made up of these small cloud components.
So you ended up with a highly distributed system that's inherently more complex to manage than a less scalable, but more cohesive monolith. So you have to then understand all the nuances, the restrictions and the controls from the cloud vendor, like identity and access management, infrastructure as code. Deployment. So if we look at the cloud serverless serverless, right, like Lambda, DynamoDB, AppSync, Step Functions, API Gateway, they all require a pretty good amount of knowledge and technical expertise if you really want to run them in production.
DynamoDB is a prime example here. It doesn't take a lot of skill to put an entry in a DynamoDB table and take it out again. But if you want to actually scale that in production over time, then you really have to understand the cost, performance, scalability, how to design indexes, partitions, and if you're really going to make it work well. So it's almost deceptively simple, but you have to understand what the long term impact is going to be like.
Another one of the challenges, local development and testing. So I think that's when I look at the surveys around challenges and servers, I think this is one that comes out top. You rely on full cloud environment to really replicate your production environment. There is no like for like local replica mechanism. So running locally really requires you to under structure your code and set up tests in a way that you can run some parts of your code locally, but that if you really want to test it, integrated or end to end, you have to deploy to the cloud.
So it all places this obligation on you to put in place more effective testing and testing asynchronous event driven distributed systems is hard. There's no escaping that. So the tooling has to improve there. Another one is that I suppose there's a lack of standards. So every cloud does it differently. Every vendor, Azure, AWS, Google Cloud, all the others. They do things like serverless services differently. They do their functions differently. So there's a learning curve.
You might also be concerned about the stability of interfaces. So the way we develop serverless applications today is at the same as with the way you're going to do it in three years. Will your code still last or will it gather dust? So all of this is possible to overcome, but you know, you need good training, best practices, expertise, standards and high levels of automation. And this is probably one of the reasons why serverless adoption, somewhat surprisingly, is less than expected in startups and more than expected in enterprise in large companies.
Now usually the startups were the early adopters. That was the case for to a certain extent with serverless, but generally startups are trying to get time to market so they stick with the tools they know. That's the way it should happen generally, but enterprises can afford the time and investment to invest in the tooling for this next generation of technology. So you do see some of the more innovative big companies moving forward with serverless and investing in the training and the tooling. So I guess with all that said, what do we think we need from the next generation of serverless or serverless 2.0? Yeah, I think I'm going to repeat some of your points because you definitely highlighted some of the major weaknesses of serverless today.
Luciano: So on the other hand, serverless v2 is going to try to resolve all these issues or at least some of them. So the main one that we mentioned is that there are lots of different services for different types of tasks, but at the end of the day, not all of them are truly serverless in that essence that you don't have to focus on managing the service itself, scaling it, and also in terms of pricing that it doesn't scale to zero.
I don't know, it forces you to think about like instance sizes rather than how much am I using this particular service. So definitely we need more of these serverless, first I'm going to call them, services for everything like caching, orchestration, high performance computing, so that coming to a new project, you don't really have to think this part is serverless, all these other parts is not serverless because there isn't a solution yet.
It's like you should be able to embrace serverless 100% in your architecture. Similarly, you mentioned for instance DynamoDB and how misleading can that be. So, and I want to definitely echo that feeling. I am the first one that says that DynamoDB is really, really good when you know exactly how it works and when you figure out all the access patterns to your data. But the truth is that if you're working in a new project, most of the time you don't know in advance of the access patterns for the future years, so it becomes very easy at the beginning to adopt but then later on, it might trick you in different ways and it's very hard to change the data as you go and implement new access patterns.
So definitely, and this is just not to mention all the amount of configuration that you have to put into it anyway because even if you don't have to think about databases, you just think about tables, you still need to put a decent amount of configuration in every table you create. And that might not be obvious at all to understand how that configuration will convert into scalability capabilities, or the ability to change the data as you go or the ability to perform different kinds of queries.
That requires a lot of expertise and again, it kind of conflicts a little bit with that idea of servers that you want to think more about business logic rather than all these details that are more operational details. So I suppose that one idea there for Serverless V2 would be, can I just have a default table where I can store data and it's going to automatically scale and deal with in a way that allow me to support different kinds of query capabilities without having to think, now I need to create a new index or now I need to replicate this data in a different shape somewhere else. Hopefully all this stuff can be somewhat automated and give the users just the ability to think more about the data rather than how to make it work at scale. Nice.
Eoin: Other than that, another topic is probably observability. It's something we covered in the past in other episodes and we also invested in some ways that allow people to automate all the observability concerns.
Luciano: By the way, if you're curious, check out SLIC Watch on GitHub. We'll give you a link on the show notes. But the idea is that if you want to do good observability today, it's definitely possible. There are lots of tools in AWS and all these tools are actually quite good. It just takes a lot of time to configure all of them correctly and connect all of them together and instrument all your code to really take advantage of these tools.
There is very little automation and with the experiments that we have done, with the research we have done, we realized that there is a lot of room for automation. It's just AWS is not investing enough in this area yet. So this is the reason that we hope to see more in serverless v2. And similarly, this is also another topic we discussed about in the past. As a developer, there is this kind of developer experience where on one side you are feeling, okay, I'm just writing functions.
And I feel a lot more able to focus on the business logic when I'm writing this one function that really encodes a specific workflow and I don't have to think about everything else. But then in reality, when you go and deploy that function, it never really works the first time because one time you forgot a permission. Another time, maybe you didn't configure the networking correctly. There are so many things that can go wrong from how that particular function is wired into the rest of the cloud environment.
So one solution to this problem could be that you have a better tooling that can somehow look at your code and also look at the rest of your architecture and your environments and make sense of maybe you are forgetting to create a policy and can tell you in advance, maybe before you deploy, you are using this SDK call that is going to require you S3 access. I don't see any policy attached to this function that gives you S3 access. Are you sure this is really what you want to do?
Something like that would be already very useful. And I saw that some time ago on GitHub, somebody was trying to build something like that, but it feels like the need is clear, but still not. We are not seeing a lot of investment in that direction. And hopefully, again, wishes are that serverless v2 will address also this problem as well. Then I have other one. I'm going to go quickly through them. Faster deployments. We know that deploying a significantly big serverless application might take, I don't know, even 15 minutes or more.
And you don't want to be spending 15 minutes every time you are doing a deployment. Imagine you are fixing a very bad issue in production. You want to deploy it as quick as possible. You don't want to be waiting for a pipeline to trigger and then spending the next 15 minutes looking at it, hoping it will go faster. And similarly, infrastructure as code, it's an area that we have seen a lot of innovation, actually, if we think about serverless framework, some, but all this innovation seems to have focus around the function as a service aspect of serverless.
It's making it easier to configure everything related to functions. But for everything else, you are still writing like barebone infrastructure as code where you need to specify every single detail. So hopefully the same trend that we saw around functions to making them simple, how to generate some policies, how to generate some of the wiring around networking and security, maybe we can see the same also for other parts of the infrastructure of different kinds of serverless architectures. So given what we just said, what do we think is going to happen there? Is this something that, I don't know, today we are seeing somebody in this space already addressing some of these concerns? Yeah, I think there are examples, right? If we look to some of the third parties, we can see innovation that is already maybe a generation ahead of the cloud vendors in terms of the serverless offerings.
Eoin: And maybe this has already been the case. Like we can see from the history, we had Heroku and Parse and all these other players building platforms as a service that try to make it easier for developers to adopt new technologies. And we're seeing examples of that in the serverless space now. So they might provide us with some kind of clues as to where the next version of serverless is coming from. Okay, so let's look at a few examples. Vercel is one that immediately jumps to mind. So it's mainly for front end and agile functions, sorry, agile functions, edge functions.
But they've really had success in terms of adoption because they made it easy for developers to connect a repo, get automatic deployments, monitoring environments, branch previews, and just make that experience really simple. So whoever is looking at product management in these cloud vendors, I'm sure they're looking at these as ways they can simplify the whole process. And you mentioned serverless framework. And I think this year, maybe late last year, they launched their serverless cloud.
And that's also trying to address all of these same challenges, right? With faster deployment, seamless local front end with a cloud backend. So you can do front end development and integrate it into your cloud, but it's all updated locally. Getting rid of the YAML configuration altogether, simplifying data storage and access like we talked about, simplifying events as well. And their approach is basically they'll do that for you and run it in their cloud infrastructure, which is going to run on top of a public cloud anyway, but it's all abstracted away from you.
So you don't see what the raw resources are under the hood. On the other hand, you have examples like SST from the serverless stack. And when I started learning serverless and experimenting with serverless years and years ago, I was using the serverless stack tutorials, which are really, really excellent documentation on getting up to speed with serverless. I'm really happy to see them continually innovating. And the SST tool is really taking off.
It's really one to watch right now. Right. So this is open source tooling. It provides a simpler level of abstraction for building applications than we're used to. But it's still your account and your resources. So it's still creating Lambda functions and everything under the hood. It builds on top of the CDK, adds a nice UI. They've got loads of starter examples and all in all tries to make the experience a little simpler, like with Vercel or with serverless cloud.
But you still have your own infrastructure and you can still see what the raw pieces are under the hood. Another one that you might take inspiration from, just because I suppose it's so futuristic in some ways, is Darklang. And Darklang is, I almost see it like a concept car, whereas it's not a car you're ever going to buy. But it might give you some kind of indication as to where the future is headed, because the interface is very different.
They're trying to provide a UI and a back end and everything all in one application. So you don't use your normal editor or your source provider. It's all in Darklang. And you code up to data sources in this kind of visual editor. The whole point that they're trying to push towards is zero deployment time. So sub 20 millisecond deployment time. So as soon as you edit your code, it's already deployed and you just turn it on with a feature flag.
The appeal of that is massive for me, because I think because local development in serverless isn't really possible, you spend your time trying to optimize your deployment of the cloud. Getting it down from 30 seconds or 45 seconds down to zero seconds would be a big win. And the last thing I suppose we could mention, just in terms of looking at where the innovators are coming from, there's a load of serverless databases coming out all the time now. And I think they're really pushing the simplification of data storage and data access and data scalability. So some dimension are FaunaDB, which is really big in the serverless space. Firestore from Firebase is, has been around quite a long time, actually, but it's a good example of making that developer experience simpler. CockroachDB is another one. And then you have lots of kind of domain specific databases, if you like, like content backends, headless CMSs like Sanity. I think we covered some of those on previous podcasts.
Luciano: Yeah, I really like that you kind of somehow underlined that there are these two different approaches where on one side, you are trying to simplify the space and make it more managed. But at the same time, you are abstracting a lot like it's not clear what's actually running under the hood. While there are other approaches that are just giving you extra layers that are simpler. But then at the end of the day, it's very clear how these layers translate to actual infrastructure.
You are still in control of that infrastructure. So it feels like more tooling than actual new solutions. And I really like that. I'm not sure if I have a preference for one or another. But I think at the end of the day, they both try to improve the developer experience in different ways. Given also what you said, looking at all of this innovation, we mentioned that there will be players competing outside the main cloud vendors, but also the cloud vendors could be doing something in this space to improve themselves. So what do you think will happen in the future? You're going to see a mix because different people require different modes, depending on the context.
Eoin: If you're a startup and you're just focused on speed, time to market, then simple tooling that abstracts everything for you. And you don't have to look at all of the complexity under the hood might make a lot of sense. Or even for enterprises building line of business apps where it's just low code. They're just looking for low code, simple applications. I would still say like cloud vendors are going to grow the serverless offerings and hopefully simplify both the services and the tooling.
We mentioned that AWS SAM is kind of going in the right direction. That should make serverless more compelling for startups and enterprises. But we can also see services are getting simpler, especially the newer services like EventBridge, Step Functions. These are really changing how we think about serverless, right? Because they're completely different offerings. They have loads and loads of features, but they're not as complex to manage as some of the services that have come before.
So I think we can expect a lot more of both types of innovation from the cloud vendors. And as well then with the startups and the innovators, third parties. The issue there, I guess, is that not a lot of large companies are going to build critical infrastructure on top of platforms from startups. Because of the perceived risk there. Unless those startups then go and get acquired by the major cloud vendors and get strengthened and grown from there.
So that's going to be a challenge for some of the players like serverless cloud and also some of the serverless database vendors. They have to mature and validate their offering and reach a certain critical mass before lots of people will flock to them. We've been here before with Parse, where it was acquired by Facebook and later shut down. And people have built on top of that mobile backend and lost out as a result.
It does lead us to that initial tease, right? Who is the best placed challenger for AWS when it comes to the next wave of serverless? And I throw it out there that the most likely challenger is Microsoft. And it's not because of Azure, although that is certainly a strong challenger. But since Microsoft released VS Code and acquired GitHub and then NPM became part of that ecosystem as well, they've invested a lot in developer tooling and in owning the places where developers live. So now you can develop code with cloud-based editor or with VS Code on your desktop. You can build and deploy with GitHub actions to a GitHub repository. You can have copilot write half the code for you, albeit with some dubious results.
Luciano: But it's not a big leap for Microsoft or GitHub to add lower code compute and database and keep building out that developer-centric ecosystem.
Eoin: And it makes perfect sense for that to be very serverless in nature. So it might be through Azure or it might be done with different branding or a different take. But I think Microsoft have positioned themselves very well here. And while AWS is obviously a strong market leader, I think there's a good challenge there. Microsoft have been smart in how they've aligned themselves well with the developer community. What do you think? Do you have any other challengers to AWS? I like your idea that Microsoft maybe, if you look at Azure, I don't know if I would agree, like the state of Azure right now.
Luciano: But given how Microsoft is positioned more globally, I absolutely agree with your assessment. They are in a unique position to build something new. And if they connect all the dots that they already have there and make them even better, I think they are up to something really, really interesting. So I think it's a good bet. But I have maybe a little bit more controversial one. And I've been really looking at DigitalOcean in the last few years.
And I think it's an interesting one, even though you wouldn't really associate them with serverless today. But I really like their approach. They started by just giving you visual machines. It was very simple to get one. The documentation and the all-over user experience was really, really good. They put a lot of effort into designing all of that experience. They put a lot of effort into creating guides, tutorials, case studies.
Also, the pricing model is extremely simplified. They never really wanted to give you anything that could scale to massive levels. But for starting, building a small startup, you always got a good offering. And over the years, they have kept the identity where everything is simple, everything is accessible, the pricing is clear. Lots of tutorials and good development experience. But interestingly enough, they also started to expand their own offering.
They started to give databases, Kubernetes, functions as a service. So it's really interesting to see if they start to invest more into this serverless space. What's going to happen in the future? Because I really like the way that they're focusing on the developer experience. So probably they are in a position to address some of the challenges that we just described. Which at the end of the day, they are mostly all around the developer experience. And now developers are empowered to actually build cool stuff. So that's my bet. I might have other ones. For instance, I really like the direction of things like Code Sandbox or similar tools. But you might argue that what GitHub is already doing with Codespaces is pretty much in line with that. So that might be just a component that maybe somebody else is going to acquire. It's going to require one of the successful comps to be more competitive in that particular direction. I really like that. It's a really interesting alternative option.
Eoin: I think all this competition in space hopefully makes it better for everybody. And that's something that we really need. So I guess the question as we finish up here is where would you place your bet? On AWS, DigitalOcean or something else completely? And what do you think is the future for serverless? Thanks very much for joining us today. Let us know all your comments on Twitter. Let us know what you think of all those questions. And thanks for joining us again. That's all for today. We'll see you next week.