这是一个思想实验。拿一台计算机，在其上安装主流操作系统，以及各种软件（数据库，应用程序服务器，Web服务器等）。一切正常后，拔下电脑并将其放入壁橱中一年。在这一年过去之后，从它的避风港取回它，将其插入电源和互联网，并启动它。什么是第一件事（或者说，第一套事情）会发生什么？47软件更新可用！新病毒定义!! Office需要关闭所有浏览器才能自行更新！即使壁橱内没有任何改变，整个宇宙仍然继续其无情的步伐。软件世界中没有任何东西是静态的。
软件架构师有责任通过创建具有不同程度排序的图表来阐明系统如何组合在一起的决策。图表周围有一种模糊的确定性，一种飘荡的数学香气。因此，架构师经常陷入将软件架构设想为他们必须解决的等式的陷阱。销售给软件架构师的大部分商业工具都强化了数字化的确定性，用盒子，线条和箭头图表不会说谎！虽然有用，但这些图提供了一个二维视图，一个理想世界的快照，但我们生活在一个四维世界。要充实2D图，您必须具体说明它。2D图上的ORM标签变为Hibernate v4.2.17，演变为世界的三维视图。如果您有计划如何将其投入生产并在六个月内升级到不可避免的Hibernate v4.3.0.1，那么您已经毕业于四维世界。太多的建筑师没有意识到architetcure的静态图片的保质期很短。软件世界存在于不断变化的状态，它是动态的而不是静态的。架构不是一个等式，而是一个正在进行的过程的快照。
持续交付和DevOps运动说明了忽略实施架构并保持最新状态所需工作的缺陷。建模体系结构和捕获这些工作没有任何问题，但实现只是第一步。架构在实施之前是抽象的。换句话说，除非你不仅实现了它，而且还要升级它，否则你无法真正判断任何架构的长期可行性。甚至可能使它能够承受不寻常的事件。
这是一个基于真实客户体验的具体示例。航空公司的架构师使用规范的客户服务创建了基于服务的架构，封装了所有关于客户的知识。这是软件设计的自然本能，DRY（不要重复自己）原则，单一真理来源和其他好（但抽象）的想法。然后，冰岛爆发了一座火山，大大扰乱了航空旅行。该航空公司的客户通过电话向支持中心充斥，询问灾难是否会影响他们的航班。在世界上未受影响的地区持票的人无法登机（因为当然，票务查询涉及到客户）。虽然这种架构具有逻辑意义，但在特殊情况下它却失败了。虽然它可能看起来很浪费甚至可能导致重复（喘气！），但拥有多个客户服务（一个处理客户问题，一个处理登机）将更好地为业务服务。只有考虑架构的操作方面，才能构建更强大的系统，这是微服务架构的目标之一。
微服务架构是DevOps后的第一次革命架构，突出了架构和DevOps必须融合的认识，使运营问题成为建筑设计中的一流公民。传统上，变更是软件架构最令人担忧的事情。Martin Fowler撰写了一篇名为“谁需要建筑师？突出了几个建筑的历史定义，其中一些人说“建筑是必须在项目早期制定的一系列设计决策”。因为架构元素呈现其他一切必须依赖的脚手架，所以对架构的改变通常是耗时且困难的。这种困难的一部分是由于忽视了架构的操作方面。微服务架构假设不断演变，即使在特殊情况下也会降低成本并且容易出错。设计稳健性的一个很好的例子来自参考微服务架构之一NetFlix。许多运营团体将其部署视为脆弱，微妙的事物。Netflix试图通过像Simian Army这样的工具破坏他们的生态系统，旨在以富有想象力的方式强调他们的架构。
您不必一直走到异国情调的微服务架构，看看这种观点转变带来的好处。良好的操作控制对架构的赋权效果的一个很好的例子是将部署与发布分离的持续交付实践。Going Live是传统巨石最可怕的事件之一，因为你必须让所有变化同时发挥作用：数据库，代码，配置，集成等。如果你已经习惯了这个大爆炸世界，那么像连续部署一样的练习疯了：你怎么能一直管理所有变化？秘诀是将部署与功能发布分开。功能切换是一种常见的持续交付实践，允许在基于主干的开发中进行飞行中的功能定义。像Togglz这样的切换库允许您通过过滤器servlet在运行时控制功能展示。因此，您可以将一个组件部署到您的生态系统中，其中包括切换代码，这样您就可以确保（通过监控）已部署的组件对生态系统没有任何不良影响。在选定的时间，您可以启用该功能，继续监控以确保没有任何错误。如果出现问题，请在确定修复时关闭该功能。通过将部署与发布分离，我们将操作问题与开发人员和用户分开。
微服务恰好是第一个完全接受DevOps的架构，但它不会是最后一个架构。架构的操作问题将继续影响我们的设计和决策，我认为这是软件架构成熟过程的一部分。
