In 2016, helped by the popularity of AWS Lambda, a new buzzword started circulating: server-less. That obviously doesn’t mean that you code everything in your front end and forget about everything else, but rather that you won’t need to administer and provision your backend, that’s left to a third party provider.
If you think about it in the context of “as-a-Service” architectures, server-less can be placed between “SaaS” (Software as a service), where you delegate everything to an external provider, and “PaaS” (Platform as a service) where you deploy your application with its backend to a platform like EC2. This is an oversimplification though; there are different shades of server-less, you can decide to delegate just some of your backend components to a third party provider, leaving most of it in house.
BaaS
Running in a Backend-as-a-Service environment means that you can still have a certain degree of control on how your backend runs, but the amount of control is up to you and your use case. The extreme solution where there is no backend logic of your own is being widely used by mobile application developers, where you might just need a storage and an authentication solution to be up and running, public APIs can do the rest.
Think about Firebase (now acquired by Google); with all the services offered, you wouldn’t need any backend coding for most of the mobile apps out there.
It can also be a mix and match of services. Think about authentication, how many times have you implemented an authentication/authorisation solution? Did you logic differ much between the different implementations? The answer is most likely no. That’s when services like Auth0 comes in handy, they avoid you writing cumbersome code and concentrate on your actual business logic. You still have control over your backends, but you delegate just some pieces of functionality to off the shelf components.
FaaS
Function-as-a-Service has become popular with AWS Lambda, even though Amazon is not the only provider out there. The other major cloud providers are following suit: Google with Cloud Functions, Microsoft with Azure Functions and IBM with OpenWhisk.
In such an environment, you only need to provide the piece of code you want to run in response to a trigger, there is no need provide a container or a runtime. The platform will take care of creating and/or finding ephemeral containers where your piece of code will run and will scale it if the demand requires it.
Your functions can be driven by different type of events:
- Time based events
- Message driven events
- HTTP request driven events
- Storage based events (e.g. a file is uploaded to S3 in AWS or a change is detected in a Google Cloud Storage bucket)
- Other cloud specific triggers that depend on the vendor used
Pros of a Server-less architecture
Reduced Time to Market
It goes without saying that, if big chunks of your applications are already there, your time to market will be impacted in a positive way.
Reduced infrastructure and Labour cost
The economies of scale allow vendors to charge a relatively small fees for the use of their services. The cost of in house implementation would be usually higher, but it must obviously assessed before hand.
FaaS vendors charge for only the effective compute time used and they are usually really granular; for example AWS Lambda does it down to 100ms.
Scaling Flexibility
It is true that platforms like EC2 allows automated scaling, but, when it comes to FaaS, this goes one step further. Starting up a new EC2 instance takes time, but running a new function doesn’t. As always you need to think about your use case, because you will probably save money in case of frequent and unpredictable spikes in traffic, but if your traffic is fairly uniform, it might end up paying more.
Cons of a Server-less architecture
Lost control
You save money and development time, but you give up control on how and where your code is run. You will certainly have limits (see here for AWS Lambda’s ones) and, despite a vendor best efforts, you might be impacted by unplanned downtime.
Slow cold start
In a FaaS environment, if you have a function that is used only occasionally, a cold start can be in the order of seconds, especially for a JVM runtime, while a hot start is much quicker. It might not be a deal breaker for you, but it’s worth considering.