Overview

Compute modules enable you to run serverless Docker images in Foundry and horizontally scale them up or down based on load in your frontend applications (such as Workshop and Slate).

When to use compute modules

Some common use cases for compute modules include:

• Integrating existing code bases: If you have business critical code that would be risky or expensive to rewrite in Foundry, you can containerize the code into a Docker image and run it as a compute module.
• Supporting any programming language: Compute modules allow you to run any code that can be containerized regardless of language. This means you aren't limited by the languages Foundry supports natively
• Dynamic and predictive horizontal scaling: If you expect to serve a varying number of requests, Compute modules can ensure higher availability by scaling the number of available replicas up or down based on current and historic load.
• External and in-platform connections: Compute modules enable you to write custom logic leveraging Foundry products, for instance to read and write data or media sets, or connect to external systems (such as Twilio).

When to avoid using compute modules

Compute modules are not recommended for:

• Dynamic vertical scaling: If you expect to have a single request vary dramatically in size, for instance from 1MB to 100GB, and want to support dynamic vertical scaling, compute modules may perform poorly "out of the box", as the amount of resources allocated is static and defined manually. It is possible to create differently provisioned tiers of the same compute module and multiplex between them, but that solution may be more complicated and cumbersome.
• Replacing existing features supported natively by Foundry: Compute modules can theoretically be used to build any desired feature. However, by virtue of being very generalized and powerful, this may come at the cost of having a more complicated solution.

Architecture

Each compute module consists of a number of replicas. The number of replicas changes as the request volume changes.

Each replica contains the same set of one or many isolated containers. One container serves as the entry point, and it must implement a client that forever polls for events to process. The other containers can contain anything.

By default, there are few guardrails for setting up a many-container compute module. One suggested method is to have them communicate using standard networking protocols; another suggestion is to used shared volume mounts. Containers in the same replica can communicate via those methods (and more), but containers cannot communicate across replicas, and you should not rely on any state they may accrue.

To get started, see the guides for building a compute module in Foundry or for building a compute module on your local machine.