你以为是微服务或Docker？其实是组织架构！

今日洞见

文章作者、图片来自ThoughtWorks：肖然。部分图片来自网络。本文版权属ThoughtWorks公司所有，如需转载请加其官方微信在后台留言联系。

It’s Microservices …It’s docker …It’s organization structure

微服务和容器毫无争议的成为了这个时代的主旋律，大家争先恐后地让自己的团队和企业去尝试这样的旋律，但往往发现曲高和寡，难以在整个组织内形成共鸣。

在本文中，我们尝试揭开微服务和容器技术背后映射出的组织结构的变迁，以及组织结构对落地微服务和容器化架构所带来的反向制约，最后用INVEST原则来看看支撑这样松耦合架构的组织结构应有的特质。希望能够帮助迷茫中的企业和组织重新思考自己的微服务之路。

Microservices（微服务）和docker（容器）成了近一年来软件行业的新宠，每次参加相关活动总会感到康威老先生站在背后邪邪地笑着：“我早告诉你们了”。

尽管Martin Fowler在“定义”微服务时十分小心的警告了大家所要付出的代价，但好像微服务的优点太过于吸引人，以至于大部分软件开发组织和企业都把微服务这种架构方式作为了未来的必选，大家都觉得我就是那个高个子（I’m that tall!）。

Martin Fowler对伴随微服务架构的高工程实践能力的比喻

随着容器技术到达生产应用的临界点，这种化学效应好像一触即发，我们仿佛看到了未来一个不一样的软件微服务大集市在逐步展开！

在这个集市里会有淘宝这样的平台，为中小服务卖家搭起一个在线商城，买家可以根据自己的需要搜索及购买琳琅满目、各式各样的服务，在线或是二进制、代码质量及自动化覆盖率等指标成为同类服务评级的重要标准。

杀手级的服务如区块链或者量子加密可能成为皇冠销量服务。最后掀起一大波程序猿开微服务店的热潮~ 很期待那是怎样的卖家秀和买家秀啊！

这种几乎接近于科幻的描述可能只适合作为微信上的谈资，但微服务和容器技术的流行却并非偶然。康威老先生用自己的定律揭示了一个更深刻的道理：

这不是一次技术架构或者基础设施的革命，而是为了保持组织灵活性的必由之路。

换句话说，软件开发组织或企业开始意识到一切的管理和技术实践都必须为保持尽可能高的组织灵活性服务。一定会有人问为啥要保持“尽可能高”的灵活性呢？铁打的营盘流水的兵、稳定的规章制度不也缔造出了历史上那么多成功的组织和企业吗？

论尽可能高的组织灵活性

所以我在前面加了定语“软件开发”，当然现在我们有一个更广泛的提法：科技企业。通常我们认为产品或服务的技术含量比较高，具有核心竞争力，能不断推出适销对路的新产品，不断开拓市场的企业为科技企业。

在我们所处的软件时代，大量的科技企业都跟软件沾上了边。但历史上我们可以回想大生产时代炼钢也曾是高科技，信息时代发邮件也是高科技。

前两波的“科技企业”给我们的印象可不是灵活的：几大钢铁巨擘让人联想到的应该是当年国家呼唤生产力全民建设的宏伟场景；信息时代佼佼者如Microsoft和IBM让人联想到的应该是动辄千人的大型工业软件开发队伍，一个部署都得来一个专家队伍。

那么为啥现在咱们的科技企业必须灵活，而且必须尽可能高呢？

这里我们再次使用康威老先生的定律来做推论，康威定律说：

“一个产品或系统的设计（架构）受到其生产组织自身交流沟通结构的制约”，

换句话说如果你有一个前端展现团队、一个后端服务团队和一个数据库团队，那么我们可以肯定，搞出来的系统会分前后台和数据库的设计。这本身是一个悲观的定律，所以前面的团队发现新需求来了必须沟通三次，前后台团队关心新需求对自身架构的影响，数据库设计关心对现有数据结构的冲击，最后总是会在各方的争执中得到一个别扭的解决方案。

