Git 和其他现代化运维工具可以简化 Day 2 运维,即使对于最复杂的云原生应用也是如此。
译自 Learn to Love Day 2 Operations with GitOps-Driven API Management,作者 Emile Vauge。
让我们面对现实:爱上 Day 2 可能很难——应用程序部署到生产环境后发生的一切。对于支持现代 云原生应用程序 的许多工程师来说,Day 2 一直是手动监控和管理流程、孤立的操作以及对破坏某些内容的担忧。
Day 2在现代环境中通常如此具有挑战性的一个核心原因是,它们涉及大量连接的系统,而管理所有这些系统——以及 连接它们的 API——可能非常困难。API 是将现代分布式应用程序粘合在一起的粘合剂;然而,如果你以命令式、手动的方式进行开发、监控和更新 API,则可能会非常耗时且乏味。
这是针对微服务应用程序管理 API 的传统方法的情况。但这不必如此。通过更现代的策略——基于 Git 和其他对现代运维至关重要的工具——你可以简化和精简Day 2运维,即使是最复杂的云原生应用程序也是如此。
Day 2运维包含所有任务——包括 API 部署、版本控制、监控、故障排除、事件缓解和更新——团队必须执行这些任务才能持续保持应用程序的正常运行。
鉴于根据 Palo Alto Networks的说法,当今单个应用程序平均依赖 26 到 50 个 API ,管理Day 2运维具有挑战性的原因有很多:
这些不同的挑战根源于相同的基本原因:复杂性。当你有复杂的应用程序架构和复杂的 API 时,在降低风险的同时快速创新比在更简单的环境中要困难得多。基于虚拟机的单体应用程序很少依赖 API(如果有的话),可以更快、更轻松地进行监控和更新,因为它包含的活动部件更少,潜在故障点也更少。云原生应用程序并非如此。
面对现代应用程序的Day 2运维挑战,团队该怎么做?
错误的答案是避免复杂的架构。云原生应用程序及其支持的 API 更难管理,但避免它们意味着错失现代应用程序提供的更大的可扩展性、可靠性、成本效益和其他重要优势。
更明智的策略是在有意义的情况下开发云原生应用程序(或将单体架构重构为云原生架构),同时利用现代运维来简化Day 2运维。
例如,现代运维意味着使用 Git 来管理和自动化环境配置。这使 GitOps(GitOps)涉及编写资源的声明式配置文件,在 Git 中存储和版本控制它们,并自动将更新推送到生产环境。
GitOps 方法简化了围绕Day 2运营的一些最深层次的挑战,尤其是涉及 API 的那些挑战:
简而言之,现代运营为你提供了Day 2的双重优势:降低风险和快速协作创新。而且,由于现代运营是自动化且可重复的,因此你可以像管理一个 API 一样轻松地管理 1,000 个 API。你的扩展能力几乎是无限的。
传统的 API 管理方法可以追溯到云原生革命之前,云原生革命使高度可扩展的分布式环境成为常态。如今,Day 2运营需要自动化。事实上,自动化是获取云原生策略优势的唯一途径。
从 API 管理的角度来看,自动化意味着超越缓慢的变更管理、漫长的恢复流程和对 API 的控制不力。它需要采用一种现代的、轻量级的、模块化的、Kubernetes 原生的、基于 GitOps 的 API 管理方法,而这正是你应该从现代 API 管理解决方案中期待的。