与云共舞

最近，我撰文探讨了技术谬误带来的危险，其中最令人沮丧的之一就是关于“同类最佳”的讨论。根据我的经验，这种心态导致技术团队陷入太多无意义的讨论，随后是无休止的概念验证工作，全都为了寻找那个不存在的完美工具。事实上，大多数组织不需要最好的，他们需要“足够好”，以便继续开展业务。但这种错觉在云环境中会带来更严重的后果。

当你仅基于“同类最佳”的要求选择工具时，可能会损害云架构的完整性。如果不考虑上下文，你的选择可能违反数据中心设计的一个神圣原则——最小化故障域的规模。

对许多人来说，云对底层网络的抽象降低了复杂性，这通常看起来像是神秘莫测的知识。它还允许开发团队不受看似反复无常的网络工程师的恐惧困扰而工作。然而，基础设施即服务（IaaS）的缺点是，这种同样的模糊性使得没有传统数据中心设计背景的人会在容错方面犯下关键错误。

我们都听说过关于云应用程序失败的恐怖故事，因为它们只位于单个可用区（AZ）或区域。更糟糕的是，由于跨AZ或区域的应用程序依赖关系而发生的部分中断。虽然这在物理数据中心仍然可能发生，但更明显，因为你可以看到系统在机架中的位置，而当你没有构建容错能力并阻碍了他们计划的维护窗口时，你的网络工程师会指出来。

如今，组织通常使用各种软件即服务（SaaS）应用程序，而不知道正在使用哪些底层云提供商或这些服务是如何设计的。虽然这种简单性通常对业务有益，因为它提高了服务交付的速度，但它也可能创造盲点，违反与IaaS相同的故障域原则。只有最执着的技术专家才能揭开这些应用程序的内部工作原理，以确定它们是如何部署的，以及是否与组织的基础设施设计一致。

不幸的是，业务部门并不总是理解这种细微差别，并可能成为“同类最佳”谬误的牺牲品，导致由于大故障域而环境脆弱。通过将本地缓慢的系统换成SaaS，组织通常接受了一组与风险相关的不同问题。

最终，在选择能力时，更好的建议是“与带你来的云共舞”。与其担心“同类最佳”，你希望选择更接近你基础设施的技术，在可行的情况下利用云提供商的服务。这转化为更好的技术架构，因为云提供商确保他们的托管服务具有低延迟、弹性和高可用性。虽然这可能并不总是可行，但通过在解决方案的选择和实施过程中考虑故障域原则，你将实现更好的服务交付。