8 Reasons why we built the Fn Project

Having been early pioneers of serverless technologies at Iron.io, our team has watched the market grow and evolve, and we believe the Fn Project will help accelerate the adoption of serverless, evolve the architecture to include full serverless programming models, and create a path towards true multi-cloud computing. In this blog post, I’ll cover the what and why of the Fn Project.

Open sourcing the Fn Project on stage at Java One (Click to view video)

What is the Fn Project

The Fn Project today consists of 4 major components:

1. Fn Server is the Functions-as-a-Service system that allows developers to easily build, deploy, and scale their functions into a multi-cloud environment. It’s fast, reliable, scalable, and container-native, which I’ll discuss more below.
2. The Fn Load Balancer (Fn LB) allows operators to deploy clusters of Fn servers and route traffic to them intelligently. Most importantly, it will route traffic to nodes where hot functions are running to ensure optimal performance, as well as distribute load if traffic to a specific function increases. It also gathers information about the entire cluster which you can use to know when to scale out (add more Fn servers) or in (decrease Fn servers).
3. Fn FDK’s — Starting with Java, we are releasing a number of FDK’s, or Function Development Kits, aimed at quickly bootstrapping functions in all languages, providing a data binding model for function inputs, make testing your functions easier, as well as lay the foundation for building more complex serverless applications.
4. Fn Flow allows developers to build and orchestrate higher level workflows of functions all inside their programming language of choice. It makes it easy to use parallelism, sequencing/chaining, error handling, fan in/out, etc., without learning complicated external models built with long JSON or YAML templates. Best of all, Flow tracks all of the function call graphs, allowing for visualization in the dashboard, full stack logs of entire “Flows”, and variable/memory reconstitution throughout the entire function graph.

Experimental user interface to Fn Flow visually representing “flows” of Functions

We have much more in the pipeline for the project, but believe these four components are core pieces of the serverless application puzzle.

Why the Fn Project

So why build another serverless framework? Our vision at Iron.io was a lot larger than a simple FaaS platform. We set out to build a platform, a rich ecosystem, and an experience that is both welcoming and embracing to developers of all skill levels and companies from small 1-person teams to the largest global enterprises. This proved difficult as a startup ourselves, but now at Oracle we are equipped and resourced to carry out this vision. Here are some of the key differentiators we believe will set the Fn Project apart:

1. Open Source: We believe that open source is the way software is now delivered and adopted. Everything in the Fn Project is open source under Apache 2.0 with an open and transparent governance model.
2. Multi Cloud: Whether you are adopting multiple clouds or not, your technology stack should not lock you into one. Everything we build in the Fn Project will always cover multiple cloud providers including running on your own hardware. Serverless should feel serverless to developers, but enterprises still have a lot of actual servers that can be utilized.
3. Developer Experience: Despite the economics and operational efficiencies being very attractive for the business and ops teams, serverless remains an architecture for developer empowerment and agility. That is why the experience is essential and must be baked into the product every step of the way. From `fn init` to `fn deploy`, we’re thinking about how to make the Fn Project natural, elegant, and fun.
4. Container Native: Containers fundamentally change the way we package software. Our goal for the Fn Project is to abstract out the complexities of containers, even create a “containerless experience”, but expose the power of containers to those who have adopted containers as their packaging format. That is why `fn deploy` can abstract the whole process away from you, but we also support native Docker containers as Functions. This party is optionally BYOD: Bring your own Dockerfile.
5. Programming Model: The cost, operational benefits, and hype, of serverless has created a rush to adopt, and this has led to many fantastic use cases including ops tooling, event-driven architectures, triggers in the cloud, etc., but there are still technology gaps preventing more complex serverless app design utilizing native language features, true IDE integration, testing, workflow, etc. We want to address this, starting with the release of the Java FDK and Fn Flow as initial blueprints.
6. Orchestrator Agnostic: Kubernetes is great, and deployments of Fn can benefit from it handling all the lower level infrastructure, but it’s not the only game in town, nor do we want end users of Fn having to learn or deal with Kubernetes. A clear separation of serverless and container orchestration is important, thus allowing the project to adapt and evolve in an ever-changing cloud landscape.
7. Vision and Depth: Fn, Flow, and the FDK’s are the foundation, but there’s a lot more to come, and over the years we’ve established a strong vision for where serverless is and needs to go. Truly going multi-cloud serverless takes a wider stack of services, and much of this work is ahead of us. We’ll start to work with the community and partners on a roadmap very soon. Join us on this journey. For ways to get involved, see below.
8. Sustainability: No not saving the planet (although compute efficiencies of serverless will certainly have that effect), I mean many projects are flashes in the pan. It’s easy to release something and get to the front of hacker news for a few days, but it’s much harder to sustain the momentum, community, and vision all while maintaining technical and usability excellence. Our team founded and built a successful startup so we know the difficulties of the journey and now at Oracle we’re excited to see the complete vision through. We’re ready to run the marathon it takes to build a great and lasting project.

What’s Next

We have a lot coming, so I’ll save roadmap and longer term vision for another post, but here are few things you can expect over the next few months:

1. Community and Partners: Community and partners will be critical to the success of the Fn Project. We are seeking leaders, doers, partners, and supporters of all kinds to help join us in our mission. Please reach out to get involved by way of the links below!
2. Services: Expect to see the Fn Project launched as a service starting on Oracle Cloud Infrastructure, and eventually on many cloud providers in many regions around the world.
3. Language Support: The Fn runtime supports almost every language today and you can even “bring your own Dockerfile” and launch as a function. That said, we are creating FDK’s that will provide deeper language functionality for both Fn and Fn Flow. Today we’ve got Java, Go, Python, and Ruby, and adding more every week.

And these things are just the beginning.

Get Fn Involved

Come say hello. Feedback of any kind welcome!

• Star and watch our Github repo: https://github.com/fnproject/fn
• Join us on Slack to say hello: http://slack.fnproject.io

Let’s build the future together.

Chad