Top Related Projects
OpenFaaS - Serverless Functions Made Simple
High-Performance Serverless event and data processing platform
Kubernetes Native Serverless Framework
Fast and Simple Serverless Functions for Kubernetes
Kubernetes-based, scale-to-zero, request-driven compute
Apache OpenWhisk is an open source serverless cloud platform
Quick Overview
Iron Functions is an open-source serverless platform that allows developers to build, deploy, and manage serverless applications. It provides a flexible and scalable environment for running functions in various programming languages, with support for both local development and cloud deployment.
Pros
- Language-agnostic: Supports multiple programming languages, including Go, Node.js, Python, and more
- Open-source and self-hosted: Gives users full control over their serverless infrastructure
- Docker-based: Leverages Docker containers for consistent and portable function execution
- API-driven: Offers a robust API for easy integration with existing tools and workflows
Cons
- Steeper learning curve compared to some managed serverless platforms
- Requires more infrastructure management than fully managed solutions
- Limited ecosystem and community support compared to larger serverless platforms
- Documentation could be more comprehensive and up-to-date
Code Examples
- Creating a simple function in Go:
package main
import (
"encoding/json"
"fmt"
"io"
)
func main() {
fmt.Println("Hello World!")
}
- Deploying a function using the Iron CLI:
iron init
iron functions create myapp
iron functions deploy myapp /path/to/function
- Invoking a function using the Iron CLI:
iron functions call myapp /function-name
Getting Started
- Install Iron CLI:
curl -sL https://cli.iron.io | bash
- Create a new function:
mkdir myfunction && cd myfunction
echo 'def main():
print("Hello from Iron Functions!")' > func.py
- Deploy the function:
iron init
iron functions create myapp
iron functions deploy myapp .
- Invoke the function:
iron functions call myapp /myfunction
Competitor Comparisons
OpenFaaS - Serverless Functions Made Simple
Pros of OpenFaaS
- More active development and larger community support
- Supports multiple programming languages and frameworks
- Offers a web UI for easier function management and deployment
Cons of OpenFaaS
- Steeper learning curve for beginners
- Requires more resources to run compared to Functions
Code Comparison
OpenFaaS function example:
version: 1.0
provider:
name: openfaas
gateway: http://127.0.0.1:8080
functions:
hello-world:
lang: python3
handler: ./hello-world
image: hello-world:latest
Functions function example:
package main
import (
"encoding/json"
"fmt"
"os"
)
func main() {
fmt.Println("Hello World!")
}
Both projects aim to simplify serverless function deployment, but they differ in their approach and feature set. OpenFaaS offers a more comprehensive solution with broader language support and a user-friendly interface, making it suitable for larger-scale deployments. Functions, on the other hand, provides a simpler, more lightweight option that may be preferable for smaller projects or those with specific requirements.
The code examples demonstrate the different configuration styles: OpenFaaS uses a YAML file for function definition, while Functions relies on standard Go code. This reflects the projects' different approaches to function deployment and management.
High-Performance Serverless event and data processing platform
Pros of Nuclio
- Supports multiple programming languages and runtimes
- Offers real-time processing and auto-scaling capabilities
- Provides built-in monitoring and logging features
Cons of Nuclio
- Steeper learning curve due to more complex architecture
- Requires more resources for deployment and management
- Limited cloud provider integrations compared to Functions
Code Comparison
Functions example:
func Handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello from Functions!")
}
Nuclio example:
def handler(context, event):
return context.Response(body="Hello from Nuclio!",
headers={},
content_type="text/plain",
status_code=200)
Both Functions and Nuclio are serverless platforms designed to run and manage functions-as-a-service (FaaS). Functions focuses on simplicity and ease of use, making it ideal for smaller projects or teams new to serverless architecture. It offers straightforward deployment and integration with various cloud providers.
Nuclio, on the other hand, is more feature-rich and designed for high-performance, real-time processing. It excels in scenarios requiring low latency and high throughput, making it suitable for more complex, enterprise-level applications. Nuclio's support for multiple languages and runtimes provides greater flexibility, but this comes at the cost of increased complexity and resource requirements.
While Functions offers a more streamlined experience, Nuclio provides advanced features like built-in monitoring and auto-scaling, which can be beneficial for larger-scale deployments. The choice between the two depends on the specific needs of the project, team expertise, and desired level of control over the serverless environment.
Kubernetes Native Serverless Framework
Pros of Kubeless
- Native Kubernetes integration, leveraging existing K8s concepts
- Supports multiple runtimes (Python, Node.js, Ruby, PHP, Go)
- Built-in CLI for easy function management
Cons of Kubeless
- Less active development (archived repository)
- More complex setup compared to Functions
- Limited documentation and community support
Code Comparison
Kubeless function deployment:
apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
name: hello
spec:
handler: handler.hello
runtime: python2.7
Functions function deployment:
{
"name": "hello",
"image": "iron/hello",
"config": {
"language": "python2.7"
}
}
Both projects aim to provide serverless function capabilities, but Kubeless is more tightly integrated with Kubernetes, while Functions offers a simpler deployment model. Kubeless supports a wider range of runtimes out of the box, but being archived, it may lack ongoing updates and improvements. Functions, on the other hand, has a more active development community and simpler setup process, making it potentially more accessible for newcomers to serverless architectures.
Fast and Simple Serverless Functions for Kubernetes
Pros of Fission
- Kubernetes-native serverless framework, offering better integration with existing Kubernetes infrastructure
- Supports multiple languages and runtimes out of the box
- Provides live-reload for faster development cycles
Cons of Fission
- Steeper learning curve due to Kubernetes dependency
- May have higher resource overhead compared to Functions
Code Comparison
Fission (Python):
from flask import request
def hello():
name = request.args.get('name', 'World')
return 'Hello, {}!\n'.format(name)
Functions (Go):
import (
"net/http"
"fmt"
)
func Hello(w http.ResponseWriter, r *http.Request) {
name := r.URL.Query().Get("name")
if name == "" {
name = "World"
}
fmt.Fprintf(w, "Hello, %s!\n", name)
}
Both examples demonstrate a simple HTTP function that greets a user, showcasing the syntax differences between the two frameworks. Fission uses Flask-like syntax in Python, while Functions uses Go's standard library for HTTP handling.
Fission is more Kubernetes-oriented, making it suitable for organizations already using Kubernetes. Functions, on the other hand, offers a simpler setup for those not invested in Kubernetes infrastructure. The choice between the two depends on existing infrastructure, team expertise, and specific project requirements.
Kubernetes-based, scale-to-zero, request-driven compute
Pros of Knative Serving
- More comprehensive serverless platform with broader Kubernetes integration
- Active development and larger community support
- Supports multiple programming languages and runtimes
Cons of Knative Serving
- Steeper learning curve due to Kubernetes complexity
- Requires more resources and infrastructure setup
- May be overkill for simple serverless function needs
Code Comparison
Functions:
func Handle(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Hello from Functions!")
}
Knative Serving:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
value: "World"
Functions focuses on simplicity with a straightforward function definition, while Knative Serving uses Kubernetes-style YAML configuration for more complex deployments and scaling options. Functions is easier to get started with for basic serverless needs, but Knative Serving offers more advanced features and integration with Kubernetes ecosystems.
Apache OpenWhisk is an open source serverless cloud platform
Pros of OpenWhisk
- More extensive ecosystem with multiple runtimes and integrations
- Highly scalable and distributed architecture
- Active community and ongoing development as an Apache project
Cons of OpenWhisk
- Steeper learning curve and more complex setup
- Higher resource requirements for deployment
- Potentially slower cold start times for functions
Code Comparison
OpenWhisk action example:
function main(params) {
var name = params.name || 'World';
return {payload: 'Hello, ' + name + '!'};
}
Functions (Iron.io) function example:
package main
import (
"encoding/json"
"fmt"
)
func main() {
name := "World"
fmt.Printf("Hello, %s!", name)
}
Both platforms allow for easy function creation, but OpenWhisk uses a more standardized approach with a main
function that receives parameters, while Functions uses language-specific implementations.
OpenWhisk offers more flexibility in terms of function triggers and integrations, whereas Functions focuses on simplicity and ease of use. OpenWhisk's architecture is designed for large-scale deployments, making it suitable for enterprise applications. Functions, on the other hand, provides a more straightforward solution for smaller projects or teams looking for quick serverless deployments.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Welcome to IronFunctions! The open source serverless platform.
What is IronFunctions?
IronFunctions is an open source serverless platform, or as we like to refer to it, Functions as a Service (FaaS) platform that you can run anywhere.
- Write once
- Run anywhere
- Public, private and hybrid cloud
- Import functions directly from Lambda and run them wherever you want
- Easy to use for developers
- Easy to manage for operators
- Written in Go
What is Serverless/FaaS?
Serverless is a new paradigm in computing that enables simplicity, efficiency and scalability for both developers and operators. It's important to distinguish the two, because the benefits differ:
Benefits for developers
The main benefits that most people refer to are on the developer side and they include:
- No servers to manage (serverless) -- you just upload your code and the platform deals with the infrastructure
- Super simple coding -- no more monoliths! Just simple little bits of code
- Pay by the milliseconds your code is executing -- unlike a typical application that runs 24/7, and you're paying 24/7, functions only run when needed
Since you'll be running IronFunctions yourself, the paying part may not apply, but it does apply to cost savings on your infrastructure bills as you'll read below.
Benefits for operators
If you will be operating IronFunctions (the person who has to manage the servers behind the serverless), then the benefits are different, but related.
- Extremely efficient use of resources
- Unlike an app/API/microservice that consumes resources 24/7 whether they are in use or not, functions are time sliced across your infrastructure and only consume resources while they are actually doing something
- Easy to manage and scale
- Single system for code written in any language or any technology
- Single system to monitor
- Scaling is the same for all functions, you don't scale each app independently
- Scaling is simply adding more IronFunctions nodes
There is a lot more reading you can do on the topic, just search for "what is serverless" and you'll find plenty of information. We have pretty thorough post on the Iron.io blog called What is Serverless Computing and Why is it Important.
Join Our Community
Join our Slack community to get help and give feedback.
Quickstart
This guide will get you up and running in a few minutes.
Prequisites
- Docker 1.12 or later installed and running
- Logged into Docker Hub (
docker login
)
Run IronFunctions
To get started quickly with IronFunctions, just fire up an iron/functions
container:
docker run --rm -it --name functions -v ${PWD}/data:/app/data -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 iron/functions
where ${PWD}/data is the directory where the functions application data files will be stored
This will start IronFunctions in single server mode, using an embedded database and message queue. You can find all the configuration options here. If you are on Windows, check here.
CLI tool
Install the IronFunctions CLI tool:
curl -LSs git.io/ironfn | sh
This will download a shell script and execute it. If the script asks for a password, that is because it invokes sudo.
Once installed close and re-open the terminal so the installed command fn
is in your path.
on OSX with HomeBrew:
brew install iron-functions
Write a Function
Functions are small, bite sized bits of code that do one simple thing. Forget about monoliths when using functions, just focus on the task that you want the function to perform.
The following is a Go function that just returns "Hello ${NAME}!":
package main
import (
"encoding/json"
"fmt"
"os"
)
type Person struct {
Name string
}
func main() {
p := &Person{Name: "World"}
json.NewDecoder(os.Stdin).Decode(p)
fmt.Printf("Hello %v!", p.Name)
}
Make a new folder and cd into that folder then copy and paste the code above into a file called func.go
. From that folder run the following commands to build your function and deploy it:
# create func.yaml file, replace $USERNAME with your Docker Hub username.
fn init $USERNAME/hello
# build the function
fn build
# test it - you can pass data into it too by piping it in, eg: `cat hello.payload.json | fn run`
fn run
# Once it's ready, build and push it to Docker Hub
fn build && fn push
# create an app - you only do this once per app
fn apps create myapp
# create a route that maps /hello to your new function
fn routes create myapp /hello
Now you can call your function:
curl http://localhost:8080/r/myapp/hello
Or surf to it: http://localhost:8080/r/myapp/hello
To update your function:
# update a function with a new version and push it
fn bump && fn build && fn push
# then update the route
fn routes update myapp /hello
See below for more details. And you can find a bunch of examples in various languages in the examples directory. You can also write your functions in AWS's Lambda format.
Usage
This is a more detailed explanation of the main commands you'll use in IronFunctions as a developer.
Create an Application
An application is essentially a grouping of functions, that put together, form an API. Here's how to create an app.
fn apps create myapp
Or using a cURL:
curl -H "Content-Type: application/json" -X POST -d '{
"app": { "name":"myapp" }
}' http://localhost:8080/v1/apps
Now that we have an app, we can route endpoints to functions.
Add a Route
A route is a way to define a path in your application that maps to a function. In this example, we'll map
/hello
to a simple Hello World!
function called iron/hello
which is a function we already made that you
can use -- yes, you can share functions! The source code for this function is in the examples directory.
You can read more about writing your own functions here.
fn routes create myapp /hello -i iron/hello
Or using cURL:
curl -H "Content-Type: application/json" -X POST -d '{
"route": {
"path":"/hello",
"image":"iron/hello"
}
}' http://localhost:8080/v1/apps/myapp/routes
Authentication
Iron Functions API supports two levels of Authentication in two seperate scopes, service level authentication, (Which authenticates all requests made to the server from any client) and route level authentication. Route level authentication is applied whenever a function call made to a specific route.
Please check Authentication documentation for more information.
Calling your Function
Calling your function is as simple as requesting a URL. Each app has its own namespace and each route mapped to the app.
The app myapp
that we created above along with the /hello
route we added would be called via the following
URL: http://localhost:8080/r/myapp/hello
Either surf to it in your browser or use fn
:
fn call myapp /hello
Or using a cURL:
curl http://localhost:8080/r/myapp/hello
Passing data into a function
Your function will get the body of the HTTP request via STDIN, and the headers of the request will be passed in as env vars. You can test a function with the CLI tool:
echo '{"name":"Johnny"}' | fn call myapp /hello
Or using cURL:
curl -H "Content-Type: application/json" -X POST -d '{
"name":"Johnny"
}' http://localhost:8080/r/myapp/hello
You should see it say Hello Johnny!
now instead of Hello World!
.
Add an asynchronous function
IronFunctions supports synchronous function calls like we just tried above, and asynchronous for background processing.
Asynchronous function calls are great for tasks that are CPU heavy or take more than a few seconds to complete. For instance, image processing, video processing, data processing, ETL, etc. Architecturally, the main difference between synchronous and asynchronous is that requests to asynchronous functions are put in a queue and executed on upon resource availability so that they do not interfere with the fast synchronous responses required for an API. Also, since it uses a message queue, you can queue up millions of function calls without worrying about capacity as requests will just be queued up and run at some point in the future.
To add an asynchronous function, create another route with the "type":"async"
, for example:
curl -H "Content-Type: application/json" -X POST -d '{
"route": {
"type": "async",
"path":"/hello-async",
"image":"iron/hello"
}
}' http://localhost:8080/v1/apps/myapp/routes
Now if you request this route:
curl -H "Content-Type: application/json" -X POST -d '{
"name":"Johnny"
}' http://localhost:8080/r/myapp/hello-async
You will get a call_id
in the response:
{"call_id":"572415fd-e26e-542b-846f-f1f5870034f2"}
If you watch the logs, you will see the function actually runs in the background:
Read more on logging.
Functions UI
docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" iron/functions-ui
For more information, see: https://github.com/iron-io/functions-ui
Writing Functions
See Writing Functions.
And you can find a bunch of examples in the /examples directory.
More Documentation
See docs/ for full documentation.
Roadmap
These are the high level roadmap goals. See milestones for detailed issues.
Alpha 1 - November 2016- Initial release of base framework
- Lambda support
Alpha 2 - December 2016- Streaming input for hot functions #214
- Logging endpoint(s) for per function debugging #263
- Beta 1 - January 2017
- Smart Load Balancer #151
- Beta 2 - February 2017
- Cron like scheduler #100
- GA - March 2017
Support
You can get community support via:
You can get commercial support by contacting Iron.io
Want to contribute to IronFunctions?
See contributing.
Top Related Projects
OpenFaaS - Serverless Functions Made Simple
High-Performance Serverless event and data processing platform
Kubernetes Native Serverless Framework
Fast and Simple Serverless Functions for Kubernetes
Kubernetes-based, scale-to-zero, request-driven compute
Apache OpenWhisk is an open source serverless cloud platform
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot