与云共舞:后现代安全视角下的云架构与故障域考量

本文探讨了企业在采用云计算时常见的“最佳实践”迷思,分析了基础设施即服务(IaaS)和软件即服务(SaaS)中因忽视故障域设计原则而引入的风险,并建议优先选用云提供商的原生服务以构建更健壮、低延迟且高可用的技术架构。

与云共舞

最近,我撰文探讨了技术谬误带来的危险,其中最令我沮丧的谬误之一是关于“最佳实践”的讨论。根据我的经验,这种思维方式会导致技术团队陷入太多无意义的讨论,随后是没完没了的验证工作,这一切都只是为了寻找那个并不存在的完美工具。事实是,大多数组织需要的不是最好,而是“足够好”,以便他们能继续开展业务。但这种错觉在云环境中会产生更严重的后果。当你仅基于“最佳实践”的要求来选择工具时,你可能会损害云架构的完整性。不考虑具体情境,你的选择可能会违反数据中心设计的一个神圣原则——最小化故障域的范围

对许多人来说,云对底层网络的抽象减少了过去看似神秘莫测的知识所带来的复杂性。它还让开发团队无需再担心网络工程师看似反复无常的决定,从而更顺畅地工作。然而,**基础设施即服务(IaaS)**的缺点在于,这种同样的模糊性使得没有传统数据中心设计背景的人可能在容错设计上犯下严重错误。我们都听过那些可怕的故事:云应用因为只部署在单个可用区(AZ)或区域而失败。更糟糕的是,由于跨可用区或区域的应用程序依赖关系而导致的局部中断。虽然这种情况在物理数据中心也可能发生,但它更明显,因为你可以看到系统在机架中的位置,而且当你没有构建容错设计并打乱了网络工程师计划的维护窗口时,他们会直接指出来。

如今,组织普遍使用各种**软件即服务(SaaS)**应用程序,但却不知道背后使用的是哪家云提供商,或者这些服务是如何设计的。虽然这种简单性通常对企业有益,因为它加快了服务交付速度,但它也可能造成盲点,从而违反与IaaS相同的故障域原则。只有最执着的技术专家才能揭开这些应用程序的内部运作,以确定它们是如何部署的,以及是否与组织的基础设施设计保持一致。不幸的是,业务部门并不总是理解这种细微差别,并可能陷入“最佳实践”的谬误,由于过大的故障域而导致脆弱的环境。通过将本地的缓慢系统换成SaaS,组织往往接受了一套与风险相关的不同问题。

最终,在选择功能时,更好的建议是“与带你来的云共舞”。与其担心“最佳实践”,不如尽可能利用你的云提供商的服务,选择那些更贴近你基础设施的技术。这能为你的组织带来更好的技术架构,因为云提供商正确保其托管服务具有低延迟、弹性和高可用性。虽然这并非总能实现,但在选择和实施解决方案时考虑到故障域原则,你将能为组织实现更好的服务交付。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计