From DevOps to MLOps and platform engineering: what to learn

The uncomfortable question every DevOps engineer is asking#

There's a conversation that keeps coming up in infrastructure teams: if AI can write YAML, generate basic pipelines, review logs and propose starting configurations, what's left of the traditional DevOps role?

It's a fair concern. Much of the work that defined a DevOps engineer for years is manual, repetitive and automatable, what Google's SRE book calls toil. That is exactly the kind of work AI tools keep getting better at. Generating a Kubernetes manifest, sketching a CI/CD pipeline or summarizing a stack trace no longer sets you apart.

But reading “part of my job is being automated” as “my role is disappearing” is a mistake. DevOps isn't dying; it's moving up the value chain, and the people who see that shift early end up in more strategic roles.

Documentation: Google SRE Book · Eliminating Toil ↗

DevOps doesn't disappear: its center of gravity shifts#

The future of DevOps isn't writing less infrastructure. It's designing better infrastructure and letting repetitive execution be automated.

As AI absorbs the basic operational layer, value moves to what AI doesn't do well: architecture decisions, cost and performance trade-offs, designing secure and scalable platforms, and running complex systems in production without 3 a.m. outages.

Three disciplines capture that shift, and all three are a natural evolution of a DevOps profile rather than a career change:

• Platform engineering: building internal platforms the rest of the organization consumes self-service.
• MLOps: getting machine learning and AI models into production reliably, reproducibly and with monitoring.
• DevSecOps: building security and compliance into the design instead of patching it on at the end.

The good news: if you come from DevOps, you've already covered much of the ground.

From DevOps to platform engineering: from operating to enabling#

Platform engineering answers a real problem: development teams don't want to become Kubernetes, networking and cloud configuration experts just to ship an application. Every hour a developer spends fighting infrastructure is an hour not spent on product.

The traditional DevOps role handled this through tickets. Platform engineering handles it by building an internal product: golden paths, secure-by-default templates and self-service that hide cloud complexity. DORA reports that by 2025, 90% of organizations said they used an internal developer platform and 76% had dedicated platform teams.

The mindset shift is big. You stop running deployments and start designing the system through which hundreds of deployments happen on their own. Your customer is no longer a server but the internal developer, and your metric is no longer “ticket closed” but how long it takes a team to get code to production safely.

The fundamentals, Kubernetes, infrastructure as code, automation, pipelines and observability, are still the foundation. What you add is product thinking, developer-experience design and a sense for standardization. Backstage, the developer portal framework Spotify donated to the CNCF, is a good place to see how a catalog of services and templates is modeled.

Documentation: DORA · Platform engineering ↗ · CNCF TAG App Delivery · Platforms white paper ↗ · Backstage · What is Backstage? ↗

From DevOps to MLOps: infrastructure is the real challenge of AI in production#

There's an expensive myth that AI is mostly a data science problem. Google's paper on hidden technical debt in ML systems makes the point clearly: the model code is a small fraction of the system, surrounded by data collection, configuration, serving, monitoring and infrastructure. Keeping a model in production, with low latency, detecting degradation, retraining when data changes, controlling GPU cost and keeping it traceable, is an infrastructure and operations problem. In other words, your turf.

MLOps is essentially DevOps applied to the model lifecycle, and most of what you know carries over:

• CI/CD pipelines extend to versioning data and models, not just code; Google frames this as moving from manual deployments to continuous training.
• Observability widens: beyond CPU and latency you track data drift, concept drift and prediction quality.
• Automation covers retraining and rolling out new model versions.
• Cost management becomes critical: AI runs on expensive compute, and someone has to design infrastructure that scales without burning the budget.

What's new is vocabulary and tooling: model registries, feature stores, dataset versioning, serving frameworks and model monitoring. New concepts, built on fundamentals you already have. A model registry, for instance, is to a model what an image registry is to a container:

import mlflow
from mlflow import MlflowClient

MODEL = "fraud-detector"
run_id = "<training-run-id>"   # handed over by the training pipeline

