Tomek on Software

StopGHG - A Free Carbon Footprint Calculator

Mon, 20 May 2024 00:00:00 +0000

Lately I’ve been exploring the climate space with an eye toward areas where technology can help companies do their part to protect it. One such area is carbon footprint calculation. As a result, today we are shipping StopGHG - a free, self-service carbon footprint calculator for companies.

Understanding your company’s carbon footprint is indispensable to remain competitive. Many regulatory frameworks, such as the CSRD directive in the European Union or the SEC Climate Rule in the US, require accurate carbon footprint reporting. Beyond legal requirements, companies worldwide that want to improve their image make their carbon footprint public as part of ESG (Environmental, Social, and Governance) reporting. Frequently, customers and partners ask for your carbon footprint to satisfy their own regulatory obligations.

Calculating your company’s greenhouse gas emissions is complex. StopGHG uses the global standards set by the Greenhouse Gas Protocol (GHG Protocol) and the current emission factors published by the Intergovernmental Panel for Climate Change (IPCC) to provide you with the most accurate results needed for compliance.

StopGHG is dedicated to helping the climate by providing companies like yours with the tools they need to do their part. Our free, easy-to-use, web-based carbon footprint calculator built on the GHG Protocol is a great companion on your sustainability journey.

Start your carbon footprint calculations today!

StopGHG - darmowy kalkulator śladu węglowego

Mon, 20 May 2024 00:00:00 +0000

Ostatnio zainteresowałem się zagadnieniami związanymi z ochroną klimatu, w szczególności obszarami, w których technologia może wesprzeć firmy w jego ochronie. Pierwszy taki obszar to wyliczenie śladu węglowego. W rezultacie, dzisiaj wypuszczamy StopGHG - darmowy kalkulator śladu węglowego dla firm.

Określenie śladu węglowego Twojej firmy jest niezbędne do opracowania strategii przewagi konkurencyjnej. Wiele ram regulacyjnych, takich jak dyrektywa CSRD Unii Europejskiej czy SEC Climate Rule w USA, wymaga od firm regularnego raportowania śladu węglowego. Pomijając wymagania prawne, firmy dążące do poprawy swojego wizerunku upubliczniają swój ślad węglowy w ramach raportów ESG (Environmental, Social, Governance). Często też klienci i partnerzy Twojej firmy oczekują danych związanych ze śladem węglowym w celu zaspokojenia własnych potrzeb raportowania.

Wyliczenie emisji gazów cieplarnianych jest skomplikowane. Dlatego zbudowaliśmy darmowy kalkulator śladu węglowego StopGHG, który wykorzystuje globalne standardy zdefiniowane przez organizację Greenhouse Gas Protocol (GHG Protocol) oraz aktualne współczynniki emisji określone przez Intergovernmental Panel for Climate Change (IPCC) w celu dostarczenia wiarygodnych wyników zaspokajających wymagania prawne.

W ramach StopGHG, naszą inspiracją są działania zmierzające do poprawy klimatu, w tym dostarczanie firmom narzędzi potrzebnych w tym procesie. Nasz bezpłatny, internetowy kalkulator śladu węglowego jest intuicyjny i łatwy w użyciu. Jest oparty na standardach GHG Protocol i stanowi doskonałe narzędzie ułatwiające drogę Twojej firmy do zrównoważonego rozwoju.

Rozpocznij obliczenia śladu węglowego już dziś!

Launching GetGaap - a financial API for your app or spreadsheet

Mon, 08 Apr 2024 00:00:00 +0000

Today, I am launching GetGaap, a financial API for your app or spreadsheet. Using GetGaap, you can access data from the financial reports companies file with the Securities and Exchange Commission (SEC) in the US.

GetGaap provides access to 100+ million financial facts from 18+ thousand companies filed using forms 10-K, 10-Q, and others, directly from the SEC EDGAR system. You can access quarterly or annual point-in-time data, or a quarterly or annual histogram for a specific metric.

As an investor or financial researcher, you can import the data directly into a spreadsheet to build financial models, custom indices, or charts.

As a developer, you can access the financial data using convenient HTTP APIs serving JSON or CSV. For advanced use cases, GetGaap also supports SQL access.

The best way to get familiar with the platform is to run through the three-minute tutorial to build your first financial chart in Google Sheets.

How does GetGaap work?

The Securities and Exchange Commission (SEC) operates the SEC EDGAR system that allows companies to file their 10-K, 10-Q, and other financial statements. SEC is then required by law to make this information available to the general public. It does so by exposing a web interface as well as a set of rudimentary APIs. The APIs satisfy the requirement for public disclosure but are not intended for consumption at scale.

