在互联网早期，如果你想推出一个应用，你必须购买或租用硬件——单台物理服务器或服务器阵列，而且每个应用需要一台服务器，成本很高。在2001年，VMware推出了虚拟化，允许用户在同一硬件上运行多个应用程序。这意味着你可以将一个“盒子”分解成多个虚拟“盒子”，每个“盒子”运行自己的环境和应用程序。这给企业带来了巨大的成本节约。
 
到2006年，亚马逊通过AWS及EC2推广了IaaS的概念。你不再需要购买自己的硬件。你甚至不用担心运行和管理那些应用程序的虚拟机。你实际上是租用运行服务所需的计算环境和底层基础设施。你按小时支付，跟租用会议室一样。这使得公司能够优化资源以降低成本，只购买所需的计算能力。这是革命性的，使得计算成本惊人地下降。
 
三年后，Heroku提出了PaaS的概念。通过删除对虚拟操作系统的管理，PaaS在EC2之上运行着一个层。Heroku神奇地简化了应用程序新版本的部署——你只需要键入git push heroku。一些最著名的网络公司都起源于Heroku。
 
这些进步使得以任何规模部署应用程序变得更容易和更实惠。它们导致了许多新业务的创建，并推动了企业对待基础设施的巨大转变——将其从资本支出转移到可变的运营支出。
 
听起来很好，但有一个大问题。所有这些提供商都是专有公司。这就是供应商锁定。在各种环境之间迁移应用程序很困难。混合和匹配内部部署的和基于云的应用程序几乎是不可能的。
 
到开源的时候了。还是Linux，Docker和Kubernetes——它们是云的Linux。
 
开源成了救星
 
Docker在2013年出现，推广了容器的概念。“容器”这个名字对应着一项全球化的革命——船运公司用适合船舶、卡车和铁路车厢的标准化的大型金属集装箱取代其他的货运装载形式。
 
与运输容器类似，Docker容器创建了可在任何基础设施上运行的基本计算包装。容器风靡世界。今天，几乎所有的企业都在计划着容器基础设施之上的未来化应用程序，即使它们现在在私有硬件上运行着应用程序。容器是管理现代应用程序的一种更好的方式——现代应用程序经常被切割成无数的组件（微服务），需要轻松地迁移和连接。
 
这导致了另一个问题。DevOps团队过去对管理容器一无所知，而它给移动部件的数量和围绕应用程序部署的动态活动带来了阶跃性的变化。于是轮到了Kubernetes。
 
2015年，谷歌将Kubernetes作为开源项目发布。它是谷歌内部系统Borg的实施。谷歌和Linux基金会创建了云原生计算基金会（CNCF），将Kubernetes（和其他云原生项目）作为一个由社区管理的独立项目。Kubernetes迅速成为历史上增长最快的开源项目之一，拥有成千上万的贡献者。
 
让Kubernetes的发展速度如此令人难以置信的是，它自带谷歌Borg的经验。没有哪家公司的规模能大过谷歌。Brog每周推出超过20亿个容器，平均每秒3300个。在高峰时期，数量更多。Kubernetes出生在“水深火热”中，在应付巨量工作负载方面久经考验。

 基于Dockers和Kubernetes的核心理念，CNCF成为许多其他云原生项目的“家园”。现在，云原生领域有超过369个大大小小的项目。由CNCF管理的重要云原生项目包括Kubernetes、Prometheus、OpenTracing、Fluentd、Linkerd、gRPC、CoreDNS、rkt、containerd、Container Networking Interface、CoreDNS、Envoy、Jaeger、Notary、The Update Framework、Rook和Vitess。
 
汲取其他开源项目的经验教训，CNCF一直非常谨慎，以确保只选择那些能够很好地协同工作并能够满足企业和创业公司需求的技术。这些技术正在被大量采用。
 
企业涌向开源技术的一个最大的原因是避免供应商锁定并能够跨越云和私有基础设施移动容器。使用开源软件，你可以轻松切换供应商，也可以混合使用供应商。如果你有足够的技能，你可以自己管理堆栈。
 
切割单体
 
Kubernetes和容器不仅可以提升规模化管理的能力，还可以采用大规模的单体应用程序，并且更容易将它们分割成更易于管理的微服务。每个服务可以根据需要进行缩放。微服务还支持更快的部署和更快的迭代，以满足现代化持续集成实践的需要。基于Kubernetes的编排可以通过动态管理和调度这些微服务来提高效率和资源利用率。它还带来了非凡的弹性水平。你不必担心容器故障，也可以不用管需求的增加和减少继续运行。
 
