Last week, I hosted a Cloud Academy webinar about open-source FaaS and FaaS on Kubernetes. If you missed the live event, you can watch it here.
In this post, I’d like to briefly recap some of the main topics covered, including a high-level introduction to FaaS and an overview of the main open-source projects. Also, I will be answering all of the questions that we received during the webinar, including the ones that I didn’t have time to answer during the live event.
Faas on Kubernetes: Webinar Agenda
My agenda included the following points:
- What does FaaS mean?
- FaaS in the open-source world
- FaaS frameworks for Kubernetes
- Pros & Cons of “on-premises” FaaS
Let me explain why “on-premises” is in quotes here: FaaS was born in the public cloud, and here I wanted to explore alternative ways of building your own FaaS platform, either in your own private cloud or on top of the IaaS layer of a public cloud.
While Kubernetes is not the only container orchestration system available, I decided to focus on a couple of open-source FaaS frameworks for Kubernetes that have been announced recently: Funktion and Fission.
What does FaaS mean?
The concept of Function as a Service (FaaS) was born with AWS Lambda, and it kept growing as one of the core components of the serverless movement. I would actually refer to FaaS as the main component. Without the ability to bring your own code and execute it on demand, serverless would just represent brainless outsourcing.
On Wikipedia, FaaS is directly compared with PaaS (Platform as a Service) solutions. This is a crucial point for many skeptics, in my opinion.
It reads:
In most PaaS systems the system continually runs at least one server process and even with auto scaling a number of longer running processes are simply added or removed meaning that scalability is more visible to the developer as a problem.
The first key point is that, even if the underlying architecture is very similar, PaaS developers have to explicitly take care of scalability concerns since, for the most part, the concept of “server” is still part of their daily workflow. With FaaS, you no longer have to think of servers or containers. Understanding how containers are handled under the hood is always useful, of course.
Quoting Wikipedia again:
In a FaaS system, the functions are expected to start within milliseconds in order to allow handling of individual requests. In a PaaS systems, by contrast, there is typically an application thread which keeps running for a long period of time and handles multiple requests.
This is the second key point, which has a direct effect on the corresponding pricing model. Indeed, FaaS will only charge you for the actual execution time of your function, rather than the whole application container life.
Roughly speaking, I identified the following minimum requirements of FaaS:
- Function as the unit of delivery: Each function should be an independent unit of delivery and deployment with its own configuration and properties (e.g. versions, env. variables, permissions, etc.)
- Multi-language support & BYOC: You could potentially develop each function with a different programming language. In other words, you can Bring Your Own Code and your programming language of choice as well.
- Transparent scaling & PAYG: High availability and scalability should be as transparent as possible without any impact whatsoever on the development or deployment process. This should hold both for performance and pricing, meaning that you will automatically pay-as-you-go on a weekly or monthly basis.
- No infrastructure management: As a direct consequence of the previous point, you shouldn’t have to interact with the underlying infrastructure unless your FaaS platform is running on your “on-premises” cluster and you are responsible for such infrastructure as well. We will discuss the pros and cons of this use case later in this post.
So, how do you deal with FaaS, as a developer? These are the most common concepts and tasks that you need to know:
- Independent functions development: This is what you’d hopefully do most of the time if the framework/platform allows you to automate a large amount of the following tasks.
- Versioning & staging (nice-to-have): Unfortunately, not every FaaS platform offers native versioning and staging environments, but I’d say that this is a critical requirement for stable and mature FaaS platforms.
- Cross-team collaboration: In order to speed up your team, you may need collaboration tools and role-based permissions that are well integrated with your versioning and staging functionalities.
- Automated workflow: Automation is not always required for FaaS solutions that lack a lot of features such as versioning or events mapping. An automation framework becomes a core component of your stack as soon as you have a complex application built with FaaS.
- Triggers/Events: The way you invoke functions can vary based on the specific FaaS platform, but you will always need a flexible and stable tool to track down what’s being invoked, how, and when. Things can get very complicated when you need to update such trigger configurations, especially if you haven’t followed all of the recommended best practices.
- Local unit testing: Unit testing is recommend with FaaS as well as with any other programming stack, although FaaS often requires deep integration with the corresponding cloud environment, and you may need to learn how to mock it properly.
- Integration tests: Testing every component of a FaaS can be tricky, especially if you consider how many things can’t be tested locally and how many can easily go wrong in a real environment. Ideally, you should have adequate tools to test and identify problems at each step (function code, trigger configuration, deployment process, 3rd-party services, etc.).
- CI/CD: If every point mentioned above is satisfied, achieving continuous integration and continuous delivery shouldn’t be difficult.
As far as I know, a complete platform does not yet exist, although you can get pretty close by using AWS Lambda and the Serverless Framework. I think all of the other serverless solutions will begin to keep up with the ideal expectations in 2017.
FaaS in the open-source world
Open-sourcing a project is a great way to let the community improve it and to get feedback as soon as possible (and ideally before the project is obsolete with respect to potential “competitors”).
There are three main open-source projects that allow you to build your own FaaS platform:
- Apache OpenWhisk: Backed by IBM and recently incubated by Apache, OpenWhisk is the FaaS component of IBM Bluemix, although it does not support Kubernetes yet (see the GitHub issue or read more about it here).
- IronFunctions: The open FaaS component of Iron.io. It supports both Docker and Kubernetes.
- Funker: A small open-source project based on Docker Swarm, which already supports Node.js, Python, and Go.
I haven’t personally experimented with IronFunctions and Funker, but they both seem very promising. On the other hand, OpenWhisk is much more mature and comes with dev-friendly tools such as the Serverless Framework OpenWhisk Plugin.
FaaS on Kubernetes: FaaS frameworks for Kubernetes
A few FaaS solutions for Kubernetes have been announced and shared recently, thanks to several companies and individual contributors active in the Kubernetes community.
I explored three of these solutions during the webinar:
- Kubeless: A proof-of-concept developed at Skippbox based on Apache Zookeeper and Apache Kafka. It supports both HTTP and PubSub as function triggers.
- Funktion: Developed by fabric8 and backed by Red Hat. It seems to be well integrated with fabric8’s Developer Platform, and it supports multiple languages such as JavaScript, Python, Ruby, Java, etc.
- Fission: As the newest of these solutions, it was designed to be extensible and fast, thanks to reduced cold starts. For now, it only supports HTTP triggers and Node.js/Python.
Interestingly, each of these are written in Go and offer a very similar approach from the function development point of view. Funktion and Fission adopted the very same function interface, which is also quite similar to AWS Lambda.
Pros & Cons of “on-premises” FaaS
Why would you decide to build your own FaaS platform? I think there are a few reasonable benefits, as well as strong limitations. As usual, it’s a tough trade-off between freedom, features, costs, and complexity. This holds with or without Kubernetes, in my opinion.
Here are the potential benefits of building your own FaaS platform:
- You will achieve the same abstraction level for developers while using open-source technologies instead of proprietary black boxes.
- You will have much more control over infrastructure and therefore the flexibility to cover more scenarios with fewer constraints.
- Since you own the infrastructure, you may avoid a few non-functional limitations such as maximum timeouts, unmodifiable machine configurations, etc.
- The overall solution might be cheaper and faster, although you should also take operational costs into consideration.
In terms of the cons, I see two. First of all, many of the nice-to-have features of FaaS are not currently available out of the public cloud, such as versioning, staging, environment variables, per-function monitoring and logging, advanced permissions and orchestration, and native triggers for databases, streams, object storage, etc. Secondly, the possibility to have more control over the underlying infrastructure may turn out to be a nightmare and not as cost effective as a public cloud solution, given the high operational complexity.
Faas on Kubernetes: Webinar Q&A
Here is the complete list of questions that we received during the webinar.
Q: What is the relationship between functions and APIs? I guess we’d want publicly facing APIs that forward to internal functions?
Functions don’t necessarily correspond to RESTful APIs. Some of your functions may respond to events in your system such as newly uploaded objects, updated database records, incoming streaming data, etc. In the case of APIs backed by functions, you need publicly facing endpoints that will forward requests to your function and return its results back as HTTP responses. This is exactly what most FaaS frameworks do, as well as PubSub mechanisms that allow you to implement more complex and event-driven logic.
Q: Apart from AWS Lambda, are there other FaaS platforms?
The most well known public FaaS platforms are AWS Lambda, Azure Functions, Google Cloud Functions, IBM Bluemix, OpenWhisk, Webtask.io, Iron.io, weblab.io, stdlib.com, UnitCluster, and many more still in preview or stealth mode.
Q: I understand that you probably don’t want to be biased, but for newbies, it would be nice to have a recommendation for which one to start with.
Although some of them have a corresponding commercial service, they are all open-source projects worth exploring. OpenWhisk seems to be the one that is the most mature and supported, even if it doesn’t support Kubernetes yet. Regarding the three Kubernetes frameworks I presented, I would start from Fission, which seems to be the most promising for now.
Q: Are you seeing an increase in the industry in terms of moving from PaaS toward FaaS?
Yes, definitely. FaaS and serverless are quickly changing how developers want to build quickly and efficiently. As with every technology out there, it’s not the perfect choice for every scenario, but it can drastically simplify your life and development workflow when you need to build microservices, RESTful APIs, and highly scalable event-driven applications.
Q: Which of the most mature frameworks make the debugging process easier?
I am not aware of any easy debugging strategy for FaaS at the moment. This is probably the hardest thing to do when you start having 10+ functions that react to different events and sources. AWS is actively working to solve the problem in-house with AWS X-Ray (still in preview). Other players such as the Serverless Framework allow you to fetch function logs and inspect them locally, which is more comfortable, but still not easy. Other services and startups – for example, IOpipe – are working hard on the same problem, which involves both debugging and monitoring.
Q: Cloud service, then microservice, then container, then function. So, what is the future of function?
That’s a very good question. I am not sure if we can achieve a more granular unit of delivery than individual functions. Indeed, FaaS might be the ultimate model from the development point of view, although there is plenty of margin for improvement, especially on the underlying layer. The future of FaaS – and development in general – might go from serverless to codeless altogether. That’s a future where everything has already been implemented by someone else, and you just have to put all of the pieces together. At that point, I’m afraid that machines will have already taken over! 🙂
Let us know what you think of FaaS and what you’ve built with it. You can watch the FaaS on Kubernetes webinar here. Don’t forget to watch our webinars if you want to learn more about Kubernetes and Docker.
