What opportunities are there for Perl in Cloudflare’s serverless environment?

What opportunities are there for Perl in Cloudflare’s serverless environment?

In Cloud Computing without Containers Cloudflare describes their take on a Serverless compute environment. Lets take a look at some of the specifics of what they did, consider what impact that’ll have on the industry, and speculate on how Perl could be used in such an environment.

How it works

Cloudflare is primarily a service that caches web sites on behalf of their customers. They have a need to run customer supplied code on their servers to facilitate custom filtering and URL rewriting. They took a look at doing this with virtual machines and decided it would be prohibitively costly to do it at the scale they needed. Even using a serverless architecture, like Amazon’s Lambda, wouldn’t improve the situation enough.

The answer they came up with was to leverage Chrome’s V8 JavaScript engine. Being designed for a web browser, it had code isolation features that Google calls Isolates. They link variables and their associated code that is permitted to modify them. Isolates were intended to separate Javascript from site A from being able to manipulate variables belonging to Javascript from site B, but the same mechanism can be used to separate code belonging to different customers, or tenants in cloud-speak. Cloudflare calls this tech Workers.

A consequence of this approach is that a single, persistent process can support code for a bunch of customers. The per-customer RAM usage is an order of magnitude less. The overall system ends up having fewer processes, and context switching among Isolates is lighter weight than context switching at the OS-level. Their architecture also doesn’t require swapping in a process to run a customer’s code. These combined result in switching between customers taking 5 milliseconds, instead of 500 milliseconds to 10 seconds.

See the article and other materials at Cloudflare to get a deeper understanding.

What this means

If the resource advantage, and thus economic advantage, they claim proves accurate, this is a big deal. Their approach has limitations, but it’ll handle most jobs targeting a serverless environment, and cost will compel taking this approach.

One of the big risks is their assertions about V8’s security, and confidence in how well it has been vetted and tested due to use in web browsers. Competing solutions have multiple layers enforcing multi-tennant isolation; the V8 approach barely has a “belt”, never mind “suspenders.”

If this takes off it could create a massive industry bias towards languages that are either JavaScript or compile to WebAssembly.

How about Perl?

The obvious approach to getting Perl into this environment would be to use WebPerl, which cross-compiles the C code of the Perl interpreter to WebAssembly. Then your code would run on the Perl interpreter running on the V8 JavaScript engine. This might work, but it would be far from efficient. The Perl interpreter should be part of the code designated as shared among tenants, but with this approach you’d likely end up with each tenant having their own copy. So a 10-line serverless function would carry with it the multi-megabyte overhead of the Perl interpreter.

An interesting project would be adding the equivalent of V8’s Isolates to Perl. Then a single Perl interpreter instance running under FastCGI could handle code for multiple tenants. Perls’s architecture might fight you, though on the other hand, Perl internals already have lots of metadata on memory structures, like whether an item is tainted. Replacing that slot with a UID, and tagging code chunks with UIDs might end up being fairly straight forward. (As always, a bit more complex than that.) It would be great to hear from a Perl (5 or 6) internals expert as to how feasible this might be.

One major problem with taking something like that to production is it won’t get the same level of security review and testing that a JavaScript engine that’s been running on millions of user’s browsers for years has gotten.

There are yet other pieces of the puzzle needed to complete a serverless environment, like the infrastructure to create an event loop and map a request to the right chunk of customer code. Things you’d need to build in this scenario that would likely be provided by Cloudflare’s Workers if you took the WebAssembly approach.

Isolates in Perl would be academically interesting, but I suspect the cost-benefit ratio won’t be there. It would be a huge project just to implement, never mind security audit. More importantly, the end product would be a custom serverless stack that you have to host in your own VMs. It wouldn’t address the desire to get your Perl code running on existing, commodity (if Cloudflare’s approach gets widely adopted) serverless infrastructure.

You might instead be able to get good enough results by using the first approach and taking steps to have the V8 engine treat the Perl interpreter as a shared library.

We’re curious to hear how you would approach this, and what experiments you would try as stepping stones towards getting Perl running on Cloudflare’s Workers.

Tom Metro is founder and Chief Consultant at The Perl Shop. He has been providing software consulting services since 1991 for companies ranging from startups to large enterprises, like Ticketmaster, Shopzilla, and Partners Healthcare. Currently specializing in agile software development using open source technologies, such as object oriented Perl, on medium to large scale web-based applications. Tom also contributes to open source projects and volunteers for local open source related organizations, such as Boston Perl Mongers and Boston Linux/UNIX user group.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.