Open Source Business Automation | Activiti
云原生范式转变：您准备好了吗？
The Cloud Native Paradigm Shift: Are You Ready?
https://blog.container-solutions.com/the-cloud-native-paradigm-shift-are-you-ready
云原生范式转变：您准备好了吗？
2019年4月3日由皮尼列兹尼克 - 4分钟的读出时间
在Container Solutions，当我们说我们要帮助公司将自己转变为Cloud Native实体时，我们出于特定原因使用该术语。Cloud Native是一项重大的范式转变，不仅仅是将最新的新技术固定在公司多年来一直在做的事情上。
上一次真正的范式转变是敏捷，它发生于20年前，但尚未结束。很少有人真正在做纯粹的敏捷，尽管许多组织都这样认为。大多数人并不真正了解敏捷-并且绝对不练习敏捷。尽管如此，许多人至少已经适应了一些敏捷工具，因此将自己视为敏捷。
更大的担忧是人们普遍认为Cloud Native仅是敏捷的增量阶段，就像下一步一样。但这既不真实，也有潜在危险。CN不是敏捷的一些向前迭代。这是真正的范式转变。它是敏捷的替代品。
为什么这么重要？对于我们来说，这是我们在进行Cloud Native准备情况评估时发现的。这意味着，实际上，在这样的组织中进行成熟度评估时，我们需要意识到这一点。
真实示例：一位客户，具有敏捷倾向的瀑布（冲刺和Scrum大师）打电话给我们，请教他们的云迁移。他们接受了我们的分析和反馈，并编写了一份长达80页的报告，花了四个月的时间将其汇总在一起。如果您有80页的图表和文档，那么您就不会敏捷。在CN中，如果您给我们四个月的时间，我们可以交付整个系统。
在决定迁移到CN时，应该在所有方面重新考虑您所做的一切。从文化到技术。假设您做的每件事都是错误的，并问自己如何改进。可以想象，这种“您需要改变一切”的信息，对于客户来说是非常惊人的。但这是正确的道路。
对于任何希望进行Cloud Native转型的公司来说，核心问题是他们根本不知道自己不知道的事情【出自：达克效应】。
可怕但必经之路
对于传统的瀑布式公司而言，这尤其具有挑战性。在他们的预测方法中，可以理解事情的运作方式。例如，召集一名工程师来估算为其产品制作iPhone应用程序需要多长时间。工程师说，三个月，他们的经理加倍或增加三倍，以考虑其他因素并得出切合实际的时间表。但这是线性推论，每个人都理解其中涉及的步骤。
但是，在Cloud Native转换的情况下，工程师没有估算依据。他们没有技术经验，因此只能做出最佳猜测-由于分布式系统固有的指数级困难和复杂性，这是完全错误的。他们说一个星期，事实证明是一年。
同样，他们的经理听见了三个星期的估计，进行了通常的推断，并提出了三个月的建议。。。但实际上已经三年了。只有他们无法知道这一点，也无法理解为什么会这样。他们不知道他们不知道的东西。
接下来发生的是，经理很快就用光了预算和耐心。典型的企业要耐心一到两年；我们最好，最支持云的客户需要一年的时间进行迁移。大多数公司需要更长的时间。
真实示例：我们曾经有一个客户端，该客户端安装了OpenShift（容器应用程序平台），并且在测试中运行了一个应用程序。基于这一成功经验，他们决定“确定，现在我们将在接下来的三周内加入10个团队。我们已经准备好完全使用Cloud Native！”
这是基于他们以前总是做事的方式，在这种情况下，这是一个可以理解的决定。但是，他们所做的是在他们一直使用的同一系统之上安装了一堆昂贵的复杂工具。是的，他们将拥有Kubernetes-但它们仍将每六个月部署一次。
我们需要更深入的了解，尽管这是向前迈进的一步，但实际上是相反的。当我们观察最终为公司带来的价值时，实际上是负面的。
没错，您可以指出拥有容器化微服务，并相信这使您成为Cloud Native公司。但是，实际上，您刚刚花了很多钱并投入了很多工作-但您并没有变得更快或更便宜。
典型的Cloud Native转换方案
既然我们能够识别一些常见的CN转换情况，那么我们在Container Solutions进行Cloud Native的时间已经足够长了。这些场景可能在细节上有所不同，但在结构和来源上却极为相似，我们在评估企业时经常会发现这些场景。对于全新的迁移计划，或者更经常的是，被要求找出导致该计划出错的原因。
这篇文章是 我们研究各种频繁发生的转换方案，它们的外观，发生的原因以及解决方案的几种方法之一。这些情况和解决方案也可以在我们即将出版的O'Reilly书中找到，“ 云原生转换：实用的创新模式” 。