如何避开陷阱迈向云原生
Posted InfoQ
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何避开陷阱迈向云原生相关的知识，希望对你有一定的参考价值。
如今，许多开发团队仍在数据中心中运行着单体应用程序。那些久经考验的三层架构真是太棒了！你雇来的开发人员写好代码，扔到应用里，而你请来的系统管理员随时待命，负责运行这些应用。一般来说，因为这种工作分配机制，你们每年才能交付和部署一个大版本——如果你们真的很擅长做自己的事情，那么一年可能会交付和部署两个大版本。如果你们不是谷歌或 Netflix，这样做完全没问题——用作者 Jim Butcher 的那句知名格言来说，你只需要比直接竞争对手更快就行了。
但是要真正超越竞争对手，你需要投资工具链和方法，来更快获得可以让用户受益的功能。迁移到云并充分利用开源软件和开放规范可以让你跑得更快、最大程度地减少对供应商的依赖、实现更快的迭代，并促进利益相关者之间的信任。这些好处让开源方法成为了一种特别高效的，支持向云中的容器化应用程序迁移的方式。
在数字化转型项目和较小的、更接近战术层面的项目中，迁移到云的一大核心动机往往是自助服务。相比需要管理和维护平台、还要管理部署的 IT 运维方法，自助服务方法可以让开发人员从集群级别的访问到更类似 PaaS 的环境中自己处理各种事宜。在这种情况下，容器化微服务至关重要：容器解决了包装层面的挑战，而微服务则让各个开发团队可以独立地迭代和发布他们的服务和功能，这和单体应用中的情况是不一样的。
这种动态变化需要一些组织层面的调整，尤其是在 IT 部门内部，因为团队必须更加主动和一致地沟通，而不仅仅是通过格式票证来交流，这样才能促进新功能的发布。与过去的日子形成鲜明对比的是，IT 运营商和开发人员会发现他们的动机是一致的；过去的日子里，开发人员通常希望最大化功能的交付数量，而运维人员则希望最小化交付数量以保持整个系统的稳定性。当你迁移到较小的部署单元后，由于云将虚拟机和网络等构建模块隐藏在了 API 的后面，因此开发人员最终将承担起运维例程的责任，包括安全性、可观察性，并对所部署的代码随时待命。软件供应链的转变意味着开发人员必须养成良好的运维习惯，例如对应用程序源代码进行编排以发出日志、指标和跟踪，或扫描代码寻找漏洞。
在这种转型过程中，请记住在同事之间、管理链中以及与合作伙伴和供应商之间建立信任都需要花费时间。向云迁移所带来的企业文化变化通常是摩擦最严重的部分。新建项目和 / 或小型项目在这个过程中是很有用的：你可以快速查看结果、从错误中学习，并通过实施 DevOps 实践（如小批量工作并承诺快速反馈循环）等来逐步建立信任。
免费的开源软件作为你的库的一部分或在服务背后部署时有很多好处——重点在于你可以自己修复有问题的代码。当然，对我们大多数人来说，维护一个分支并不是完全可持续的行为，但是比起依靠供应商来处理支持案例，如果能立刻获得临时的有效缓解措施的话，生产力自然要高得多。
如果你选择以开放规范为构建基础（甚至可能是受互联网工程任务组、万维网联盟或云原生计算基金会等机构认可的标准），那么另外一个好处是，你可以在本地和云端使用相同的设置。对于本地设置，你可以部署开源解决方案、开 / 闭源混合解决方案，甚至是专有解决方案。在云中，你将使用基于开源项目或符合开放规范的托管服务。开源示例的列表几乎是无止境的，包括可观察性领域的 OpenTelemetry 和 OpenMetrics、用于定义和执行组织或监管策略的 OpenPolicyAgent、用于可移植容器包装和执行的 Open Container Initiative 映像和运行时规范，以及 Kubernetes API、Envoy xDS API 或用于容器编排和联网的 Service Mesh 接口。另外一个优点是，对于每种规范、API 和格式，通常都可以选择多个开源实现，这样就扩展了你的选择范围。
开放规范和开源软件还可以促进迁移本身：当你将负载从数据中心转移到云中时，你可以将升级操作系统、库和安全补丁等基础架构组件的繁重工作转移到你选择的云提供商上，从而释放资源，让你可以专注于你的核心业务和产品。
除了所有这些优势，你自然也会面临一些挑战。我们来重点看看我在实践中目睹的两个最突出的障碍。
首先是开源软件不一定像企业服务那样受到良好的支持。只要觉得合适，任何人都可以使用开源软件并运行它。但如果你遇到错误，或者想要添加功能，或者想要对其进行扩展测试的时候该怎么办呢？开源软件的作者没有义务为你提供你需要的补救措施。FOSS（Free Open Source Software）中的“F”表示你被允许并鼓励使用封闭的专有软件无法执行的某些操作，但这并不意味着你将获得免费支持。相反，你可能需要向某些供应商付款才能获得支持，或者在你的团队内部加强工程能力来解决问题。
第二个是与社区相关的挑战：你需要在一定程度上与项目社区的步调保持一致。以 Kubernetes 的发布周期为例：Kubernetes 的小版本每三个月发布一次，结果你需要每年升级你的平台两到三次。这种升级涉及很多核心依赖项，例如群集附件、托管的应用程序，以及第三方组件（例如运行时扫描器或可观察性代理），你需要对它们都做好测试才能确保它们都可以在新版上继续工作。沃德利地图（https://en.wikipedia.org/wiki/Wardley_map）可以帮助你了解给定的 FOSS 产品及其生态系统在商品化与定制频谱之间处于哪个位置，帮助你了解随着时间的推移，与项目社区保持一致将需要花费多少精力。
在采用开源组件推动你的云原生之旅时，专注于更底层的容器这样的抽象，而不是更接近 PaaS 或者 FaaS 级别的抽象，这是没有错的。如果你能根据你的特定业务需求来优化负载，很可能会给你带来超越竞争对手的优势。请注意你所使用的抽象级别，并准备好处理这种抽象带来的后果，因为它可能会影响可移植性和开发人员的生产力。
那么，如何才能到达云端呢？首先，应该将迁移视为一种组织和文化挑战，而不是技术挑战。充分利用开放规范和开源软件，将它们作为迁移策略的一部分，你就可以增强团队能力、促成必要的开发运维协作，从而更快地发布功能，并在迁移至较小的部署单元时明确责任归属。它也可以基于自助原则带来更容易（由人类）扩展的系统。只要保持对开源产品的客观认识，你就能够避开陷阱，并充分利用你手头的工具。
以上是关于如何避开陷阱迈向云原生的主要内容，如果未能解决你的问题，请参考以下文章