Cloudflare Platform Week Recap – Workers

This is my second installment of coverage on Cloudflare’s Platform Week, held from May 9th – 16th. In my prior post, I focused on the announcements related to new data products. These included several exciting new offerings to round out capabilities available to developers to store, process and distribute data. Highlights were a new relational database (D1), their R2 object store moving to GA (with pricing), a publish-subscribe system (Pub/Sub) and a time series database (Analytics Engine). Each of these provides developers with another tool for building modern Internet applications to run in a decentralized fashion across the edge of Cloudflare’s network. These products are also being monetized, which should start contributing to revenue going into 2023.

For this next post, I will focus on the announcements related to their core development runtime, the Workers engine. Cloudflare announced a number of key features during Platform Week that will make Workers easier to extend, combine and configure. These product improvements should open up Workers to more developers and application use cases. Additionally, they have removed any philosophical adoption argument based on perception of being a proprietary system.

Cloudflare has set an ambitious goal to increase the utilization of the Workers platform from its current 450k developers to a million by end of 2022. With all of the next features introduced during Platform Week, Cloudflare has certainly broadened the developer appeal and expanded the addressable application use cases. With 15% of customers paying for Workers in 2021, I think these new capabilities pave the way for an even larger revenue contribution over the next year.

Let’s take a look at the major announcements made around the core Worker product capabilities during Platform Week.

Open Source

Cloudflare will be open sourcing the Workers runtime under the Apache 2.0 license. This is an interesting move. The Apache 2.0 license is a permissive, free software license. It poses no restrictions on how the software can be used, beyond requiring the copyright notice be preserved. This differs from copyleft licenses that require open sourcing of derivative works. This means that other parties could take the Workers source, modify it and even run a commercial service using it.

We should keep in mind that parts of the Workers runtime are based on other open source projects, like the V8 JavaScript engine developed by the Chromium Project for Google Chrome. Recall that when Cloudflare first built the Workers product, they chose to build it on top of the V8 engine, rather than create their own proprietary framework. This saved the Cloudflare engineering team a lot of work, allowing them to focus on customizing aspects of V8 for their environment (like additional security, performance enhancements and supporting services). Now, all those enhancements will be available for others to inspect and use.

On the surface, this sounds risky, but I think it is a smart move for a couple of reasons. First, this obviates customer concerns around potential lock-in. If Cloudflare were to ratchet up pricing or go out of business, customers could choose to run their Workers code in their own environment. Second, it allows engineering organizations to set up local runtime environments on their machines or spin up a hosted development environment. This is a common practice and provides more convenience for a large team than trying to share a development instance on Cloudflare.

On the flip side, a competitor could use the Workers open source to run a Cloudflare look-alike service or customers could invest in their own server infrastructure to self-host. However, I think this risk is limited. What makes the Workers runtime powerful is Cloudflare’s distributed edge network, enabling code to execute in parallel worldwide and serve customers at the location nearest to them. There wouldn’t be much advantage in running Workers from a centralized infrastructure.

For these reasons, I think the advantages of open sourcing Workers code far outweigh any risks. I can see large organizations (like new customers Meta and Atlassian) appreciating the ability to host their own local Workers environment for shared internal development and testing. Additionally, this reduces concerns about lock-in, as a worst case could involve the organization self-hosting their Workers code if they needed to move off of Cloudflare.

In the past, software companies based on open source projects made for bad investments. They faced high competition, both from other companies copying their work and from cannibalization by customers deciding to run the open source software themselves. However, I don’t think this move makes Cloudflare an open source software company. Plus, all the services around the Workers runtime are still proprietary and revenue generating.

Beyond mirroring Cloudflare’s distributed hosting infrastructure, choosing to run an open source project themselves is not a practical cost savings tactic for an enterprise customer. Operating an open source project, like a database or application runtime, requires staffing DevOps personnel to install, configure and manage the services. These staff are expensive. Additionally, they are unlikely to be as knowledgeable about the open source package as the maintainers, resulting in misconfigurations that can cause wasted resources, downtown or security holes.

All-in-all, I think open sourcing Workers is a bold move by Cloudflare. It should be received positively by customers and may push some larger engineering organizations off the fence, driving incremental adoption. Further, by open sourcing the software, Cloudflare may pick up some free contributions, bug fixes and security audits. Peer review should ultimately make for a better product. This will allow Cloudflare to focus on the services that surround their Workers environment, for which they will charge. Finally, making Workers open source doesn’t imply a reduction in Workers pricing or revenue, as it is still reasonable for a customer to pay Cloudflare to host and run the software.

