博客

关于数字化转型的惊人事实: 云乱象

Lori MacVittie 缩略图
洛里·麦克维蒂
2018 年 6 月 4 日发布

这是有关数字化转型带来的挑战的系列博客的第二篇。

云乱。

一些聪明的工程师现在正在评论说这句话是多余的。 云计算毕竟是混乱的,它缺乏治理,采取自由放任的方式保护应用程序,而没有明确的时间表,这些应用程序就被扔进了云计算的深渊。

我们在这里停下来思考一下,与云相关的混乱通常是人员流程的问题,而不是技术问题。

这并不是说云计算不存在技术挑战(或者至少是架构挑战)。 其中一些与虚拟网络的复杂性有关。 但大多数是建筑方面的。 这些架构挑战之一与云的本质及其对每个应用程序的关注密切相关。

如果你仔细想想,公共云及其部署模型被认为是理想的(柏拉图主义者称之为“云的形式” )云的形式。 这意味着私有云也应该遵循其规则并表现出相同的特征。

这意味着 API 和自助服务配置。 仪表板和基于 Web 的控制台。 但这也意味着架构将转向纯粹专注于单个应用的部署。  

每个应用程序的架构都是云中的常态。 服务的部署和配置是为了一次支持一个应用程序,并创建从用户到遍历这些服务的端点的单一数据路径。 这与传统数据中心网络设计形成了鲜明对比,在传统数据中心网络设计中,大量网络和应用服务基础设施是共享的。

在与公共云一样以应用程序为中心的 DevOps 和敏捷开发世界中,“共享基础设施”的概念变得越来越具有挑战性。

传统的共享基础设施和网络导致“从门口到应用程序只有一条真正的路径”。 在当今快节奏的数字化世界中,这种方法面临的挑战包括:

  • 基础设施版本对齐。 一个应用程序可能需要升级或补丁提供的功能,而另一个应用程序则依赖于现有版本。 共享基础设施通常不允许同一系统上存在多种版本,因此可能会阻碍一个应用而支持另一个应用程序。
  • 部署计划冲突。 当共享资源受到影响时,企业开始谈判阶段,应用利益相关者试图解决部署计划中的冲突。 这个过程可能很漫长(并且总是很痛苦),而且当新应用或更新由于时间安排冲突而被推迟时,没有人会获益。 
  • 爆炸半径。 毋庸置疑,如果我的应用程序导致共享系统失败,那么依赖该系统的每个应用程序都会失败。 共享基础设施的爆炸半径非常大,这是不愿意向 IT 部门以外的人员提供更多部署管道访问权限的一个重要因素。
  • 故障排除。 尝试翻阅汇总日志是件很痛苦的事。 非常成功的公司建立的原因无非是挖掘海量日志并将数据分解回每个应用程序流的能力。 对共享系统进行故障排除非常复杂且耗时,并且会对平均解决时间(现代 IT 的一个关键 KPI)产生负面影响。

在云中,这些通常都不是问题。 每个应用只有一条路径,因为应用通常按照自己的时间表在自己的环境中部署 - 通常由不同的团队部署。 

为了保持我们的理智(和我们的数据中心),我们需要在本地采用这种方法,无论是否在私有云中。

您仍将拥有共享网络服务。 防火墙、IPS/IDS、DDoS 和用户检查对于应用而言非常中立,并且可以(而且应该)在整个公司范围内应用。 对于其他一切,都有针对每个应用程序(如果您愿意,可以是特定于应用程序的)的服务和基础设施。 这种逻辑分离既能保持业务的稳定性和安全性,又能使更易波动、更不稳定的环境更接近应用程序。 它还为传统(遗留和传统)应用程序保留了数据路径,这些应用程序不需要新应用程序所需的速度和支持。 每个应用程序的网络可能是私有云,或多个容器集群,或它们的某种组合。

两者的结合将产生一个更加稳定、有弹性、灵活和快速的网络。 

除了缓解共享方法与现代应用程序架构和交付模型相结合所产生的问题之外,每个应用程序的网络方法还有多种好处:

  • 单独的管道和时间表。 我可以在部署准备就绪时安排我自己的部署,因为它们不会影响任何应用程序或基础设施,只会影响我自己的。 这提供了灵活性来支持您必须在现代数据中心支持的各种计划。
  • 限制爆炸半径。 如果我的部署导致我的专用系统崩溃,那都是我的责任。 它不会影响任何其他应用程序。 这种专用的每个应用程序数据路径方法进一步使故障排除变得更加容易,因为我可以确信所有系统上的日志和错误消息都属于我和我的应用。
  • 规模不仅限于平台资源。 在这个高度不稳定、动态的世界里,几乎不可能知道下一批访客何时会到来,或者某些内容是否会迅速传播,又或者,天啊,你正在遭受攻击。 无论原因是什么,当共享系统(硬件或软件)上的应用程序需求激增时,规模都会受到平台上可用资源的限制。 使用每个应用程序的架构可以减轻这种限制,并使各个组件能够根据需要扩展以满足需求。
  • 支持真正的基础设施即代码模型。共享系统使用共享配置,即使它只是具有每个应用程序策略的基本配置。 当尝试实现基础设施即代码模型时,该模型可能会造成混乱,尤其是当多个应用程序同时尝试更新时。 更改可能会在没有警告的情况下影响其他应用程序,或者由于其他人在您需要时锁定资源而导致提交和克隆操作失败。 每个应用程序的架构确保部署工件仅属于一个应用程序,并且可以由应用程序所有者(无论是 dev、DevOps、NetOps 还是)进行正确管理。


虽然每个应用程序的架构无法解决数字化转型带来的所有问题,但它可以在很大程度上缓解云带来的混乱。 它为标准化安全性以及支持大多数企业正在成为的多云环境提供了更大的机会。

请继续关注本系列的下一篇文章,我们将深入探讨如何处理那些由于数字化转型带来的市场压力而跳过安全措施的人。