职场必杀技_达到必杀技：云成熟度的四个层次

职场必杀技

通过从您的应用程序学习企业APM产品，发现更快，更有效的性能监控。 参加AppDynamics APM导览！

云采用是一段旅程，在云平台（公共或私有）上采用微服务可以带来更大的敏捷性，显着的成本节省以及组织的出色弹性。 阅读更多内容以了解考虑的方法和采用DevOps实践是实现“涅rv状态”的最快方法。

出于充分的理由，采用云技术是每个CIO的首要任务。 技术栈正以迅雷不及掩耳的速度发展。 在过去的十年中，应用程序架构正在快速老化，并已被基于现代，公共和私有云的架构所取代。 但是，尽管不可避免地采用云技术，但是绝大多数组织仍在寻找有效的应用程序迁移策略， Gartner指出。

如果您觉得自己在云计算之旅中落后于竞争对手，则无需惊慌。 结构化，全面的迁移模型与明智的投资策略相结合，将对确保成功大有帮助。 我们的云成熟度模型基于我们从与CIO进行的数百次对话中收集的见解，这些对话涉及CIO的云采用策略以及我们成功支持的众多客户迁移。 在采用过程中，我们已经确定了常见的模式或“成熟度级别”。 通过了解此成熟度模型，您可能会发现开发自己的云策略更加容易。

下面我们描述云成熟度的四个级别。 重要的是要注意，进步并不需要一路走好每一步。 一些组织跳过级别，例如从级别1跳到级别3，并完全绕过级别2。 并非所有组织都需要达到第4级，并且大多数组织将同时在不同成熟度级别的产品组合中使用不同的应用程序。 例如，由于产生收入的面向客户的应用程序必须是最敏捷和响应最快的，因此有必要将它们迁移到3级或4级，这是为快速交付应用程序和扩展而优化的。 另一方面，处于维护模式的旧应用程序可以保持在1级或2级，而不会产生过多的额外投资。 此外，请记住，公司正在采用DevOps运营理念来完成这些转型任务（请参见下文）。

混合应用程序也是现实，在混合应用程序中，由于大型机系统无法移动或数据重力而使应用程序的某些部分继续在本地运行（戴夫·麦克罗里（Dave McCrory）的概念，即数据如此之大而几乎无​​法移动）。

级别1：传统数据中心应用

传统的数据中心应用程序可以在经典的虚拟机（例如VMWare）中运行，也可以在私有数据中心的裸机上运行，​​并且通常由IT Ops团队进行监控。 当然，这些架构和部署各有利弊。 优点包括完全控制您的硬件，软件和数据； 减少对互联网连接等外部因素的依赖； 大规模部署时可能会降低总拥有成本（TCO）。 缺点包括通常需要资本支出（CapEx）的大量前期成本，以及维护责任。 它们还导致更长的实施时间，从编写任何代码之前的硬件和软件采购开始。 鉴于这些缺点， 到2020年，企业“无云”政策极有可能会非常罕见。

第2级：提升和转移的应用

鉴于云对弹性和敏捷性的承诺，几乎每个IT组织都已开始采用云。 那些尚未真正开始迁移生产工作负载的人肯定是在此领域进行原型设计或试验。 但是，云迁移很少能顺利进行。 通常，组织会采用与本地运行的虚拟机相同的虚拟机，然后将其“提升并转移”到云中。 目标环境通常是公共云提供商，例如Amazon AWS，Microsoft Azure或Google Cloud，或者有时是配置为私有云的私有数据中心。

合理的迁移策略？ 并不是的。 尽管这种方法有望节省成本，但一家公司经常发现，以与本地部署相同的方式在云中运行其应用程序要昂贵得多。 这些应用程序设计用于的大型VM配置在云中非常昂贵。 在其他情况下，底层基础架构缺乏其在内部的支持。 例如，某些依靠多播功能相互通信的应用程序服务器在完全抬起和转移时不再在云中工作。 这些缺点要求应用程序重构。

最后，也许是最重要的是，这些传统的数据中心应用程序是在某些硬件可靠性假设下编写的，这些假设在云中可能不再有效。 本地硬件通常是自定义构建的，旨在提高可靠性，而云的构建宗旨是：硬件便宜且不可靠，而软件层则提供了应用程序的弹性和健壮性。 这是必须进行应用程序重构的另一个原因。

级别3：重构的应用

一旦组织意识到其某些迁移和迁移的应用程序在根本上阻碍了云的发展，就需要重构其应用程序。 专门为在云环境中运行应用程序而构建的几种现代平台是重构程序的理想选择。 这些现代平台通常包括应用程序平台即服务（PaaS）技术或云原生服务。 典型的PaaS技术包括Pivotal Cloud Foundry，Red Hat OpenShift，AWS Elastic Beanstalk，Azure PaaS和Google App Engine。 云原生产品包括AWS，Azure和Google Cloud提供的数百种托管服务，例如数据库，Kubernetes和消息传递服务等。

在传统的数据中心应用程序环境中，IT组织负责部署，管理和扩展应用程序代码。 相比之下，这些现代平台使任务自动化并抽象出许多复杂性。 应用程序变得灵活，动态消耗计算资源来满足各种工作负载。 现代方法使IT组织无需维护对其业务没有任何知识产权保护的东西，从而使其能够专注于业务问题而不是基础结构问题。

第3级是组织开始看到云真正潜力的迹象。 这也是公司可以涉足容器技术并开始建立组织才能在现代架构中运行应用程序的地方。 但是，在这个世界上，并非所有事物都是完美的。 组织在采用某些云原生服务时需要谨慎，这可能导致供应商锁定和较差的应用程序可移植性-对于某些公司而言，这是头等大事。

尽管现在看来云之旅已经完成，但障碍依然存在。 重构应用程序通常与整体应用程序中的代码相同，只是分解为更易于管理的组件。 这些较小的组件现在可以使用PaaS或云原生服务自动扩展，但是它们的代码最初并不是为真正的模块化，无状态部署而设计的，因此无法线性扩展。 是的，在获得自定义性能的芯片升级后，汽车的运行速度可能会更快，但是为了高速协商赛车场的转弯，需要从头开始构建汽车才能获得高性能。

级别4：微服务-涅rv状态

顾名思义，微服务是一种体系结构，其中应用程序是小型，模块化和可独立部署的服务的集合，这些服务可以按需扩展以满足应用程序工作负载的需求。 这些服务通常使用容器和编排技术（Docker和Kubernetes或AWS，Azure和Google容器服务）或无服务器计算（AWS Lambda，Azure Functions或Google Functions）进行架构。

该级别被称为“涅磐状态”的原因是因为基于微服务架构构建的应用程序具有超伸缩性和容错性，从而确保了应用程序的超响应性和不间断的最终用户体验。 组织可以将较小的服务分发给灵活的DevOps团队，这些团队独立运行并享有更快创新的自由，从而可以在更短的时间内将新功能推向市场。

但是，这需要做出巨大的承诺：公司必须从核心重新构建其应用程序，或者使用微服务方法编写所有新应用程序。

尽管这些细粒度的服务提供了许多好处，并且单个服务更易于管理，但是将它们组合到更广泛的业务应用程序中可能会变得复杂，尤其是从监视和故障排除的角度来看。

DevOps适用的地方

尽管此成熟度模型通过技术角度探讨了云的采用，但组织的发展对于采用过程的成功至关重要。 从孤立的Dev和IT组织过渡到更高的DevOps模型对于实现更高成熟度的所有收益绝对至关重要。

DevOps团队通常由8至10人组成，其中包括开发人员和站点可靠性工程师（SRE）。 每个超级敏捷团队仅负责少量服务，而不负责整个应用程序。 团队对服务的响应能力以及交付新功能的速度感到非常自豪。 这里的主要原则是：构建，拥有，运行它！ 这就是使DevOps与传统的Dev和Ops分离不同的原因。

必杀技需要时间和努力

云采用是一段旅程，在云平台（公共或私有）上采用微服务可以带来更大的敏捷性，显着的成本节省以及组织的出色弹性。 有时这条路似乎很危险，但不要气disc！ 每个人都在同一个道路上。 CompTIA预测 ，全球IT领域有望再度实现爆炸性增长（5.0％），并且正在拥抱快节奏的创新。 采取深思熟虑的方法并采用DevOps实践是实现“涅rv状态”的最快方法。

详细了解 AppDynamics如何在云成熟的道路上为您提供帮助。

通过从您的应用程序学习企业APM产品，发现更快，更有效的性能监控。 参加AppDynamics APM导览！

翻译自: https://www.javacodegeeks.com/2018/04/attaining-nirvana-the-four-levels-of-cloud-maturity.html

职场必杀技