Plans to get serverless?
It’s dangerous to go alone — take this!
Getting “serverless” is a thing right now and the offerings out there in the wild are so colourful and widespread that you could need a handful of information and tips to get started with your first steps. Later on you can use the tips for getting a grip on your technical based business decisions.
And because it’s dangerous to go alone — take those 5 facts!
Fact #1: FaaS is stateless by nature!
Always assume that from one function invocation to the next none of the previous state will be available, neither in RAM or on disk (which can be an exception within Azure Functions).
This has big impact on the application architecture. In a lot of cases functions are completely uncoupled of any state by e.g. being the middleman of taking incoming data from a trigger and write it to an output source.
If the function nevertheless needs state information of any kind, make sure to use databases, cross-application caches like Redis or network file stores e.g. Blob storage or S3 to satisfy this requirement.
Fact #2: Execution duration
Execution duration in combination with used memory is the gold of functions — for the provider. The user gets charged by those two parameters, so the goal is to not execute the function senselessly often and not waste RAM. This has an impact on the application architecture as well as on the decision on what logic a very function shall cover.
Be aware of hard timing restrictions from some providers also. Your function may get killed during the execution because of exceeded runtime limits.
Fact #3: Startup Latency
Depending on how often a function is used it may not be successfully spun up when you request it. It can take your function and the whole underlying service between a couple of milliseconds up to seconds to get ready to work. Moreover spontaneous upscaling from e.g. 10 req/sec to 100 req/sec in a very short time frame can cause those delays. As the FaaS providers are constantly improving their function feature sets this will be hopefully getting a lot better in the near future.
Fact #4: Tooling
Let’s be honest. Tooling is still poor. Very poor. By now there are first steps of local and remote debugging of function code by Azure Functions and a first draft of function specific monitoring. But regarding application / function-app monitoring and alerting there is still a lot to do compared to the tools which are available for “traditional” backend application development. We are still lacking cost monitoring and predictions. Think about your function gets DDOSed — you will pay the bill afterwards. So let’s watch out for new feature announcements on this matter by each and every FaaS provider.
Fact #5: The ultimate one — Open Source or Provider Lock-in
This should basically be the first and most important tip of them all — but let’s make it a last but not least.
Before you start coding and doing your super fancy nerd stuff with functions and all their feature possibilities, answer yourself the following question:
“Is it crucial or can it be problematic to — yes even hurt — my business that my application logic is locked to a certain provider’s platform?”
If the answer to this question is NO: Have fun and go experiment with all the fancy stuff out there.
If the answer is YES — which I actually assume — read the following lines carefully and take the facts into consideration when choosing your home provider for your serverless applications.
There are two quite big players for FaaS out there and bunch of smaller ones.
- AWS with Lambdas (https://aws.amazon.com/lambda) is quite evolved by now but lock the function logic to their platform. Functions developed in AWS it stays in AWS.
- Microsoft Azure with Azure Functions (https://functions.azure.com) are quite unique because the whole functions ecosystem is open sourced — runtime, web portal and core technologies. So you can use the service within Azure, setup your own service or just reuse parts of it for customised application needs.
IBM has their offering for serverless services with OpenWhisk (https://developer.ibm.com/openwhisk/), which they open sourced as well. So the same advantages apply here as with the Azure Functions.
So choose wisely, but keep the fun going!
… and let me know what you’re thinking :)