Donna Schut says the Practitioners' Guide to MLOps grew from customer requests for guidance on ML processes rather than only technical architecture.
2
Christos Aniftos recommends choosing MLOps capabilities from specific use cases and adding capabilities incrementally as new requirements appear.
3
Donna Schut and Christos Aniftos say successful MLOps work needs business support, platform-team support, cross-functional cooperation, and attention to tooling, costs, and ownership.
Summary
Donna Schut and Christos Aniftos explain how Google Cloud developed the Practitioners' Guide to MLOps from repeated customer questions. The guide describes six connected processes, including experimentation, training operationalization, continuous training, model deployment, prediction serving, and continuous monitoring. Data and model management supports traceability, compliance, reuse, and discovery across those processes. Christos argues that teams should select capabilities from concrete use cases instead of trying to build a complete platform immediately. He illustrates this with a call-center text analysis model that needs model monitoring and reuse, while continuous integration and delivery can wait. Donna describes customer work as an iterative cycle of pilots, feedback, internal collaboration, and repeated adoption. Both guests discuss obstacles in larger organizations, including interoperability, governance, cloud cost ownership, and the difficulty of standardizing tools across regional teams. They also describe communication, humility, and judgment about what is sufficient as important skills for ML engineers.
The guide came from customer requests about ML processes
Donna Schut says Google Cloud had already published guides about technical architecture and a broader AI Adoption Framework. Customer conversations kept returning to the processes around machine learning, so the team decided to share its guidance more broadly. Her team works with customers during the incubation phase, meeting them to understand requirements, piloting solutions, and improving them through feedback from customers and internal teams. Once a solution works repeatedly, they may publish the approach and help land it with customers. Christos Aniftos adds that customer needs are passed to product teams, but Google Cloud does not automatically build every requested feature. The team checks how broadly the need applies and looks for workarounds across the wider Google Cloud ecosystem.
The framework connects six ML processes around data and model management
Donna describes six integrated and iterative processes in the Practitioners' Guide to MLOps. They begin with ML development, experimentation, and prototyping. Training operationalization packages, tests, and deploys training pipelines. Continuous training runs those pipelines again when new data arrives or on a schedule. Model deployment packages, tests, and deploys models for online experimentation and production serving. Prediction serving handles inference from deployed models. Continuous monitoring looks for performance degradation, data drift, and outliers. Data and model management sits at the center, governing ML artifacts and supporting auditability, traceability, compliance, sharing, reuse, and discovery. Donna says organizations can reuse existing infrastructure, security, and CI/CD investments, then add ML-specific capabilities such as metadata tracking and ML pipelines.
Donna says customers usually deploy the framework in phases rather than implementing every process at once. Teams with only a few ML systems may start with development, model deployment, and prediction serving. Continuous training and monitoring may come later, depending on the use case. She describes a telecom example in which regional teams ran similar models with local requirements. Shared templates reduced repeated work while still allowing regional changes. A media company instead adopted capabilities around specific recommendation and audience-segmentation use cases to reach the market faster. These examples led to a separate article about selecting MLOps capabilities by use case. The advice is practical: the platform grows from the work teams actually need to do.
Christos says building a broad ML platform is different from adding a few ML capabilities. A platform must address access, data, security, user permissions, and how data scientists and ML engineers move assets from development onward. He recommends starting with one or a few use cases. If an organization mostly works with structured data, it can prioritize capabilities for that type of workload. A later image-based use case may require different capabilities, which can then be added. Christos describes this as an incremental process rather than an attempt to build the best possible platform immediately. Once a capability such as a feature store or continuous training exists, other use cases may use it, even when it was not an initial priority. The use case determines what comes next.
The call-center example separates requirements from preferences
Christos applies the selection guidance to a hypothetical model that analyzes call-center transcripts for complaints and customer-service reports. Because the report is internal and errors would not directly create financial or reputational damage, he classifies it as non-mission-critical. Full metadata and artifact tracking therefore do not need to be the first priority. The model may be reusable by another department, which creates a need for a model registry, tags, descriptions, and performance information. Since the language model does not need frequent retraining, a training service is still needed, while continuous retraining is unnecessary. Monitoring remains important because the model can become stale when language or products change. The internal batch use case does not require online experimentation or A/B testing. Continuous integration and delivery can also wait when code changes are infrequent.
Large organizations need adoption through usefulness
Christos says small teams can agree quickly on how to build and productionize ML systems. Global organizations have a harder problem because they need tools that reflect local needs while still being shared in a standardized way. Teams cannot simply enforce one architecture everywhere. The platform must be useful enough that local groups choose it because it makes their work easier. Donna adds that successful efforts often combine demand from the business with support from a platform team. She also sees interoperability problems when customers use several tools or vendors. Moving to Google Cloud can change cost management because teams may create and remove resources more easily than when a central team owned the budget. Labels, transparent ownership, and FinOps practices can help address that change.
ML engineers need communication and judgment as well as technical skills
Donna describes an internal study of strong ML engineers. Technical knowledge includes distributed systems, testing, and security, but the work also requires strong communication because ML sits between many teams. She mentions a humble approach because the field changes quickly. She also values knowing what is good enough. That judgment matters when different teams, use cases, and constraints make a single architecture unsuitable. The comments connect back to Christos's advice about prioritizing the capabilities a use case needs. An engineer may know how to build continuous delivery or detailed metadata tracking, but the immediate task may not justify either investment. The guests present cross-functional work as a normal part of building maintainable ML systems, rather than as work limited to ML specialists.
"We don't want to kind of impose that, you know, everybody has petabytes of data and therefore we try to kind of adapt our solutions in different scenarios depending on different customer needs."Christos Aniftos09:49
Who should watch
You are deciding which MLOps capabilities to build first and need a way to scope the work to actual use cases.
Your organization is moving from individual ML projects toward a shared platform, especially across regional or cross-functional teams.
You want practical guidance on when monitoring, registries, CI/CD, continuous training, and other capabilities are worth adopting.
