四五年前刚接手一套近乎裸奔又支持了大量在线业务的遗留系统时，马不停蹄地打补丁。那时候庆幸自己还有点“全栈”的本事，软件的编译、安装、配置，服务器的调优、防火墙的建立…… 虽然不算做得特别好，总归是在没有影响业务的前提下把短板补到差强人意的地步了。那种焦虑和抓狂的感觉，让我记忆犹新。
有了这一次的经验，后来再接手遗留系统时就感觉从容了很多。对于成长迅速而又没有从一开始重视IT的公司来说，问题基本还是那些问题，解法也基本还是那些解法，这次解决起来就是轻车熟路了。
不过，同样的事情干两遍确实有点浪费的，所以我习惯事后反思第二次接手的整个过程，以及如何能做得更好。一想之下我才发现，这一次能做得顺利并不单纯是因为自己有经验，云服务已经给了我们很大帮助。
第一次接手遗留系统时，云服务不成熟也不普及，所以很多问题的解法还是延续惯常的思路，即基于单机平台或自己动手搭建集群的做法，即便知道要“服务化”，也必须自己亲自实现服务。繁琐的实现细节很多，但这是保证“稳定”和“放心”必须付出的代价。
第二次接手遗留系统虽然只隔了两三年时间，云服务却已经在这两三年里悄然发展了很多。大量小文件的存储、大容量数据的冷备份、海量电子邮件的发送、文本语种的分析、服务器和服务状态的监控和告警、前端机器的迅速架设等等，对保证业务开展和系统稳定至关重要而又异常繁琐的工作，已经不再用自己动手了，都以价格低廉（甚至免费）而且运行稳定的云服务的方式存在着，帮开发人员省了很多力气。大量使用云服务还有一个好处在系统迁移，大家都只需要关心“资源如何使用”，而不用关心“资源到底以什么方式存在哪里”，系统的耦合度大大降低，也方便让刚入行的程序员理解好的架构应该是怎样的。
当然云服务也不免让程序员担心，之前耗费了许多年积攒的“手工”解决各种问题的经验，已经被云服务提供商干脆取代。这就好比说，程序员积累了不少经验，知道在平路、山地、沼泽、沙漠等地形走路的门道，云服务就像大潮淹没了一切，以后的程序员只要知道如何开船就可以通达四方了，再不必关心具体地形。以前大家声讨“机器吃人”，现在则亲眼见到“云吃人”。那么，程序员的工作是不是会逐渐被云服务彻底取代了？
在我看来答案无疑是否定的。按照我的反思，对于自己接手的工作，如果有什么“能做得更好”的地方，我觉得是没有基于云服务的大潮流来考虑业务。一些业务还是先自己手工做完，再迁移到云服务的，这种周折其实没必要。如果还有下次，一定要基于云服务的大潮来考虑，能上云服务的业务直接上云服务，即便一些业务暂时没有现成的方案，如果判断对应的云服务很快可以发展成熟，等一等也是可以考虑的选择。
我确信这种思路是没有错的，因为应用开发的程序员很快就会发现，他们需要征服广阔得多也崎岖得多的地形，借助云服务的潮流反而是一条坦途。要知道，简单取代已有单机应用只是云服务的第一步，现在的情况是应用日益复杂化、数据日益海量化，传统单机应用或者简单架构已经非常吃力，可惜无论是学校的教育，还是开发的历史习俗，甚至是类库和框架的积累，都没有为这种局面做好准备，结果程序员不但要花大力气在应用层，还要花同样甚至更多的力气在实现层。所以云服务的大潮淹没了程序员原本熟悉的世界只是事情的一方面，另一个方面是让程序员能省心去到更多地方。
我们先来看看传统的系统，它的一大特点是处理的数据主要是交易数据，这些数据非常精确，比如时间、金额等等，而且非常“节省空间”，即便是复杂的业务往往也只需要记录最核心最关键的数据而已。这种类型的数据用关系数据库记录是再合适不过了，简单业务逻辑可以直接对应到数据库的各种特性，复杂业务逻辑可以交给编程语言。除此之外，大概还有一些外围文本信息，以及辅助性质的图片、音乐、视频等等多媒体信息——但是，它们都与交易无关，所以重要性相当有限。
随着互联网的发展，很多人只看到数据量增长速度远远超过关系数据库的承受范围，却没有看到数据多样性和应用难度大幅上升，以及交易数据的重要性逐渐下降——这几点恰恰是云服务能发挥价值的重要领域。
从数据多样性来讲，在经典的数字、日期等数据类型之外，大文本、富文本已经成了必备，图片、音乐、视频等媒体类型也必须支持，否则很多业务简直无法开展。比如客服系统，传统的客服交流或许靠文本（短信、邮件、语音转换为文本录入）就可以完成，但现在为了给客户提供足够好的体验，也为了提供足够高的效率，巴不得客户的信息越详细越好，除了文本，还有超链接，更有图片、录音、视频。这些数据不再扮演“辅助”的角色，而是承载了重要的价值，所以其应用需要和文本同样程度的重视。
从应用难度来讲也是这样。我们以检索为例，传统的检索行为都是基于关系数据库的，所以大文本的检索是第一个挑战，对于图片、音视频等本身不包含语义的信息来说，检索和组织的难度就更大，但这往往是应用的增长亮点。再比如数据的展现，文本的展现是相当简单的，图片的展现则需要考虑在品质、容量、带宽之间求得平衡——WebP已经迅速打破了JPEG一统天下的局面，但能玩转WebP的人可比玩转JPEG的人少多了；视频就更复杂，不但需要有多码率，而且要能迅速上传，动态切换，多屏同步… 这些问题都是不能靠经典理论或成熟现成框架来解决的。
再进一步说，与传统系统只记录“核心”的订单数据不同，现在的系统还有大量的过程数据需要记录、存储、分析。对于某个交易，传统系统可能只记录订单而已，如今的系统还需要记录订单发生的场景、客户的身份、历史交易习惯、决策过程等等各种信息。而这些信息不但量很大，而且天然就是以各种非结构化的形式存在的，没有现成的存储方案，更没有现成的检索、管理等功能。但是如果因此忽略这些数据，对数据的把握又无从谈起，IT的价值也会大打折扣。
要怎样应对这些挑战呢？传统的软件开发中很多人习惯去自己实现，自己找一些类库和框架，亲手搭建服务系统，这种方式的实现难度是相对较小的。然而看看今天我们面对的挑战，无论是数据多样性，还是应用难度，还是大量过程数据的存储和分析，不花大量的精力在实现上都很难快速、高质量地解决问题。但是，业务的压力又逼迫开发人员不能逃避这些挑战。大公司往往有专门的基础设施或者平台团队来提供支持，但是在大量业务先行的小公司甚至创业公司，即便技术负责人自己知道如何应对这些问题，也难以招聘到足够多足够高水平的工程师来搭建稳定的服务平台，怎么办？
从我的经验来看，适度转变云服务与开发的合作模式，是个不错的解决办法。对云服务提供商来说，不必再自我定位于“中立”、“普适”的基础性的计算、存储等服务，而是深入某几类领域的业务，有针对性地提供若干具体的服务；对业务系统的开发方来说，不应该再纠结于“自己动手实现”，而是应当更专注于业务，转换思路、开拓眼界寻找市场上的专门服务，甚至根据这些服务来定制自己的系统架构和技术规范。
仍然用“云服务的大潮”来说，云服务的提供商需要能把水引向更多的地方，业务系统的开发方需要更多练习行船的本领，最终实现双赢的局面。从我的经验出发，这种选择对业务先行的小公司甚至创业公司的意义更大，因为它能有效解决业务问题中的技术复杂性问题，也让有限的IT资源更好地聚焦于业务而不是技术。
这种局面看起来很美好，但是它真的具备可行性吗？之前我虽然有意识地把实现方式从类库和框架逐步转向云服务，也取得了不少成果，但没有太多使用国内的云服务，所以并没有十足的把握。最近和七牛云存储的道哥（李道兵）长谈过之后才恍然大悟，知道原来国内很多创业公司已经把自己的具体业务交给云服务提供商，并且取得了不错的成果，所以我确信这种方式是可行的——看到还有那么多创业公司被技术实现所困扰着，我真心希望云服务的大潮能早日淹没更多的崎岖。
就在我写好这篇文章的时候，道哥告诉我说，七牛CDN融合服务宣布降价，降幅达到42%。而且七牛已经的客户已经包括了顺丰、OPPO、步步高、大疆、饿了么等等公司，相信有更多的传统企业能借力云服务，所以容我为七牛站个台吧。点击“阅读原文”可以直达七牛降价的官方页面。