Nanoservices: Open Source Serverless Technologies (3/4)

There are several opensource technologies that can be used to create a nanoservices platform. As these technologies require high performance and low latency, they are implemented in languages known for performance such as c++, golang,? rust etc.? In this article, let us go through some of them,

• Firecracker
• Workerd
• Apache OpenWhisk

Firecracker

Firecracker is an open source virtualization technology that is purpose built for creating and managing secure, multitenant function-based services that provide serverless operation models. Firecracker runs workloads in lightweight virtual machines called microVM’s which combine the security and isolation properties provided by the hardware virtualization technology with the speed and flexibility of containers.

Why Firecracker ?

• As it is a microVM, it is possible to run any language runtime inside it like in a VM
• Security and Isolation: Prevents container escape vulnerabilities, side channel attacks etc.
• Overhead and density: Offers less memory overhead as less as 5MB per container
• Overhead and density: Can run 100’s to 1000’s of microVM’s in a single machine
• Overhead and density: Can start a instance with as little as 128 MB
• Performance: Can boot within 125 ms
• Performance: Allows creation of 150 MicroVM’s per second
• Performance: Provides comparable performance to running an application in a host

Firecracker golang sdk allows one to programmatically manage firecracker microVM’s using GoLang and allow running nanoservices inside them. I have created a POC using the same and is available in the following repositories.

• Setting up the environment - https://github.com/chenthillrulz/firecracker-setup
• Managing Firecracker instances - https://github.com/chenthillrulz/fc-dvc-mvm?

As the connectors were written in JavaScript, POC involved running a nodejs app inside a firecracker microVM and allowing multiple microVM’s to communicate with each other. I was preferring Golang based POC here, as some other teams in the Organization used the same and it is also easier to learn compared to that of Rust which requires a C++ background.

The following white paper provides a comprehensive understanding on Firecracker. There are various organisations who have already built several solutions on top Firecracker which are in production,

• AWS Lambda and Fargate
• Fly.io - global containers
• Koyeb - serverless platform
• Liquid metal - IAAS
• Astronomer.io - hosted Apache Airflow
• Kata Containers
• Actuated.dev - CI solution for faster builds at low cost
• Appfleet

Maintained by: Amazon

Authored language: Rust

Orchestrating firecracker microVM’s: To be presented in next article

GitHub repository: https://github.com/firecracker-microvm/firecracker

Workerd

Workerd is an open source JavaScript/Wasm server runtime based on the same code that powers the CloudFlare workers. Workerd was originally designed to self-host applications that one would otherwise run on cloudflare workers. It is intended to be a production-ready web server for this purpose.

If the connectors are JavaScript functions, it should be possible to run connectors with security, isolation and high performance using workerd. Workerd is based on V8 isolates. It promises the ability to run all connectors from a single host.

The following are some salient features of workerd,

• The ability to run V8 isolates in threads with security and isolation is a fascinating feature. The lowest latency can be achieved if two threads (running FAAS) can communicate with each other with sufficient security and isolation.
• It is cheap to create and destroy V8 isolates
• Capability bindings provides a permissions model allowing access control to services for communicating with the platform as well as other services
• Deploy all nanoservices to all machines allowing a homogenous deployment
• Built in API’s are based on web platform standards
• Allows running nanoservices

I did POC’s with workerd and had discussion with the Founder, Kenton Varda from Cloudflare along with our team.

Challenges faced with workerd

• Requires customizations/forking workerd to adapt to our needs. Many features were built to suit technologies (KV, R2 etc. - cloudflare technologies) used inside cloudflare workers. One will have to extend the platform to a cache store such as Redis.
• The lifecycle of the V8 isolates was not managed. The ability to evict idle V8 isolates was missing and had to be enhanced
• Requires changes to be made to existing connectors as workerd supports ES modules while we were using commonJS modules as part of nodejs.
• Providing common SDK libraries for building connectors involves enhancement to the platform
• Although workerd is used in production at cloudflare, it is still in a nascent stage. Could not find more organisations that use it for their own purposes.
• Not all development teams want to work on languages that involve managing memory by the developers. This was required as we had to enhance the platform for our needs.

Due to the above challenges, Firecracker was more preferable. Having said that, workerd is still promising if some organisations start contributing and adapting it. The following talk from Kenton Varda talks about workerd and it’s features.

Maintained by: Cloudflare

Authored Language: C++

Orchestrating workerd: Kubernetes

GitHub repository: https://github.com/cloudflare/workerd

Apache OpenWhisk

Apache OpenWhisk is an open source, distributed serverless platform that executes functions in response to events at any scale. OpenWhisk manages the infrastructure, servers and scaling using docker containers.

As OpenWhisk uses Kafka as a messaging layer and could consume longer timeframe for executing a function, had to avoid venturing more into it. As we saw the previous article, we wanted to avoid the messaging layer.

Maintained by: Apache Foundation

Authored Language: Scala

GitHub repository: https://github.com/apache/openwhisk?

While there many more technologies that can be evaluated such as the following,

• OpenFaaS
• Knative
• etc.

In the next article we will look at solutions to orchestrate Firecracker.

Prev Next