Reading Time: 6 minutes
As is typical with new concepts and technologies, the absolute definition of “serverless” or FaaS (Functions as a Service) is broad and undefined. In essence, it is a concept that takes cloud computing and “convenience as a service” to the extreme, spinning up processing power when your application needs it and responding with data.
Serverless is perfect for IoT devices, microservice architectures, or any other application that needs to be efficient. In this article, I will look beyond the major players (AWS, Azure, Google) to highlight lesser-known contenders for you to consider for your next project.
Many share similarities and features, some are container-based, some open source (requiring setup on your part), and some don’t describe themselves as “serverless” but share enough conceptual similarities I included them anyway.
Google App Engine
It supports Node.js, Java, Ruby, C#, Go, Python, and PHP, adds features such as routing traffic to different versions and applications, security, and access to Google’s other cloud services. I wonder if App Engine and Cloud Functions will ever merge, but for now, it’s a reliable option with ten years of development and usage.
Despite this (lack of) cost, it has a decent CLI tool and support for secrets, NPM modules, logs, cron tasks, custom domains, and a whole lot of other features. Webtask requires familiarity with the concepts of serverless, but for anyone with that knowledge looking for a service to experiment with, then it’s perfect.
Using a Node.js shim, Apex lets you use AWS Lambda with languages that it doesn’t support. As Lambda adds more language support, Apex may become less useful, but for now, it still plugs a couple of useful holes.
As an open-source project, it does leave me wondering how quick it is at supporting new features as they emerge. But currently, it supports a wide range of Lambda functionality.
As the name suggests, PythonAnywhere only supports Python and is aimed at the education market.
It’s more of a fully featured online IDE and hosting environment than pure serverless, but it does mean that smaller internet-connected devices can access the power of Python, so it shares some similarities. And for devices that have no screen, the platform can accept code pushes from any public repository.
Apache OpenWhisk is a promising open-source option for anyone who prefers complete control of their applications.
Figuring out how to get started is a little confusing, a common problem with open-source projects. I followed a Getting Started guide that took about 30 seconds before I received an error message and got stuck.
If you’re less concerned about the self-hosting aspect, then IBM’s cloud functions use OpenWhisk under the hood. A quick search will find you dozens of resources to help get started, but most are written by IBM employees, so they still push you down the IBM Cloud platform.
The biggest stumbling block I hit was how to use OpenWhisk without IBM Cloud. I finally hit upon this guide from The New Stack that suggests using Vagrant for local testing. This caused me to dig into the codebase for OpenWhisk and discover that while it’s possible to install and run on most platforms and start accepting requests, it’s complex.
!Sign up for a free Codeship Account
IBM Cloud Functions
As IBM Cloud Functions is hosted Openwhisk, I’ll focus on what the service adds on top. Openwhisk has one of the better selections of runtimes and includes languages that better represent IBM’s priorities such as Swift, PHP, and Java.
Recently IBM added a composer tool that lets you combine different services programmatically. They’re pushing hard to show users what pieces of their cloud puzzle fit together to meet certain use cases. One of the biggest advantages of Openwhisk is its integrated access to IBM’s Watson service, plugging your small internet-connected devices into a powerful artificial intelligence.
Spotinst is pretty much a host for the Serverless Framework, so its documentation is a little thin, and you’ll have to jump between the two.
While it doesn’t claim to be serverless, Hook.io offers microservices and webhook hosting that are close enough to the concept for me to include here. The platform supports a large range of programming and scripting languages, and anything that has an HTTP or cURL client can request a response.
If you are already using Kubernetes for other aspects of your infrastructure, then Kubeless adds a “ThirdPartyResource” function definition that allows you to deploy small code units to your cluster without the need for building container images each time.
It supports Python, Node.js, and Ruby, and also integrates with Kafka and Prometheus, again bringing serverless concepts to preexisting infrastructures.
In a similar vein to Kubeless, OpenFaas is a framework for building serverless functions with Docker and Kubernetes.
In theory, it supports any language supported by Linux and Windows containers, has its own web UI, and leverages a lot of the scaling and metrics features of Kubernetes, Docker, and Prometheus. This involves a modicum of initial setup on your part, and as a new project, the current documentation is lacking. However, once you’re set up, I recommend this blog post that shows you how to use the OpenFaas CLI to create and deploy functions.
Another solution that leverages a container-based infrastructure, IronFunctions is an open-source serverless framework that you can self-host or use Iron’s FaaS offering.
As it runs in containers, you can use any language supported by Linux and Windows. IronFunctions supports AWS Lambda format and the ability to import existing Lambda functions, and a CLI tool for easy creation and deployment of functions.
The project is less than a year old, but with backing from a well-established cloud-native provider, it shows promise and looks well designed.
As the name implies, the Serverless Framework is not so much a platform but a framework that helps you create serverless applications on top of other platforms.
The intention is that you can write your code once and deploy to whichever platform you prefer. In reality, the experience varies depending on the languages and features each platform supports. You might it find it best to start developing from a “minimum shared feature set,” separating out platform-specific features into supplemental functions.
Conclusion as a Service
Phew. That’s a lot of options to consider, and I’m sure I missed one or two. I’d love to hear which you’ve tried, your experiences, and recommendations.