This is where GetGaap comes in. It provides an API layer on top of the data exposed by SEC EDGAR that is more suitable for direct consumption from apps and spreadsheets.

This is how GetGaap functions at the high level:

Every night, it imports all financial statements ever filed in SEC EDGAR as one large ZIP file containing xBRL data. This contains 100+ million financial facts from 18+ thousand companies and represents the then-current source of truth.
The large ZIP file is uploaded to AWS S3.
Processing of the ZIP file is sharded into 40 chunks, each executed in parallel in AWS Lambda.
Each shard unzips the relevant portion of the ZIP file, parses the data, and uploads it to Google BigQuery.
After all the shards have completed processing, certain static aggregates are calculated and stored in AWS S3, and the snapshot of all the data is “committed” as current.

From there, the HTTP API exposed by GetGaap runs queries in BigQuery in response to data requests.

While this may sound like a system with a lot of moving parts, its implementation was hugely accelerated by building GetGaap on top of 47chapters/letsgo, an OSS boilerplate architecture for AWS. It comes ready with application components like API, Website, workers, and queues, to cut months of development time.

Enjoy!

Letsgo - a starter kit for starting startups

Mon, 20 Nov 2023 00:00:00 +0000

New SaaS businesses cut corners that are hard to fix later. Today I am shipping LetsGo, an open-source project to address this issue: 47chapters/letsgo.

When you start a new SaaS application, you often optimize for the time to market. In the process, many reduce the near-term work while creating technical debt. If your business shows signs of traction, the time comes to address this debt. However, making architectural changes with customers in production is expensive. It is like changing brakes on a running train. At one point, many early-stage SaaS businesses find themselves in a situation where it is hard to make progress and evolve the product.

The root of the problem is the lack of a proper foundation to build a new SaaS application. On the operations side, AWS provides a fantastic set of building blocks, but you still have to write a lot of code to combine them all together and engineer a proper devops experience. On the product side, many of the SaaS applications solve the same problems over and over:

marketing site,
management dashboard,
HTTP API,
worker behind a queue,
database,
authentication,
payment processing,
devops story.

All of this boilerplate work stands in your way to working on the core product, so it becomes a natural target for cutting corners.

This is where LetsGo comes in.

LetsGo provides the architecture and the tooling that will put your startup on a solid foundation from day one.

It helps you save months of work leading to the launch while allowing you to focus on the essence of your product. The day you let the first customer in, you have no technical debt. As you grow, you can continue focusing your resources on what matters most: your customers and product.

LetsGo does it by providing a prescriptive architecture implemented with a modern set of technologies and robust operational tooling for managing your app in AWS.

On day one you start with more than most startups build in the first two years.

LetsGo gives you:

An application architecture with a web, HTTP API, worker, and database components, all wired up and ready to go.
A devops CLI that helps you set up CI/CD and manage several deployments of your app in AWS to help you segregate your production and development workloads or to support dedicated deployments for your customers.
Integration with Auth0 to authenticate your users and protect your APIs.
Integration with Stripe to automate your billing and subscription lifecycle management.
Integration with Slack to keep current with new customers signing up and subscriptions being paid.
A flexible tenancy and user model with membership management and invitation flow.
A set of modern yet robust technologies including Next.js, Node.js, and Typescript that make your days exciting and the nights boring.
LetGo is open source under MIT, so there is no vendor lock-in and you can always see what makes it tick.

I want to welcome you to explore how LetsGo can help you at https://github.com/47chapters/letsgo.

Let’s go!

Create a contact sheet photo collage poster

Thu, 14 Sep 2023 00:00:00 +0000

Creating a photo collage from your digital photos should be easy, right? It is unless you have very specific needs for how you want your collage to look like.

In my case, I have just returned from a year-long, around-the-world travel with 25,000+ pictures, and I wanted to arrange some 500 of them in a contact-sheet-like 30”x20” photo collage poster to hang on a wall. I wanted each picture to have a custom description and the GPS location where the picture was taken, extracted from the EXIF metadata.

When I started looking for a solution, no tool out there did exactly what I wanted, so I created my own: tjanczuk/mkcollage. Here is a sample of what the tool can create, with a few pictures from south of the equator:

What can you do with tjanczuk/mkcollage?