Workers for Platforms

Related to the open sourcing of the Workers runtime, Cloudflare announced Workers for Platforms. This capability takes programmability and extensibility to the next level, by providing customization to the customers of Cloudflare’s customers. The idea is that a large customer that built a product or service on Cloudflare’s Workers platform could then allow their customers to create their own Workers code to handle specific events or address custom business logic.

Because the Workers runtime is serverless and multi-tenant, it is able to provide the isolation needed for untrusted developers to build and run their own scripts. This capability would apply to large Cloudflare customers, who have the staff to support this customization of their application by their customers. One of Cloudflare’s launch partners for this capability is Shopify. While Shopify provides its merchants with many options to configure their online stores, pricing rules and merchandising, some merchants need to introduce additional customization.

With Cloudflare for Platforms, Shopify is able to allow developers within the merchant organizations to deploy their own Workers scripts that add custom logic to their stores. These scripts could be called by Shopify’s platform when triggered by an action in the merchant’s store (like a purchase). The script would then be run in isolation on its own Worker, with the output shared with Shopify’s runtime.

To support this capability, Cloudflare is adding functionality to the Workers environment. First, they are providing customers with an API to invoke a script on a new Worker process. This provides the hook to run a developer’s custom code. Cloudflare also created a debugging capability, called a Trace Worker. This will receive execution event data about the processing of a different Worker. The developer can apply this to examine log data as part of testing or debugging. Finally, customers can specify chains of execution for Workers. This allows the customer to inject any pre or post processing scripts around the third party developer code.

Workers for Platforms is being rolled out as a private beta, for customers with a specific use case. Customers can complete an online form for access. It’s not clear if Cloudflare will monetize this directly – likely the capability will drive more usage of Workers in general, as third-party developers can generate additional scripts to be executed. It will be interesting to see what materializes from this offering, but I can see it appealing to large “platform” offerings like Shopify, where their application is consumed by other companies to run their businesses.

Service Bindings

Service Bindings represents a very exciting new capability that provides Cloudflare’s serverless implementation with better developer support and an efficiency advantage over serverless implementations from some hyperscalers.

Introduced during Full Stack week in November, Worker Services provides a major building block for developers assembling distributed applications. The previous implementation of Workers revolved around single scripts, where all functionality is bundled into one instance with one externally facing interface and one codebase. This is akin to the legacy software application convention of a “monolith“, where engineering departments all worked in the same code base and had to coordinate releases across multiple teams. This design worked okay for small teams, but quickly bogged down the development pace as the organization grew.

These constraints of a large monolithic codebase sparked the advent of micro-services. A micro-services architecture involves breaking the monolith into functional parts, each with its own smaller, self-contained codebase, hosting environment and release cycle. In a typical Internet application, like an e-commerce app, functionality such as user authentication, profile management, product search, check-out and communications can all be separate micro-services. These communicate with each other through open API interfaces, usually making network connections between servers and sometimes even calling over a public network using HTTP.

With Worker Services, Cloudflare is adding support for a micro-services architecture. Every Worker script can now be deployed into its own runtime environment. This comes with easily configurable environment variables, hostnames, DNS and SSL. Beyond easing developer operations and adding scalability, Services adds secure “composability” to the mix. Each service can easily reference and invoke another, through a new convention called a Service Binding. A service binding enables developers to route requests to another service (in this case a Worker script), without those requests going over the Internet. That allows developers to invoke other Workers directly from the code in a running Service. Service bindings open up a whole new level of composability and security. 

This provides an easy way for developers to leverage functionality in existing services as they build new applications, saving time and speeding up cycles. Because of Cloudflare’s globally distributed, serverless architecture, these services are effectively self-referencing, meaning that all Worker instances run all services, so a call from one service to another can happen within the same runtime. This is a very powerful concept which has huge implications for security and scalability.

The reason for this advantage has to do with the standard way of hosting a classic service-oriented architecture. That involves provisioning a set of servers in one cloud location, loading the micro-service code, setting up environment variables and configuring security permissions to protect the service from public traffic. Calls between two services will travel over the network, either within a virtual private cloud, or across the Internet. In either case, that network hop introduces latency and the potential for errors through dropped packets.

This is the architecture employed by the hyperscalers in their centralized data center solutions. For edge-based, serverless offerings, they generally separate routing logic (API Gateway) from invocations of the processing code. Different services scripts are instantiated on different edge servers, introducing network overhead. This also incurs extra costs, as upstream service invocation will idle while waiting for a response from the downstream service. Because edge script and gateway services are run in separate servers, these cross service calls introduce latency.

