Cloud Foundry

问题症状： 我在CloudFoundry环境的Service Market place里根本找不到Leonardo ML foundation这组服务。 解决方案： 进入global Account->Entitlements->Subaccount Assignments, 点击Configure Entitlements： 再点击Add Service Plans按钮： 从Service Catalog的All Categories列表里，选中SAP Leonardo Machine Learning foundation： 之后这个Service就出现在Service Assignments里了： 现在，该account的Service Marketplace里终于能看见SAP Leonardo Machine Learning服务了。 要获取更多Jerry的原创文章，请关注公众号"汪子熙": 来源： oschina 链接： https://my.oschina.net/u/3771578/blog/3073922

Jerry之前的两篇文章介绍了如何通过Restful API的方式，消费SAP Leonardo上预先训练好的机器学习模型： 如何在Web应用里消费SAP Leonardo的机器学习API 部署在SAP Cloud Platform CloudFoundry环境的应用如何消费 当时Jerry提到，Product Image Classification API只支持29种产品类别： 如果我们开发应用时需要支持额外的产品类别，就得需要自行提供该产品类别的图片并重新训练。 下面是SAP Leonardo上机器学习模型的重新训练步骤。 假设我们期望重新训练之后，Product Image Classfication这个模型能够识别出不同种类的花，那么我们首先得搞到大量花的图片。Tensorflow的官网上，已经体贴地给想做模型训练的学习者们，提供了一个做练习用的压缩包，里面包含了大量各式花的图片。 http://download.tensorflow.org/example_images/flower_photos.tgz SAP Leonardo接受的能用于重新训练模型的数据集，必须符合下列的层级结构，即training, validation和test三个文件夹下面，分别包含以产品类别命名的字文件夹，且数据规模之比为8:1:1. 有了用于训练的数据后，下一步就是把这些数据上传到SAP

Jerry的前一篇文章 如何在Web应用里消费SAP Leonardo的机器学习API 里介绍的例子是Neo测试环境的Web应用消费sandbox版本的机器学习API，url如下： https://sandbox.api.sap.com/ml 本文介绍一个部署在SAP Cloud Platform CloudFoundry环境下的应用，如何消费SAP Leonardo上的机器学习API。 登录SAP Cloud Platform Cockpit，进入CloudFoundry环境的Service Marketplace，找到SAP Leonardo机器学习的服务，单击该服务的超链接进入明细页面： 创建一个新的服务实例： Service Plan就选默认的standard： 给这个服务实例取个名字： 单击这个创建好的服务实例，然后创建一个新的Service Key： 给Service Key也取个名字。 我们通过创建Service instance进而创建Service Key的目的，是为了得到下图的clientid和clientsecret。 而我们拿到clientid和clientsecret，是为了用它们换取OAuth2.0协议里的access token. 关于更多clientid和clientsecret基于OAuth2.0换取access token 的细节

一天天的,PaaS深入人心，Cloud Foundry为首的传统PaaS，开始蓄力基础设施领域的 平台化 和 PaaS化 ,于是发现了PaaS中的问题 1 如何给应用打包 Cloud Foundry/OpenShift/Clodify都没给出答案，走向碎片化歪路 此时，名不见经传的PaaS创业公司dotCloud，却选择了开源自研的容器项目 Docker 谁也不会料到,就这样一个平淡无奇古天乐一般的技术，开启了名为“Docker”的新时代 这个🐳公司，最重要的战略之一就是：坚持把**“开发者”群体放在至高无上的位置** Docker项目的推广策略从一开始就呈现出一副“憨态可掬”的亲人姿态，把每一位后端技术人员（而不是资本家）作为主要的传播对象。 简洁的UI，有趣的demo，“1分钟部署一个WordPress网站”“3分钟部署一个Nginx集群”，这种同开发者之间与生俱来的亲近关系，使Docker项目迅速成为了全世界会议上最受追捧的新星 > Docker项目，给后端开发者提供了走向聚光灯的机会 > 比如Cgroups和Namespace这种已经存在多年却很少被人们关心的特性，在2014年和2015年竟然频繁入选各大技术会议的分享议题，就因为听众们想要知道Docker这个东西到底是怎么一回事儿。 一方面解决了应用打包和发布这一困扰运维人员多年的技术难题 另一方面

容器!容器! 回溯历史源头 相比于盛极一时的 AWS OpenStack 以Cloud Foundry为代表的PaaS项目，却成了当时云计算技术中的一股清流 Cloud Foundry项目已经基本度过了最艰难的概念普及和用户教育阶段，开启了以开源PaaS为核心构建平台层服务能力的变革 只是,后来一个叫 Docker 的开源项目横空出世 当时还名叫 dotCloud 的 Docker 公司，也是PaaS热潮中的一员 相比于Heroku、Pivotal、Red Hat等PaaS新宠， dotCloud 微不足道，主打产品跟主流的Cloud Foundry社区脱节，门可罗雀! dotCloud 公司突然决定：开源自己的容器项目 Docker ！！！ 显然，这个决定在当时根本没人在乎。 “容器”这个概念从来就不是什么新鲜的东西，也不是Docker公司发明的。 即使在当时最热门的PaaS项目Cloud Foundry中，容器也只是其最底层、最没人关注的那一部分。 PaaS项目被大家接纳的一个主要原因是它提供“应用托管”能力 那时主流用户的普遍用法，就是租一批AWS或者OpenStack的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。 当然，部署过程难免碰到云端虚拟机和本地环境不一致问题，当时的云计算服务，比的就是谁能更好模拟本地服务器环境，带来更好“上云

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal