The platform and MLOps engineer

Measured on other people’s speed

A platform engineer builds the road other teams drive on. Nobody outside your team can name what you shipped, and the honest measure of your work is a question about somebody else: how long does it take a data scientist here to go from an idea to a model serving live traffic?

If the answer is eleven weeks, you have work. If it is two days, you have done the job.

The week

Somebody’s training run has been queued for four hours and they want to know why. A model is serving 300 milliseconds slower since Tuesday and nobody changed the model, so it is the infrastructure. Finance has sent the cloud bill with one line highlighted in yellow. A new starter needs access to five systems and the process for that is a document from 2023 that references a team which no longer exists. In between, you are building the thing that makes the next twenty deployments boring.

The idea that carries the role: paved roads

The temptation in platform work is to build a system so general it handles every possible case. The better instinct is a paved road: one well-supported way to do the common thing, documented, tested and fast, with an explicit exit for the rare team that needs something else.

A paved road for model deployment might be: put your model behind this interface, commit it here, and CI builds the container, runs the evaluation set, deploys behind a feature flag at 5% traffic, and rolls back automatically if error rate or latency crosses a threshold. Three teams using that beats twelve teams each inventing their own, even when each of their versions is slightly better suited to them.

The corollary is uncomfortable and important: a platform nobody adopts is worse than no platform, because it costs maintenance and splits the organisation. Adoption is the metric. If people are routing around you, they are telling you something true.

What MLOps adds beyond ordinary DevOps

Three things, and they are the reason the term exists at all.

• Models decay without anybody changing the code. The world moves and yesterday’s model is quietly worse. Nothing in ordinary software deployment prepares you for an artefact that rots on its own, so you need monitoring of input distributions and output quality, not just uptime.
• You must be able to answer “which data trained the thing currently serving?” Reproducibility spans code, data and configuration, which means versioning the data too.
• Rollback includes the model, not only the code. A rollback that restores the previous container but keeps the new model is not a rollback.

The stack

• Linux, networking and enough security to not be dangerous. This half is unglamorous and does most of the work.
• Containers and orchestration: Docker, Kubernetes. Free to learn locally with kind, k3s or minikube on an ordinary laptop.
• Infrastructure as code: Terraform or OpenTofu, both free; Pulumi if the shop prefers code.
• CI/CD: GitHub Actions and GitLab CI both have free tiers generous enough to run a real pipeline.
• Observability: Prometheus and Grafana, free and open source, are what the paid products are usually wrapping.
• Model-specific pieces: MLflow or similar for a model registry, KServe, BentoML or plain FastAPI for serving.

You can build a credible portfolio here on one machine: a model served in a container, deployed by a pipeline on every commit, with metrics on a Grafana dashboard and an automatic rollback rule. It costs nothing and demonstrates the entire role.

Two routes in

From DevOps, systems administration or backend. Add the model lifecycle. This is the shortest path into a well-paid seat that exists in this field, and it is under-advertised because people who could take it do not think of themselves as AI people.

From data science. Learn the systems half properly. Slower, but the resulting engineer is unusually valuable because they understand what the scientists actually need.

The failure that ends the first year

Building the platform in isolation and unveiling it. Six months of work meets three teams who each say “that does not fit how we work”, and they are right, because nobody asked them.

The alternative is to take one team’s real deployment, do it with them by hand, and only then generalise the parts that repeated. Platform work done as a service to a specific team first, and generalised second, almost always survives; the reverse almost never does.

The limitation

Your best days are invisible. When the platform works, nobody mentions it, and in performance reviews this is a genuine problem you must actively manage by measuring and reporting the things you removed: deployment time down from eleven days to two, cloud spend down 30%, four fewer incidents this quarter. If you do not count it, nobody will.