How We Built autom(8) So Fast

This is a guest post by Fn contributor Gregg Altschul of autom(8)


In October of 2018, the very beginnings of the autom(8) concept started to take shape. We didn’t start building in earnest until late December of 2018 and by April 2019 we launched a fully functional alpha version of the product. We went from our first line of code to alpha in just over five months. Here’s how we did it…

libp2p — Our Rocket 🚀

When we first told one of our friends and de facto advisor, Raul Jordan, about what we were building he immediately told us to look into libp2p, developed by Protocol Labs. He and the Prysmatic Labs team were using libp2p as their P2P technology to build Prysm (also my wife’s name 🤯), a sharding client for Ethereum 2.0. Based on his high regard for this tool, we knew we had to check it out.

And boy were we glad we did! Because of libp2p, we were able to skip a lot of the difficult work that, quite frankly, was scaring the shit out of us. With libp2p, here’s what we get out of the box:

  • P2P connectivity – libp2p handles peer-to-peer streaming out of the box. It’s super easy to get bootstrap nodes up and running to provide connectivity to the broader network.
  • Cryptographic security – When it comes to decentralization, security is paramount. You can’t have a trustless protocol without it. Thankfully, libp2p takes care of this out of the box. Every message is secured via public/private key security between nodes that are in direct connection.
  • DHT support – DHT stands for distributed hash table. Basically, what this means is that you can store content in a hash table that exists in nodes on the network. You can retrieve this simply by looking for content similar to a regular hash table lookup.
  • PubSub – One of the coolest features libp2p offers is decentralized pubsub. We don’t use this yet, but this will be the future underpinning of how function triggers will work.

Fn — Our Rocket Fuel🔥🔥🔥🚀

Now that we had the P2P layer under wraps, we turned our focus to the FaaS layer. Like P2P, building this layer ourselves seemed daunting… so we took to Google and found the Fn Project, open sourced by Oracle. We couldn’t wait to give it a try, so we ran some tests and it worked exactly as advertised. In an afternoon, we had Fn running and were deploying functions to it. Easy!

Fn offers exactly what we were looking for in a FaaS technology:

  • Container-native - Since Fn runs functions wrapped in Docker containers, a(8) could support every language from the get go. Bam!
  • Language support - When it comes to building functions in your favorite programming language, Fn provides FDK’s (function development kits) that make it dead simple to build functions in Node, Go, Ruby and many more languages.
  • Powerful Tools - The Fn CLI supports a powerful suite of functions that any developer would expect. With in seconds you’re able to initialize, deploy and run a “Hello World!” function. Support for reasonable expected function configuration — like versioning, memory constraints, runtime variables, etc — are out of the box and make functions flexible.
  • Light - Unlike many of the other FaaS technologies we investigated, Fn does just enough to make you 😁, but not too much to make you ☹️.
  • Flow - I think Flow is Fn’s secret weapon and I’m super excited about it. In a nutshell, Fn Flow enables you to create long-running distributed processes using functions. Flows are parallelizable, scalable and don’t require complex declarative languages to execute. We don’t support this in a(8)…. yet 😉.
Image result for fn flow

As if all that wasn’t enough, Fn is open source (thanks Oracle!), so we started contributing. We joined their slack group and started talking to the core developers — Reed Allman and Denis Makogon — as well as project lead, Chad Arimura, who is Serverless OG; they have been beyond helpful working through issues with us. We participate in their bi-weekly community meetings and it’s been fun to meet the other folks using their tech. Fn is certainly an inspiration to us as we forge ahead with our own open source project.

People 👨‍👨‍👧‍👦 , Research 📝 , And Timing ⏱

When it comes to timing we got lucky. Two mature projects — libp2p and Fn Project — already existed and enabled us to build in 5 months what took years for our competitors who were earlier to market to build. We spent a good amount of time up front researching before building (highly recommended), but what really helped us was talking to people early. Our mentors combined with our partners at libp2p and Oracle helped us take the technology we found and turn it into a feature complete alpha release in very little time.