如图
azure环境应用托管方式对比
1. app service + serverless
azure的app service支持几乎所有语言开发的web app，既可以手动使用publish profile部署，也可以使用vsts创建一个（CDCI）持续集成。都非常方便。
而azure的function app可以用于创建定时执行的脚本，比如web hook，也可以把windows service逻辑搬到云环境，无需IDE。
优势：
pay as you go。使用才付钱，做POC（演示）的首选。比如是开发环境或测试环境，或者只是演示给客户看。这种方式比较高效。
不要求容器化部署，数据可以放在云端的应用（如果数据落地，可考虑混合云），都可以考虑使用。
缺陷：
容器化部署的话需要使用azure container service。
2. vm scale sets
azure 的IAAS（infrastructure as a service)基础架构即服务。就是创建一组虚拟机，自己管理维护。
优点：可以通过配置达到自动伸缩，可以自己管理虚拟机上的一切，比如子网。
缺点：
网络安全隐患，比如没有及时装安全漏洞的补丁。
成本很高。
3. azure 容器服务 （Azure container service)
适用场景：
azure container service更像是IAAS（infrastructure as a service)基础架构即服务的层面。如果希望在云环境自己管理维护docker容器可以考虑这种方案。
优点：
可以在云环境托管自己的docker镜像。
兼得docker镜像和云托管的好处。
缺点：
需要自己管理一切配置。如端口号需要映射从host到container，并要在最外部防火墙那里管理inbound outbound的规则。
docker中的容器通信，资源共享，可能需要借助storage account来解决，但有额外开销
4. 将docker部署在本地
优势：
可使用swarm或kubernate动态伸缩
节约托管成本，最大化利用硬件资源，单机就能托管多容器从而达到高可用
一次创建image可重复使用
弊端：
容器的创建完全动态并由swarm管理，应用的状态数据需要在存在容器外部
容器最好完全隔离。如果真需要通信，container之间通信需要创建bridge，跨节点通信需要创建overlay
容器的引入需要为持续集成环境配置额外的步骤，增加了devops的成本
container之间的共享资源需要额外处理
适用场景：
一定要本地部署并且要求docker。客户坚持需要把应用部署在本地，完全不用云。除了使用传统的多VM+负载均衡以外，可以使用docker。
结论。首选PAAS，就是azure app service + function app；如果需要容器化考虑azure container service（ACS）；如果在本地部署，建议容器化；如果要传统的多vm+负载均衡也没问题，与docker比，只是硬件不能充分利用而已；不建议在azure上跑虚拟机 sets，开销太大还要自己维护。
