101

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

 6 years ago
source link: https://mp.weixin.qq.com/s?__biz=MzA5NTUxNzE4MQ%3D%3D&mid=2659269066&idx=1&sn=7508c548e46df7c3f81aa8db97716e56&chksm=8bcbb958bcbc304ea2a92f98f0eaa0e2c4ec33c9910df3329700bddee0543ae02ac1d0dd72b6%23rd
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

Original Boring 编译 道客船长 2017-10-26 11:21 Posted on

Image

你是否能准确地描述云原生的具体概念?你的应用和基础架构是否又需要诞生在云端?技术和方法之间的平衡是什么?本期的译见带你走进 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"一文,点击 阅读原文 可查看英文原文。

Image

☟点击查看英文原文


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK