仅仅让云部署工作不再是目标。关注构建和部署最佳解决方案的新指标和方法。
随着云计算架构的成熟，我们定义成功的方式也应该成熟。在2021，我指出，优化云计算更多的是二进制过程，而不是模拟过程。
我当时所说的仍然是正确的：“这关系到很多问题。未充分优化且成本高昂的架构（云架构）也许确实有效，但它们可能会导致企业每周损失数百万美元，而大多数人对此一无所知。30种技术被用于12种可能更好的技术，而不为改变而设计意味着业务敏捷性受到影响。”
为什么大多数云架构都没有得到很好的优化？在规划和设计阶段，大多数云架构师都会按照云架构课程中教给他们的内容来做，或者他们会将所读内容应用到大量的“如何云”参考资料中，或者他们甚至会采纳从以前的云架构项目和导师那里学到的技巧。所有这些都将引导架构师使用一系列通用参考模型、流程和技术堆栈，这些模型、流程和技术堆栈应该进行修改，以满足企业独特的业务需求。这种方法始终导致未充分优化的架构，这会给企业带来更多（或更多）的成本。发生什么事了？
要回答这个问题，让我们后退一步。优化的云架构实际上意味着什么？我在2020年10月定义了云架构优化的过程，并包括了一个要利用的高级模型。我甚至扩展了我的云架构课程，加入了这个概念，这个概念很快将在这里发布。
其次，我们需要认识到，过去的主要重点是让所有东西协同工作，而很少考虑它的工作效果如何或解决方案变得多么复杂。衡量成功的标准是“它有效吗？”不是“它工作得怎么样？”
在开发过程中，团队专注于云架构、迁移和网络新开发的方法，包括广域（元云架构）和窄域（微云架构）。现在，更多的是关于如何设计和部署云迁移和新的云本地开发，或者如何利用容器、无服务器或其他小型或大型云计算解决方案。相反，关键在于如何定义解决方案的目标。
IT和企业管理层普遍认识到，一个“有效”或“似乎具有创新性”的解决方案并不能真正告诉您为什么运营成本比预测成本高很多。今天，我们需要审核和评估云解决方案的最终状态，以明确衡量其成功与否。云部署的规划和开发阶段是规划和构建审计和评估程序的好地方，这些程序将在开发后进行，以衡量项目的总体ROI。
这种从端到端的观点将对构建和部署云及云相关解决方案的人造成一些干扰。大多数人相信他们的设计和构建都是最前沿的，并且采用了当时最好的解决方案。他们相信他们的设计是尽可能优化的。在大多数情况下，他们是错的。
过去10年中实施的大多数云解决方案都严重优化不足。如此之多，以至于如果公司对部署的内容和应该部署的内容进行诚实的审计，一个真正优化的云解决方案的完全不同的图景就会形成。也许容器的使用太多或不够。或者没有强制云原生重构，或者没有考虑这些优势。或者我所看到的新趋势，使多云变得比它需要的更复杂，并且未能定义常见的跨云服务，如安全和操作。在某些情况下，解决方案使用了太多的公共服务，但这些情况并不常见。
概括地说，云架构师应用了他们从书籍、视频、文章甚至我和其他专家报告技术应该如何利用的方法中学到的知识。架构师定义业务需求，然后将这些需求与最优化的解决方案相匹配。这是个好办法。
但是，假设供应商A拥有适用于您的财务运营的最佳原生应用程序，供应商B拥有适用于您的CRM需求的最佳原生应用程序，供应商C拥有适用于您的库存需求的最佳本机应用程序。为了满足这三个需求以及数十种其他选择（安全性、存储、网络等），使用多云来获得最佳产品可能不符合企业的总体最佳利益。这些选择中的每一个都增加了另一层复杂性和成本，很快就会超过额外的好处。
这并不意味着廉价使用用于构建云解决方案的技术。只是要知道，获得最优化的架构仍然是艺术多于科学。有时你需要投资更多的技术，有时需要投资更少的技术。重要的是定义尽可能接近优化的内容。
今天，云优化意味着我们必须审核和重新评估我们当前的云解决方案，然后再考虑进一步增加指标。这并不容易，但考虑到潜在的价值返回到业务。在某些情况下，云优化甚至可以挽救业务。
当有云解决方案可用时，“足够好”团队中的许多员工倾向于成为三只聪明的猴子中的一只或全部：他们不想听到、看到或谈论他们帮助部署或当前运行的云解决方案的任何坏话。相反，团队中似乎总是有人“等等，这要花多少钱？”谁意识到云解决方案将继续消耗企业资源，其消耗量将远远超过应有的水平。他们将是第一个建议或坚持进行审计的人。
原文：https://www.infoworld.com/article/3646989/view-cloud-architecture-throu…