译见|行业专家带你论道「云原生」

译见

你是否能准确地描述云原生的具体概念?你的应用和基础架构是否又需要诞生在云端?技术和方法之间的平衡是什么?本期的译见带你走进 InfoQ 与行业专家的部分讨论,了解更多关于云原生的相关内容。

参与讨论的专家有:

  • Christian Posta – 首席架构师,《Microservices for Java Developers》一书的作者。
  • Kevin Hoffman – Capital One 的工程师,《Building Microservices with ASP.NET Core》一书的作者。

核心要点

  1. 云原生架构增强了我们实施 DevOps 和持续交付的能力,并利用了云基础架构的特点。
  2. 不是试图“更好地预测未来”,而是要建立一个“更好地应对变化和不可预测性”的系统。
  3. 云原生不是所谓的银弹,抱着这样的想法进行实施会适得其反。

---------  01 ---------

问:应该如何定义云原生,为什么到现在大家都在关心以这样的方式创建应用程序?

Posta:

在回答什么是「云原生」之前,让我先解释一下为什么大家都应该关心“这种方式”vs“过去的方式”。我认为“过去的做法”可以总结为试图“真正预测未来”。这是讨论的关键。过去,我们花费了大量的时间,精力和金钱来“预测未来”:

  • 预测未来商业模式
  • 预测客户想要的
  • 预测设计/构建系统的“最佳方式”
  • 预测如何保持应用程序不失败

……

最后得出的想法是,我们不应该试图“更好地预测未来”,而是要建立一个“更好地应对变化和不可预测性”的系统。该系统由组成,并通过技术交付。

我们不应当考虑如何预测客户的需求,而应当通过将想法/产品/服务放在客户面前,核定其影响力,尽可能快地进行成本最低的实践。

我们不应当考虑如何预测构建系统的最佳方法,而应当在组织内进行实践,并通过观察决定什么是最契合员工/能力/期望的。

我们不应当考虑如何进行预测以避免应用程序的故障,而应当抓住故障和架构的可观察性,这样我们便能很快地对故障进行分类,对服务进行恢复并利用混乱测试不断地进行印证,长此以往。

「云原生」是描述应用程序,架构,平台/基础设施和流程的形容词,他们一起使用更为经济工作的方式,让我们能够提高快速响应变化和减少不可预测性的能力。

Hoffman:

Christian Posta 给出了一个绝妙的回答,我不认为我能回答得比他更好。

---------  02 --------

问:容器是云原生方法的重要组成部分吗?为什么是?或者是为什么不是?

Posta:

诚实的说,我不是很赞同这个问题的提出。我更喜欢在「云原生」方法中去考量在“功能和实践”上“什么才是至关重要的”。例如,让进行小批量生产更为低成本,所需的功能和实践是什么?诸如低成本的应用程序构建,安全部署,部署的自动化管理(启动/停止/扩展/健康检查等),安全性,分布式配置,流量路由等功能可以对如上的问题进行实现。容器在实现这些功能方面起着基础作用,并形成提供这些功能的技术/平台的基础,但同样功能也是十分重要的。

Hoffman:

我一直都认为这个问题是一个“错误的问题”。当我们考察一些与技术无关的需求,以实现与云原生相关的优势时,我们会看到如下的内容:快速和自动化的部署,容错,快速启动和停机时间以及环境平衡的能力。

深入探查这些需求列表,我们会看到其中许多都依赖于一个较低级别的需求 – 使用“不变的版本实体”。这是一种可移植的,不变的实体,它可以在虚拟机之间进行动态传输,并且可以在我们所有的环境中运行,而不会有所改变;它也可随时随地自动编排和启动; 这有助于我们实现许多云原生的需求。

所以,我会说,依赖不变的版本实体,是我们今天想到的支持云端的构建块的基础。容器(Docker 或其他)是我们用于实现不变的版本实体的执行细节,它只是一种手段而不是最终的目的。

---------  03 --------

问:云原生应用程序是否会改变操作和系统管理的性质?如果是这样,我们又应该怎么做?

Posta:

是的。云原生架构和应用程序会改变操作和系统管理的性质。

