Paas 比较
在2015的微软//Build大会中，Mark介绍了当前微软的公有云服务栈，提出Open Choice at Every Layer。
The Next Generation of Azure Compute Platform with Mark Russinovich
Open意味着更有活力，更多选择。这诚然是个好事，不过也意味着要学习更多知识。我对Azure Cloud Service 有4年的使用经验，ServiceFabric则是刚刚入门。在学习SF的过程中发觉，文档组织的有些混乱，脑子里的知识很零散，很容易遗忘。在看CloudFoundry时，发觉更加困难，不知如何开始。
为了把知识连接和巩固起来，我从Azure Cloud Service和中提炼出一些关键概念，然后在SF中寻找相关文档，学习它的运行方式。同时，发掘两个PaaS明显区别，进行详细比较并理解其缘由。在学习CloudFoundry时，用了同样的办法。作为学习的一个产出，有了如下这篇文章。文章中的误差和错误在所难免，随着进一步学习，会继续更新。
Candidate
Azure Cloud Service（或者叫Azure PaaS v1）, Service Fabric, Cloud Foundry
Factor
Architecture ： 从架构入手观察全局，避免迷失在细节中。
Dependency ： 依赖性决定了PaaS能在哪里运行，移植性。
Application running environment ： 应用程序的运行环境决定了应用程序能够控制的环境，从而影响应用程序的功能（Dev Functionality）。
Dev Functionality ： 如用那种开发语言，什么操作系统，存储访问方式等等。
Deploy ： 部署，包含PaaS环境的搭建以及应用程序的部署/更新。
Telemetry ： Logging & Metrics & Analytics。
Auto-recovering ： PaaS如何检测和自动恢复故障中的服务，需要多少人为干预。
Availability ： PaaS基础服务以及应用程序的可用性分析。
Scalability ： PaaS基础服务以及应用程序的规模伸缩性。
Performance ： 性能的比较太复杂，所以目前把它排除在外。
Comparison
Architecture
Azure Cloud Service 架构和组件
Cloud Foundry架构和组件
Dependency
azure cloud service 比azure iaas vm诞生还要早，是azure platform土著居民。Azure platform FC原生支持 cloud service stateless vm instance， 其好处是支持真正的 elistic auto scale，直接向azure 数据中心申请计算资源(vm)。不过cloud service 并非建立在azure iaas之上，其紧密依赖于FC，难以独立运行在其他云计算环境中。
service fabric 也叫 azure paas v2, 它建立在 azure公开的iaas服务上（VM, VM extension, VM scaleSet, Virtual Network, Azure Resource Manager，Availability Group），对azure内部没有紧密耦合。这样使其具有迁移其他平台的潜力，未来可以独立与Azure cloud，运行在win server， azure stack，甚至linux cluster上。
Cloud Foundry 是独立与云计算提供商的PaaS解决方案，它不和Cloud provider直接打交道，而是通过Bosh来完成系统的provision。bosh暴露了一组接口 cloud provider interface（CPI），cloud provider 只要实现了CPI，即可运行Bosh，也就可以运行Cloud Foundry。 因此，CF对底层云平台的依赖度很小
App Running Environment
Azure Cloud Service每个服务（角色）实例独占一台虚拟机，用户代码的访问边界即为虚拟机。运行环境初始化(如安装中间件)可由startup script完成。Azure虚拟机有多种型号可供选择，每个型号拥有不同的CPU核数，内存空间，硬盘空间和网络带宽。不过，相比于Process，Container，虚拟机的资源粒度仍然过大。
Service Fabric运维一组虚拟机组成的虚拟机资源池，所有的用户服务作为micro-service运行在虚拟机中。即每个服务实例作为虚拟机中的一个进程，共享虚拟机资源。SF提供load balance底层服务，减少进程间的影响。中间件如何安装(Java runtime, web server)? 另外，随着Win server 2016发布，SF未来会支持 Windows Container作为服务运行环境。
Cloud Foundry 同样运维一组虚拟机组成的资源池（Cells），用户代码运行在虚拟机上创建的Container中，container可以分配给定的内存大小，隔离性要比Process好。中间件可由buildpack完成，使用方便。集成 Diego后， Cloud foundry可以支持Docker镜像，这样，用户可以充分控制Container环境。
Dev Functionality
| Azure PaaS V1 | Service Fabric | Cloud Foundry | |
| Dev Language | 提供了多种语言的SDK，还提供接口运行cmd, exe | 提供了.net SDK，还提供接口运行cmd, exe | 通过Buildpack 支持多种语言 |
| OS environment | Windows Server Only | Windows Server (Linux in plan) | Linux, Windows(Iron Foundry) |
| Middleware | 使用startup script 配置 | 无* | Buildpack, stack |
| Storage | 本地磁盘做临时存储，external storage保存 persistent data | Reliable collection做replica数据同步。external storage保存 persistent data | external storage保存 persistent data |
Deploy
Azure Cloud Service：当部署用户Application时，通过SDK把代码和配置文件编译&打包，之后可以通过Azure管理门户或者Management API直接部署到云端。代码Update支持deployment swap 和 in-place update 两种方式，都能实现无downtime的部署。
Service Fabric：在部署应用程序前，需要首先在云平台上provision Service Fabric Cluster，随后通过Service Fabric提供的API来部署应用。 SF支持 in-place update，在更新过程中，支持health monitor和rollback。
Cloud Foundry：同样，在部署应用程序前，需要首先在云平台上provision Cloud Foundry Instance，随后通过SF CLI来部署应用。CF支持 Blue-Green Deployment，类似与azure deployment swap。Cloud Foundry的 Application没有层级关系（Azure Cloud Service 有 Role的概念，Service Fabric 有 Service），因此在部署和更新复杂系统时，Cloud Foundry可能需要更多的额外操作。另外当应用程序的部署规模很大时，使用deployment swap更新并不合适。
Telemetry
Azure Cloud Service：使用Windows Azure Diagnostics Extension（WAD） 来收集Log 和 Metrics。Log可由Azure IoT套件来做进一步分析， Metrics可以作为Scale Service 的输入，实现根据负载而动态Scale。
Service Fabric：默认的Logging机制是输出到虚拟机的Event Log，然后通过 WAD来上传到云存储。Metrics同样可以使用WAD。同时，SF提供Application level的Metrics接口，可由Application 汇报workload，SF的load balancer根据metrics完成负载平衡的工作。
Cloud Foundry：Cloud Foundry 使用 Loggregator 组件来完成Log/Metrics 收集工作，同时暴露接口供下游数据筛选和处理（Firehose, Nozzles）https://docs.cloudfoundry.org/loggregator/architecture.html
运行在Azure VM之上的 CF也可以使用 WAD完成虚拟机level的logging
Auto-Recovering
Azure Cloud Service：通过GuestOS Agent检测并汇报VM state给Fabric Controller，Fabric Controller take action (restart, reboot, reimage) to recover Instances. Cloud Service自身不能检测到僵尸实例，需要由外部系统来检测其功能性。https://blogs.msdn.microsoft.com/kwill/2011/05/05/windows-azure-role-architecture/
Service Fabric: 一旦replica或host VM出问题，由failover service 检测并恢复。
Cloud Foundry：由HM9000 或 Diego中的Converger 和Cell Rep 检测和恢复Application。
Availability
Azure Cloud Service: 对于用户的服务，当每个Role运行至少2个实例时，Azure平台确保99.95%的服务可用性。Azure Cloud Service的底层模块RDFE，FC…都是Azure平台组件，客户不需要维护其可用性。
Service Fabric：Azure平台保证cluster 99.95%的可用性。应用程序通过创建多replica确保高可用性。SF的基础服务也作为特别的Application运行在SF cluster上。
Cloud Foundry: 应用程序通过创建多实例确保高可用性。CF controller不同模块的高可用性方案不相同，参考 https://docs.cloudfoundry.org/concepts/high-availability.html，相比于上述两种Paas offer，CF高可用需要更多的配置。
Scalability
Azure Cloud Service: 直接从Azure数据中心申请虚拟机资源，伸缩非常方便。通过Scale Service可以方便的实现auto-scale。虚拟机大小可以调整，但是需要重新部署。
Service Fabric：SF的scale分两个level，application level指的是application partition和replica的伸缩，可以通过SF API完成。SF cluster level指的是虚拟机数量的伸缩，这个需要通过Azure Management API来调整ScaleSet规模。
Cloud Foundry：CF的情况和SF类似，CF也是个cluster的管理系统，其scale也分两个level， application level指的是application instance的伸缩，既可以调整instance大小（Memory），也可以调整数量（container 数量）。CF cluster level指的是虚拟机数量的伸缩，这个通过BOSH来进行调整。
Additional
作为微软尝试的第一代云产品，从名字就能看出Azure Cloud Service被委于完整云计算模型的重任。通过增加Azure Drive，VM Role等特性，Azure cloud service不断扩展其应用场景。不过，微软经过一些战略调整，不断细分云计算的场景，目前已拥有从IAAS层到SaaS层很多的云计算产品，用户可以根据自由度、开发、维护复杂度的要求，选择更加合适的技术产品。Azure Cloud Service 的很多技术 (如GuestOS Agent, WAD)都已经被融合到Azure新一代的服务中，自身则会逐渐淡出。
VM Scale Sets & Open Source PaaS on Azure: Deep Dive
Service Fabric在public GA之前，它已经被微软内部使用了很长一段时间，很多云服务如SQL Azure Database，Azure Cache都建立在SF上。SF提供原生的分布式存储ReliableCollection，并且支持Partition和Replica，这为开发分布式应用提供了很多便利。不过服务隔离性和中间件机制的缺乏限制了应用场景，随着Windows Container技术的加入，以上不足有望被填补。
CloudFoundry是开源项目，而且对云计算平台的依赖性很弱，具有很强的移植性，这些特性对担心被平台lock in的客户很有吸引力。CF使用Container技术，支持Linux Server和Windows，适用的场景很广。同时，CF提供service broker，marketplace，offer以及billing模块，管理功能更为丰富。劣势在于：CloudFoundry搭建和维护比较复杂，与微软产品相比，更难掌握。一些云提供商如IBM，Pivotal CloudFoundry代用户托管CloudFoundry cluster，减少了用户的工作。