Use image files from your local drive to create contact-sheet-like, poster-size photo collages.
Export the final collage image as PNG, JPEG, or WEBP.
Set the desired collage width and individual picture height.
Annotate images on the collage with custom descriptions or based on EXIF information in the image.
Select images to include or order images based on image metadata, including EXIF information (the example above used a filter that only included images with latitude below 8 degrees South).
Rich customization using CSS.

Check out the documentation for details, and happy collaging!

Scalable CRON job executor for AWS Lambda

Thu, 27 May 2021 00:00:00 +0000

Running scheduled jobs at scale in the cloud is an interesting problem to solve. In this post I will describe an architecture we came up with at Fusebit that allows us to execute a large number of arbitrarily scheduled CRON jobs in AWS using Lambda, SQS, and CloudWatch.

The problem

Say you are building a large-scale, multi-tenant system where tenants define programmatic jobs to be executed in the cloud on a given schedule. You have a large number of such jobs, each with a potentially different execution schedule.

In the context of Fusebit, we needed a solution to this problem to enable customers of our integration platform to implement and run integration logic on a given schedule. For example, to export new leads from HubSpot to MailChimp every night, or to send a status report based on Jira tickets to Slack every hour.

The non-scalable CRON solution

We have decided to use AWS Lambda to run the customer-provided logic. While Lambda is not an ideal compute layer for all types of integration workloads, in our case it satisfied the functional requirements while providing a convenient way of scaling and isolating workloads of multiple tenants.

Once the infrastructure was in place to run the customer code, the next step was to trigger it on a customer-defined schedule. There are many ways to trigger execution of a Lambda function in AWS. One of them uses scheduled CloudWatch Events. On the surface, CloudWatch Events meet all the requirements. You can define an arbitrary CRON schedule following which a CloudWatch Event will be triggered, and attach a specific Lambda function to execute in response.

The problem with using CloudWatch Events in a highly scalable system is the limits. Per AWS region and account, one can only support up to 100 scheduled events (as of this writing), which was not sufficient to support the needs of a highly scalable multi-tenant system. We clearly needed a different approach.

The scalable CRON solution

After looking around for the right building blocks, a lesser known feature of Amazon SQS drew our attention: SQS delay queues. The feature enables a message published to an SQS queue to remain invisible to consumers for a configurable time, up to 15 minutes.

Equipped with this new tool, we have split our CRON processing pipeline by adding SQS delay queues in the middle, and using two additional Lambda functions: a scheduler and an executor.

First, we defined a single scheduled CloudWatch Event that triggered the scheduler Lambda function every 10 minutes, starting at minute 8 of an hour. So the scheduler Lambda was running at minute 8, 18, 28, 38 etc. of every hour.

The purpose of the scheduler Lambda was to consider all scheduled jobs in the system (possibly millions), and select those that were due for execution in the subsequent whole-10-minute interval. For example, if the scheduler Lambda was running at 3:18, it would determine all scheduled job executions that need to occur in the 3:20-3:30 time span. The scheduler Lambda would then enqueue those job definitions to the SQS queue, setting the delayed delivery for each to correspond to the exact intended moment of execution of that job. For example, if a job was to run at 3:24, the scheduler Lambda running at 3:18 would enqueue that job to SQS setting the delayed execution to 6 minutes. The granularity of delayed execution allows the execution time to be set with 1 second precision.

Lastly, the executor Lambda would consume messages from SQS as they are released following their delayed delivery settings. The executor Lambda would then invoke the appropriate customer-defined Lambda function to execute the intended logic.

With this architecture, we were able to use a single CloudWatch Event to schedule a very large number of jobs and support our scheduled integration needs.

Shameless plug

This is just one of many interesting technical problems we are continuously solving when building the integration platform at Fusebit. If you enjoy working on developer-centric products and cracking this type of technical problems on a daily basis and in a good company, we are hiring!

Embedded NPS widget with webtask.io

Fri, 31 Aug 2018 00:00:00 +0000

Net Promoter Score (NPS) has been an established tool for measuring customer loyalty since 2003. It is based on asking your customers a single question: how likely are they to recommend your product to others? Research shows that the answer is correlated to the future success of the product.

In this post I will show how you can create a free NPS widget, complete with UI, backend storage, and reporting using Auth0 Webtasks, and embed this NPS widget with one line of HTML into your web application, single page app, or a blog post.

Taking the high road

Start by installing and initializing wt-cli if you have not already:

npm install -g wt-cli
wt init

Next, create your free NPS widget hosted as a serverless endpoint on webtask.io:

wt create -n nps-blog \
  -d webtask-compiler \
  --meta wt-compiler=webtask-compiler/nps <<EOF
EOF

You will get back a URL we will call {webtask_url}. This is the endpoint of your NPS survey.

Next, use an iframe to embed your NPS survey in your web site, single page app, blog post, or wherever you host your HTML:

<p>How likely are you to recommend MyProduct to your friend or colleague?</p>
<p><iframe src="{webtask_url}" style="border: 0; height: 1em; width: 11em;"></iframe></p>

Next, sit back and watch as NPS survey results pour in when your customers visit your site and share their opinion:

Lastly, to view the results of your NPS survey, navigate to {webtask_url}/stats. You will get back a JSON document with the histogram of all answers as well the number of NPS promoters, detractors, passives, as well as the overall NPS score:

{
  "histogram": {
    "0": 0,
    "1": 0,
    "2": 2,
    "3": 0,
    "4": 0,
    "5": 1,
    "6": 0,
    "7": 2,
    "8": 4,
    "9": 5,
    "10": 6
  },
  "count": 20,
  "avg": 8.05,
  "nps": {
    "promoters": 11,
    "passives": 6,
    "detractors": 3,
    "score": 40
  }
}

Congratulations on your NPS score of 40%! MyProduct has a bright future.

Test it out

Now that you experienced creating your own, embeeded NPS widget, I need to ask you a crucial question:

How likely are you to recommend webtask.io NPS widget to your friend or colleauge?

If you answered 9 or 10, you have a moral obligation to tweet this blog post with a nice comment.

To check the results of the survey above, click here.

Wait. What, how?

Your NPS widget is an HTTP endpoint created with webtask.io. Webtask.io is a sample, freemium deployment of the Extend platform, a powerful solution for extending and customizing SaaS platforms.

The NPS webtask responds to HTTP GET requests by serving HTML representing the survey, allowing users to click to enter their answer, and making an HTTP POST request back to itself to register that answer. Survey results are stored in webtask storage, and disambibuated between individual users using an HTTP cookie randomly generated and set if not already provided on the HTTP POST request. This is of course not a waterproof way of ensuring one user can only provide a single answer (since cookies can be purged or anonymous sessions used), but in many situations more than adequate. Cookies also allow the widget to present the user with the last answer they provided on subsequent visits to your site, and change that rating without double-counting.

The last function of the widget is to respond to HTTP GET requests to {webtask_url}/stats with a JSON document that represents the statistical results of the survey, including the NPS score.

If you are interested in the technical details of the implementation, as well as many other cool things you can do with Auth0 Webtasks, check out tjanczuk/wtc.

Shameless plug

If you enojoy the flexibility of Auth0 Webtasks, you may be interested in the commercial product we’ve built on top of this technology: Extend. Extend removes friction from the customization and integration of SaaS platforms by providing an embedded scripting experience, “serverless wehbooks”. Check it out!

Build your own Twitter scheduler

Thu, 05 Apr 2018 00:00:00 +0000

Twitter is great for marketing your product or personal brand, but it has one disadvantage: you must actually tweet.

In the next 2 minutes I will show you how to create a simple yet flexible (and free) Twitter scheduler that allows you to set up your tweets along with a tweeting schedule ahead of time. You can then focus your attention and energy elsewhere, while Auth0 Webtasks dilligently follow your tweeting directions.

Your own Twitter scheduler

Start by installing and initializing wt-cli if you have not already:

npm install -g wt-cli
wt init

Next, create your intial tweet schedule in YAML in the buffer.yaml file. You can change the schedule later:

cat > buffer.yaml <<EOF
tweets:
  - text: "Check out this free Twitter scheduler that uses @auth0_extend and @webtaskio: https://tomasz.janczuk.org/2018/04/build-your-own-twitter-scheduler.html\n\n#nodejs #serverless"
    media: https://tomasz.janczuk.org/assets/images/b_1.jpg
    schedule: 
      - 4/4/2018 09:00 PDT
EOF

(More on the format later).

Last step: create a CRON job on Auth0 Webtasks that will run every 15 minutes, inspect your schedule, and send out any due tweets:

wt cron create buffer.yaml -n buffer \
  --schedule 15m \
  --no-auth \
  -d webtask-compiler \
  --meta wt-compiler=webtask-compiler/twitter \
  -s TWITTER_CONSUMER_KEY={YOUR_TWITTER_CONSUMER_KEY} \
  -s TWITTER_CONSUMER_SECRET={YOUR_TWITTER_CONSUMER_SECRET} \
  -s TWITTER_ACCESS_TOKEN_KEY={YOUR_TWITTER_ACCESS_TOKEN_KEY} \
  -s TWITTER_ACCESS_TOKEN_SECRET={YOUR_TWITTER_ACCESS_TOKEN_SECRET}