Kubernetes已成为云原生编排的首选。它也是开源历史上速度最快的开发项目之一，得到了AWS、微软、红帽、SUSE等主要厂商的支持。
 
所有这些都对企业有直接的影响。根据Puppet的2016年DevOps状态报告，高性能云原生架构可以拥有更频繁的开发、更短的交付周期、更低的故障率和更快的故障恢复。这意味着功能可以更快地推向市场，项目可以更快地发挥作用，而工程和开发团队的等待时间则可以短得多。
 
现在，如果你要从头开始构建新的应用程序，那么云原生应用程序架构是正确的方法。同样重要的是，云原生思维提供了一个路线图：如何利用现有应用程序，并将它们慢慢转化为运行在容器和Kubernetes上的更高效的、更有弹性的基于微服务的架构。要知道，单体应用程序构成了当今大部分软件产品。

单体与云原生是对立的。它们昂贵，灵活性差，紧耦合和脆弱。问题是：如何将这些单体分解为微服务？你可能想要重写所有的大型遗留应用程序。但事实是，大多数重写都以失败告终。
 
你可以更有效地解决这类问题。首先，停止向现有的单体应用程序添加重要的新功能。有一个“lift and shift”的概念——这意味着你把一个需要GB级RAM的大型应用程序用一个容器包起来。很简单。

举个栗子：从单体到容器的转变
 
Ticketmaster是这种方法的一个很好的例子。它拥有在PDP-11上运行的代码。它创建了一个在Docker容器内部运行的PDP-11仿真器，以便能够容器化该遗留应用程序。Kubernetes有一项特定的技术，称为Stateful Sets（以前称为PetSets），它允许你将容器锁定到一个硬件，以确保它具有主动性能。
 
Ticketmaster存在一个独特的问题：每当要出售票时，它实际上发起了分布式拒绝服务（DDoS）攻击。该公司需要一组前端服务器，可以扩展和处理这个需求而不是尝试将其写入遗留应用程序中。为此，它在遗留应用程序的前面部署了一组新的微服务容器，从而最大限度地减少了遗留架构中的持续蔓延。
 
当你试图将工作负载从遗留应用程序迁移到容器时，你可能还希望将某些功能从应用程序迁移到微服务中，或者使用微服务来添加新功能
（而不是添加到旧代码库中）。例如，如果你想添加OAuth功能，可以在遗留应用程序前放一个简单的Node.js应用程序。如果你有一个高度性能敏感的任务，你可以在Golang中编写它，并将其设置为一个驻留在遗留单体之前的API驱动的服务。你仍然可以将API调用返回到现有的遗留单体。
 
这些新功能可以由不同的团队用更现代的语言编写，这些团队可以使用自己的一系列库和依赖关系，并开始拆分该单体。
 
北卡罗来纳州的KeyBanc就是采用这种方法的一个很好的例子。它在遗留Java应用程序之前部署Node.js应用程序服务器来处理移动客户端。这比往遗留代码里添加更简单，更高效，并且有助于确保其基础设施的发展。
 
真正的云原生是互补项目的组合

如果你正在转向使用云原生技术，你应该考虑用一系列互补项目来提供核心功能。例如，云原生环境中的最高优先事项是监控、跟踪和日志记录。你可以使用Prometheus、OpenTracing和Fluentd。Linkerd是支持更复杂版本路由的服务网格。gRPC是一个非常高性能的API系统，可以替代需要更高吞吐量的应用程序的JSON响应。CoreDNS是一个服务发现平台。这些项目现在都是CNCF的一部分，CNCF希望继续为互补的解决方案集增加更多的项目。
 
任何领域都可以是云原生的

当你将遗留单体迁移到云原生微服务时，你不需要重写所有内容。像Kubernetes这样的CNCF技术热爱“棕色地带”的应用。这是一条几乎每个企业和公司都应该走的进化之路。你可以在Kubernetes中建立一个全新的应用程序，也可以稳步地将单体演变成一个很棒的、未来几年都好用的云原生微服务网格。

原文参考：
https://opensource.com/article/18/2/how-kubernetes-became-solution-migrating-legacy-applications

推荐阅读：

扎心！Kubernetes企业落地六大“难”
解读2017之Service Mesh：群雄逐鹿烽烟起
大规模生产中 自动化Kubernetes的7种经典装备