Unified Delivery Pipelines for Apps, ML Models, and Data Products by End of 2026—Is the "Separate ML Platform" Already Legacy?

General
1

I just read Platform Engineering’s 2026 predictions, and one line stopped me cold:

“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.”

We’re about to invest in a dedicated ML platform. Separate infrastructure, separate deployment processes, separate governance. The quote makes me wonder if we’re already building legacy infrastructure.

Why this matters right now:

  1. The separation is expensive - We’re looking at running parallel deployment systems with different RBAC models, different resource quotas, different monitoring stacks. That’s not just infrastructure cost—it’s cognitive load on every engineer who touches both.

  2. The “handoff” tax - Model handoffs remain manual today. An ML engineer trains something in one environment, then it has to get packaged, validated, and deployed through a completely different system. Every handoff is a place where things break.

  3. AI agents need platform citizenship - If AI agents are becoming “first-class platform citizens” with RBAC permissions and resource quotas like the predictions say, does it even make sense to separate “ML infrastructure” from “app infrastructure” anymore?

But here’s my product lens concern:

When I talk to our ML team, they say app deployment pipelines don’t understand their world. They need feature stores, model versioning, A/B testing for models, data drift monitoring. These aren’t just “deploy a container and call it done.”

Our platform team says building one pipeline that serves both personas means either:

  • Lowest common denominator (nobody’s happy)
  • Maximum flexibility (unmaintainable complexity)

The questions I’m wrestling with:

  • Is “unified” even the right goal? Maybe standardized interfaces between specialized systems is smarter than one pipeline trying to do everything?

  • Who wins and who loses? If we unify, do app developers get more complexity they don’t need? Do ML engineers lose tooling they depend on?

  • What’s the actual business case? “Unified” sounds good, but is the ROI in reduced operational overhead worth the migration pain and potential productivity hit for specialized teams?

I’d love to hear from folks who’ve tried this. Are you running unified pipelines that actually serve multiple personas well? Or are you keeping things separate and solving the integration problem differently?

What am I missing in this decision?

2

We went through this exact decision 18 months ago. We chose unified, and I’ll be honest about what we learned.

What actually happened:

We built one delivery pipeline that handles web apps, background services, ML models, and data products. Same CI/CD, same approval gates, same observability stack. The architectural bet was that models are just services with different SLIs.

What worked:

  • Governance at scale - When we needed SOC 2 compliance, we hardened one system, not three. When FinOps wanted cost gates, we implemented them once. Every control applies to everything.
  • Onboarding velocity - New ML engineers who already know Kubernetes can ship a model in days, not weeks. They learn our deployment process once.
  • Reduced operational burden - We have one on-call rotation for deployment infrastructure, not separate rotations for “app platform” and “ML platform.”

What broke (and what we had to fix):

  • Model-specific workflows got forced into container patterns - Our first unified pipeline didn’t understand model versioning or A/B testing for inference. ML engineers worked around it with custom scripts. We had to add first-class support for model registries and canary deployments.
  • Performance requirements diverged - App deploys needed speed (sub-5-minute builds), ML model training needed burst capacity (spin up 64 GPUs for 6 hours). We ended up with workload-specific execution pools but shared orchestration.
  • Monitoring blind spots - Our standard health checks (HTTP 200, latency p99) didn’t catch model drift or data quality issues. We had to integrate model observability as a deployment requirement.

The brutal truth:

“Unified” doesn’t mean “identical workflows for everyone.” It means common infrastructure with persona-specific abstractions.

Our platform now has:

  • One control plane (deployment approval, RBAC, cost tracking)
  • Persona-specific interfaces (web app deploy vs model deploy has different CLI commands)
  • Shared primitives (containers, resource quotas, observability)

ROI was real but delayed:

  • Year 1: Productivity hit. ML team slower because we didn’t support their workflows yet.
  • Year 2: Break-even. Feature parity achieved.
  • Year 3: 40% reduction in platform team size because we’re operating one system instead of three.

If I were making the decision today, I’d still choose unified. But I’d timebox “unified” to infrastructure and governance, not force identical user experiences across personas.

The question isn’t “unified vs separate.” It’s “what layer do you unify at?”

3

This hits home. We’re running separate ML and app platforms right now, and the organizational debt is crushing us.

The hidden cost nobody talks about:

It’s not just infrastructure duplication. It’s the team fragmentation.

  • Our app platform team (6 people) doesn’t understand ML requirements.
  • Our ML platform team (4 people) reinvents deployment patterns that already exist in the app platform.
  • Neither team talks to each other except during incidents.

When we had a security vulnerability in our base container images, we had to patch it twice—once in each platform. Different timelines, different rollout strategies, different communication plans.

The Conway’s Law trap:

