aws-lambda-runtime-interface-emulator VS rivet

FWIW, Lambda takes the opposite of your assertion: there are function entrypoints and the HTTP or gRPC or Stdin is an implementation detail; one can see that in practice via the golang lambda "bootstrap" shim <https://pkg.go.dev/github.com/aws/[email protected]/lamb...> which is invoked by the Runtime Interface Emulator <https://github.com/aws/aws-lambda-runtime-interface-emulator...>

I don't have the links to Azure's or GCP's function emulation framework, but my recollection is that they behave similarly, for similar reasons

Another option I explored was the AWS Lambda Runtime Interface Emulator. This is an official AWS tool that lets you run Lambda inside a Docker container, mimicking the AWS runtime. It's particularly useful if you're deploying container-based Lambdas.

Enter the aws-lambda-runtime-interface-emulator. This tool will allow us to emulate the AWS Lambda Runtime API locally (I suspect that the AWS SAM uses this tool under the hood as well). The aws-lambda-runtime-interface-emulator is designed to be used with Docker. Still, nothing stops us from containerizing our code for the sake of development and then, whenever we are ready, proceeding with deployment how we wish to. This local workflow is a bit more involved than the previous one, but it might be a valid alternative for those not using AWS SAM or are already using containers to deploy their Lambdas.

There is a special tool to test AWS Lambda images locally. It's called AWS Lambda Runtime Interface Emulator (RIE). You have two options: include RIE in your image or install it locally. We don't need it in the production image, so let's choose the second option. We will download binary locally and mount it to our image if we need to test it.

Suggestions:

1. If you are building APIs and using Lambda functions as targets from an API Gateway API, look into libraries like serverless-wsgi (Python) or wai-handler-hal (Haskell) that translate between API Gateway request/response payloads and some kind of ecosystem-native representation. Then as long as you're writing code where all state gets persisted outside of the request/response cycle, you can develop locally as if you were writing for a more normal deploy environment.

2. Look into the lambda runtime interface emulator ( https://github.com/aws/aws-lambda-runtime-interface-emulator... ). This lets you send invoke requests to a fake listener and locally test the lambda more easily. While the emulator is provided in the AWS container base images, you don't need to run it inside a container if you're deploying with zip files. (AWS-provided container images automatically enable the emulator if not running in a lambda runtime environment, and using docker for port remapping is nice. But not at all required.)

3. Get really good at capturing all requests to external services, and mocking them out for local testing. Whether this is with free monads, effect systems, gateway classes will depend on your language and library choices.

Our self-hosting docs are very rough right now – I'm fully aware of the irony given my comment. It's on our roadmap to get them up to snuff within the next few weeks.

If you're curious on the details, we've put a lot of work to make sure that there's as few moving parts as possible:

We have our own cloud VM-level autoscaler that's integrated with the core Rivet platofrm – no k8s or other orchestrators in between. You can see the meat of it here: https://github.com/rivet-gg/rivet/blob/main/packages/core/se...

For example, Rivet has an API to dynamically spin up a cluster on demand: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...

Once you start the Rivet "seed" process with your API key, everything from there is automatic.

Therefore, self-hosted deployments usually look like one of:

- Plugging in your cloud API token in to Rivet for autoscaling (recommended)

- Fixed # of servers (hobbyist deployments that were manually set up, simple Terraform deployments, or bare metal)

- Running within Kubernetes (usually because it depends on existing services)

This is fun! I’ve come across a few tools like this before and almost dismissed it due to past poor experiences. However, I just diagrammed our startup’s codebase, and it came surprisingly close to our hand-made diagram. I tried customizing it with specific instructions, but the one-generation-per-day rate limit is a bit restrictive.

For comparison:

- Hand made diagram: https://github.com/rivet-gg/rivet/blob/d45bf556e903404ab2df0...

- GitDiagram (no instructions): https://gitdiagram.com/rivet-gg/rivet

Github URL: https://github.com/rivet-gg/rivet

I skimmed a bit about Durable Promises, and if I understand correctly, they’re similar to workflow tools like Temporal but come with high-quality language bindings that let you write workflow steps using async/await.

We built something almost identical in Rust to let us use async/await for long-running & failure-prone workflows. This powers almost everything we do at Rivet. We have a technical writeup coming later, but here's a couple links of interest:

- Rough overview: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...

- Example async/await-heavy workflow: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...

- Example actor-like workflow: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...

Rivet Actors can start, stop, or crash at any time and still continue functioning, much like Durable Promises.

However, their scope differs: Rivet Actors are broader and designed for anything stateful & realtime, while Durable Promises seem focused on workflows with complex control flow.

Rivet Actors can (and likely will) support workflow-like applications in the future, since state management and rescheduling are already built-in.

For a deeper dive, Temporal has a writeup comparing actors and workflows: https://temporal.io/blog/workflows-as-actors-is-it-really-po...

This is very cool! Trying to get it added to awesome-tunneling: https://github.com/anderspitman/awesome-tunneling/pull/149

Related -- we also built a simple (but not production-grade) tunneling solution just for devving on our open-source project (multiplayer game server management).

We recently ran in to an issue where we need devs to be able to have a public IP with vanilla TCP+TLS sockets to hack on some parts of our software. I tried Ngrok TCP endpoints, but didn't feel comfortable requiring our maintainers to pay for SaaS just to be able to hack around with our software. Cloudflare Tunnels is awesome if you know what you're doing, but too complicated to set up.

It works by automating a Terraform plan to (a) set up a remote VM, (b) set up SSH keys, and (c) create a container that uses reverse SSH tunneling to expose a port on the host. We get the benefit of a dedicated IP + any port + no 3rd party vendors for $2.50/mo in your own cloud. All you need is a Linode access token, arguably faster and cheaper than any other reverse tunneling software.

Source: https://github.com/rivet-gg/rivet/tree/main/infra/dev-tunnel

Setup guide: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...

https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...

lists nomad as apache 2.0, when its either MPL or BUSL depending on version.

We built our OSS company (Apache 2.0) with Nomad at its core. We provide game server orchestration with a handful of services around it, which could be misconstrued to be considered providing a "competitive offering to HashiCorp." Needless to say, we'll be freezing our Nomad version at the last MPL version because of how vague the license is (intentionally).

We also use CockroachDB which uses BSL, but we're not providing a remotely competitive offering.

I'll likely continue to recommend HashiCorp products (Nomad, Consul, Terraform, and Packer) to anyone who asks my advice, but it's disappointing to hear this change.

We maintain a rudimentary SBOM for anyone curious: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...