{"course":{"slug":"ai-careers","title":"Working in AI","url":"https://addaly.com/learn/ai-careers","level":"beginner","track":"work"},"lesson":{"slug":"platform-and-mlops-in-depth","title":"The platform and MLOps engineer","url":"https://addaly.com/learn/ai-careers/platform-and-mlops-in-depth","position":16,"of":85,"minutes":9,"answer":"Platform and MLOps work is judged by other teams' delivery speed and by adoption, so build one well-supported road with a real team before generalising it.","keyIdea":"Platform and MLOps work is judged by other teams' delivery speed and by adoption, so build one well-supported road with a real team before generalising it."},"body":{"format":"markdown","text":"## Measured on other people's speed\n\nA 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?\n\nIf the answer is eleven weeks, you have work. If it is two days, you have done the job.\n\n## The week\n\nSomebody'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.\n\n## The idea that carries the role: paved roads\n\nThe 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.\n\nA 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.\n\nThe 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.\n\n## What MLOps adds beyond ordinary DevOps\n\nThree things, and they are the reason the term exists at all.\n\n- **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.\n- **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.\n- **Rollback includes the model, not only the code.** A rollback that restores the previous container but keeps the new model is not a rollback.\n\n## The stack\n\n- **Linux, networking and enough security to not be dangerous.** This half is unglamorous and does most of the work.\n- **Containers and orchestration**: Docker, Kubernetes. Free to learn locally with kind, k3s or minikube on an ordinary laptop.\n- **Infrastructure as code**: Terraform or OpenTofu, both free; Pulumi if the shop prefers code.\n- **CI/CD**: GitHub Actions and GitLab CI both have free tiers generous enough to run a real pipeline.\n- **Observability**: Prometheus and Grafana, free and open source, are what the paid products are usually wrapping.\n- **Model-specific pieces**: MLflow or similar for a model registry, KServe, BentoML or plain FastAPI for serving.\n\nYou 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.\n\n## Two routes in\n\n**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.\n\n**From data science.** Learn the systems half properly. Slower, but the resulting engineer is unusually valuable because they understand what the scientists actually need.\n\n## The failure that ends the first year\n\nBuilding 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.\n\nThe 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.\n\n## The limitation\n\nYour 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."},"check":{"question":"A platform team spent six months building a general model-deployment system. Three product teams have each declined to use it and continued with their own scripts. What is the most productive response?","options":[{"text":"Mandate the platform through an engineering policy so the organisation stops fragmenting.","correct":false,"tempting":"Forces adoption of something unvalidated, which produces compliance rather than usage and hides the mismatch instead of fixing it."},{"text":"Take one team's real deployment, do it end to end with them using the platform, fix whatever breaks, and generalise only the parts that then repeat across a second team.","correct":true},{"text":"Add the missing features each team asked for, so the platform covers all three cases.","correct":false,"tempting":"Treats generality as the gap when the evidence is that the road was never paved with a real driver on it, so each added feature is another guess."},{"text":"Publish better documentation and run an internal training session.","correct":false,"tempting":"Assumes a knowledge problem, but the teams understand the platform well enough to have decided against it."}]},"prev":{"slug":"ai-engineer-in-depth","title":"The AI engineer","url":"https://addaly.com/learn/ai-careers/ai-engineer-in-depth"},"next":{"slug":"applied-scientist-in-depth","title":"The applied scientist and research engineer","url":"https://addaly.com/learn/ai-careers/applied-scientist-in-depth"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The platform and MLOps engineer', in Working in AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/ai-careers/platform-and-mlops-in-depth (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The platform and MLOps engineer","courseTitle":"Working in AI","module":{"index":2,"slug":"the-roles-in-depth","title":"The roles, one at a time"},"answer":null,"keyIdea":"Platform and MLOps work is judged by other teams’ delivery speed and by adoption, so build one well-supported road with a real team before generalising it.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"measured-on-other-people-s-speed","runs":[{"text":"Measured on other people’s speed"}]},{"t":"p","runs":[{"text":"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?"}]},{"t":"p","runs":[{"text":"If the answer is eleven weeks, you have work. If it is two days, you have done the job."}]},{"t":"h2","id":"the-week","runs":[{"text":"The week"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-idea-that-carries-the-role-paved-roads","runs":[{"text":"The idea that carries the role: paved roads"}]},{"t":"p","runs":[{"text":"The temptation in platform work is to build a system so general it handles every possible case. The better instinct is a "},{"text":"paved road","b":true},{"text":": 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"The corollary is uncomfortable and important: "},{"text":"a platform nobody adopts is worse than no platform","b":true},{"text":", because it costs maintenance and splits the organisation. Adoption is the metric. If people are routing around you, they are telling you something true."}]},{"t":"h2","id":"what-mlops-adds-beyond-ordinary-devops","runs":[{"text":"What MLOps adds beyond ordinary DevOps"}]},{"t":"p","runs":[{"text":"Three things, and they are the reason the term exists at all."}]},{"t":"ul","items":[[{"text":"Models decay without anybody changing the code.","b":true},{"text":" 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."}],[{"text":"You must be able to answer “which data trained the thing currently serving?”","b":true},{"text":" Reproducibility spans code, data and configuration, which means versioning the data too."}],[{"text":"Rollback includes the model, not only the code.","b":true},{"text":" A rollback that restores the previous container but keeps the new model is not a rollback."}]]},{"t":"h2","id":"the-stack","runs":[{"text":"The stack"}]},{"t":"ul","items":[[{"text":"Linux, networking and enough security to not be dangerous.","b":true},{"text":" This half is unglamorous and does most of the work."}],[{"text":"Containers and orchestration","b":true},{"text":": Docker, Kubernetes. Free to learn locally with kind, k3s or minikube on an ordinary laptop."}],[{"text":"Infrastructure as code","b":true},{"text":": Terraform or OpenTofu, both free; Pulumi if the shop prefers code."}],[{"text":"CI/CD","b":true},{"text":": GitHub Actions and GitLab CI both have free tiers generous enough to run a real pipeline."}],[{"text":"Observability","b":true},{"text":": Prometheus and Grafana, free and open source, are what the paid products are usually wrapping."}],[{"text":"Model-specific pieces","b":true},{"text":": MLflow or similar for a model registry, KServe, BentoML or plain FastAPI for serving."}]]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"two-routes-in","runs":[{"text":"Two routes in"}]},{"t":"p","runs":[{"text":"From DevOps, systems administration or backend.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"From data science.","b":true},{"text":" Learn the systems half properly. Slower, but the resulting engineer is unusually valuable because they understand what the scientists actually need."}]},{"t":"h2","id":"the-failure-that-ends-the-first-year","runs":[{"text":"The failure that ends the first year"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A platform team spent six months building a general model-deployment system. Three product teams have each declined to use it and continued with their own scripts. What is the most productive response?"}],"options":[{"text":[{"text":"Mandate the platform through an engineering policy so the organisation stops fragmenting."}],"correct":false,"tempting":[{"text":"Forces adoption of something unvalidated, which produces compliance rather than usage and hides the mismatch instead of fixing it."}]},{"text":[{"text":"Take one team’s real deployment, do it end to end with them using the platform, fix whatever breaks, and generalise only the parts that then repeat across a second team."}],"correct":true,"tempting":null},{"text":[{"text":"Add the missing features each team asked for, so the platform covers all three cases."}],"correct":false,"tempting":[{"text":"Treats generality as the gap when the evidence is that the road was never paved with a real driver on it, so each added feature is another guess."}]},{"text":[{"text":"Publish better documentation and run an internal training session."}],"correct":false,"tempting":[{"text":"Assumes a knowledge problem, but the teams understand the platform well enough to have decided against it."}]}],"order":[0,1,3,2],"why":null},"prev":{"slug":"ai-engineer-in-depth","title":"The AI engineer","minutes":10},"next":{"slug":"applied-scientist-in-depth","title":"The applied scientist and research engineer","minutes":9}}}