怀旧一把，还记得这个界面吗？
没错，这是第一版Windows Azure Management Portal，用Silverlight开发的，很炫！
奇怪，为什么没有Virtual Machine？
是的，最初的Windows Azure中是没有虚拟机的！
看到Hosted Service了吧？这就是Cloud Service的前身。Windows Azure原本是从PaaS开始起步的，这不难理解——微软的操作系统、开发工具是业界领先的，将传统的操作系统和开发工具“云化”，借力原有的客户群和市场影响力，无疑将成为Windows Azure的一大先天优势。
Hosted Service包括两种角色：
- Web Role：Web Application (ASP.NET，PHP，Java...)
- Worker Role：WCF Service (Web Service，RESTful Service)
无论是Web Role还是Worker Role，都是host在虚拟机上，而且是运行Windows Server的虚拟机。只是这些虚拟机由Windows Azure统一管理，用户并不需要去关注它们，或者说虚拟机被Windows Azure给包装起来了。用户通过Visual Studio创建和发布Hosted Service。一个Hosted Service可以有多个instance，每个instance对应一个虚拟机。总之，对用户而言，完全感觉不到虚拟机的存在。非常完整、优雅的PaaS体验！
后来，Hosted Service中出现了一个新的Role：VM Role——这个可以算是Virtual Machine的前身了。用户通过VM Role，可以在虚拟机上自由的部署应用或者对Web Role和Worker Role进行更加灵活的定制和调整。
据说，Windows Azure在Hosted Service中增加VM Role，是因为跟风AWS EC2。显然后退四五年，大多数用户对虚拟机（IaaS）的理解和接受程度远远高于托管服务（PaaS）。理念太超前了，难免高处不胜寒。
再后来，VM Role变成了独立的Virtual Machine，并且加入了对Linux操作系统的支持，用户终于可以在Windows Azure上部署并使用Linux操作系统啦。其实Hyper-v本来就支持Linux操作系统作为Guest OS，只不过在当时，Linux还被微软视为“癌症”。
虽然VM Role最终修成正果——成为独立的Virtual Machine，但其依然无法摆脱Hosted Service。毕竟这是一个关键而且核心的底层的架构设计，没那么容易轻易的被改变或者淘汰。Hosted Service也随之演变成现在的Cloud Service。虽然Cloud Service变得越来越强大，但其毕竟是源于Hosted Service的。而Web Role，Worker Role的概念也在逐渐的被淡化。
既然已经知道了“前因后果”，那么我们来总结一下对Cloud Service的认知吧：
- Cloud Service是一个容器，它可以包括托管服务或者虚拟机。
- 部署在Cloud Service中的托管服务虽然支持Java，PHP，Python、Ruby、Node.js等开源技术，但用来host托管服务的虚拟机运行的是Windows Server操作系统，一个托管服务的instance就是一个运行Windows Server操作系统的虚拟机，一个托管服务可以包含多个instance。
- 一个虚拟机必须放置在一个Cloud Service中。一个Cloud Service可以包含多个虚拟机，但一个虚拟机只能隶属于一个Cloud Service。
- 一个Cloud Service默认分配一个VIP，即：动态分配的公网IP地址。
- 一个Cloud Service默认分配一个唯一的二级域名。中国版是：xxx.chinacloudapp.cn；国际版是：xxx.cloudapp.net。
- 同一个Cloud Service中的虚拟机通过NAT连接到公网，即：在默认配置中，多个虚拟机共享同一个VIP。
- 虚拟机通过终结点（endpoint）实现端口映射，例如：将内网的22端口映射至公网的2222。
- 同一个Cloud Service中的多个虚拟机不能向公网开放相同的端口（终结点/endpoint），例如：Server A向公网开放了80端口，那么与Server A在同一个Cloud Service中的虚拟机就不能再向公网开放80端口。
- 每个Cloud Service可以配置一个或者多个负载均衡终结点（endpoint），Cloud Service中的虚拟机可以通过负载均衡终结点对外（对公网）提供服务。