Runtime environments for serverless cloud computing for multiple coding languages, aiming to create a consistent and predictable open standard for writing cloud functions in containerized systems.
- Flexibility (WIP) - Designed to work with multiple orchestrators using different adapters. For now only Docker and Swarm are supported, Kubernetes support is planned.
- Performance - Cold starts in less than ~100ms & executions in less than 1ms.
- Wide Support - Supports 11 (and counting) different programming languages and 18 (and counting) different runtimes. Adding new ones is straight forward.
- Open Source - Released under the MIT license, free to use and extend.
- Ecosystem - Fast growing ecosystem of ready-to-use functions for easy reuse on different platforms.
- Kubernetes Adapter - Native cloud support and easy deployment
- Official CLI - Easy deployments
- Catalog - Browse the open-runtimes functions ecosystem
- Autoscaling - Automated scaling features based on hosts and runtime metrics
The Load Balancer get requests for endpoints and responsible for balancing and scaling the requests between multiple hosts where runtime executors are available. This is the layer where you want to implement auto-scaling and keep track of which host has which runtimes available to allow wise spending of computing resources.
The Executor is responsible for starting runtimes (AKA cold starts), and directing requests, environment variables, and user inputs to each runtime. In addition, the Executor will also be responsible for managing timeouts, max runtime allowed in parallel, and cleanup of inactive runtimes in the chosen interval.
The Adapter is a software layer component that interacts with the container orchestration engine to manage the compute runtimes.
The Runtime is a containerized isolated environment to run user-provided code. The runtime is spinning an HTTP TCP server on startup from one of the supported languages and handles requests on demand. Multiple runtimes of the same function can potentially run on the same or multiple hosts.
The Functions is a user provider packaged of code that is mounted to each Runtime and is executed inside the isolated environment. The package code should already be compiled and provided with all required dependencies.
The Build is composed from a queue and set of workers, the build process receives the raw codebase from the filesystem or a VCS and compiles or packages it with all dependencies. The build help with providing the dev's Function as a ready-to-execute codebase for the Runtime.
All runtimes share a common basic structure, but each additionally adds runtime-specific files to properly support it's package manager.
.
├── src
│ ├── (runtime-specific, like index.js)
├── example
│ ├── (runtime-specific, like server.js)
├── helpers
│ ├── after-build.sh
│ ├── before-build.sh
│ ├── before-start.sh
│ ├── build.sh
│ └── start.sh
├── docker-compose.yml
├── Dockerfile
├── README.md
└── (runtime-specific, like package.json)
| Name | Description |
|---|---|
| src/ | Contains source code of HTTP server of the runtime server |
| example/ | Contains a sample function to demonstrate the usage of the runtime server |
| helpers/ | Contains bash scripts that helps with simple build and start process. Can be ignored for more complex solution. |
| docker-compose.yml | Configuration to easily run the example code with docker-compose up |
| Dockerfile | Instructions to build a runtime, install it's dependencies and setup the runtime server. These images are usually based on official alpine or ubuntu. |
| README.md | Runtime specific documentation |
Structure of helpers/ directory follows:
| Name | Description |
|---|---|
| before-build.sh | Mirroring of function code from mount directory to build directiry. Do changes inside build directory if needed. |
| after-build.sh | Append .open-runtimes file, gzip file, and store into mount directory. Do post-build changes to build output if needed. |
| build.sh | Shortcut combining before-build.sh, your custom build command (like npm install), and after-build.sh. |
| before-start.sh | Extracting of function build from mount directory into server's directory. Do changes to server directory if needed. |
| start.sh | Shortcut combining before-start.sh and your custom start command (like npm start) |
Every request sent to any of the runtimes must have the x-open-runtimes-secret header. The value of this header has to match the value of environment variable OPEN_RUNTIMES_SECRET set on the runtime. All example scripts use secret-key as the key and we strongly recommend changing this key before production use.
We use PHP framework PHPUnit to test Open Runtimes. Every PR is automatically tested by Travis CI, and tests run for all runtimes.
Before running the tests, make sure to install all required PHP libraries:
docker run --rm --interactive --tty --volume $PWD:/app composer installYou also need to install jq:
brew install yqTo run test for a runtime, get runtime name (folder name) and execute below command:
sh tests.sh go-1.22Replace
go-1.22with runtime name that you want to test
All code contributions - including those of people having commit access - must go through a pull request and be approved by a core developer before being merged. This is to ensure a proper review of all the code.
We truly ❤️ pull requests! If you wish to help, you can learn more about how you can contribute to this project in the contribution guide.
For security issues, kindly email us at security@appwrite.io instead of posting a public issue on GitHub.
Join our growing community around the world! See our official Blog. Follow us on Twitter, Facebook Page, Facebook Group , Dev Community or join our live Discord server for more help, ideas, and discussions.
This repository is available under the MIT License.