Nomad VS dapr

You'll probably want to take https://www.nomadproject.io/ and layer it on top of jails with pot:

Nomad[1] is one alternative that gives you the same infra-as-code warm and fuzzies but isn't a behemoth like k8s. It's simple to deploy, simple to operate and unless you're truly scaling big, it probably does everything you need.

I'm sure there are others in the same league that I don't know about. Maybe I'm just getting old but I'll never understand the rush to use k8s in teams of <100 developers.

[1] https://www.nomadproject.io/

Hashicorp Nomad? I ran it across a bunch of raspberry pis and proxmox VMs/LXCs. Being a Hashicorp product it plays well with Terraform. The only reason I swapped it out for k3s was upskilling for work.

[Nomad]

Lob’s core API has been fully migrated to HashiCorp's Nomad, Lob’s Next Generation service platform. This is a major milestone for the Nomad Project, the Platform Team, and Lob Engineering. This migration is the culmination of a year of R&D, months of practice migrating other Lob services, and weeks of work on this particular service. It’s absolutely worth celebrating for the complexity and customer impact.

Most of our API’s migration to Nomad happened in August, but the key feature of autoscaling was not working as expected. This turned out to be a bug in Nomad which James Douglas tracked down. The issue was recently fixed and autoscaling works as expected, completing the migration!

Nomad by HashiCorp

There's also https://pot.pizzamig.dev/ which even has a Nomad(https://www.nomadproject.io/) driver in case you want to "orchestrate" the jails(as in deploy many jails at the same time across multiple servers)

The check stanza runs a health check on the service Since the service is registered to Consul, the health check runs on Consul. The above health check is configured to run every 10 seconds, and is given 5 seconds for the health check query to succeed. Health checks in Nomad are similar to Kubernetes health checks.

Not sure if it fits here, and might be a little more complex than what you’re looking for, but Nomad is definitely worth a look.

I would like to build modules, either in a modular monolith style, or in a microservice style using DAPR and/or Tye.

Just heard about Dapr last week. Might be more than what you are asking, though but it’s probably worth a look.

https://dapr.io/

From my perspective, I’d like to explore further how Dapr can integrate with other Supabase features. It would also be great to see a Supabase state store as a built-in component that’s available in the Dapr runtime without the need of running the pluggable component separately. I also hope the proposed DocumentStore building block will get some traction this year, since this will pair up very nicely with Supabase and other PostgreSQL stores.

Could you use Kubernetes to solve this? Have a single pod running the Redis instance and then multiple running Node.js talking to the Redis instance via something like DAPR (https://dapr.io/)

Dapr is also building a workflow orchestrator into their microservice system. It's almost in Beta, and when you combine it with Dapr's Virtual Actors, it looks powerful. It will also let you integrate a workflow engine like Temporal, too. https://dapr.io/

This fantastic blog from Mauricio (Salaboy) Salatino shows how tools like Kratix (kratix.io) and Dapr (dapr.io) can help streamline golden paths: https://blog.dapr.io/posts/2023/04/02/creating-dapr-enabled-platforms-with-kratix/

Recently, the Dapr maintainers released V1.10 of Distributed Application Runtime (Dapr), a developer framework for building cloud-native applications, making it easier to run multiple microservices on Kubernetes and interact with external state stores/databases, secret stores, pub/sub-brokers, and other cloud services and self-hosted solutions.

Dapr, the open-source distributed application runtime, is often used in event-driven applications. Dapr provides a set of standardized API building blocks that simplify microservice development. By using the Bindings building block, developers can use input, and output bindings, and either trigger their apps or invoke other resources without having to learn resource-specific SDKs for these resources. With Dapr release 1.10, a new binding is provided that allows developers to publish messages to Cloudflare Queues. Because of the common set of APIs that Dapr offers, developers from any background can use the binding to publish messages to Cloudflare Queues without needing to know the Cloudflare SDKs or adding that dependency to their codebase.