(You must substitute your own Twitter credentials which you can get from here).

That’s it. Sit down and watch your tweets beeing sent out.

Wait. What, how?

Your Twitter scheduler is an Auth0 Webtask CRON job. It runs every 15 minutes (or whetever frequency you choose). It inspects the tweeting schedule you set via the YAML, and sends out any tweets that became overdue since the last time the CRON job ran. The CRON job stores the time it executed last as well as the status of the most recent tweets that were sent in webtask storage. All this logic is implemented in a webtask compiler which is defined in the webtask-compiler NPM module. In addition to implementing the actual tweeting logic, the compiler allows the use of a custom DSL (the YAML with tweeting schedule in this case) to be used as the script of the webtask.

For a gentle introduction of the powerful webtask compiler concept, check out Raymond Camden’s post.

Updating the Tweet schedule

Given that the YAML is the source code of your webtask, you can simply use the Webtask Editor to modify it. Run

wt edit buffer

which will bring up the webtask editor allowing you to change the YAML.

Make any changes, save, and you are done!

This is what you can do in the Yaml:

 tweets:
  - text: "I just installed a free Twitter scheduler that uses @auth0_extend and @webtaskio.\n\nCheck out https://github.com/tjanczuk/wtc#twitter-scheduler\n\n#nodejs #serverless"
    media: 
      - https://tomasz.janczuk.org/assets/images/b_1.jpg
      - https://tomasz.janczuk.org/assets/images/b_2.jpg
    schedule: 
      - 4/8/2018 09:00 PDT
      - 4/8/2018 15:00 PDT
  - text: "You can do amazing things with webtask.io!\n\n#nodejs #serverless"
    media: https://tomasz.janczuk.org/assets/images/b_2.jpg
    schedule: 4/5/2018 12:00 PDT

The top level object must contain the tweets array with elements representing individual tweets.
Each tweet must contain the text of the tweet, and a schedule at minimum. It may also contain the media to attach to the tweet.
The schedule is a single date or an array of dates that tweet will be sent on. You can use any format here that is accepted by Node’s new Date(...) constructor, like the simple one shown above. It is a good idea to specify the time zone.
The media element, if present, is a single URL or an array of up to 4 URLs. These must be publicly accessible URLs that serve the media (typically an image) to attach to your tweet, with correct Content-Type header.

Get the status

You can easily check the status of your Twitter scheduler by navigating to your webtask’s URL in the browser:

The schedule element shows the JSON representation of your YAML tweeting schedule, or an error if the YAML could not be parsed. The plan element specifies the Tweets that would be sent if the CRON job were to run now.

The last part of the status specifies the 20 most recently sent tweets:

For each tweet, the result element tells if the tweet was sent successfuly or not, and the unique tweet id in case you want to automate further processing.

Force the execution, now

Instead of waiting for the CRON job to execute, you can force execution of your schedule. This is done by simply navigating to the webtask URL with a ?run query string appended, e.g.:

https://{your_container}.sandbox.auth0-extend.com/{your_webtask}?run

As a result, all the overdue tweets since the last execution (either by the CRON job or manually) will be sent.

Shameless plug

How to build your own serverless platform

Sun, 25 Mar 2018 00:00:00 +0000

In this post I will provide a blueprint for building your own serverless platform, based on the lessons learned from working on Auth0 Extend in the recent years.

Why would you want to build a serverless platform?

The serverless (Function-as-a-Service) computation model is a powerful complement to the webhook-based extensibility of a SaaS platform.

In the previous post I proposed that Serverless webhooks will revolutionize the SaaS by removing friction from customizing SaaS platforms and integrating external systems.

Serverless webhooks benefit end users, sales teams, and ultimately make the SaaS platform more successful.

A growing number of SaaS platforms embrace the serverless webhook model. Twilio Functions and Netlify Functions are two recent examples.

If you want to enable the serverless webhook model in your SaaS, you may be considering building your own serverless platform to support it. The rest of this post provides one design informed by the experience of building Auth0 Extend.

Requirements

In order to complement a webhook-based extensibility model of your SaaS product, your serverless platform will need to meet this minimum set of requirements:

It must offer a core concept of a function as a unit of custom business logic that runs when a webhook in your SaaS platform is triggered.
It must support adequately rich programming environment. In this post, I will assume that Node.js with the ecosystem of all public NPM modules (over 500k) is sufficient.
It must offer an API surface that allows managing functions as individual webhooks.
When a webhook event is triggered in your SaaS platform, you must be able to execute the corresponding function to handle the webhook HTTP request.
The serverless platform must provide a mechanism to isolate the execution of functions of eache tenant, since each tenant can author their own set of functions with untrusted and potentially malicious code.
The latency of execution of your serverless webhooks must be acceptably small and predictable. In particular, the cold and warm latency cannot vary too much - this is particularly important if they execute as part of a UI interaction with the end user of your SaaS.

In practice, your specific scenario may have many more requirements. The design blueprint in this post only addresses the ones above.

Let’s start designing a serverless platform from the bottom up. We will use basic building blocks so that the design is relatively easy to port to a variety of environments.

Compute

Execution of functions requires basic computing resources: CPU, memory, disk, and network. We will then start with an empty VM.

We will tackle scalability later. Right now let’s focus on the components running within the VM.

Proxy

Serverless webhooks as well as APIs that allow their management are both exposed over HTTP. HTTP endpoints will be the main entry into the functionality of our VM, and an HTTP proxy is a component that will decide how to process a particular request.

You can use a variety of technologies for the proxy: HAProxy, Nginx, all the way to writing your own.

Management APIs

At a minimum, the management APIs of our serverless platform need to allow for basic CRUD operations on serverless webhooks. You need to be able to create, update, read, delete, and list available webhooks. So you need a specialised web server component implementing these APIs. The proxy must be able to route the management API requests to this component.

Management APIs themselves are stateless. Any durable representation of a serverless webhook, most notably its code, must be stored outside of the context of this component.

Persistent storage

Persistent storage is required to maintain any durable state representing a serverless function. At a minimum, this is the code of the function itself with a manifest of module dependencies. Depending on your scenario, this state may also include additional configuration that the code requires at runtime, like API keys, connection strings, or other metadata that controls the execution of the function.

The essence of the Function-as-a-Service paradigm is that individual functions are small units of business logic, unlike large monolithic web apps of the days past. Many standard databases or storage solutions should be a good fit to store this data. MongoDB, DynamoDB, MySQL should all fit the bill.

Now that you can manage your serverless functions via HTTP APIs, let’s move on to the interesting part - executing them with low latency and adequate isolation.

Execution model: the theory

While you could say that every function is running completely isolated from other functions, it is beneficial to introduce a level of indirection.

Consider a concept of a container which denotes an isolation boundary for executing code. Any two functions running in distinct containers are guaranteed to be isolated, while any two functions running within the same container may, in fact, share the same process, address space, and therefore in-memory state. Such design has enough flexibility to support the isolation needs of a multi-tenant SaaS platform, at the same time enabling optimizations across serverless webhooks of a single tenant.

Let’s then assume a model in which several serverless functions can be grouped together to run within the same isolation boundary of a container. They can share the state with one another (e.g. DB connection pool) while maintaining logical isolation of the business logic. Such taxonomy of containers and functions must be supported by the management APIs described above, which is straightforward to solve. The interesting challenges lie in function execution mechanics.

So, let’s design it.

Execution model: the practice

An HTTP request arrives as a result of a webhook being triggered in your SaaS. In response, the serverless platform must run a Node.js function, and do so with low latency and adequate isolation from other functions.

Given such a request, a naive, CGI-like implementation would create an isolated execution environment, e.g. one using Linux containers and namespaces, or Windows job objects, with some additional measures of security applied on top. It would load the code of the function from the persistent storage, fetch the module dependency manifest, and provision those modules. It would then execute the function in this environment, return results to the caller, and clean up after itself.

This is a great story, especially that it affords the end user ample time to go to lunch and file their tax return.

In most scenarios, the latency introduced by the overhead of creating isolated execution environments for every request is not acceptable, even in the lightweight world of Linux containers.

One solution to this problem is to reuse containers to process multiple requests of the same tenant, similar to how FastCGI improved over CGI. Container reuse will reduce warm latency. To enable processing of multiple requests by the same container, the protocol over which these requests are passed to the container must be defined. It is convenient for that protocol to be HTTP, as that will allow the VM-level proxy to simply reverse proxy serverless webhook execution requests to the container associated with the tenant who wrote the serverless webhook.

In order to pull this design off, we need a component that will manage the lifetime of the containers and their association with a specific tenant. Let’s call this component a container handler.

When a request to execute a specific serverless webhook arrives at the proxy, the proxy consults the container handler to obtain the address of the specific container that should handle this request. If a container assigned to a specific tenant is already running, the container handler promptly returns its address to the proxy which will in turn reverse proxy the request to that container.

