今天Windows Azure Live to Code的分享

今天参加了微软广州的Live to Code，晚上回公司OT写了封报告E-mail，也没让公司今天白出工资给我...

因为没有涉及到公司机密什么的，所以就拿出来跟大家分享一下。

首先要说明的是，在会议之前我对云的概念基本一头雾水，而且***居然让我们提前装好开发工具和SDK搞到我在出租屋的破网速下装到半夜，早上还发现打印好的确认函落在工资丫一大清早跑回公司拿确认函再去会议现场***居然不用确认函！！！

总的来说就是本来就不是很懂，领导临时有事让我自己去，然后前一天休息不足第二天一大早飞起来人也迷迷糊糊，所以听得不是很多也不会太懂。剩下的就是只是会后吃完饭作的简短报告，肯定没有整理过和没有深思熟虑。大学时挂了13科，也不是什么会听课的人，听讲能力也就这个样子。

如果有什么错的话也请大家一定要指出，就算是不为我个人成长，也让我对公司负责是吧。都毕业一年了，算是职业码农了，能力不足也没什么理由可以搪塞了。

在这之前会议最后主持人提到“Live to Code”说是[liv] to Code（为Code而生），我怎么老觉得应该是[laiv] to Code（现场编程）呢？因为每次Live to Code都是现场活动丫。有谁有靠谱的说法吗？

以下是E-mail全文：

Hi All,

　　今天参加了Windows Azure Live to Code的活动，广州站只有第一天的技术说明会，大致介绍了云和Azure相关的内容。

　　以下简短汇报会议内容。

　　最不重要的饮食方面，提供和上下午的茶点，以及中午价值268/位的高级海鲜自助餐。

　　活动送了两个小纪念品以及个人抽中三等奖微软无限鼠标一个（淘宝96包邮）。

　　关于云方面，首先说明微软在会议中对其公有云的定义，也是Azure的定位。

　　他们认为云是从一开始的租用服务器，到租用虚拟机，到IaaS以设备为单位租用可伸缩性的虚拟机开始为公有云服务时期。

　　而Azure定位为继IaaS之后，实现PaaS。

　　IaaS应该是Infrastructure as a Service，PaaS为Platform as a Service。

　　想必原有的租用网络空间或者虚拟机是很容易理解的事情。云服务也差不多是租用资源的一种服务，但其不同的是提供了平台化和伸缩性，以下用Azure进行说明。

　　首先是平台。Azure提供与租用服务器类似的[账号-管理]结构，用账号登陆后，进入的是一个管理界面。

　　传统的租用服务器或者虚拟机管理的就是已经设定好的虚拟机和服务器，只是往上面挂载站点，操作对象就是一台“机器”。

　　而Azure进去后操作对象是一个“平台”，需要自行在上面添加“机器”，然后往机器里面添加网站或者应用。

　　在Azure平台上你可以添加多个“机器”来实现多个网站，区别于在一个机器上挂载不同的网站。

　　这里产生了什么明显的质变呢？

　　首先来说，在Azure上你可以添加不同的机器，这些机器其实就是虚拟机，而这些虚拟机是可以选择不同的操作系统的，比如各个版本的Windows、Linux；

　　而这些操作系统上，可以根据需求挂载不同运行环境的网站或者应用，比如.NET、LAMP、Java；

　　这些平台上可以自由选择使用不同的数据库、存储方式，比如MySQL、SQL Database（SQL Server的Azure版本）；

　　所有这些都是根据需求自由组合的，不具有固定虚拟机的约束性。

　　也就是说，Azure将原本要手动配置的或者固定的东西抽象上一层，变成可选的可伸缩的组建，而Azure只是经营这些组件的“平台”。

　　下面来讲，平台化后形成的伸缩性。

　　在平台化之后，一个有效的虚拟机被定义为一个Instance，而一个网站或者应用程序我们暂时称为一个Application，一系列Application组成的一个完整的系统就成为一个完整的Service。

　　以下分为Instance，Application，Service三级来讲述其伸缩性。

　　首先是Instance。每个Instance都必然挂载着一个Application（否则就是一台没有用的空机器），那么这个Instance就可以根据需要改变其占用的资源。

　　具体来说，如果发现CPU不够用，那么就可以把该Instance的CPU变成两个、三个、四个，以此类推。

　　同理，其内存空间、硬盘空间（虚拟的）都可以被伸缩地改变，那么根据需求不同，调整该虚拟机的性能来面向不同的需求就非常节约并有效利用资源。

　　如果单个Instance不足以控制了，那我们面向同一个Application，就可以动态地添加Instance，也就是添加虚拟机，来满足需求。

　　Azure在这里会自动地对不同的Instance实现负载均衡。

　　在这之上，控制不同Application的资源伸缩管理，整合后，将一个完整的Service提供给客户。

