IT餐馆—第十五回 云端
这几日雨辰在自己的邮箱中终于把AZURE平台的所有TOKEN都收集齐了（算来自申请之日到今天已过了大半年了）。而郑伟比自己的运气要好许多，早在上半年就有了创建AZURE平台上相应项目的TOKEN，所以在这方面他走到了雨辰的前面。
周五下班回家，雨辰就开始尝试着往AZURE平台上迁移自己团队的产品。之前与微软工程师的交流，基本上扫清了关于数据存储，文件上传，路径访问，URL重写等与产品密切相关的问题，心里算是有了一些谱。因为目前还没有特别有效的将现有VS项目自动转换成AZURE项目的程序，而VS里也不支持。所以雨辰又用了最笨的方案，就是先新创建一个AZURE的解决方案，然后手工一步步将现有项目下的物理文件复制到AZURE解决方案的路径下，就这样一直折腾到晚上12点，才基本上转换完毕，也在本地测试通过了。只不过可能是时差问题，上传相应的配置和打包程序文件时总是中途断下来。必定这时候正是美国人的工作时间，看来要等到周六上午再试试了。
这时，雨辰发现QQ上郑伟发来了信息，问道：“这么晚还没休息呢，看A片呢吧！”
雨辰学着郭德纲的口气说：“不对，我看中国足球呢！”
郑伟发了个表情，说：“你真行，我也是看足球呢，呵呵。”
雨辰笑了笑，便转入正题说：“你之前用微软给你的AZURE帐号了吗，感觉开发起来如何呀。”
过了一会，郑伟回复说：“还行吧，挺方便的。.眼下我用的是VS2010的TeamSystem版，开发起来更爽。不过根据我这小半年使用的情况来看，发现了一些问题，也有一些疑问，我之前给AZURE的技术支持发了EMAIL，眼下还没收到回信儿。”
雨辰听关伟这么说，来了兴趣便问道：“什么问题呀，说来听听，呵呵。”
郑伟那边想了一想，回复到：“首先就是上传的问题，我之前打算将做的一个系统传到AZURE平台上，但当我上传完之后，发现有些小问题要修改一下，比如说换个LOGO什么的，而这时，我只能在本地更改完LOGO并重新打包发布，将全部的程序和文件再上传一遍。你知道我的一个项目连DLL在内有多大吗，10兆呀。就为了改了小图标就要这样折腾，难道VS中就没能提供一个功能支持‘修改或增量’上传吗？”
雨辰看了看，发现这个问题在之前与微软工程师交流时提到过，对于一个DEMO无所谓，也就不到1M，但项目和产品就不一样了。当时他们说这块目前还没有相关的工具来支持，不过实现起来也不该是什么难事，他们也在会上说会把这个问题反馈给AZRUE平台开发小组，另外在美国那边的开发者也提出过同样的问题。相信这也是开发者们都会想到的。
不过在会上微软的人也给了一个不算完美，并也可能解决这个问题的方案：就是在自己的产品或项目中添加一个上传页面，当把程序传到AZURE上时，就可以通过该页面上传‘经过修改过的或新添加的文件’，该页面接收‘上传文件要放置的路径’作为参数，在AZURE上的程序就可以根据该路径参数将上传来的文档MOVE到指定的路径下了，当然路径要用‘相对路径’，因为AZURE上没有本地磁盘（如C:",D:"）的概念。还有就是这个上传页画要做好权限校验，以免其他人恶意上传代码等。
雨辰把这些内容发给了郑伟，不一会郑伟就回复过来：“看来是够BT的，不过的确可行呵呵。亏他们想的出来，牛。不过我还有个问题，就是在AZURE上能运行SILVERLIGHT和其他脚本语言吗?比如 PHP等。”
雨辰笑着回复说：“当然可以了，并且我相信使用SL开发AZURE平台的应用要比开发asp.net程序要方便的多，必定SL生成的文件就是那个XAP包，在打包发布上可以剩些功夫。另外在LIVEMESH上使用SL开发相关应用也是‘首选’方式。关于PHP，当前AZRUE平台上不支持直接运行PHP脚本，但可以通过FASTCGI，将它与PHP程序一块打包上传，并在web.roleConfig、Web.config中配置相应的信息即可，我之前在网上写过这方面的内容，我一会把链接发给你，呵呵。”
郑伟回复说：“不错，看来这块你走在我前头了，呵呵。回头看看你的那篇文章。下面还有个问题，就是我想像在虚拟主机上一样，看整个站点的配置信息，但AZURE平台上目前还没有提供这样的功能，另外就是我无法看清当前站点的运行情况，比如当前应用的进程数，所耗CPU个数，占用磁盘空间，网速流量等信息。因为不清楚这些内容的话，到时AZURE平台把收费通知打过来时，我都不知道用什么来做‘比对依据’了。”
雨辰想了想回复道：“其时目前在CODEPLEX上有一些提供AZURE站点信息管理的应用，不过我下载了一些之后发现，功能不是不全，就是刚开始做，天知道将来会是个什么样了。不过当时交流时我也把这个问题提了出来，他们说AZURE平台将来会不断完善和开放出更多的开发和访问接口，以便开发者能更好的使用它们开发出更多的应用。只是就目前情况来看，还需要一些时间。不过也正好利用这段时间好好看看SDK，也许你可以先开发出来这样一个插件，到时如果微软看着好，就买过去了，到时你就发达了，呵呵。不过在会上聊天时，他们说可以访问修改AZURE项目的web.roleConfig文件，我想这也许是一个途径，通过它可以在运行时修改所使用的一些资源配置信息。”
郑伟看到这样的回复，感觉继续问下去也没什么意思了，就又叉开话题：“最近微软公布了其云平台的收费方案，你看到了没。”
雨辰回复说：“当然了，之前我就比较关注这方面的内容，甚至我还把它的收费标准与亚马逊的云存储价格作了对比，发现目前微软的收费方式也是‘按量消费’，看来这种方式已成为了云平台的计费标准了。光就存储成本而言，AZURE与亚马逊云存储使用了不同的单位，一个是GB,一个是TB。微软是‘$0.15 / GB / 月’, 亚马逊S3是‘$0.15 / TB / 月’,所以说后者的价格优势还是很明显的，并且后者还对存储区间做了一些收费调整，比如 0-50TB为 0.15，当使用达到50-100TB时，价格就变成了$0.14。 100-500TB是$0.13。而这个价格还是其在2008年11月1日后的修改价。看来微软会有一定的竞争压力了。”
郑伟回复说：“其实我使用AZURE一方面是出于兴趣，另一方面是我们单位打算把一些资料放到网上让用户观看或下载。之前我在单位的服务器上折腾了一下，发现访问速度不理想，正在考虑使用SQUID试试。后来就在TECHED2008大会上看到了关于AZRUE的介绍，感觉它应该也能解决这个问题，所以就一路跟下来了。其实我感觉目前AZURE的主要市场还是企业级数据计算和存储，这是块‘肥肉’，只是目前很多公司都对云计算抱怀疑态度，担心数据因为安全问题被泄露出去，还有云平台故障所造成的数据或文件丢失。之前在网上看了一些云平台的服务商包括GOOGLE，基本上对这种数据丢失也是采用延长免费服务期限或是降底收费价格的方式来进行弥补。我想这些服务商就应该学学当前马云做支付宝的‘做法’，搞一个‘你敢付，我敢赔’的口号，参照收费标准再整个‘损失赔付标准’出来，我想到那时，就会有企业跳出来买单了。”
雨辰说：“想法不错，但执行起来不好办，因为每个公司数据的价值都不一样，赔起来没个标准，总不能按TB或GB来做单位吧。”
郑伟回复说：“我也只是说说，毕竟你我这样的草民只是被规则约束，轮不上我们来制订规则。不过你说眼下SAAS，SOA，CLOUD都挺火，但我感觉它们之间有着关联，那就是服务，从SOA到SAAS，再到CLOUD，一路走下来，把服务的意识不断在软件设计中加以强化。而IT巨头也通过自己的技术、业务、资源等方面的优势，加入自己对这些概念的理解，比如CLOUD，目前就很混乱，几个大的IT巨头各执一词，都认为自己的东西才是真正的云，是正宗。其它的都是旁门左道，有点像笑武侠小说中的各大门派为争‘武林盟主’而展开的厮杀。现在的水已越来越混，也许这样才能摸到鱼吧，呵呵。”
雨辰说：“不过我相信对于大多数公司特别是中小企业而言，无论谁最终胜出，都能从中获得好处。必定云平台本身就是强调合理控制企业的IT运营成本，按需付费吧….。另外目前就云平台的两大业务内容而言，就是计算和存储，而各大厂家也在拼这两块的技术指标，不论是性能还是价格上面。而对于私有云和公有云，我想企业还是更有兴趣投在私有云上面。我的想法是对于企业来说，重要的核心数据放在私有云上（通过虚拟化方式布署），只有在要求访问互联网上资源的时候，私有云才会通过互联网云平台的ISB接口接入，完成相关业务操作后再自行断开，而重要的核心业务代码放在企业的‘中心业务服务器’上以便进行监控，而对那些不核心但却会占用大量CPU、存储资源的（突发）请求放到公有云中。之前有一段时间我一直把云平台看成是ESB的互联网‘版本’，即ISB（internet service bus）.也就是把整个互联网看成是一个企业，而各个公司和厂家就是这个‘企业’的一个个部门。每个公司都可以将自己开发的应用放到网上并接入到ISB上，这样就形成了一个巨大的应用平台。如果公司之间能够共享应用软件和研究成果，那么云平台就真正成为了一个‘操作系统’，每个人，公司都能从中获益。不过这太理想主义了。呵呵。现在云平台已成为了SaaS的运行和表现容器，完全可以把它看成是SaaS的‘升级版’了，而SAAS支撑平台的思想也被遗传到了云里，比如计算、存储、监控、任务调度、工作流等，我想任何一个资源过剩（客户资源，IT软硬资源）的公司，只要有技术储备，都可以跳出来搞一个云平台，从而在上面制定自己的标准，打压竞争对手，国外的亚马逊书店，国内的阿里巴巴，如出一辙。”
郑伟回复说：“眼下光看他们热火朝天的折腾了，而大部分公司企业还在观望，看来渗着看看再说吧，好在技术开发人员不在乎这一点，只要自己有兴趣就去搞一把，就像我。不过我现在对AZRUE平台的底层机制有些兴趣了，比如上传文件之后，从SANDBOX到实际运行环境下的虚机布署，资源调度，以及运行的实时监控。我之前在PDC2008的网站上看过一个关于其于这方面的介绍，多少了解了一些，但还是云里雾里的。
雨辰回复说：“其实对于开发者而言，了解一下倒也无妨，但我认为主要方面不在于Fabric Controller和均衡负载等底层机制的实现，我眼下主要观注平台后续开放出来的API接口。比如之前你所说的那些‘需求’只能通过这些API实现。呵呵。”
……
两人就这样聊到了凌晨2点多才各自休息。而第二天早上，头顶上的云却依旧那样灰蒙蒙的。
