When not to use Serverless (Jeff)
I asked in a few places whether there were any questions around Lambda and Serverless that people would like to hear about, and I got a few interesting responses, but by far the most interesting was around wondering when Serverless is the wrong solution for a problem.
It’s quite a complicated problem to answer when not to do something. It’s like a double negative, but it is possible for this scenario. The approach is to understand how Serverless works and the variables that matter in this approach.
Third Parties and Services
When using third parties, you are immediately at the mercy of their ability to deliver a service. This means that you could get an amazing service, or an average service, but you are out of control of it’s ability to manage load and other things.
Bear that in mind when developing for them. What happens if they’re down? What happens if they slow down or throttle the connection? Can it scale to where you need it?
This is a speed of response and a reliability issue.
When using AWS Lambda and similar, you are essentially running a nano-container with a single function. There is a startup cost in terms of time and load, and there is also the fact you don’t know how fast the solution will run compared with, say, a piece of hardware that you own.
Once loaded a Lambda will be “warm” and so will work faster, so that’s ok, but you still don’t have a guarantee of availability of resources in the same way when you own a server.
So you have a problem with speed of response, but not reliability or even scalability.
The whole idea (as I see it) of the single function is the lack of dependencies, which makes it quicker, but doesn’t mean it necessarily is easier to develop or provide you with an easy way of expanding the function to do more (you might need another function!).
Basically, the small amount of compute is great for small amounts of load, but for something which is larger, or longer running is probably a little more complex.
With Lambda, you have 5 minutes maximum, which is really useful, but the problem is that for a long running task you have to store data and restart a new function. Basically, split up the task into multiple Lambdas.
This means that any large scale data task or long running processing task is probably better off a Serverless infrastructure, or at least, developed in such a way as to be appropriate (which can be done).
As I see it, Serverless is primarily an asynchronous solution although it isn’t inherently asynchronous. Therefore you should approach the majority of tasks as things that you should consume, but not necessarily respond to. So long as you have a mechanism to respond (push) then the user of an app/mobile/web solution shouldn’t need to worry about anything.
The exception is when you need real-time (or near real-time) solutions. Under this scenario you have to be confident in your services and solutions to be fault tolerant but to be honest, the best solution is probably a third party that provides this for you rather than developing your own serverless nano-compute solution.
If you need to do something complex with a computer program, then that may not be appropriate. The reference implementation for a Lambda function is image processing, but imagine it was a video processing function. It might need more memory and compute than can be garnered from a Lambda compute function, so this might be problematic.
The problem is amount of available memory and compute, rather than whether the language can handle the complexity itself. This is a per-function call rather than an architecture call. If you can offload complexities into multiple functions it’s probably fine.
When is it not the best idea to use Serverless?
I would suggest that there are a number of times that Serverless isn’t appropriate.
Whenever you need real time that matters at the business level (you can do asynchronous)
Whenever you need a long running task that can’t be split into multiple compute cycles
Whenever you need complex compute with high memory/compute requirements
Whenever you need a really good speed of response
Whenever you need reliability where you can’t guarantee service availability to a high enough level.
There are other reasons, but these are the primary ones that I can think of now.
I’d be interested to know your thoughts too.
And if there are other things you’d like to know about Serverless (Jeff) then write a comment.