Is it time for your company to go Serverless?
The recent proliferation in serverless products and articles on serverless architecture might leave you wondering whether it’s time to jump on the serverless bandwagon. The short answer to that question is “yes”, but of course, things are never that simple. Let’s have a look at how companies can approach this software architecture paradigm before allocating those Q4 IT budgets.
What is serverless, again?
Mike Roberts makes a distinction between two types of serverless services, namely the Backend as a Service (BaaS) and Function as a Service (FaaS). It’s natural for these two types of services to co-exist within a single architecture, but they don’t have to. In this article I’ll be focussing on FaaS; services that allow you to upload some code and makes it available to call remotely, without worrying about scaling servers, at a lower costs. Amazon’s AWS Lambda and Microsoft Azure Functions are prime examples of such services.
The stark truth is that migrating existing applications to a serverless architecture is seldom worth the effort.
The are plenty of reasons for going serverless, such as (claimed) lower operational costs, ease of deployment and scalability. There are also plenty of reasons to not adopt a serverless architecture just yet. My main argument is that of vendor lock-in, although this might be alleviated when support for other providers drops in the Serverless framework.
Migrating existing applications
There are few reasons to migrate existing applications to a serverless architecture, but there are use cases. Applications with highly variable traffic patterns are good contenders. This is especially true if the application runs on a legacy infrastructure that isn’t able to scale automatically. Don’t expect this to be a simple migration as it will require some extensive refactoring.
Other candidates include microservices and small utility-like applications which have a relatively high operational overhead. The stark truth is that migrating exisiting modern applications to a serverless architecture is seldom worth the effort.
Green field applications
Microservices are a natural fit for a serverless architecture, even existing ones. These codebases are focussed by design and often stateless to begin with, making them a great fit for FaaS. The application is inherently small, making migration less time consuming and risky. You’re probably able to expose all of the applications’ functionality in less than a dozen public endpoints.
Asynchronous background tasks are another great fit for FaaS. Just be careful as some providers impose a limit on how long a function can run. AWS Lambda times out after 5 minutes, so you won’t be able to deploy long running or resource intensive tasks just yet. Sending emails, processing downloads, fetching and sending data from remote (web) services seem to be the sweet spot for now.
In combination with AWS API Gateway it has become quite easy to expose your Lambda functions over HTTP, enabling developers to build entire RESTful APIs on top of FaaS. These applications might not be the best fit for FaaS just yet–for instance, sharing code across functions is still quite cumbersome–but there is certainly potential.
There is one aspect that applies to all these types of applications; you have the most to gain if your serverless architecture leverages the entire ecosystem offered by the provider. When your Lambda function automagically connects to your DynamoDB database you really start to understand the power of FaaS services.
Wrap up
FaaS seems like a natural evolution from Platform-as-a-Service (PaaS) solutions like Heroku and Container-as-a-Service (CaaS) such as Docker Swarm. While this technology has yet to fully mature, there are already plenty of use cases for employing FaaS and serverless architectures. As with all new technology, don’t just drink the kool-aid because it’s the hip thing to do.