With Cloudflare’s Service Bindings, each service can reference another within the same virtual runtime, eliminating the need to make network calls between servers in the virtual environment or over the public network. Service Bindings make it easy to tie services together and minimize latency as the “travel time” is reduced to the Worker instance itself. Combined with a backplane of distributed data through the various data storage and processing offerings, each service can maintain its own data store, or share data with other services across an application.

The competitive advantage that Service Bindings, combined with Worker Services, brings has to do with the planned pricing model for Workers that utilize Service Bindings. Before Service Bindings, a customer would be charged for all the time that a Worker was active, whether actually processing or waiting. This represents the combination of the dark blue and gray bars above. With Service Bindings, Cloudflare will only charge customers for the dark blue bar time, as that represents the aggregated period of CPU utilization across all Worker services.

Cloudflare is able to do this as a consequence of their architecture. Because all the the Worker scripts run on the same Worker server instance, Cloudflare can efficiently swap CPU and memory to be utilized on the active processing thread. Therefore, they are able to charge for just the compute and memory resources used. They don’t have to reduce their margins or utilization efficiency in order to accomplish this savings for customers.

For comparable hyperscaler solutions, they would not be able to swap different service processing code out on the same host CPU and memory space, because micro-services generally run on separate server instances. This means they have to charge customers for the full time that all services are active, whether processing or waiting. This overhead is represented by the magenta portions of the bars above.

This cost advantage would be material over time. It is an outcome of Cloudflare’s disciplined architectural design principle to run all Worker services on the same hosts in all data centers in parallel. While that has made their platform much more complicated to maintain, it provides these kinds of advantages in performance and utilization efficiency. As investors consider Cloudflare’s CapEx spend in 2022, these kinds of design advantages imply that Cloudflare will at least be highly efficient in the utilization of that incremental hardware.

Custom Domains

To supplement Service Bindings, Cloudflare made the creation and routing of traffic to new sub-domains seamless. This would be relevant if a development team needed to create a URL destination for a new micro-service. For example, if their primary site were hosted at “example.com”, they could easily route user authentication requests to auth.example.com or shopping cart additions to shop.example.com. This is accomplished through Custom Domains.

Normally, creation of subdomains like this requires coordination with the DevOps team. They have to create a new DNS record, issue a certificate for secure traffic and provide a destination host to receive requests. With Cloudflare managing a company’s DNS and using Workers, creation of subdomains and routing traffic can be handled within the developer’s own toolset (Dashboard, API or Wrangler). After creating a new subdomain, the developer can assign a Worker script to process requests for that subdomain. With Service Bindings, the developer can link up different micro-services to process all the dependencies associated with a web application request.

The benefit to the developer is removal of configuration overhead and faster dev/test/release cycles. For Cloudflare, this should drive more usage of Workers, as developers can spin up additional services to handle different kinds of application use cases. More Worker invocations will generate more revenue.

Custom Domains has been integrated with the user Dashboard and APIs. Wrangler integration is coming. The product is available as an open beta now.

Investor Take-aways

As with the data product releases, Cloudflare packed a lot of improvements to the core Workers offering into Platform Week. While on the surface these may not appear to be revenue generating, I think they remove obstacles to adoption and further improve ease of use. Open sourcing the Workers runtime provides a low risk mechanism to increase confidence and comfort for large enterprise engineering organizations to migrate application services to Workers. Similarly, Workers for Platforms gives customers who use Cloudflare to sell SaaS products to other businesses a means to customize their experience. This can be done in an isolated and secure manner, providing major flexibility to end customers, but limiting the risk of damage to the core platform.

Service Bindings provides developers with a convenient tool to string together their Worker processes. This convention is important as they can break up large applications into a series of micro-services. As the processing thread traverses different Worker scripts, charges will accrue only for the time that each Worker process is active. This provides an advantage over other serverless implementations that have to bill for active time of each separate service, even if one is waiting on another to respond. Custom Domains frees up the developer to configure the various Worker services themselves and pin each to a separate subdomain for routing.

Combined, I think these capabilities add a lot of value to the Workers offering. With 15% of paying customers using Workers in 2021 and a goal to more than double the number of developers on the Workers platform in 2022, I think these capabilities will facilitate adoption. With the new product offerings around data storage, processing and messaging, developers can address more application use cases with the Workers platform. These should all drive incremental usage as the year progresses.

NOTE: This article does not represent investment advice and is solely the author’s opinion for managing his own investment portfolio. Readers are expected to perform their own due diligence before making investment decisions. Please see the Disclaimer for more detail.