Choosing the right Serverless Platform
Before we delve deep into this topic, let’s look at the concept of Serverless and why the modern AppDev approach is taking off using Serverless Framework.
What is Serverless?
“The next frontier for modern app development!” A category of cloud services that raise the abstraction level so that developers never think about servers, VMs, or other IaaS components.
But wait, let me tell you a secret, there are still servers involved. Lots of servers and networking gear and Storage too. We just don’t want to have to think about them anymore.
From this table above, you realize that we have made significant changes to our software development methodologies for almost two decades now. We have shifted our focus from Waterfall model development for a big fat monolithic application, deploying it to a physical server in our on-premise IT to a DevOps model of delivery for our Microservices based application running in small containers on a public cloud. This is a BIG change not only in terms of technology but also on quick Go To Market strategy and continuous delivery of new features.
But agility is still not an easy problem to solve. There are various business challenges that we are constantly trying to solve such as to estimate the number of servers in the cloud, pay for idle workloads, etc. We are also facing the growing code, scaling of application and then our nightmare also chasing us in terms of vendor lock-in, dependencies, etc.
A Functions-as-a-Service (FaaS) platform is the beating heart of a serverless architecture.
A function is a simple piece of code that does one job, well. It takes some input (usually on standard in) and, optionally, writes some output, usually to standard out. We are not talking about functions in the ‘functional programming’ sense here as these functions can have side-effects, rather they are self-contained units of work.
Your functions are deployed as a single unit to a Functions-as-a-Service platform. This platform then deals with the provisioning of the underlying infrastructure; deploying your function code; scaling up and down; resilience and reliability; billing; security (authentication, authorization, isolation). It has to do all this blazingly fast; at huge scale and for any language/platform that you care to use.
The primary focus of a serverless platform is your code. The FaaS encourages you to break up your app into small, isolated parts. This is great for dev as small, isolated functions are easier to reason about and manage.
Your FaaS platform will enable your app to scale organically per-request without you having to write any special code to handle it. And not just the gentle seasonal changes in demand that a retail business might experience but also sudden, dramatic surges in demand caused by your app going viral.
With this, we have thickened the plot of what is Serverless and Functions and now have an appetite to look at the various distribution of Serverless platforms.
There are mainly two buckets of Serverless Platforms. One is Vendor based and the other one being Open Source run by the Developer Community.
Let’s see the contrast between the Vendor based and Open Source FaaS Frameworks.
❌ Primarily proprietary, but some open source
❌ Many common concepts across platforms, but no standards
❌ Poor development experience — low fidelity between dev and prod
❌ Poor to non-existent Java support
However, the Ideal Functions Platform should have these characteristics:
- Open Source — No vendor lock-in
- Platform Independent — Laptop, Server, Cloud
- Approachable — Easy for new users, low-level controls for advanced users
- Docker Based — Leverage Docker Ecosystem
- Scheduler Independent — Deploy to Kubernetes, Swarm, Mesos, etc.
There are many Open Source Serverless framework that is brilliant in nature such as Kubeless, OpenFaaS, Knative, Riff, Camel K, Nuclio, Fn Project, etc.
Let’s discuss the important considerations of these myriads of Serverless Platforms, which split between Cloud Providers and Open Source Solutions.
We will put these mainly into three brackets, mainly Runtime Support, Deployment Complexity & Serverless Monitoring.
Runtime Support
Most Serverless Platforms limits the supported programming runtimes to the most popular one. This is basically to be faster on their go to market strategy, while they focus on improving the scalability, stability, and efficiency of their platform. They try to avoid the added complexity of multiple runtime support. However, our Developer community is really hungry and their appetite is so high that they don’t get stuck at one language for all development and they move to other platforms. For example, apart from IBM, no other Cloud Provider’s FaaS framework doesn’t support PHP.
Deployment Complexity
Deployment Complexity is one of the most important functionalities because easy deployment means faster Go-To-Market for your real product to your users. While AWS Lambda requires a lot of steps to be performed, such as adding API Gateway, Trigger, etc. before you even start using it, other Cloud Providers such as Google, Azure are relatively easy. Same goes for Open Source Solutions as well. More or less, all OSS Serverless Frameworks are relatively easy to deploy.
Serverless Monitoring
The observability of the Serverless Platform and the Functions is absolutely necessary for the production workload. While AWS has their CloudWatch and X-Ray to do the job, the Open Source Project Fn includes both Prometheus Metrics and Jaeger/Zipkin Tracing which puts it to the leader board.
When you deploy an Open Source Serverless Platform to Kubernetes, it creates a number of Deployment, Pod and Container components and it’s absolutely necessary to monitor each one of them and correlate the events for conclusion.
While Serverless as a Technical Subject of Computing is still very much in its early days, these factors will still determine it’s long term goal & adaptability as a whole.