很多团队早已经习惯了这样的痛苦，数字化时代的变化频率将这样的痛苦逐渐推向了顶峰。举例感受一下：达到100亿产值，首钢用了71年，联想用了13年，这个时代的小米用了仅仅3年！而今年的小米已经不是站在浪潮之巅的科技新贵了。

如果要保持产品的持续竞争力，就要保持组织的灵活性。——康威

曾经有人跟我争辩说：“我们做的是数字化时代的后台系统，不直接面对市场，需求很稳定，搞那么灵活成本反而高。”于是我指着他们有着千万行代码的系统说：“你们至少有30%代码是冗余的，这就是组织缺乏灵活性的另外一个恶果。”

这里我们先收缩范围到软件开发，非常有意思的是在咱们这个行业里，针对同一份需求，没有两个开发人员实现出来的代码是一样的（也许Hello World例外）。甚至，当我发现两个程序员使用的变量命名一样的时候我会怀疑他们抄袭了。这说明软件开发从需求提出到写代码实际都是在做设计，不同的人设计出来的东西就会不同，像大家的签名一样。

设计甚至延续到了后面的软件测试和部署，同样的应用在不同的网络拓扑结构下表现可能是完全不一样的。那些追求稳定的组织希望尽早结束设计这个高度不确定性的活动，从而能够通过标准化来提高效率。

即使在敏捷开发主流化的今天，很多团队仍然是架构师“画图”，码农堆砌代码。所以这样的组织很快发现自己深陷二进制的泥潭，进退维谷。我经常跟这样的团队讲：你们缺乏“代码的响应力”。而响应力对组织的要求就是灵活，能够从前到后驾驭设计活动带来的不确定性。

小结一下：数字化时代的市场变化是迅猛的，康威老先生已经告诉我们，处在这样时代背景下的科技企业保持组织灵活性是十分重要的。而软件（广义讲新科技领域）本身由于强设计而带来的不确定性又加重了对组织灵活性的诉求。

于是在这个时代我们看到了如Google、海尔这样已然成功的企业开始大刀阔斧地改革自己的组织结构，这种对灵活性的极致追求成就了这些组织持续保持市场领先水平的核心竞争力。毫无疑问，微服务架构的优点也正反向映射出了组织结构的灵活性，而容器技术的运用降低了这种松散集市结构的运营成本，就如同淘宝平台的出现给千千万卖家和买家搭建了一个基础的交易平台。

弹性伸缩的容器化计算资源加上松耦合的微服务架构必然会吸引追求组织灵活性的企业去打败康威定律，保持组织活力。

组织结构的INVEST原则

前面咱们辩证了数字化时代科技企业保持组织灵活性的必要，那么灵活的组织结构应该满足什么原则呢？

下面我们就借用敏捷开发中赫赫有名的需求管理原则INVEST来剖析一下怎样的组织结构才能够真正落地微服务架构和容器技术带来的灵活性优势，或者从另外一个角度看支撑微服务架构的运用。

两种组织结构对比示意

独立的：Independent

按照微服务架构的团队应该对外提供一种或多种服务，服务和服务之间应该是松耦合的，所以背后的团队也应该是相对独立的。遵循康威定律，如果一个大型组织没有能够划分出服务导向的相对独立团队，那么最后对外提供的产品或系统的内部结构也不可能是简单的服务组装，而会是我们常说的“意大利面”，内部结构纠缠不清以至于最后响应市场新需求越来越慢。

便于沟通的：Negotiable

“小”服务团队的结构必然造成整个组织的集市化、社区化。如果没有建立良好的团队间的沟通机制，很难想象这样的组织里会有任何的产出。Amazon被认为是一个微服务架构运用的成功典范，其2pizza团队的原则成为了业内的标杆。