我们应像开发人员/功能团队所想要的那样进行快速部署,并且使用一些可控的方式向我们的用户发布软件。(请注意部署和发布之间的明显差异:部署让新版本的代码进入到生产环境之中;发布能为部署带来实时流量…部署与发布的分离与绝大对数团队的工作方式不同,通常情况下,部署 = 发布,这非常危险,这也就是为什么通常可能有很多繁文缛节,审批流程等,才能让代码进入生产)

还有很重要的一点是,我们需要衡量部署版本的发布版本所带来的影响,这也是云原生与旧模式之间的区别。就如同我开始所讲的那样,我们无法预测任何方面的确定性,而是需要构建一个更好应对变化和不可预测性的系统。

---------  04 --------

问:做一个合理的假设,大多数企业都拥有传统的,非云原生应用程序的数据中心。而你们都写过关于分解策略的有关内容,但是如果要将这些应用程序升级到云端,你建议企业做些什么?

Posta:

每个公司都是不同的,对于他们希望如何进行数字化转型的愿景,都有不同的策略和方案进行匹配。只是单纯复制一家公司做过的事情,会与我们的目标相去甚远。

对于这个问题的讨论应该先退后一步,将举措归类到符合 IT 投资组合战略的水平。我使用的三个方针是:

1)MVP/创新/探索型应用程序;

2)具有高增长预期的应用程序/服务;

3)最后是缓慢增长的现有旗舰应用程序/服务。

每个方针都需要不同的解决方案,不同的评估准则和不同的管理方法。在“云原生”或“微服务”的激流之中,我们应该选取战略性的方针。我在博客文章“About when not to do microservices”。

(地址:http://blog.christianposta.com/microservices/when-not-to-do-microservices/)

在对这些计划进行策略/共同的理解之后, 我们需要探索价值流, 这是每个主动性的交付能力的一部分。通常对价值流有一个好的、规划的想法 (提供一项倡议所需的步骤)可以突出需要改进的领域(或者某项倡议是否适用于改进/现代化)。例如, 在我们的价值流中, 如果我们的应用程序体系结构不是加快速度的瓶颈(提供更快的迭代), 那么无论我们如何优化 (微服务、云原生等), 都不会提高我们的交付能力。同样, 如果我们为某一特定的方针确定价值流,我们可能会发现,某些为现代化所做的努力可能没有造成像过程改进这样的巨大影响。

最后,根据应用程序/主动性落在何处,我们可能希望:

1)探索对现有架构的改进

2)添加/补充现有架构

3)完全/部分重写,实现更优化的架构。

例如像道格拉斯·哈伯德(Douglas Hubbard)的著作《How to Measure Anything》,当我们开始与云原生共舞时,他的策略应该在每个人的头脑中处于最前沿。

Hoffman:

在我的工作中,时常遇到这样的需求。在谈方略之前,我们需要先退后一步,询问迁移背后的原因是什么。一些企业存在遗留的应用程序,因为财务原因,他们只需要从数据中心迁移到云端。这些应用可能被冻结,只是在“生命支持”。在这种情况下,让应用程序实现云原生,应用到一个容器套件中运行可能就足以完成工作。

“升级与转移”与真正的云原生之间存在一个中间位置。企业开始的想法是,他们能非常简单地提升和转移并在云中运行,但是在将所有内容堆放在一堆容器的过程中,我们总是发现一些在云中无法正常工作的事情。它所使用的软件越旧(并且它承担的主机系统需求越多)就越有可能属于这一类。在这样的情况下,我们通常不得不分解大块的脆弱部分,以使应用程序在云中运行。公司需要作出价值判断,以确定在这里完全实现云原生是否符合他们的利益。

对于迁移应用程序的具体策略而言,不存在一个通解。可能有些人通过相应的新兴技术取得了成功,但对你而言,需要回答的真正问题是 – 希望从云原生中获得什么?你将如何衡量这些收益?怎样样云原生功能又是你认为可以添加到你的应用程序之中的?

专注于对云原生的迭代之旅的每一步都将有助于保持敏捷性,并确保不会一次锁定所有的开发资源,从而削弱你在迁移旧版本时持续构建新产品的能力。
本文部分内容引用自”Defining Cloud Native: A Panel Discussion”一文

原文地址:https://www.infoq.com/articles/cloud-native-panel?utm_source=articles_about_Containers&utm_medium=link&utm_campaign=Containers

Leave a Reply

Your email address will not be published. Required fields are marked *