A problem will arise when the proxy receives a request that needs to execute in a container that is not yet running. In this case, the container handler creates a new container and provision the requested serverless function within it based on the data in the external storage. This can incur a substantial performance penalty.

Cold startup latency is one of the challenges of serverless platforms. How do you create lightweight, isolated execution environments and provision them with necessary components quickly?

We don’t want our cold startup latency to be substantially different from warm latency. Let’s go back to the drawing board.

Reducing cold startup latency, part 1

A lot of the work related to starting up a new container is generic and can, therefore, be front-loaded. Let’s have the container handler maintain a pool of pre-warmed containers ready to be assigned to tenants as necessary.

With this design, when a request arrives on behalf of a tenant that does not yet have a running container, the container handler picks up one unassigned container from the pool, assigns it to the tenant for life, and notifies the proxy where to route the request. We have now cut out a substantial part of the container initialization time from the cold startup path: the creation of a container, and starting up of a process that runs a mini-HTTP server within it.

What work still remains to be done in the cold startup path? The container handler must obtain the code of the serverless wehbook from Storage and provision it within the container, along with the module dependencies. Neither the function code or the module dependencies are known at the time the generic container is created, so they need to be provisioned lazily when a message arrives. Anyone implementing Node.js applications knows that the size of the module dependency closure (the overall size of the node_modules directory) can grow rather quickly and adversely impact provisioning time.

We are not done with the cold startup latency problem yet. How do we solve the module provisioning problem?

Reducing cold startup latency, part 2

If reducing startup latency is an objective, running npm install to provision Node.js modules based on the dependency manifest of a serverless webhook while on the hot path of message processing is just an obvious no-go. The process can take arbitrarily long depending on how many modules need to be pulled from NPM and whether any build steps are necessary.

Doing so during serverless webhook provisioning via the management APIs will be a much more acceptable solution, as development usually has less strict latency expectations compared to the runtime. Given that, we are going to front-load building of the module dependency closure of a serverless function by executing it during the management API call that creates the function. This is great, but there is more.

Another interesting aspect of this problem is related to duplicated effort. If several functions have a dependency on the same module, will we really need to build this module anew each time? After all async@2.6.0 is async@2.6.0 is async@2.6.0, regardless how many serverless functions depend on it. So let’s try to come up with a design that further optimizes around reuse of pre-built Node.js modules across different serverless webhooks, even when they are created by different tenants.

When a management API is called to create or update a serverless webhook, its module dependencies are inspected. For each dependency (e.g. async@2.6.0) that is not yet available in Storage in a built form, the management API schedules it to be built with the module builder.

The module builder is a background worker process running on a separate VM that will receive its work through a queue mechanism using technologies like AWS SQS, RabbitMQ, or similar. Its job is to receive a module build request, run npm install to build this module in the same environment in which it will eventually be used at runtime, capture the entire, built dependency closure (the entire node_modules folder), tar, zip, and put in Storage.

Since every module is considered for building individually, every version of every module will only be built once in the system as a whole. Given that, over time the latency of creating serverless webhooks via the management APIs becomes negligible, since all common module dependencies have already been built before.

At runtime, when the container handler prepares an unassigned container for execution of a specific serverless webhook, it first obtains the code of the function from Storage and then proceeds to provision modules the function depends on. This is done by obtaining the pre-built modules from Storage, unpacking them on the local volume on the VM, manufacturing a synthetic node_modules directory with symlinks to the read-only filesystem holding the physical module on the host, and attaching a volume with this directory to a specific container. This makes all module dependencies available to the serverless webhook code running within the container.

The added benefits of storing pre-compiled modules on the host VM’s filesystem and sharing them read-only with all containers and functions that require them include:

reduction of storage requirements,
reduction of network bandwidth to download the modules,
and further reduction of cold startup latency.

For serverless webhooks for which module dependencies had already been downloaded by previously running functions, even by other tenants, the container handler does not even need to reach out to Storage.

With the design described above, warm and cold startup latency of serverless webhooks is very similar, which is an important consideration in a range of SaaS extensibility scenarios.

Scalability and reliability

What we have designed so far is a single VM solution that provides a self-contained, multi-tenant platform for managing and executing serverless webhooks. So what happens when they come, and the traffic explodes?

Given that one VM is self-contained and can function independently, you can accommodate increasing throughput by scaling out the number of VMs and putting a proxy in front of the cluster. If you use a flexible scaling technology like AWS’s Auto Scaling Groups, the size of the cluster can be dynamically adjusted as the load changes.

In the current design, the VMs are independent of each other. This is hugely helpful in increasing the overall reliability of the deployment. Lack of state shared between VMs means they can crash at any time (and they will, the frequency of which depends on your choice of specific technologies and the underlying platform) without affecting the remaining VMs. The Auto Scaling Group, or a similar solution, can subsequently replace a failed VM with a new one.

This reliability advantage has a drawback, however. A container for a given tenant may exist on every VM at the same time. If you want to support an increasing number of tenants running code concurrently, this can only be accommodated by scaling up - increasing the capacity of individual VMs in the cluster. This works up to a point - beyond a certain threshold of density you will need to consider adding smarts to the container handler component to be able to handle placement of a tenant’s container on just a subset of VMs in the cluster. This would require a technology to efficiently share a synchronized routing table data across the cluster, e.g. Zookeeper, etcd, or a similar solution. Such design is more complex and beyond the scope of this post.

Are we done yet?

Yes and no. After you have implemented the design above, you have a functioning, multi-tenant serverless platform that can power the serverless webhooks of your SaaS. Your CPO is happy. Your COO’s nightmare begins.

The system is up and running. The easy work is done. Now you need to run this system at 99.9…% availability, with 24/7 uptime, and zero-downtime upgrades.

The operations and devops of a serverless solution like the one described in this post is a project in itself, in many respects just as complex as the solution. Stay tuned for another post based on our experiences building and operating Auth0 Extend to those high operational standards.

Serverless webhooks to revolutionize the SaaS

Thu, 08 Mar 2018 00:00:00 +0000

In 2007, Jeff Lindsay introduced webhooks in his Webhooks to revolutionize the web article. Since then, webhooks have become the dominant mechanism for exposing events from web services. Fast forward to 2017, and a new, better pattern started to emerge: serverless webhooks.

Webhooks (2007)

This is how Jeff defined webhooks in his iconic article from 2007:

Webhooks are essentially user defined callbacks made with HTTP POST. To support webhooks, you allow the user to specify a URL where your application will post to and on what events. Now your application is pushing data out wherever your users want.

This is a very elegant and powerful concept. It allows for a clean, protocol-based decoupling of the system that exposes an event from the system that processes that event. It is flexible enough to allow for a wide range of scenarios, including system integration, data transformation, or customization of behavior. It also embraces the asynchronous nature of interactions between web services.

Using webhooks requires setting up and running another web service. Servers, devops, monitoring, SSL, uptime, failover strategy, etc. For years this has been a small price to pay given the benefits webhooks offered, and the lack of a better alternative. However, given cloud computing advances over the last decade, there is now an opportunity to further improve on this core concept.

Serverless webhooks (2017)

Fast forward from 2007 to 2017, through IaaS, PaaS, all the way to FaaS (Function-as-a-Service, aka serverless). The essence of the serverless computing paradigm is to organize your logic into small units of computation you can refer to as functions. A single function maps very well to a single webhook.

Reacting to web service events with arbitrary business logic is the core value of webhooks. Imagine an experience where users of a SaaS platform can focus on implementing this business logic as a function without having to run a service to expose it as an HTTP endpoint:

There are several immediate advantages such a serverless webhook model brings for a SaaS platform compared to the original webhooks:

The users of a SaaS platform benefit from a dramatically improved experience of implementing custom event logic and the reduction of time to market: users can focus on the business logic without dealing with issues related to running a web service.
The sales engineers of a SaaS company are enabled to rapidly prototype custom integrations with little effort, shortening the sales cycles and highlighting the power of the platform.
The support team of a SaaS organization is equipped to better serve the customers since they have full insight into the implementation logic of the function handling the event.
Last but not least, the SaaS platform itself is using cutting-edge extensibility technology based on the latest cloud computing trends, which sets it apart from the competition.

Ten years after the introduction of the webhook concept, this is what Jeff Lindsay says about the serverless webhook pattern:

There are many existing implementations of this serverless webhook paradigm in practice. The Twilio Functions and Salesforce Apex are good examples. Until recently, these advanced solutions have been reserved for the SaaS platforms run by sophisticated, technology-savvy organizations.

Serverless webhooks for your SaaS

If you are operating a SaaS platform that could benefit from serverless webhooks, you may ask yourself what it takes to implement them. In the How to build your own serverless platform post, I describe an architectural blueprint for building a serverless webhook solution for your own SaaS platform, based on the lessons learned from the Auth0 Extend product in Auth0.