听NASA讲云计算有感
October 23rd, 2011
QCon杭州最后一天，来自NASA的一个哥们 扮演了关于云计算的流言终结者，通过展示NASA对云计算的使用来说明：云计算已经是越来越多的企业越来越不可忽视的IT战略方向。
（人家NASA从组织使命开始就非常洋⋯⋯这哥们所属的部门，它的使命是“登上太阳系内所有的行星”⋯⋯这完全就把那些唯利是图的企业给比到不知道哪里去了呀⋯⋯）
第一个流言：“云计算不安全”。这里的亮点在于：大部分企业对IT资产的安全管理其实是非常不足的。比如说操作系统的安全补丁，所有的计算机都及时打上了吗？一个合理构建的云工作环境，可以把这些要求（例如必装软件、例如防火墙配置、例如操作系统补丁）自动化地落实到所有机器上，从而使安全政策即时、有效地得以实施。所以，一个合理构建的云环境比传统的企业IT环境更安全。
第二个流言：“云计算不可靠”。首先，作为专业的高可靠性机房提供商，亚马逊的机房肯定比你的更可靠——亚马逊机房当机，这一事件只能表明你自己的机房有更高的可能性当机，而不能表明你的机房不会当机。并且在使用公有云的情况下，你可以做到多区域冗余灾备，这是私有机房做不到的。所以，没错，公有云并非100%可靠，但一定比你自己的机房可靠。
第三个流言：“云计算只适用于初创企业”。实际上，越大的公司，IT资产的浪费越严重，因此从使用公有云上获益越多。我从演讲里总结了关于IT资产的几大浪费：- 预先采购机器就是浪费。计算机价格受摩尔定律影响，贬值非常快，为了两年后的需求采购机器就等于把价格的70%直接扔进水里。
- 拥有机器就是浪费。自己采购、自己管理的计算机， 计算资源的真实使用率非常低，但仍然占用空间、电力、降温等等资源。
- 因为硬件资源的约束而限制生产力，是最大的浪费。比如说，因为没有那么多机器而不能并行计算，而导致科学家等待好几个小时，对人的浪费是最严重的浪费。
所以NASA的CIO有句话说得很好：应该把所有硬件采购的界面都变成云服务开通的界面。不使用云计算，就是在每天浪费钱。
什么是爹式开发？
September 9th, 2011
这几天跟Simore在车上聊研发云和 持续交付 ，聊来聊去就聊出了一个新概念：开发即交付——Development As Delivery，缩写DAD，也就是“爹式开发”。
免责声明：爹式开发绝大部分理念和实践是基于持续交付的。我们发明这个概念主要是为了搞笑。
在持续集成的场景下，每当程序员提交代码，就会触发一次完整的构建（包括编译、静态检查、部署、自动测试等），确保软件系统可用并且符合质量要求。但持续集成之后的软件往往仍然没有针对真实环境进行验证，没有考虑投入真实环境使用的各种问题，因此“符合质量要求”与“达到可发布水平”之间还有明显的距离，我们称之为 软件交付的最后一英里 。
为了解决这最后一英里的问题，我们有了持续交付。持续交付的核心是 构建流水线 ：流水线越靠后的阶段，验证越接近真实环境。当一个发布候选版本最终通过正规的发布过程被部署在非常类似生产环境的UAT或者staging环境上然后执行了大量的自动化功能测试，我们就可以说：这个发布候选版本已经为交付做好了准备。
然而，问题是，我们为什么需要等到提交代码之后才做这一切？为什么不在提交代码之前就确认我刚编写的代码已经达到了交付要求，然后每个人都提交绝对高质量的代码？
其中一个重要的原因是历史相关的：我们已经太习惯于测试环境（尤其是与生产环境相仿的测试环境）的匮乏了。因为这样的环境是昂贵而不易获得的，所以我们要让它成为整个团队共享的资源；因为要让它被整个团队共享，所以我们要降低它的使用频率，所以要把它放在构建流水线的最后一环。
但研发云将改变现状。测试环境将不再昂贵：它可能仍然需要5台服务器，但由于每个环境的使用率只有10%，所以整体来说它没有那么贵。并且它也不再难以获得：云计算平台方便的开通（provision）加上自动配置工具例如Chef方便的配置（configuration），让我们只要一条命令加三十秒等待就能得到一套接近生产环境的测试环境。
于是我们的观念将发生一个根本性的转变。从前当我们讲“开发环境”，我们讲的所有东西都是基于“每个人一台电脑”这个假设。但这个假设不是必要的。我们每个人都可以有一整套生产环境来做开发。你仍然做单元测试，你仍然降低耦合，但此刻你不再与生产环境隔离——你随时身处在生产环境中，你随时可以看到刚写的代码在生产环境中如何工作，并且你写的所有代码将通过生产级别的验证之后才提交。
这时候我们已经不必再强调“持续交付”，因为我们的开发就是交付（Development As Delivery，DAD）。这就是“爹式开发”。
当然它不会那么容易就实现。一切使你无法做到爹式开发的障碍，我们都称之为“坑爹”。所以，在一个践行爹式开发的团队中，我们的口号就是“不坑爹”。
附录：由于爹式开发要求每个程序员充分了解生产环境，因此会极大地促进 DevOps 在团队中的推广。最终，爹式开发会造就一种新的、具备开发和运维全面技能的人才，他们会把开发和运维工作全部搞定。这些人开展运维工作的方式，称为“多技能运维模型”（Multi-skill Operation Model），缩写MOM，简称“妈式运维”。
当通信业遇到云计算（下）：实施
June 28th, 2011
上一篇文章 讲到，运营商开展云计算业务的第一步，是把计算资源云化并以IAAS的形式出租。现在我们就来看这件事要如何落地实施。
功能：IAAS要做什么
从用户感知的角度，IAAS意味着对几种关键计算资源的按需取用、按使用计费、弹性伸缩。这几种关键资源是存储（内存和外存）、计算（CPU）和网络（带宽和流量）。说白了，用户希望快速开通自己想要的机器和网络，让它投入运行。
从运营商的角度，提供IAAS意味着至少要实现几方面的能力：
- 虚拟化（Virtualization）：将现有的、大批量的计算能力（大型主机、磁盘阵列、千兆以太网）加以虚拟化，使之可以被重组为可出租的小单元。
- 监控（Monitoring）：在客户租用计算能力的过程中监控其使用情况，以便计费并及时发现异常事件。
- 计费（Billing）：根据用户对计算能力的使用情况对其收取费用。
这三方面能力实际上分别对应于IAAS服务的开通、使用和结束三个阶段。云计算平台的架构描述（例如 OpenStack的概念架构 ）可能包含更多模块，但它们最终是服务于这三个阶段的。
建设：如何打造IAAS平台
对应于前面提到的三项基本能力，运营商需要做以下几方面的工作来提供IAAS服务：
利用开源平台实现资源云化
现有资源的虚拟化已经有众多虚拟机产品（例如 VMWare 、KVM 、Xen ）可以实现，IAAS平台应该使用这些虚拟机产品作为底层驱动，在其上提供服务开通、监控、镜像管理等功能。对虚拟机产品的适配以及上述通用功能已经有多个开源平台实现，没有理由重新发明轮子。
在选择开源平台时需要考虑授权许可的问题：例如 桉树 的开源版本使用了 GPL协议 ，基于其上开发商业应用就会遇到授权问题；而基于 Apache协议 的 OpenStack 则没有类似问题。（详见 各种开源授权协议的比较 ）
集成账务/计费
OpenStack当前的文档 中明确指出：目前OpenStack尚未提供计费组件，并且由于云计算服务提供商大多有自己的计费系统，因此OpenStack关注的重点是与现有计费系统的集成。
与之类似，在选用其他开源（乃至商业）云计算平台时，与现有营帐/计费系统的整合都将是一块主要的定制开发工作量，也是厂商设计云计算平台时的重点之一。
定制用户界面
此处所说的“用户界面”是指“用户可感知的界面”，包括API、dashboard、portal等。需要将开源平台提供的用户界面定制为具有运营商特征的界面、甚至需要本地化，这是一块工作量较大、但技术难度较低的工作。
对于IAAS而言，API的重要性甚至超过图形用户界面，因为用户绝大部分的工作都将通过API进行。提供清晰、规范、利于自动化的API，对于用户的体验非常有益。
能力：对研发提出什么要求
对于真正要设计实施云计算平台的厂商而言，首先对开源云平台的经验是必不可少的。这种经验不仅局限于对平台本身技术特性的了解，采用开源云平台亲身实施私有云的经验也是弥足珍贵的，因为这些经验将有助于厂商开发出更便于使用的IAAS产品。
在开发的过程中，针对基础设施的自动化构建、自动化测试的能力也是不可或缺的。以欧洲为源头发起的DevOps运动提出了 Infrastructure as Code 的口号：在涉及大量基础设施的环境下，基础设施本身就应该被当做源代码来看待，需要良好的设计、优雅的编码、不断的重构、持续的集成和测试。在编写应用软件代码中积累的相关经验，在云计算平台的开发过程中同样能发挥价值。
云计算平台本身实际上也是一个面向公众用户的互联网产品，它也需要在 持续交付 中不断获取反馈、不断改进。实际上，开发云计算平台的厂商可以尝试 吃自己的狗粮 ，在企业内部部署并使用云计算平台提供IAAS服务，不失为及早获得真实用户反馈的一个好办法。
从业务和技术两方面来说，云计算都是一个全新的领域；但云计算平台也是一款软件，而软件开发最基本的设计原则仍然是保持不变的。充分利用已有的软件开发最佳实践（例如 敏捷软件开发 ），并保持开放的心态学习最新技术，传统通信行业的软件开发者和企业也能很快找到自己在云端的定位。
当通信业遇到云计算（上）：行业
June 26th, 2011
移动有“大云”，电信有“星云”，联通有“沃云”。三家运营商都 推出了自己的云战略 ，通信业和云计算是如何拉上关系的？运营商要如何转变自我定位？
根源：用户的诉求
我们正处于一个信息加速爆炸的时代。根据 Hadoop引用的一份调查 ，截至2009年底，全世界有超过2亿台web服务器、超过8千万个域名在为超过17亿互联网用户服务，让他们每天发出超过2千万条tweet、在Youtube上浏览10亿个视频、并制造超过2千亿封电子邮件（尽管其中81%是垃圾邮件）。而且 有人声称 到2020年人类在互联网上创造的信息量将是现在的270倍。
除了其他的各种影响，对于提供互联网服务的企业（以及个人）来说，这意味着他们需要新的计算能力（即：消费、存储和生产信息的能力）报价：不仅是更便宜的计算能力，而且是弹性的计算能力——根据对计算能力的使用付费，而非预先购买昂贵的服务器和网络带宽，并且当业务量上升时能得到充足的计算能力。
作为信息和计算服务的重要提供商之一，通信运营商希望满足这种诉求。但他们发现这并不容易。
困局：运营商的局限
不难看到，现在最成功的“出租计算能力”供应商其实是亚马逊。其实作为一家互联网企业，亚马逊提供这种服务有一些难以克服的障碍，例如QoS：亚马逊没有办法保证用户一定能连接到EC2的机房，更没办法保证连接速度，因为它没有端到端的网络接入。运营商有。
但运营商有自己的问题。运营商（以及通信厂商）太习惯于用技术眼光来看待通信网络，核心网、接入网、路由器、交换机⋯⋯在整个数据通信网络之上，通信服务与用户真正体验到的网络服务却是完全隔离的。从网络协议栈设计的角度这当然是正确的，但从服务的角度这就体现出通信业一直是个供方市场——就好像从前计划经济时代润肤霜属于“日化产品”，现在叫“Beauty Industry”，供方市场上描述产品是从生产（而非消费）的视角出发的。
随着数据通信服务的日用品化，运营商必须到网络服务这块市场来寻找增长点了。把手上的优势资源（接入、网络、IDC）充分利用起来提供客户需要的计算能力（而不仅仅是通信服务），把亚马逊赚的钱变成运营商自己来赚，这是国内外运营商都在走的一条路。
转型：迈向云端
帝国主义老巢的运营商步子迈得稍微早一点。BT在2009年和微软一起给企业客户提供 基于云的商业协作软件 ，大致属于 SAAS ；AT&T的 Synaptic 提供了存储和计算的出租，就应该算是 IAAS ；Verizon把这种业务叫做 CAAS ，说白了还是抢亚马逊的生意。
国内的三大运营商盯上的也是IAAS。移动资深研究员杜宇健认为运营商切入云计算 从基础设施这个层面落地比较好一些 ：IAAS技术门槛不算高，需要的是大量的基础设施，而后者正是运营商手中已经掌握的。
首先把手中已有的计算能力云化（我颇喜欢“Cloudify”这个词，但好像已经被某公司使用了），将云化的计算能力以私有云的形式出租给企业用户，为将来提供SAAS铺路架桥。这个大概就是运营商向云端转型的策略了。
（讲完行业，下一篇讲实施。未完待续⋯⋯）
这个春天，我感觉运维们鸭梨很大
March 12th, 2011
壹、穷人的EC2自动快照
用两个简单的shell脚本加一个crontab就能每周（如果你愿意的话，每天也可以）备份EC2的机器。今天在Ubuntu上玩各种东西把环境玩复杂化以后，发现这个脚本蛮有用。
话说，实在没有什么理由，不到EC2搞台机器放自己的博客兼作翻墙梯啊…
贰、挪亚，不是方舟
这位John Vincent同志写了 一篇博客 论述…嗯，为什么有Chef和Puppet还不够。
Chef和Puppet管理有计划的变更，但你经常会做无计划的 偶发变更 ，而且你不太希望每次变更重启都得重启服务。所以，Vincent桑说，你需要…
Distributed coordination, dynamically reconfigurable code, elasticity and environment-aware applications.
然则，看完 Noah的README 就知道了。这就是RESTful的RMI…好吧，正确的思想永远都用得上，而且RESTful总比RMI要好那么一点点。
叁、飞禽走兽们
Nagios 是老牌的监控工具，十多年历史了。
Hadoop 这里好玩的东西不少，分布式文件系统 ，MapReduce ，还有 重新发明轮子的ZooKeeper 。
Sinatra ，快速做一个web server，不需要Rails那么庞大，比WEBrick容易写。
Redis ，又一个key-value store。加上 Ohm ，好了，NoSQL的对象持久化。
看一遍 Noah的使用场景 ，感到运维们鸭梨很大。
（还有一本 Hadoop的书 可我今天看不着…等明天翻墙再说吧。）
肆、来点音乐
Music as Data is a live programming language/environment based on Processing.org written in Clojure. It’s something like SuperCollider or Chuck but aims to be easier to hack/experiment live.
我喜欢他的网站。简约而不简单。
