应用现代化的无应力路线图

WHITEPAPER 无应力路线图应用现代化 克里斯·格伦德曼 目录 执行摘要 微服务既是应用现代化的手段，也是应用现代化的方法。 微服务架构创建了一个模块化应用程序，其中每个服务都可以独立于任何其他服务进行开发、测试、部署、扩展和最终替换。更重要的是，微服务架构所带来的敏捷性、灵活性、速度和效率正是推动组织成功数字化转型的原因，更重要的是，客户现在所期望的数字化体验。 不幸的是，大多数数字化转型、云采用和应用程序现代化工作都失败了。困难通常集中在三个主要领域之一：文化（新的运营模式通常需要新的运营结构），复杂性（模块化是有代价的，特别是在网络需求和云提供商的特点）和安全性（攻击面变得更大，更动态）。 事实证明，避免这些共同挑战的关键是准备。成功的应用程序现代化早在第一个容器创建之前就开始了。路径，以及路线图，从围绕规模、安全性、可观察性和治理这四个支柱的仔细文档、规划、文化转变和流程改进开始。本白皮书的大部分重点是解释这些支柱中的每一个，包括它们的重要性和共同挑战是什么，以及为您自己的应用程序现代化之旅提供实用和可操作的建议。 成功的道路始于规模、安全、可观察性四个支柱的规划， 和治理 Introduction 虽然一些公司在整体数字化转型方面取得了长足的进步，特别是应用程序现代化项目，但这并不适合所有人。随着围绕“云原生”，微服务，容器，CI/CD，服务网格等的所有炒作，很容易让人觉得你落后了。这种观点的问题在于，它导致许多聪明人在没有明确的成功计划的情况下跳到他们不理解的境地。 事实上，大多数组织都处于类似的位置。值得记住威廉·吉布森的这句话：“未来就在这里；它并不是均匀分布的。”作为应用程序现代化工作的第一步，你最好放慢速度并进行一些认真的计划，而不是奋力追赶。但是 ，即使对于那些知道这一点的人来说，也很难知道从哪里开始以及专注于什么。 未来在这里；它只是没有分布 应用程序现代化与容器化或部署 Kubernetes不同步 微服务是应用现代化的手段和方法 本文通过从以前去过的人那里获得的知识制定的路线图来回答这些大问题。我们将探索您前进道路上的常见陷阱 ，陷阱和其他危险。我们将仔细记录如何通过适当的计划来避免它们 并预先记录。所有这些都围绕着规模，安全性，可观察性和治理的四个支柱。在每个领域中，此路线图都提供了具体的可操作建议，以减轻您踏上旅程的压力。 底漆 如果您正在阅读本文，那么您已经对应用程序现代化有了很好的了解，至少在较高的水平上是这样。但是 ，在我们深入研究之前，“现代应用程序”的概念值得探索。 首先，错误的答案。与一些轻率的评论可能会让您相信的相反，应用程序现代化并不是容器化或部署Kubernetes的代名词。根据当前的技术水平，这是一个很容易的错误。事实是更深的一层。Kubernetes本身并不像它所支持的那样重要：微服务。 传统的单片应用程序由在内存中进行通信的层定义，例如前端，后端，Web控制器和数据库。使用微服务构建的现代应用程序由一组单独的服务定义，每个服务执行一个完整但单一的原子或复合功能，这些服务进行通信 通过网络。微服务架构创建了一个模块化的应用程序，其中每个服务都可以独立于任何其他服务进行开发，测试，部署，扩展并最终替换。简而言之，微服务既是应用程序现代化的手段，也是方法。 论房舍 传统的单片应用 使用微服务构建的现代云原生应用程序 基于云的容器 图1:微服务为现代应用程序提供动力 微服务架构提供了敏捷性，灵活性，速度和效率，使客户现在期望的数字经验 我们已经知道事情正在发生变化，但我们仍然未能做出必要的改变 微服务架构提供了敏捷性，灵活性，速度和效率，从而为组织带来成功的数字化转型，更重要的是，实现了客户现在期望的数字体验。除了自动和弹性 使用微服务构建的云原生应用程序支持并促进新的模式，例如每个服务A/B测试、蓝绿部署和金丝雀版本。如果您必须重构整个整体应用程序来响应用户偏好或趋势，那么您将永远无法跟上。通过对COVID-19大流行的全球反应，对这种高度响应、数字优先的商业方法(由使用微服务的云原生应用程序支持)的需求比以往任何时候都更加明显。所以，没有时间浪费了。 挑战 当然，知道您必须对应用程序进行现代化并不能保证成功。早在2018年1月，麦肯锡报告说：“我们最近接受调查的公司中，只有8％表示，如果他们的行业以目前的路线和速度保持数字化，他们目前的商业模式将在经济上仍然可行。然而，18个月后，贝恩公司的研究发现，“只有8%的全球公司能够通过对数字技术的投资实现其目标业务成果。 而且统计数据并没有真正改善。在2020年3月，麦肯锡的另一项调查发现，数字进展停滞在76％的组织中 ，最近在2021年6月 企业管理协会的一项调查显示，不到三分之一(28%)的受访者可以将他们的云投资归类为“非常成功”。 那么，到底发生了什么？我们已经知道事情正在发生变化多年，但我们仍然未能做出必要的改变。阻碍了什么？对于初学者来说，许多失败的数字转型和云采用努力都试图“提升- and-shift”existingmoniticalapplicationsontonewplatform.That’ssimplynotgoingtoproducetheexpectedresults.Buteventhosewhofocusonapplicationmodemplyingcan, 好消息是，所有这些挑战都在你的控制范围内，最简单的是需要一点准备工作来为成功做好准备 成功的真正秘密与适当的准备一样有限 灵活尺度的能力是现代应用设计的核心 经常这样做，奋斗。这些斗争通常集中在三个主要领域之一：文化（新的运营模式通常需要新的运营结构） ，复杂性（模块化是有代价的，特别是在网络需求中）和安全性（攻击面变得更大，更动态）。另一个因素是云平台之间缺乏标准化，使每个平台都以自己的方式独特，并使混合和多云部署复杂化。 好消息是，所有这些挑战都在你的控制范围内，最简单的是需要一些准备工作来为自己的成功做好准备。 ROADMAP 幸运的是，您并不是第一个走这条路的人。不那么幸运的是，许多在您之前踩过的人都失败了或目前陷入困境。尽管许多人会日日夜夜争论哪个配置管理平台或自动化服务器 使用，很少有人愿意承认成功的真正秘诀是无聊的适当准备。关键在于围绕规模、安全性、可观察性和治理这四个支柱的有意识和有意的文档、计划、文化转变和流程改进。规模是我们的目标，安全是我们的任务，可观察性为我们提供了洞察力，治理提供了灵活的控制。花时间提前考虑你目前和理想的状态在所有四个支柱将支付红利。 最重要的是，成功的应用程序现代化早在部署第一个容器之前就开始了。在以下各节中，我们将探讨这些支柱中的每一个——为什么它们很重要，哪里会出错，以及如何为成功做好准备。 支柱1：规模 灵活扩展的能力是现代应用设计的核心。它实际上是驱动力之一，这正是我们看到所谓的“超大规模” 的原因 （亚马逊、谷歌和Netflix等公司）率先实施面向服务的架构（SOA）、微服务和容器/Kubernetes。传统的单片应用程序只能垂直扩展和“一次性”，而微服务应用程序可以垂直、水平和弹性扩展，并且可以在集群或服务级别进行扩展。 但是，就像许多事情一样，规模不仅仅是默认情况下发生的——它必须精心策划。此外，虽然微服务架构可以通过模块化应用程序和解耦功能实现惊人的规模，但它通过引入必须处理的额外操作复杂性来实现。使用微服务构建的现代云原生应用程序可以轻松拥有数百或数千个服务，每个服务都有数十或数百（或更多！ ）实例。这些实例通常从数据中心扩展到云再到边缘。仅仅思考，更不用说管理了。这种分布式的规模。 图2:微服务使应用程序能够轻松扩展 首先确定服务边界，然后建立符合这些边界的开发团队 要使您的组织能够成功扩展，首先需要解决的是组织结构。康威定律在这里适用，这是一句格言 说明“组织设计反映自己的通信结构的系统”。要利用这些知识，您应该首先确定（并记录）服务边界。然后建立映射到这些边界的开发团队。不要忘记，许多更改需要跨越这些边界来完成，因此您的团队需要一个除了组织结构之外，您还需要一个健壮的数据治理模型，以确保跨服务的适当并发性和数据一致性。 当然，您还需要直接管理规模的技术能力。NGINX是有效扩展的一个很好的例子。NGINX最初是为解决C10K问题而开发的，它可以帮助您在Web应用程序，整体，API和基于微服务的应用程序中扩展和管理流量。轻量级且与平台无关，NGINX可以部署为 Web服务器、负载均衡器、反向代理、内容缓存、API网关、KubernetesIngressController和服务网格。 像F5NGINXController这样的工具不仅使NGINX实例的管理更加站得住脚，而且还增强了我们上面认为必不可少的跨团队沟通和协作。在管理平台中寻找的关键事项是 以应用程序为中心和多角色自助服务。参与应用程序开发和部署的每个人都应该能够通过模块化工作流管理和监控对他们来说很重要的生命周期。 支柱2：安全 每个威胁造成的潜在损伤达到灾难性水平 我们都知道我们需要“向左转移安全” 安全性可能已经成为整个行业的首要考虑因素。不仅攻击变得越来越普遍，每个威胁造成的潜在损害也达到了灾难性的水平。现代应用程序不能幸免，它们的体系结构实际上可以使困难复杂化。使用微服务构建的云原生应用程序本质上是分布式、异构和网络依赖的。这意味着攻击面成倍增加。 没有单一或通常甚至可识别的边界。每个服务和每个API都必须单独和共同保护。 除了技术挑战之外，开发人员（和DevOps）团队之间几乎总是存在文化摩擦，业务和安全团队的新速度受到为传统IT方法设计和部署的策略和工具的阻碍。 在这一点上，我们都知道我们需要“向左转移安全”，因为将安全测试和控制纳入开发、QA和运营的日常工作会带来更好的结果。但是，如果这很容易，我们就不会谈论这么多了，对吗？ SEC p DEV OPS n SEC r u 图3:在软件开发生命周期的早期考虑安全性 首先必须解决的问题之一是集中、不灵活、事后、基于外围的安全保护传统安全方法与快速、敏捷、持续的现代应用程序开发和部署之间的这种摩擦。第一步是彻底检查安全策略及其执行方式。以分层方法记录安全目标和策略。哪些控制需要集中，以及。 哪些可以是自助服务？你如何发展你的安全程序，使其更加以应用程序为中心？ 开始部署服务之前需要的另一个关键操作是选择安全性 可以作为代码直接插入CI/CD管道的工具。一个示例是找到轻量级Web应用程序防火墙(WAF)，例如F5NGINXAppProtect，它可以轻松部署到多个环境中，同时自动执行安全配置和策略。 这使您可以在开发的每个阶段测试安全性，而无需停止甚至放慢速度。 选择可以作为代码直接插入您的 CI/CD管道的安全工具 还有一个安全问题要提前问：“我们将如何协调所有人的安全 我们的应用程序、服务和API？“在这里要特别注意，不仅要在整个房地产中分层安全性，还要向Dev和DevOps团队提供自助服务访问，同时向安全团队提供所需的可见性和洞察力。利用以应用程序为中心的控制平面，如NGINXCotrollerAppSecrity附加组件，可以很好地满足这些需求。 支柱3：可观测性 可观察性旨在消除“未知未知” 从技术上讲，可观察性是根据系统的外部输出推断系统内部状态的能力。在现代应用开发的现实中，它更加复杂。 一个有用的比较是传统的监控，它基于收集预定义的信息（“已知未知”），希望在你以前看到的问题再次发生之前抓住它们。另一方面，可观察性范围更广，旨在揭示“未知的未知因素”，目的是捕捉以前看不见的问题和趋势。虽然监控适用于许多简单的遗留系统，但现代分布式系统的世界需要可观察性。 Monitoring可观察性 图4:快速检测已知未知和未知未知对于提供卓越的数字体验至关重要 根据我们已经了解到的使用微服务构建的