# 1. Register the artifact as a new model version
mv = mlflow.register_model(f"runs:/{run_id}/model", MODEL)

# 2. Promote only if it passed automated evaluation in CI
client = MlflowClient()
client.set_registered_model_alias(MODEL, "champion", mv.version)

# 3. The inference service loads the alias, not a pinned version:
#    rolling back means pointing the alias at the previous version.
model = mlflow.pyfunc.load_model(f"models:/{MODEL}@champion")

Managed services follow the same logic: SageMaker Model Monitor and Vertex AI Model Monitoring compare production traffic against a baseline and alert when it drifts.

Documentation: NeurIPS 2015 · Hidden Technical Debt in Machine Learning Systems ↗ · Google Cloud · MLOps: continuous delivery and automation pipelines in ML ↗ · MLflow · Model Registry ↗ · AWS · SageMaker Model Monitor ↗ · Google Cloud · Vertex AI Model Monitoring ↗

DevSecOps: security stops being optional#

As infrastructure carries AI, automation and sensitive data, the attack surface grows and regulation tightens. DevSecOps becomes part of the baseline design: secrets management, policy as code, continuous scanning, access control and auditable compliance from the first commit.

NIST's Secure Software Development Framework (SP 800-218) is a solid reference for organizing those practices, and tools like Open Policy Agent let you express deployment rules as reviewable code.

For a DevOps engineer this is a clear specialization path: a company that adopts AI without a solid security layer is building a liability, not an advantage.

Documentation: NIST SP 800-218 · Secure Software Development Framework ↗ · Open Policy Agent · Documentation ↗

What to prioritize so you don't start from scratch#

With a solid DevOps foundation you don't need to reinvent yourself, just reorient. A reasonable order:

• Take Kubernetes and infrastructure as code to design level, not just usage; include GPU scheduling on Kubernetes if you're heading toward MLOps.
• Master real observability: metrics, traces and logs, and above all the ability to explain how a system behaves in production. OpenTelemetry is the open standard worth knowing.
• Learn the model lifecycle: data and model versioning, serving, retraining and drift monitoring.
• Think in platforms and costs: self-service, scalability and cloud spend efficiency.
• Treat security as design, not a patch.
• Use AI as a multiplier: let it automate the repetitive work so you can focus on architecture and decisions.

Documentation: Kubernetes · Schedule GPUs ↗ · OpenTelemetry · What is OpenTelemetry? ↗ · Kubeflow · Pipelines overview ↗

Infrastructure is still the foundation#

AI doesn't remove the need for good infrastructure; it amplifies it. Every model in production, every agent and every automated workflow sits on compute, networking, security, pipelines and observability that someone has to design and run well. That layer decides whether an AI project scales profitably or turns into a cost sink.

That's why the DevOps profile isn't going extinct. It sits at the center of the next wave, as long as it moves from operational execution to strategic design. You can't build AI on makeshift infrastructure, and building that foundation remains the most valuable work in DevOps.

Frequently asked questions#

What's the difference between MLOps and platform engineering? MLOps manages the lifecycle of models in production; platform engineering designs self-service internal platforms for developers. Both grow out of DevOps with a different focus, and in many companies the platform ends up offering MLOps capabilities as one more service.

Which technical skills do I need for MLOps? ML fundamentals, pipeline orchestration with tools like Kubeflow or MLflow, and production model monitoring: data drift, concept drift and inference latency. You don't need to become a data scientist.

Is learning DevOps still worth it? Yes. Automation, CI/CD and infrastructure as code are the foundation of both specialties. What changes is the focus: designing systems and platforms instead of repetitive manual execution.

How do I get started with platform engineering? Accept that you're building a product for other developers. Explore golden paths and Backstage, and measure success by fewer support tickets and less time for a new team to ship.

What happens if I don't evolve my profile? The risk is commoditization: manual operational work is increasingly automatable, and professional value is shifting toward architecture, platform design and running complex systems.

Documentation: Backstage · What is Backstage? ↗ · Kubeflow · Pipelines overview ↗ · MLflow · Model Registry ↗