A Serverless Library for Building Developer Velocity – InApps 2022

The true value of serverless is not per-second compute power, but developer velocity, says founder and CEO of the FaaS platform Standard Library, Keith Horwood.

“Our perspective is that in serverless, developer velocity is the greatest strength,” said Horwood, whose Standard Library (known as StdLib) provides a platform where coders can write or compose functions that autoscale. “We often hear at the CIO level, that they are very concerned with serverless architecture as it does all this awesome avoidance of under and over-provisioning, but the way we are looking at this is that there are people who want to ship products as quickly as possible. They understand what writing code is all about, but they have become hesitant to jump into web development because there is now a plethora of tech that has solved for scalability but at a cost of developer velocity.”

Horwood believes that serverless allows a return to the promise of the late 90s and early 2000s programming models. Developers could build websites by simply modifying the PHP code of an existing page, load it up via SFTP and have it available to the worldwide web audience. In that paradigm, scripts were considered as base shippable code. Then, as internet use exploded, distribution and performance at scale became a key concern for developers, even those focused on front-end applications and websites.

Horwood says this affects developer velocity in a number of ways. Not only in the complexity of components that need to be managed in an operational environment but more so in the cognitive overhead that keeps a developer constantly worrying about “what if it goes down”.

“Saving that is a huge benefit, it will have immeasurable value for teams and for developers managing their time. That will be the ultimate true driver for serverless,” said Horwood.

StdLib as a Functions as a Service Platform

StdLib allows developers to install a command line interface (CLI) tool, which allows access to a range of library commands and creates some lightweight scaffolding for scripts. From there, developers can search for available APIs where functions have already been built (such as being able to create a Slack app or incorporate Stripe into an online store), or write their own functions in node.js. Once functions are tested (StdLib comes with self-documenting type safety checks to ensure functions are executable), they can be either incorporated into any enterprise existing code base or accessed via webhook using the StdLib user’s function URL.

“In the end, you are building your own function library,” said Horwood. “We take away that abstraction of application servers, so you just think of functions, and turn them into web services and API endpoints.”

Horwood argues that StdLib lets dev teams use functions as “first class citizens” in an enterprise software code base. In an existing code base, when wanting to use functions, developers would install the lib module and then execute the StdLib function as if it was an inline function.

The other alternative is to rely on webhooks and call the user’s StdLib function URL to trigger an event. For some enterprises trying to balance the spreading of their code base across different platforms, curtailing this to StdLib and their in-house code may be one way to ensure oversight.

With SaaS platforms like Twilio, Auth0 and others beginning to offer serverless function platforms, some have worried that this will introduce more complexity for an enterprise in knowing exactly where its code is being run in a more widely dispersed microservices and functions architecture. Perhaps using StdLib will allow enterprises to maintain oversight of code in just two locations: their own repos and in their StdLib library.

Monitoring Functions in StdLib

While scaling operations are taken care of in StdLib’s FaaS approach, there is still function level operational issues that need to be monitored.

Functions may time out without executing, may crash and not run as expected, or be built using out-of-date packages which aren’t synced in production.

Horwood says the StdLib team deals with most of these concerns without the StdLib users needing to see what has happened. For example, if a package isn’t up-to-date, StdLib would see a lot of runtime errors and would correct the package usage, which Horwood says doesn’t happen often anyway.

Users may need to watch for function timeout errors by checking their logs or the service analytics dashboard that signed-in users see. They can then allow for longer execution time in their code.

For better insights into what is happening with functions running in StdLib, users will need to build their own solution. Activity logs are written as part of the platform functionality, but users must create their own cron job to save these console log files, as they are only kept for a day, according to Horwood.

The platform also hasn’t implemented alerts systems as a function yet, for example, if a user wanted to receive a notice about anything that might be happening in their execution log, although Horwood says they do “have an API log endpoint, so if someone wants to schedule a cron job it is within the realms of possibility.”

StdLib as an Ecosystem Entry Point

When first gaining community interest, serverless was often talked about in terms of building complete end-to-end serverless applications. That is possible, mostly in the static and single page apps space. But more often than not, enterprises are beginning to use serverless for a range of specific workflow tasks, where tasks are handed off to a serverless environment to compute and then reintegrated into a larger workflow.

Scheduled cron jobs and image processing are two key examples. Another example that is becoming more common recently is to asynchronously update customer records.

For example, a customer signs up via an email tool integrated on a business’ website. That may then trigger three asynchronous serverless functions to operate:

• Add an entry to the CRM for that new email address
• Use Clearbit API to populate client data about that email address and add that to the CRM record as well
• Add the email address to a drip marketing funnel.

Horwood says this sort of example is becoming a mainstay for enterprise and a key first serverless and FaaS platform use case. Another is distributed web scraping, where StdLib lets a business do “massively parallelized DNS alignment” to instantiate as many functions as possible and cast a wide net to collect data on websites. That is, MapReduce-like tasks are being carried out in StdLib leveraging serverless, says Horwood.

These use cases reflect how many enterprises are using serverless not so much for external-facing applications, but for speeding up development time of internal workflows. Horwood says this is also a major way enterprises are using StdLib to create internal Slack workflows, more than external customer-facing bots.

Where Horwood sounds really excited about the potential of StdLib is in the way they have worked with Slack to date. A tutorial explaining how to build a Slack app with StdLib has become one of the most popular content pieces for Slack’s developer blog. Horwood sees this as indicative of the role StdLib can play in helping any emerging SaaS platform create a low barrier entry point to their developer ecosystem. In most cases, if a developer wants to build on a SaaS platform, they must handle all of the application server and scaling tasks of their integrated product before they can gain the benefits of becoming a partner. If SaaS platforms like Slack continue to use StdLib, the onboarding of new ecosystem partners can speed up and the costs for developers to create on an external platform are reduced. And what they build can go straight into the platform’s marketplace, as it would if they built the integration from scratch on their own.

Horwood is speaking on developer velocity at the Serverlessconf in New York City on Oct. 11. He also spoke earlier this year on service composition:

Feature image (left to right): StdLib’s Jacob Lee, Keith Horwood, Steve Meyer.