架构上进行了分层抽象，实现上也只需要三步。
第一步是创建一个Docker镜像，下面的Dockerfile例子是从TensorFlow项目中截取出来的，官方已经提供了一个可以运行的Docker镜像，通过加入定制的启动脚本就可以实现开发环境、模型训练以及模型服务等功能。
第二步是实现一个标准的API服务，下面是一个Python实现的实例，用户发送一个启动训练任务的请求，服务端可以解析请求的参数和内容，并将任务提交到Kubernetes等后端集群中。
第三步是生成Kubernetes所需的文件格式，下面的JSON文件大家也可以在GitHub中找到，实现了将分布式TensorFlow任务提交到Kubernetes集群中运行。
我们通过简单的三个配置就可以完成机器学习任务从本地到云端的迁移过程，也就是实现了Cloud Machine Learning服务。前面提到云深度学习平台需要支持资源隔离和资源共享，这是如何实现的呢，其实Kubernetes本身就有这个抽象，用户可以在请求时申明需要的CPU、内存、甚至是GPU资源，通过cgroups、namespace等容器技术来实现资源隔离，而kube-scheduler实现了资源调度和资源共享等功能。实现自研或者公有云的Cloud Machine Learning平台，开发者可以很容易提交训练任务、创建模型服务等，但在一个真实的机器学习场景中，只解决计算资源的隔离和调度是远远不够的，我们还需要重新思考如何集成数据处理、特征工程等问题。
重新定义云深度学习平台TensorFlow是一个可用于深度学习的数值计算库，基于TensorFlow可以实现MLP、CNN、RNN等机器学习模型，但有了它是不是就不需要Spark呢？他们的关系是什么？
在生产环境中，我们发现TensorFlow并没有完全取代已有的大数据处理工具，我们需要用Spark做数据分析和特征工程，还需要数据仓库等服务去存储和查询结构化数据。TensorFlow是一个非常优秀的深度学习框架，但在真实场景中用户还需要一些PowerGraph处理的图关系特征作为输入，这都是单独一个框架无法解决的。对于用户的建模流程如何组织、如何做数据清洗、如何做特征抽取、如何上线训练好的模型、如何预估模型效果，这些可以使用Azure ML Studio工具去完成，而且是TensorFlow所缺乏的。
前面我们介绍了Cloud Machine Learning，可以实现一个类似Google的分布式、高可用、带集群编排的计算平台，但这远远不够，因为我们还需要使用大数据处理的框架，包括MapReduce、流式处理、图计算等框架。TensorFlow只是整个机器学习流程里面做模型训练其中一部分，我们可能还需要Kubernetes做CPU、GPU的管理和调度。如果我们要完成一个机器学习的业务，就需要同时掌握TensorFlow、Spark、Hadoop、Hive、Kubernetes等框架的原理和应用，而不只是提供一个Google Cloud-ML或者AWS服务就够了，这也是我们要重新定义Cloud Machine Learning的原因。
前面在客观上我们需要这么多知识，但主观上我们希望有什么呢？我们更希望有一个从数据处理到模型训练再到模型上线的一个全闭环服务，而不仅仅是机器学习框架或者通用计算平台，我们希望不写代码就可以做特征抽取的工作，我们希望机器学习的工作流是很容易描述的，而不需要通过编写代码的方式来实现，我们需要一个很灵活的基础架构可以支持各种异构的计算资源，我们希望平台是可拓展的可以实现自动Failover和Scaling。 除了前面提到的Google、微软、亚马逊做的云机器学习平台，我们还需要从IaaS、PaaS、SaaS多维度上提供使用接口，满足不同层次用户的使用需求，另一方面这应该是低门槛的产品服务，让任意的领域专家都可以轻易使用。
后面我们会介绍在真实场景下如何改造Cloud Machine Learning平台，并且介绍第四范式对外提供的低门槛、分布式、高可用的先知机器学习平台。
第四范式的云深度学习实践经验第四范式先知平台是一个基于Cloud的全流程机器学习产品，用户通过Web登陆到先知平台就可以使用模型调研、预估服务的功能，并且可以通过拖拽的方式来描述机器学习的工作流 。