Hi everyone, I'm new here and still figuring things out. 😅
I'm trying to set up Arize for our team. We have a bunch of microservices, each with its own models. It's getting confusing to track them all. What's the best way to organize projects in Arize for this "model zoo" setup? Should each microservice be its own project, or is it better to group by model type? Any tips would be really appreciated.
I'm a platform data engineer at a mid-sized e-commerce company where we run about 30+ ML models across recommendation, search, and fraud detection microservices, using Arize in production for model monitoring and performance tracking.
The core architectural decision for organizing a model zoo in Arize hinges on balancing isolation for operational autonomy with aggregation for oversight. Here's a breakdown of the main approaches.
* **Access Control and Team Boundaries:** If your microservice teams (e.g., Fraud Team, Search Team) own their models end-to-end, creating one Arize project per microservice aligns cleanly with existing IAM and reduces cross-team noise. We found each team typically needs 3-5 members with specific roles (admin, viewer), which Arize handles at the project level.
* **Observability Surface and Cost:** Grouping by model type (e.g., "Recommendation_Models") can reduce dashboard sprawly and lower cost if you're on a per-project pricing plan. However, we saw a concurrency limit of ~20 simultaneous users analyzing logs in a single, very busy project before performance noticeably lagged; per-microservice projects distribute this load.
* **Integration and Deployment Effort:** A project-per-microservice pattern simplifies CI/CD. You can bake one set of Arize project credentials into each service's deployment. Grouping by type requires a central credential service or more complex orchestration, adding roughly 1-2 days of initial setup overhead for credential management.
* **Limitation of Shared Context:** The primary drawback of grouping disparate microservices into one project is tag collision. If teams use different conventions for `model_version` or `environment`, the shared project's global filters and dimension analysis become unreliable. We had to standardize a half-dozen column names across teams to make a "by model type" project work.
My pick is to default to one Arize project per owning microservice. It mirrors your existing software boundaries, minimizes cross-team coordination, and scales cleanly as you add services. If you're strongly considering grouping by model type instead, tell us the size of your central ML platform team and whether you already have a centralized feature store or schema registry in place.
Data is the new oil – but only if refined
You've got the right instinct to align projects with your team structure. While grouping by model type seems logical, it creates friction when ownership is split.
The operational metric that's often overlooked is the cost of context switching. If an alert fires at 2 a.m., the on-call engineer needs to know immediately which service and team owns it. A project-per-microservice setup enforces that clarity by design.
Start with that mapping, then use Arize's tags and spaces for cross-cutting views by model type later.
independent eye
The "project per microservice" advice you're getting is sound for organization, but has anyone mentioned how that scales in Arize's pricing model? Each project could nudge you toward a higher enterprise tier.
Grouping by model type might be more chaotic for your team, but it could keep you in a cheaper plan longer. Depends if you value neatness over your budget, I suppose.
—DW
If you're new and still figuring things out, the "project per microservice" advice is going to hit you with a billing surprise later. That structure creates a project count that can quickly force you into an enterprise contract.
Sure, it's organizationally clean, but have you checked the pricing page? That neatness has a price tag. Sometimes a little chaos in one project with good tagging is cheaper than paying for ten separate ones.
—DW
Sure, the 2 a.m. alert clarity is a compelling point.
But what if your team boundaries are temporary? Re-orgs happen. Merging projects is a nightmare compared to retagging.
You're swapping one type of friction for another.
Doubt everything
Yeah, re-orgs are a real concern. I've seen teams get shuffled and suddenly their clean project structure is a mess.
Is it actually hard to merge projects in Arize? Or do you just have to recreate everything in the new one?
That's a very common challenge when starting out with a model monitoring setup. You're right to think about structure from the beginning.
The most practical advice is to start simple and mirror your team's existing accountability. If each microservice is owned by a distinct team or a clear set of engineers, making each service its own project gives you clean access control and alert routing from day one. It prevents the confusion of mixed ownership inside a single project.
You can always use tags and spaces within those projects later to create the "model type" view you mentioned, without sacrificing that core operational clarity.
—HR
Hey, I'm new to Arize too, and I was wondering the same thing. The advice about matching projects to microservices makes sense for teams, but I hadn't thought about the pricing angle that others mentioned. That's a good point.
Do you know if tagging models really works as well as separate projects for filtering and alerts? I'm worried about things getting messy in one big project.
Tags work for filtering dashboards and alerts, but not for user permissions. That's the trade-off.
If your team is small and owns all 30 models, a single project with strong tagging conventions is viable and cheaper. If separate teams need different data access, you're forced into multiple projects anyway.
Pricing scales on monitors and data points, not just projects. Calculate both before deciding.
Prove it with a benchmark.