gregfurman

You’re pretty much describing LocalStack [1].

IMO much of the product’s success was derived from the extensive snapshot + behavioural tests they created to validate parity with AWS.

The basic engineering loop was: 1. Write tests against AWS 2. Record all results 3. Run tests from (1) against emulator and diff with results from (2)

Like, theoretically, you could use their preexisting suite of tests to construct a pretty decent emulator, since the engineering + cloud costs of recording behavior has already been frontloaded, and resides within their snapshot files [2].

[1] https://github.com/localstack/localstack

[2] https://github.com/localstack/localstack/tree/main/tests/aws...

Seconding this as a brilliant project!

Shameless self promotion here but I’m currently using wasm2go to build a native Go runtime for MicroPython https://github.com/gregfurman/micropython-go

This looks great! Wonder how it compares to https://github.com/genkit-ai/genkit since they also offer similar SDKs and support for different model providers.

That’s fair. There’s still a free tier that you can use.

https://blog.localstack.cloud/the-road-ahead-for-localstack/...

But IMO, LocalStack community’s S3 service is pretty stable, so I’m doubtful there’ll be much parity drift in the short to medium term.

Have you heard of LocalStack’s AWS emulator? [1] It’s runnable within a docker container and has a high fidelity S3 service.

Disclosure, I’m a SWE at LocalStack.

[1] https://github.com/localstack/localstack

Fluvio looks awesome!

Any chance you’re going to be reviving support for the Kafka wire protocol?

https://github.com/infinyon/fluvio/issues/4259

Discovered this sometime last year in my previous role as a platform engineer managing our on-prem kubernetes cluster as well as the CI/CD pipeline infrastructure.

Although I saw this dissonance between actual and assigned CPU causing issues, particularly CPU throttling, I struggled to find a scalable solution that would affect all Go deployments on the cluster.

Getting all devs to include that autoprocs dependency was not exactly an option for hundreds of projects. Alternatively, setting all CPU request/limit to a whole number and then assigning that to a GOMAXPROCS environment variable in a k8s manifest was also clunky and infeasible.

I ended up just using this GOMAXPROCS variable for some of our more highly multithreaded applications which yielded some improvements but I’ve yet to find a solution that is applicable to all deployments in a microservices architecture with a high variability of CPU requirements for each project.