A Hackathon Team May Have Discovered ‘Serverless Done Right’
A day in the life of a platform developer usually involves listening to users’ needs and customers’ issues, then writing code and solving problems. Suppose these developers had free time to explore some new ideas beyond immediate priorities?
At our last Cloud Foundry Summit, while training was going on as scheduled and users were gathering for the community day, the developers who work on and around the Cloud Foundry platform competed in an all-day hackathon. They worked together in self-selected teams to explore new ideas or take time to invent tooling to make their lives easier.
For us at the Cloud Foundry Foundation, this was a first-time adventure.
Teams had 24 hours to design, prototype, and share a project. At the end, five teams submitted projects. The winners — a team of Pivotal and IBM developers who dubbed themselves “Hot Topic” — came up with a way to use Cloud Foundry to host “functions” (think: serverless) with the same capabilities as the long-running applications more traditionally hosted in the system. They called their submission “CF Serverless done right.”
“PaaS is about just pushing code. Serverless is about just pushing functions,” wrote Ed King in his write-up of the project. As King explained, both concepts are about abstractions that let developers write stateless bits of code that a platform can use to manage, scale and orchestrate.
But there are critical differences: “Apps are just stateless containers triggered by routes and scaled by CF scale,” he wrote. “Functions are the same thing, but triggered by events in a shared message queue and being auto-scaled by message queue length. Hot Topic is a proof of concept that uses a CF map-event command, similar to CF map-route to make FaaS and PaaS work together in a really nice, simple and orthogonal way.
“Just cf push. Use cf map-route if you want a web app. Use cf map-event for functions. Same log streaming, packaging, orchestration, workflow, same way to bind services, all fully integrated, simple and consistent.”
The winning entry was an excellent prototype of an event-driven programming model spinning into the Cloud Foundry runtime. Julz Friedman, another member of the project team, gave a great (and funny) talk at the event to give his perspective on the team’s central project thesis.
There are certainly other event-driven programming models out there that work with or sit next to, Cloud Foundry. The Hot Topic team started with a deeply integrated approach. It then built on the basic abstractions of the Cloud Foundry platform. Finally, it gave users access to the platform’s entire ecosystem of languages, frameworks, and backing services. The only additional abstraction the team added was to support binding of a “topic” to a deployed app. On the back-end, the project uses autoscaling and a message queue to spin up instances of the app as needed, based on how many messages are in the queue.
Cloud Foundry’s Take on Serverless-ness
“Serverless” is a term you’ve seen in The New Stack before that bears some additional explanation in this context. A better term for serverless in our field may be “event-driven functions.” Instead of a web app that spins its wheels in a constant loop, listening for HTTP requests, code written for the serverless model only runs when there are events to process. Scaling, both up and down, is magically handled for you.
This is a different take on microservices, giving the application developer a way to think much more simply about event-driven apps. The developer doesn’t have to worry about scaling, instead focusing her attention on writing the app, so she can just drop messages in the queue to be processed. She doesn’t have to implement a bunch of logic or worry about plumbing or delivery. Simply enough, she produces serverless code that just accepts messages and manages their delivery.
Without an event-driven approach, there’s a lot more plumbing to worry about. Developers would need to be more aware of how event-driven messaging works, and produce that code themselves. They directly interact with the message queue of the system and write logic that pulls in messages as they occur. It’s a more complex approach that requires you to do the scaling yourself.
Hot Topic’s winning approach is a great way to implement the event-driven deployment model, but even better, you still just cf push your app.
More Platform Innovations
The second- and third-place winners of the Hackathon both created tools that make work easier for BOSH authors. Placing second, Team BCRaaS from Engineer Better and Pivotal, devised a time-saving service that precompiles BOSH releases in an AWS S3 bucket. Usually, the compile process or the BOSH platform takes a lot of time and effort. Team BCRaaS’s entry makes it easier for someone to use a precompiled BOSH release, instead of doing it themselves.
Authoring a BOSH release takes some effort, especially if you’re trying to repackage other open source software that’s already been packaged for a Linux distribution. In third place, Team Debr — made up of employees from Pivotal — came up with a way to automate BOSH release creation sourced from Debian packages. It did some magic to crawl dependency trees and map the contents of each package from one format to the other.
The Hackathon was a blast, and all the teams involved seemed to have fun. Better still, great ideas saw the light of day and even got jump-started as prototypes. We’re looking forward to the next Hackathon.
Cloud Foundry is a sponsor of The New Stack.