　　而对客户来说，这个Service只是一个统一的单独的对象，就是为他提供相关服务的一个对象，像云一样，拿出来的都是同样的东西，无论形状、大小。

　　当然，Azure提供了完整的监控工具来让你监测各资源的使用情况，以调整资源占用，也提供了各种API，允许你系统自行监控和调整资源。

　　整个平台让我们能将精力集中在系统开发和资源控制方面，而不用在理会管理上的事情，实现了更高层次的托管。

　　另一个Azure提供的伸缩性需要补充，就是实例是以虚拟机为单位的，这个虚拟机是可以转移的：

　　可以从一个地区的服务器，复制或者转移到另一个地区；

　　可以从Azure转移到本地，也可以从本地转移到Azure。

　　而存储和应用是分开的，也就是说：

　　你可以选择A地区的Azure部署应用，然后在B地区部署数据库；

　　你可以选择用自己的数据库，用Azure的应用，反过来亦然。

　　在此我简单距离云服务所带来的三个应用场景：

　　第一个场景。

　　我们的商城要进行一次抢购活动，会在某个时间段进行，但原本我们只有一个虚拟机。

　　我们可以提前一个小时甚至更早地随时生成成百上千个虚拟机，只为了这次活动，活动结束后我们就可以释放掉这些资源。

　　如果没有云的伸缩性，我想我们的解决方案应该是疯狂加班弄一个可以负载那么多并发的应用，然后提前投入大量的硬件资源，事后被浪费。

　　或者我们要去租用大量的临时服务器去解决，然后还要链接这些服务器，做均衡、做配置等。

　　而有了Azure（或者类似的云服务），我们只需添加服务器镜像，就是在管理界面活动前后点几下鼠标而已。

　　第二个场景。

　　我们的项目面临着不可控制的需求增长，然后我们可以利用云，随着增长而添加虚拟机。

　　到后来我们的需求减少了，我们可以简单地减少虚拟机。

　　我想，这种伸缩性+平台化会比想办法一台台去租用服务器，一台台去配置，然后冗余了等过期才能退回去强。

　　第三个场景。

　　我们的一个客户的网站本在国内，由我们负责开发和管理。

　　客户的业务有一天要向国外扩张，则需要在国外设立一个镜像。

　　如果是以前，就是在国外找一个服务商，然后把镜像放上去。

　　有了Azure的话，直接可以部署到当地的云服务器即可。

　　这些场景已经很明显地解释了情况：

　　这些需求我们本来就有了传统的解决方案；

　　Azure（或者云）提供了更便利、更高效、更可选的解决方案。

　　所以剩下的就是成本问题了，估计也会是公司最终考虑的最重要因素。

　　以下说明成本问题。

　　首先这是会后这两个小时总结和写的，中途还逛了下亚马逊的蓝牙耳机，所以不可能细致地分析具体成本，我也没有权限去得知现在的相关的公司成本。

　　所以，这里我暂时只作简短的分析。

　　首先在成本上来讲，云服务（指Azure和相关公有云，以下同）所做的就像传统的技术革命一样，用大量的新工具、更高的产量来代替传统劳动。

　　体现在这里的就是，用信息化管理平台替代很多人为操作（租借、搬运、管理服务器），以及用集中化量产来降低成本（蟑螂生孩子一样生产云服务器集群和扩充数据中心）。

　　也就是云的使用成本比传统成本低很多，而起生产成本极可能依着产量的上升而降得比传统低，甚至可能已经比传统低了。

　　另一个最大的影响就是市场，但云是一个巨大的竞争市场，有充分的市场竞争，不太可能会形成垄断经营，从而不会有过分的销售价。

　　总体对公司未来来说，云极有可能是更低成本的解决方案。

　　但我觉得，这不会造成公司成本下降，反而可能导致成本上升。

　　因为这只导致了运营成本的下降，但大家运营成本都下降了，竞争也就加大了，所以大家的生产投入必定加大。

　　也就是我们需要更少的运维，需要更多的开发人员，这跟从打洞洞到敲键盘、从写汇编到写高级语言类似，因为市场需求会像脱缰的剩女而狂奔。

　　而未来投入的每一分钱，都会更多地为了创造新价值，而不是维护原有价值。

　　当然我个人作为开发人员并不乐观，因为这曾经就是造成开发人员如此命贱的原因，我对市场持乐观态度，对无产阶级前景持悲观态度。

　　另外，就这次的自助餐而言，相对于Microsoft其他只有茶点的苦逼活动，个人觉得微软在Azure中国上投入应该相对大和有诚意的。

　　以上，作为今天Azure Live to Code的简短报告，如果各位同事有兴趣或者有需要，我再进行详细回答或者整理出正式文档。

　　通讯录没太多人，请自行转发给有需要的同事。

Regards,

Indream Luo