3 posts tagged with "workflows"

Dapr is a strong distributed application runtime. It gives teams a sidecar, service invocation, pub/sub, state management, bindings, actors, workflows, secrets, configuration, and a component model that can sit beside services across different hosting environments.

W7S starts from a different premise. If the application already deploys through W7S, the platform can own many of those concerns directly: deployment identity, internal routing, managed bindings, storage provisioning, background delivery, workflow dispatch, local multi-repo testing, and usage accounting.

That makes the useful question narrower than "can W7S run Dapr?"

Can the product behavior people reach for Dapr to get be built from W7S components that already exist?

For many W7S apps, yes.

Kubernetes is powerful because it can run almost anything. Pods, Deployments, Services, Ingress, Jobs, CronJobs, ConfigMaps, Secrets, volumes, operators, service meshes, and controllers can model a huge range of systems.

That flexibility is also why Kubernetes is often too much for small apps.

Many apps do not need a cluster. They need:

• a frontend;
• a few backend routes;
• a database;
• file storage;
• a background queue;
• a schedule;
• a durable workflow;
• a deploy path from GitHub;
• logs and usage feedback.

W7S is designed for that smaller shape.

NATS is a strong general-purpose messaging system. It gives teams subjects, request/reply, publish/subscribe, queue groups, persistence through JetStream, and a fast broker that can sit between many services.

W7S does not need to copy that model to support the same application patterns. In many W7S apps, adding NATS would introduce another control plane, another credential model, another operational surface, and another local development story. The better default is to ask a narrower question:

Can the same product behavior be built from W7S components we already have?

For many cases, the answer is yes.