但这样服务导向小团队集合的底层是长期磨合形成的良好团队间沟通机制，甚至当我们问到Amazon各个团队如何发现其它服务或要求其它团队协助完成需求时，团队都说不出具体的流程机制，一切都变得很自然，全然像我们走进自己熟悉的超市一样，能够很自然的找到日常所需。

有价值的：Valuable

毫无疑问，每个团队必然是面向价值交付的。敏捷开发方法的提出其实很早就指出了传统方式下按照功能部门划分的瀑布交付模式的原罪，即每个功能部门都不对最终的价值交付负责（Output over Outcome，输出大于结果）。这样的组织结构必然造成对市场变化响应的滞后。

值得一提的是面向价值交付的团队往往也是跨职能的，按照微服务的架构，团队需要负责服务从需求到部署运营的全生命周期（Outcome over Output，结果大于输出）。这也是为什么在基础的工程交付平台及实践上团队必须是一个“高个子”。

可估计的：Estimable

这样的服务团队交付周期应该是很短且可以准确估计的，上线应该是家常便饭，而不是过去短则数月、长则一年的大爆炸模式。持续交付在这样的组织里应该是标准实践，让软件系统时刻处于可发布状态是团队的共同责任。从Amazon和Netfliex这样的现代科技企业身上我们已经看到了这样组织结构下逐步形成的工程能力优势，并最终转换成了业务服务上的巨大成功。

 短小：Small

前面提到了Amazon的2pizza团队，人数10人以内，经典的敏捷管理框架Scrum也建议5~9人的团队，可见小团队成为组织灵活性的一个必要条件。中国俗语有“船小好调头”朴实地揭示了小的灵活性，但为什么不再小一点呢？比如两个人结对一个团队。

显然大家很容易发现软件开发本身的复杂性决定了要端到端交付价值两个人的团队是搞不定的。从整个组织的健壮性来讲，过小的团队也会增加企业形成单点依赖的风险。虽然没有正式确认，但我们交流中发现Amazon这样的微服务组织里其实也是存在服务冗余的，这样的重复保证了组织在切割成小团队后风险得到适当的规避。

可测试的：Testable

在面对市场情况高度不确定性时，我们应该直面试错这件事情。传统职能型的大组织结构往往是不能容错的，错误的代价就是整个企业走偏了方向，或者一个部门在企业里失去了话语权。

在灵活性高的组织里我们却应该是能够很容易进行这样的“测试”，企业更能够利用这样的结构进行动态的投资组合管理，像Google著名的7：2：1投资比例，最后的一成就是利用组织的灵活性进行创新的测试。测试的结果往往是失败的，但正是这样的不断测试创造了Google历史上很多著名的“黑天鹅”。

打破康威定律

最近很多以精益（LEAN）为关键字的理论框架在咱们这个领域冒了出来，也包括我前期撰文提到的精益企业（Lean Enterprise），于是有朋友揶揄说又开始炒概念了。我却很严肃地澄清正是不希望炒概念，所以才回到了上个世纪就论证和发展起来的理念：精益。

来源于丰田制造的精益总结出了很多的原则和实践，但有意无意中丰田完成了自身组织持续灵活性打造这项超越同期其它企业的伟业。其结果就是在响应需求多样化时展现出的更强适应能力。

如果用我们前面的INVEST原则来看待精益组织，你会很快找到对应的原则和实践，即使在传统的工业流水线上，丰田也在形成一个个的小团队（cell，单元生产），也在通过员工的多技能培养来完成小团队内部的“跨职能”。其持续改进（Kaizen）的核心思想有力保证了团队面向价值的工作方式和良好的跨团队沟通文化。

某种意义上讲精益在康威定律定义之前就打破了康威定律！

微服务和容器技术无疑是这个时代工程架构方面支撑组织灵活性的重要一步，然而我们不能忘记一个组织是五脏俱全的，如精益企业提到的，组织的财务审计、人力资源、采购合规等功能如何有效的“微服务”化和如何能够合力构建一个弹性的“容器”支撑平台仍然需要诸君努力！