O’Reilly 软件架构大会第二天要点概述

O’Reilly 软件架构大会的第二天从 The Home Depot 高级架构师 Christopher Grant 的主题演讲开始，他演讲的题目是“走向微服务：HomeDepot.com 如何转变”。The Home Depot 第一个面向客户的 Web 页面是在 1996 年部署的，自此以后，他们的 Web 网站和软件应用资产已经实现了大幅的增长。新老技术 & 应用程序的整合导致了日益延长的提前期和脆弱的部署。他们转而采用一种敏捷的工作方法，定义职责的“领域空间”，利用持续集成实践极大地减少了冲突。2015 年，The Home Depot 技术团队全面采用了云和微服务，那对架构提出了新的挑战。

为成功实施重大架构调整，Grant 提出了四条建议：制定规划、了解目标、选取重点、分步实施。进一步的建议包括：“分析和定义边界”——清楚定义业务产品和领域（及相应的数据模型和人员结构），绘制责任地图；“架构设计要考虑变更”——设法预见未来的变化（在可能的情况下），预计（但要最小化）未来的工作；“落实安全措施”——尽早自动化，根据情况尝试就地升级和全新的做法（没有哪种方法适合所有情况）。最后的建议是 Grant 从实际的工作中学到的，包括利用功能开关和流量阀门限制和控制问题，鼓励团队之间互相独立——不要过分依赖集中指挥。

在实施重大架构调整时：制定规划、了解目标、选取重点、分步实施。

Chip Childers 是 Cloud Foundry Foundation 的技术副总裁，他做了上午的第二场主题演讲，题目是“迈向云原生：这需要一个平台”，他认为，采用一个“平台”是创建“云原生”和基于微服务的应用程序的关键。平台应该简化软件开发的流程，提供开发模式和流程，管理横切关注点，如安全和日志，高度自动化，并易于扩展。那些已经按照“十二要素应用”原则设计，或者作为微服务系统构建，或者已经打包在容器中的应用程序特别适合如今的平台即服务（PaaS）产品，比如 Cloud Foundry 、 Heroku 或 OpenShift 。

Childers 表示，他建议使用一个平台，“不只是跟技术有关”——经济上也经过了充分的论证。恰当的平台有助于“工业化软件开发工艺”，他还讨论了“节拍时间（ Takt time ）”的概念，这与使用平台标准化特定的操作（比如部署）所带来的好处有关。节拍时间来源于德语词汇 Taktzeit，是指“开始生产一个单位到开始生产下一个单之间的平均时间，这些生产起点的设置与客户需求的速度相匹配”。Childers 在总结中讲到，平台约束了软件系统，但“恰当的约束在最重要的地方释放了我们的创造力”。

在最后题为“让痛点可见”的开幕主题演讲中，New Iron 首席技术官兼 Open Mastery 创始人 Janelle Klein 介绍了“Idea Flow”学习框架，该框架提供了一种度量开发者冲突的策略，可以让问题可见。Klein 指出，传统的软件开发过程常常遵循一种在各组织中普通存在的消极重复模式，从“各类问题，到痛苦的发布，再到系统抖动，最终项目崩溃”。显然，必须改变使用的策略，必须让软件开发的“痛点”更加可见。不过，这里有两个主要的障碍——第一个是“管理层”通常说一种与“工程师”不同的语言（即管理层和开发团队之间的“无明墙”），第二个是开发人员所做的改进经常毫无作用。

Klein 指出，在软件开发过程中，导致大多数痛苦和“冲突”的问题通常是“人的因素”，而不是人们常常怀疑技术债务。

可以说，软件开发最困难的部分是“准确确定需要解决的问题”，但许多组织都没有一种有效的方法来处理这个问题。 Richard P Rumelt 曾经说过，“一个良好的策略是对发展阻力的一种明确而一致的反应（和克服方法）”，Klein 问与会者，我们现在使用的策略，在识别和消除由“高质量代码、低技术债务、易维护的代码和良好的代码覆盖率”所带来的冲突和痛苦时，是最好的吗？他在演讲结束时发出呼吁，在让软件开发的痛点更加可见（和可控）方面，“作为一个行业整体，我们要一起学习和分享”。关于他在演讲中提到的想法，可以查看 Leanpub 图书“ Idea Flow：如何度量软件开发之痛”来了解更多信息。

Mark Bates 是 Meta42 Labs 的创始人兼首席架构师，他介绍了“微服务的反面”，并详述了他的经历，从使用基于 Go 的微服务和 Angular.js UI 为一家创业公司构建一个全新的 Web 应用程序，到最终将整个代码库改造成一个 Ruby on Rails 单体应用。他向软件开发团队传递的关键信息有助于企业寻找合适的产品市场组合，然后尽可能做最简单的事。Ego 可能会驱使开发人员选择“最新最好”的技术和架构风格，比如微服务，但 Bates 发现，对他而言，最小化开发应用程序所需的认知“范围”是最重要的价值，因为他业余时间要忙于创业公司的工作。采用基于 ROR 的单体架构，可以最小化所需的活动组件和编排。

由于我是兼职做软件开发，所以我希望最小化变更所需的 [认知] 范围。在这种情况下，RoR 单体架构是最好的选择。

James Stewart 是 UK Government Digital Service 的技术架构主管，他演讲的题是“作为教练的架构师”。他在演讲开始时断言，“大 IT”的时代已经结束，如今的架构师和开发人员（而不是供应商）有很大的权力，他们必须负责任地行使这种权力。Stewart 认为，由于全部公共和私人部门的技术所普遍具有的特性，“软件现在就是政治”，相应地，架构决策会产生广泛的影响。Stewart 提出了一个问题，就是作为组织的“高级技术负责人”意味着什么，对此，他表示，你的职责范围通常不限于培训，该角色的职责一般是纵观全局，推动组织沿着正确的方向变革。这个职位的一项关键技能是，对于组织的方方面面，知道提出什么问题，而且要明白，没有高层的支持，变革目标无法实现。

下面是贯穿整场的 7 个推动变革的关键点：

• 了解受你影响的人；
• 影响有影响力的人——大多数高层领导通常都非常忙，很难接近并影响他们。不过，他们一般由一个团队协助，这些人比较容易接近和影响；
• 提早交付价值，并理解这样做的价值——争取快速反馈；
• 找出共同的参考点和原则；
• 说他们的语言——理解高层领导，并务必使用与他们相同的词汇和术语描述问题；
• 要接受变革需要时间的现实，不能自以为是；
• 让团队同你站在一起。

关于在纽约举行的O’Reilly 软件架构大会的更多细节，可以在大会网站上找到。 O’Reilly 软件架构大会的其他活动将于 2016 年 10 月 18~21 日（提案征集截止日期5 月2 日）和11 月13~16 日（提案征集截止日期6 月1 日）分别在伦敦和旧金山举办，相应提案征集页面现在已经可以使用了。

查看英文原文： Key Takeaways from the O’Reilly Software Architecture Conference: Day Two