Unified Delivery Pipeline for Apps + ML Models + Data Products: Is the Separate ML Platform Already Legacy?

[maya_builds]

Unified Delivery Pipeline for Apps + ML Models + Data Products: Is the “Separate ML Platform” Already Legacy?

I’ve been deep in the weeds lately thinking about our design system deployment pipeline, and it got me wondering—why do we treat ML model deployments completely differently from app deployments?

Here’s what triggered this for me: We just spent 3 months building a unified component library delivery pipeline. Push to main, automated tests, staging environment, production rollout. Clean. But then our data science team wanted to integrate a recommendation model into the same product, and suddenly it’s a completely different world—separate infrastructure, different deployment process, different governance, different monitoring. It felt like we were building two parallel universes.

The Industry Shift: Convergence is Happening

I started digging into this and found some fascinating trends. According to Platform Engineering’s 2026 predictions, by the end of 2026, mature platforms will offer a single delivery pipeline serving app developers, ML engineers, and data scientists through one unified experience.

The convergence of AI with platform engineering is accelerating fast:

• 55% of organizations have already adopted platform engineering as of 2025
• 92% of CIOs are planning AI integrations into their platforms
• Gartner forecasts 80% adoption by 2026
• The MLOps market hit ~$3-4 billion in 2025, growing at 40%+ CAGR

What really caught my attention: “As organizations scale from a handful of models to hundreds and begin introducing GenAI and agent-based workflows alongside traditional ML, gaps become harder to manage with disconnected tools.”

The Current Reality: Silos Everywhere

Right now, most companies I talk to have:

1. App delivery pipeline: GitHub Actions/CircleCI → Docker → K8s → Datadog
2. ML pipeline: Jupyter → MLflow → SageMaker/Vertex AI → Custom monitoring
3. Data pipeline: Airflow → dbt → Snowflake → Looker

Three separate stacks. Three different ways to deploy. Three different governance models. It’s like we learned nothing from the DevOps movement about breaking down silos.

And the handoffs are brutal:

• Data scientists work in notebooks, then throw models “over the wall” to ML engineers
• ML engineers package models, then hand them off to platform teams
• Platform teams integrate models into apps with completely different deployment workflows
• Each handoff introduces delays, miscommunication, and finger-pointing when things break

The Unified Vision: One Pipeline to Rule Them All

The vision is compelling: one delivery pipeline where:

• An app developer pushes a React component update
• An ML engineer pushes a fraud detection model update
• A data scientist pushes a customer segmentation update

All three go through the same pipeline, with the same governance, the same monitoring, and the same deployment process. Same RBAC permissions, same resource quotas, same cost gates, same observability.

Platforms like Databricks Lakehouse and Dagster are heading this direction—unifying data engineering, ML, and business intelligence on a single architecture.

The Big Question: Can One Pipeline Serve All Personas?

Here’s where I get stuck. As a designer, I’m all about understanding different user personas and their needs. And these three personas—app developers, ML engineers, data scientists—have fundamentally different workflows:

App developers think in: commits, branches, PRs, deploys
ML engineers think in: experiments, model versions, evaluation metrics, drift
Data scientists think in: notebooks, datasets, feature engineering, validation curves

Can a unified pipeline actually serve all three without becoming a lowest-common-denominator mess? Or does “unified” just mean “one team owns the infrastructure” while the workflows stay siloed?

The Failure Mode I’m Worried About

I’ve seen this pattern before with design systems. We tried to create “one component library for everyone”—marketing, product, internal tools. It failed because the contexts were too different. Marketing needed flashy animations. Product needed accessibility and performance. Internal tools needed speed of development.

We eventually split into three libraries with shared primitives. Not fully unified, but better than forcing everyone into the same box.

Is the “unified delivery pipeline” heading for the same fate? Will we build one pipeline that tries to serve everyone and ends up serving no one well? Or will we end up with “unified infrastructure” that just means shared Kubernetes clusters while the actual deployment workflows stay separate?

What I’d Love to Know

For folks who’ve actually tried this:

1. Has anyone successfully unified app + ML deployments? What did you have to give up? What did you gain?

2. Where did the standardization break down? Was it the deployment process? The testing? The monitoring? The governance?

3. Did unification actually speed things up, or just shift the complexity? Are we trading “three separate pipelines” for “one complicated pipeline with three different modes”?

4. What about personas who need both? If I’m a full-stack engineer who also trains models, do I get the best of both worlds or the worst?