We’ve accidentally created two platform organizations because we have two platforms. Guess what? Now our ML engineers and app developers live in different worlds.

An app developer can’t help debug an ML deployment. An ML engineer can’t reuse app platform tooling. We’ve built institutional silos through infrastructure decisions.

What’s working at my previous company (fintech):

They unified around Kubernetes as the common substrate, but built different control planes on top:

  • App developers use Heroku-style git push workflows
  • ML engineers use Kubeflow pipelines
  • Data engineers use Airflow for orchestration

All three compile down to Kubernetes resources. All three share the same RBAC, networking, and observability. But the user experience is persona-specific.

My advice:

Don’t ask “should we unify?” Ask:

  1. Can we share the infrastructure layer? (Kubernetes, service mesh, observability)
  2. Can we standardize governance? (RBAC, cost controls, compliance)
  3. Can we allow persona-specific interfaces? (Different CLIs, different abstractions)

If yes to all three, you get most of the benefits of “unified” without forcing everyone into the same workflow.

The alternative—parallel platforms—means you’re running two companies. That’s expensive and fragile.

4

Coming from the design systems world, this conversation feels deeply familiar.

A few years ago, we had the same “unified vs specialized” debate about component libraries:

  • Should we build one design system that serves web, iOS, Android, and marketing?
  • Or separate libraries optimized for each platform?

We tried unified first. It failed spectacularly.

Why “one library for everything” broke:

  • Web needs DOM-specific interactions (hover states, keyboard navigation)
  • iOS needs platform conventions (swipe gestures, bottom sheets)
  • Marketing needs brand flexibility (custom colors, one-off layouts)

A “unified” component meant either:

  • Lowest common denominator (works everywhere, optimal nowhere)
  • Configuration hell (37 props to handle every platform’s edge cases)

What actually worked:

Shared design tokens (colors, spacing, typography) but platform-specific implementations.

The design language is unified. The code is not.

This maps directly to platform engineering:

Unified:

  • Shared primitives (containers, resource limits, RBAC)
  • Shared governance (approval workflows, cost controls, security policies)
  • Shared observability (logging, metrics, tracing)

Specialized:

  • Deployment interfaces (web app deploy ≠ model deploy ≠ data pipeline)
  • Abstractions (Heroku-style for apps, Kubeflow for ML, dbt for data)
  • Defaults (app = fast startup, ML = GPU access, data = batch processing)

The question that clarified everything for us:

“What needs to be consistent across personas vs within a persona?”

Across personas (unified):

  • Security posture
  • Cost visibility
  • Compliance controls
  • Incident response

Within a persona (specialized):

  • Deployment commands
  • Testing workflows
  • Performance SLIs
  • Debugging tools

If you’re asking “unified vs separate platforms,” you’re asking the wrong question.

Ask: “What layer of abstraction do we unify at, and what do we specialize?”

ML engineers shouldn’t use the same deployment CLI as web developers. But they should absolutely share the same compliance gates.

5

The infrastructure decision is actually an organizational design decision in disguise.

When you choose “separate ML platform,” you’re choosing:

  • Separate hiring pipelines (platform engineers who understand Kubernetes vs ML platform engineers who understand Kubeflow)
  • Separate on-call rotations
  • Separate roadmaps and prioritization
  • Separate incident response processes

The talent pipeline question:

Where do you find “ML platform engineers” who understand both distributed systems AND model serving? That’s a tiny talent pool, and they’re expensive.

If you unify, you can hire platform engineers and cross-train them on ML requirements. Much larger hiring pool, much better retention (engineers who get to learn new domains tend to stay longer).

The team cohesion question:

At my previous company, we had app platform team and ML platform team. Guess what happened during outages?

  • App team blamed ML team for saturating shared networking
  • ML team blamed app team for not allocating enough GPU quota
  • Both teams pointed fingers, customers suffered

When we unified the teams (not just the infrastructure), accountability became clear. One team, one platform, one roadmap. Conflicts got resolved in planning, not during incidents.

The diversity question nobody asks:

Separate ML platforms create exclusive knowledge silos. If only 4 people understand your ML deployment system, you’ve created a bus factor of 4.

When those 4 people leave (and they will), you’re stuck. Unified platforms mean distributable knowledge. More people can contribute, more people can cover on-call, more people can debug production issues.

My recommendation:

Start with the organizational outcome you want, then design infrastructure to support it.

Do you want:

  • Agile, cross-functional teams that own features end-to-end (app + ML + data)?
    → Unified platform with persona-specific interfaces

  • Specialized centers of excellence where ML experts optimize ML infrastructure?
    → Separate platforms with strong integration contracts

We chose the first model. It’s been 2 years. Our app developers now ship ML features without waiting for “the ML team.” Our ML engineers contribute to platform improvements that benefit everyone.

The infrastructure enables the org design, not the other way around.