Hi @nimatel! It really depends on the kind of isolation you need.
If you’re mostly concerned about resource isolation, you can definitely use
constraints along with DCs to define a set of clients that receives different sets of work. I’ve done this when I wanted to keep a set of VMs reserved for “user-facing” applications vs “monitoring and telemetry” applications, but didn’t want the overhead of running separate sets of servers. But in this scenario, there’s no network isolation between the applications (which was fine for my use case!).
If you wanted to layer network isolation on top of that, you could use our Connect integration to make sure that applications can’t talk across the network to each other unless specifically allowed.
If you need isolation between teams of people, rather than the applications, that’s where the Nomad namespaces feature comes in (which is as you’ve noted, an enterprise feature). But for a small dev shop it’s probably overkill, as you’ve noted. In my experience with small and startup-sized orgs, I’ve mostly worried about team isolation by giving the team tools to prevent accidental screwups, like avoiding deploying a dev project onto the prod cluster by driving all the deploys from CI rather than the command line.