by Application deployment strategies are really evolving fast. While containerized applications still look hot, there’s something even more interesting happening. What if instead of dealing with application containers we’d got rid of redundant shell and send application functions directly to the cloud? Sounds insane, right? Yet all major cloud providers have function-as-a-service (FaaS) functionality, which along with object storage and database services is enough to build a fully functional web application without a server – a serverless application.
Of cause, there’s still a server somewhere. Maybe many of them. But this time we neither know, nor care about them.
Transition from server to -less
Classical web application would definitely have a server. We’d put static HTML/JS content and API at one server, relational or document database to another and happily wait for a paycheck.
Containers changed a picture quite a bit. It helped us to pretend that servers are smaller now, much easier to create and provision, so we’d split app in more logical pieces and deploy them with more ease.
But here’s the thing. It’s all in a cloud now, so why should we have a dedicated container for a database which somebody’s still has to maintain, when we could use database service provided by cloud provider? Amazon DynamoDB or Google Cloud SQL are already there – just turn them ON.
Even more, why do we need a container for static web content? Object storage, like Amazon S3 or Google Storage existed for quite a while. It can host the content for us.
Finally, API server also doesn’t has to be.. well, a server. Amazon Lambda, Google or Azure Cloud Functions can host individual API functions, so we can put them right there.
What we’ve got in the end is serverless application. Pure app stored somewhere in a cloud.
Why would we want to do that?
One of the biggest answers – the cost. Renting a server, virtual and not, costs money, whether application is doing something or not. Moreover, servers also need some care and love, so somebody should monitor and update them regularly. Not to forget that most of the time the server will be underutilized, so it can survive peak usages.
FaaS model on the other hand implies that we’ll pay only for function executions. When users use it, we pay more. When nobody knows about it, we pay nothing.
Another huge reason is scalability. Serverless function can’t have a state between executions. Obviously, we could put something into the database or other persistent storage, but the function itself isn’t a class member, it doesn’t have access to global mutable variables. It’s almost pure. And pure functions scale. For cloud provider it doesn’t really matter if it’s executing one instance of the function, or a hundred.
For some tasks serverless approach sounds like a right way to begin with. Imagine you need to build a service that monitors health of a web server. Once per minute it pings the server, and if server responds service remains happy, or sends an email if it doesn’t. We’d probably put the service to some sort of a server or container. But alternative approach is to deploy a ping function directly into the cloud, connect it to provider’s scheduler on the one hand and emailing service on the other, and problem solved.
What can be wrong with serverless approach
It’s something very new to learn. AWS Lambda, which seems to be the oldest serverless provider, is just three years old. It’s not fully clear what are the best practices, what are the pitfalls, what is the right way to version control it, to stage it, to test. What is the right way to debug that damn thing after all?
It’s also not clear how it scales from development point of view. TODO app might be very simple thing to make serverless, but what about something more complex? Can I create Facebook killer app like that?
Finally, the vendor lock-in. With good old containers and servers we’d simply move between cloud providers, looking for the best service and price. Going serverless on the other hand implies much tighter integration with provider’s services and APIs. You can’t just copy Google Cloud Function and paste it to AWS Lambda or vice versa.
Conclusion
Even though I probably wouldn’t recommend my company to adopt serverless application approach right now, the idea itself looks really appealing. For years we’ve been moving away from hardware and operation systems, narrowing down the focus of attention at the app itself. Going serverless looks like a step in the same direction and probably the farthest one we can make. It’ll just take some more time to come to understanding how to do it properly.