5. Is the ML platform already legacy? Or is this just another hype cycle where separate specialized platforms actually work better?

I’m genuinely torn on this. The convergence narrative is compelling, but my design instincts scream “you can’t optimize for everyone.” Would love to hear from folks in the trenches on whether unified pipelines are the future or just the latest attempt to solve organizational problems with technology.

---

For context: I lead design systems at a mid-size company. We have ~30 app developers, ~8 ML engineers, and ~5 data scientists. We’re evaluating whether to build unified deployment infrastructure or keep specialized platforms.

[cto_michelle]

This is THE question every CTO is grappling with right now. I’ve been on both sides of this—ran separate platforms at my last company, now building unified at current company. Here’s what I’ve learned:

Unified Infrastructure ≠ Unified Workflow

You nailed the key tension: infrastructure can be unified while workflows stay differentiated. That’s actually the sweet spot.

At my current company (mid-stage SaaS, ~120 engineers), we’ve successfully unified the infrastructure layer:

• Same K8s clusters for apps and ML workloads
• Same CI/CD orchestration (GitHub Actions)
• Same observability stack (Datadog + custom)
• Same governance/RBAC/cost controls

But we kept workflow differences:

• App developers still use standard deployment manifests
• ML engineers use Kubeflow pipelines on the same clusters
• Data scientists use notebook environments that compile to K8s jobs

Result: 40% reduction in platform team overhead (one cluster to maintain, not three), but each persona still has their native workflows. The unification is invisible to them.

Where Standardization Actually Matters

Based on 18 months of building this, here’s where unified standards provide massive value:

1. Security and compliance: One RBAC model, one audit trail, one compliance framework. Huge win for financial services / healthcare.

2. Cost governance: FinOps preventive controls work across all workloads. We now block deployments that exceed unit-economic thresholds—whether it’s an app or an ML model.

3. Observability: Unified metrics and logs mean incidents don’t get lost in translation between teams. When a model causes app latency, we see it in one dashboard.

4. Resource optimization: ML training jobs run on same GPU nodes as inference workloads—we get better utilization through time-shifting.

Where It Breaks Down

The failure modes are real:

1. Deployment velocity mismatch: App teams want to deploy 10x/day. ML teams deploy 2x/week after extensive validation. Forcing them into the same deployment cadence creates friction.

2. Testing paradigms: Unit tests for apps are fast. Model validation requires test datasets, evaluation runs, A/B testing infrastructure. We had to build parallel testing tracks.

3. Rollback semantics: Rolling back code is easy. Rolling back a model means dealing with data drift, retraining, evaluation state. The “deploy” abstraction leaks.

The ROI Question: Is It Worth It?

Honest answer: Yes, but only at a certain scale.

For your size (30 app devs + 8 ML engineers + 5 data scientists), I’d say:

• Don’t unify if: ML is experimental, models change monthly, DS team is research-focused
• Do unify if: ML is production-critical, models power core product features, DS team ships to production regularly

At our scale, unified infrastructure saved us 2.5 platform engineers’ worth of work (we didn’t hire them). But we invested 1.5 engineers’ worth of time building the abstraction layers to preserve workflow differences.

Break-even was around 100 total engineers with 15+ ML/DS folks shipping to production weekly.

My Recommendation

Start with selective unification:

1. Phase 1: Unified observability and cost tracking (low risk, high value)
2. Phase 2: Shared K8s infrastructure with separate namespaces (infrastructure unification, workflow separation)
3. Phase 3: Common deployment orchestration with workflow-specific plugins (true unification, but preserve persona differences)

Don’t try to boil the ocean. The “one pipeline for everything” vision is real, but it requires investment in abstraction layers that preserve workflow ergonomics.

The separate ML platform isn’t legacy yet—it’s just becoming a logical separation on top of unified infrastructure rather than a separate infrastructure stack.

Great framing of the problem, Maya. This is exactly the kind of architectural tension that determines whether platform engineering initiatives succeed or become organizational bottlenecks.

[eng_director_luis]

Maya, your design system analogy really resonates—I’ve watched teams try to force unification when separation made more sense, and vice versa.

I’m running a team of 40+ at a Fortune 500 financial services company, and we’re in the middle of this exact transition. Let me share what’s actually working (and what’s failing) on the ground.

The Messy Reality: Hybrid Is Winning

After 12 months of trying, here’s where we landed:

Unified: Infrastructure (K8s, networking, security), governance (RBAC, audit), observability (metrics/logs/traces)

Still Separate: Deployment tooling (ArgoCD for apps, custom for ML), testing frameworks, release cadences

We tried to unify deployments—GitOps for everything!—but it fell apart because:

• App teams deploy 40-60 times per week
• ML teams deploy 2-3 times per month after extensive model validation
• Forcing ML teams into continuous deployment created more problems than it solved

The Organizational Problem You Can’t Tech Your Way Out Of

Here’s the hard truth: the pipeline isn’t the bottleneck, the handoffs are.

Even with unified infrastructure, we still have:

1. Data engineers prepare datasets → handoff to data scientists
2. Data scientists train models → handoff to ML engineers
3. ML engineers package models → handoff to app developers
4. App developers integrate models → handoff to SRE for monitoring

Four handoffs. Four points where context gets lost, accountability blurs, and timelines slip.

Unified infrastructure reduced handoff time from 3 days to 3 hours, which is huge. But it didn’t eliminate the handoffs. We’re still working on that through org changes (embedded ML engineers in product squads).

Where Unification Delivers Real Value

I’ll be specific about wins because the abstract benefits don’t translate:

1. Incident Response: Last month we had a production incident where a recommendation model caused API latency spikes. With unified observability, we traced from user request → API endpoint → model inference → database query in one trace. Previously this would’ve required 3 different tools and 3 different on-call people. Saved 2 hours of MTTR.

2. Resource Costs: We’re now running ML training on spot instances in the same cluster as our app workloads. When app traffic is low (nights/weekends), ML training ramps up. We’re seeing 30-35% better GPU utilization compared to dedicated ML clusters that sat idle overnight.

3. Security Compliance: Our compliance team audits one platform, not three. This cut our SOC 2 prep time by about 40% (less time gathering evidence from multiple systems).

4. Cross-functional debugging: When app developers can see model performance metrics in the same dashboard as API latency, they actually understand the dependencies. This has reduced “it’s the ML team’s fault” finger-pointing significantly.

The Specialized Tooling We Still Need

Even with unified infrastructure, we maintain specialized tools:

• Jupyter notebooks for data scientists (not going away—interactive exploration can’t be replaced)
• MLflow for experiment tracking (apps don’t need this)
• Feature stores for ML-specific data access patterns
• Custom monitoring for model drift, data quality, prediction distributions

The key insight: these tools now run on the unified platform rather than being the platform. Data scientists use Jupyter, but the notebooks execute as K8s jobs. MLflow stores experiments, but deployment happens through the same pipeline as apps.

My Take on “Is Separate ML Platform Legacy?”

No, but it’s evolving.

Think of it like this:

• Legacy: Separate infrastructure, separate teams, separate governance
• Modern: Shared infrastructure, workflow-specific abstractions, unified governance
• Future: Same deployment primitives with persona-optimized interfaces

The separate ML platform is becoming a workflow abstraction layer rather than a separate infrastructure stack. That’s a meaningful distinction.

Recommendation for Your Team Size

For 30 app devs + 8 ML + 5 DS, I’d actually not recommend full unification yet. Here’s why:

With only 13 total ML/DS people, the coordination overhead of unification might exceed the benefits. I’d focus on:

1. Shared observability first: Get everyone using the same monitoring/logging/tracing. This is low-hanging fruit with immediate ROI.

2. Document the handoffs: Map out where ML artifacts go from team to team. Optimize those touchpoints before building infrastructure.

3. Pilot with one critical ML workflow: Pick your most important production ML feature and run it through a unified deployment process. Learn from that before rolling out to all ML workloads.

4. Wait until 20+ ML/DS people before investing in full unification. Below that threshold, the platform team overhead probably exceeds the efficiency gains.

The design system lesson applies perfectly here: start with shared primitives, not forced unification. Build the common foundation (K8s, RBAC, observability), then let workflows evolve based on what teams actually need.

Great discussion starter, Maya. This is one of those decisions that looks obvious in blog posts but gets messy in production.

[product_david]

Coming at this from the product side, and I think there’s a crucial dimension missing from the technical conversation: time-to-value and customer impact.

The Product Question: Does Unification Speed Up Shipping Features?

I’ve been VP Product at a Series B fintech startup for 2 years. We have ML-powered fraud detection at the core of our product. Here’s what I’ve observed:

Before unified pipeline (separate ML infrastructure):

• Feature idea → production: 6-8 weeks
• Product, engineering, ML, data—four separate teams coordinating
• Most time spent on: handoffs, integration, testing across boundaries

After unified pipeline (same deployment process):

• Feature idea → production: 3-4 weeks
• Same cross-functional team, but less time lost in translation
• Most time spent on: actual product work, customer validation, iteration

The speedup isn’t from the infrastructure itself—it’s from reducing context switching and cognitive overhead for the product team.

When our PM can see model deployment status in the same dashboard as app deployment status, they can make informed decisions about launch timing. When engineering can roll back a model with the same process as rolling back code, we’re not blocked waiting for the ML team.

The Real Benefit: Business Velocity, Not Technical Elegance

Michelle and Luis covered the technical trade-offs well. From a product perspective, here’s what actually matters:

1. Faster Iteration Cycles

When we ship an ML-powered feature, we’re running A/B tests to compare:

• Baseline (no ML)
• Model v1
• Model v2
• Model v2 + UX tweak

With separate pipelines, each variation required separate deployment processes. With unified pipelines, we can roll out all variations in one deploy and toggle them with feature flags. This cut our experimentation cycle from 2 weeks to 3 days.

2. Reduced Product-Engineering Friction

I used to have standups that sounded like:

• PM: “Can we ship the new fraud model this sprint?”
• Engineering: “Need to check with ML team”
• ML: “Model is ready, but need platform team to deploy”
• Platform: “Backlog is 3 sprints out”

With unified pipeline:

• PM: “Can we ship the new fraud model this sprint?”
• Engineering: “Yes, model is tested, we’ll deploy Thursday”

One conversation. One team. One deployment process.

3. Customer-Facing Transparency

Our enterprise customers ask: “How often do you update your fraud detection?” With separate ML platform, the honest answer was “whenever we can coordinate all the teams—quarterly, maybe?” With unified pipeline: “We deploy model updates weekly, just like feature updates.”

That answer changes sales conversations. It signals operational maturity.

Where Product Interests Conflict with Technical Purity

Here’s where I push back on pure unification:

We still need specialized tools for product discovery work.

Our data scientists spend 80% of their time in exploration:

• Which features predict fraud best?
• What does customer behavior look like?
• How do we handle edge cases?

That work happens in Jupyter notebooks and SQL editors, not deployment pipelines. Trying to force that exploratory work into a “unified pipeline” would kill innovation.

The unified pipeline should start after the exploration phase—when we’re ready to deploy a validated model to production.

The Framework I Use: Unified Infrastructure for Production, Specialized Tools for Discovery

Think of it like product development:

• Discovery phase: Specialized tools (notebooks, SQL, dashboards) for data scientists to explore
• Delivery phase: Unified pipeline for deploying validated models to production

We don’t try to unify the discovery tools. That’s where creativity and iteration happen. We do unify the production deployment pipeline, because that’s where speed and reliability matter.

Measuring Success: Product Metrics, Not Infrastructure Metrics

Here’s how I evaluate whether unified pipelines are working:

Not this: “We reduced deployment tools from 3 to 1” (infrastructure metric)

This: “We shipped 40% more ML features per quarter” (product outcome)

Not this: “All teams use the same CI/CD” (technical standardization)

This: “Time from model validation to customer value decreased 50%” (business velocity)

The platform team should optimize for reducing time-to-value for customers, not technical elegance.

Recommendation: Start with the Customer Journey

For your team (30 app + 8 ML + 5 DS), I’d map the customer journey:

1. Which ML models directly impact customer experience? Start there. Unify deployment for those first.

2. Which ML work is internal/experimental? Keep specialized platforms for that. Don’t force internal analytics into production pipelines.

3. Where do customer-facing features depend on ML + app coordination? Those handoffs are your biggest opportunity for velocity gains.

4. What’s the cost of delay? If slow ML deployment is costing you deals or customer satisfaction, unification is worth it. If ML is still experimental, separate platforms are fine.

The technical question (“can we unify?”) is less important than the product question (“should we unify based on where we’re heading?”).

If your roadmap shows ML becoming core to your product value proposition—unify now. If ML is exploratory or nice-to-have—wait until it matters to customers.

Maya, love the design systems parallel. The right answer isn’t technical, it’s strategic. What does your product roadmap say about how central ML will be to customer value in 12-24 months? That should drive the decision, not what’s technically elegant.