When to Adopt Cloud Native？（什么时候适合云原生）

Cloud Native Infrastructure不是适合所有人的，任何架构设计都是一系列的权衡。只有熟悉自己需求的人才能决定哪些权衡对他们的需求有利或不利。

Cloud native infrastructure is not for everybody. Any architecture design is a series of trade-offs. Only people familiar with their own requirements can decide what trade-offs are beneficial or detrimental to their needs.

在不了解工具或设计的影响和局限性的情况下，不要采用该工具或设计。我们相信云原生基础设施有很多好处，但也应该盲目采用。作者不愿意引大家走错路。

Do not adopt a tool or design without understanding its impact and limitations. We believe cloud native infrastructure has many benefits, but realize it should not be blindly adopted. We would hate to lead someone down the wrong path for their needs.

如何知道你是否应该使用云原生基础架构进行架构设计？ 以下是您需要回答的一些问题，以确定云原生基础架构是否最适合您：

• 您是否拥有云原生应用程序？ （有关可从云原生基础结构中受益的应用程序功能，请参阅第1章。）
• 您的工程团队是否愿意并且能够为承载着具体功能的软件编写有生成质量代码？
• 您是在本地还是在公共云中可以使用API驱动的基础设施（IaaS）？
• 您的企业是否需要更快的开发周期或非线性的系统与维护人的比例？

How can you know if you should pursue architecting with cloud native infrastructure? Here are some questions you can ask to figure out if cloud native infrastructure is best for you:

• Do you have cloud native applications? (See Chapter 1 for application features that can benefit from cloud native infrastructure.)
• Is your engineering team willing and able to write production-quality code that embodies their job functions as software?
• Do you have API-driven infrastructure (IaaS) on-premises or in a public cloud?
• Does your business need faster development cycles or nonlinear people/systems scaling ratios?

如果您对所有这些问题的回答都是肯定的，那么您可能会受益于本书其余部分所述的基础设施。 如果您对这些问题的回答均为“否”，则并不意味着您无法从某些云原生实践中受益，但是需要做很多前置准备工作。

If you answered yes to all of these questions, then you will likely benefit from the infrastructure described in the rest of this book. If you answered no to any of these questions, it doesn’t mean you cannot benefit from some cloud native practices, but you may need to do more work before you are ready to fully benefit from this type of infrastructure.

在您的业务准备就绪之前尝试采用云本地基础设施和强制采用不正确的解决方案同样糟糕。 通过尝试在不进行尽职调查的情况下获得收益，您可能会失败并认为此架构有缺陷或没有任何好处。 由于过去的偏见，由于过去的偏见，一个屡试不爽的解决方案以后很可能难以采用，不管它是否是正确的解决方案。

It is just as bad to try to adopt cloud native infrastructure before your business is ready as it is to force a solution that is not right. By trying to gain the benefits without doing due diligence, you will likely fail and write off the architecture as flawed or of no benefit. A tried and failed solution will likely be harder to adopt later, no matter if it is the right solution or not, due to past prejudices.

我们将讨论一些成为云原生时要关注的一些领域。 有许多事情需要考虑，但最关键的是您的应用程序，组织中的人员，基础架构系统和您的业务。

We will discuss some of the areas to focus on when preparing your organization and technology to be cloud native. There are many things to consider but some of the key areas are your applications, the people at your organization, infrastructure systems, and your business.

Applications（应用）

应用是最容易准备好的部分，自从公有云出现依赖，一些设计模式已经很好的建立，工具也得到了大大的改善。如果您无法构建云原生应用程序并通过经过自动验证和测试的流水线，并自动部署它们，则不应继续采用Cloud Native基础设施来支持它们。

Applications are the easiest part to get ready. The design patterns are well established, and tooling has improved dramatically since the advent of the public cloud. If you are not able to build cloud native applications and automatically deploy them through a verified and tested pipeline, you should not move forward with adopting the infrastructure to support them.

构建云原生应用并不意味着你必须是微服务，它也不意味着你必须使用潮流的语言编译你的软件。但是你必须要写可由软件管理的软件。

Building cloud native applications does not mean you must first have microservices. It does not mean you have to be developing all your software in the newest trending languages. It means you have to write software that can be managed by software.

人与云原生应用程序进行的唯一的交互应该是在开发过程中。其它所有的应由基础设施或其他应用程序管理。

The only interaction humans should have with cloud native applications is during their development.1 Everything else should be managed by the infrastructure or other applications.

了解应用程序的另一种方法是，他们需要动态扩展多个实例。 扩缩容通常意味着负载均衡器后面的同一应用程序的多个副本。 它假定应用程序将状态存储在存储服务（即数据库）中，并且不需要在运行实例之间进行复杂的协调。

Another way to know applications are ready is when they need to dynamically scale with multiple instances. Scaling typically implies multiple copies of the same application behind a load balancer. It assumes that applications store state in a storage service (i.e., database) and do not require complex coordination between running instances.

动态应用程序管理意味着没有人做这项工作。应用程序的度量触发了扩容，而基础设施做了正确的事情来扩展应用程序。这是大多数云环境的基本特性。能够自动扩容并不意味着您拥有云本地基础设施；但如果能够自动扩容，则可能表示您的应用程序已就绪。

Dynamic application management implies that a human is not doing the work. Application metrics trigger the scaling, and the infrastructure does the right thing to scale the application. This is a basic feature of most cloud environments. Running autoscaling groups doesn’t mean you have cloud native infrastructure; but if autoscaling is a requirement, it may indicate that your applications are ready.

为了使应用程序受益，编写应用程序和配置基础结构的人员需要支持这种工作方法。 如果没有人准备放弃对软件的手工控制，你将永远不会意识到这些好处。

In order for applications to benefit, the people who write the applications and configure the infrastructure need to support this method of working. Without people ready to give up control to software, you’ll never realize the benefits.

People（人）

人是云原生基础设施中最难的部分

People are the hardest part of cloud native infrastructure.

如果你想建立一个架构，用软件取代人们的功能和决策，你需要确保他们知道你有他们的最佳利益。他们不仅需要接受变化，而且还需要自己构建它自己。

If you want to build an architecture that replaces people’s functions and decisions with software, you need to make sure they know you have their best interests in mind. They need to not only accept the change but also be asking for it and building it themselves.

开发应用程序很难; 运营基础设施很难。 应用程序开发人员通常认为他们可以用工具和自动化替换基础设施，基础设施的运维希望应用程序开发人员编写更可靠的代码，能够通过自动调试和恢复。这些紧张关系是DevOps的基础，DevOps还有许多其他相关书籍，例如《Effective DevOps》by Jennifer Davis and Katherine Daniels (O’Reilly, 2016)

Developing applications is hard; operating infrastructure is hard. Application developers often believe they can replace infrastructure operators with tooling and automation. Infrastructure operators wish application developers would write more reliable code with automatable debugging and recovery. These tensions are the basis for DevOps, which has many other books written about it, including Effective DevOps, by Jennifer Davis and Katherine Daniels (O’Reilly, 2016).

人员不成规模，也不擅长重复乏味的任务

People don’t scale, nor are they good at repetitive, mundane tasks.

应用程序和系统工程师的目标应该是消除乏味和重复的任务，以便他们可以专注于更有趣的问题。 他们需要由能力开发可以包含业务逻辑和决策的软件。 需要有足够的工程师来编写所需的软件，更重要的是维护它。

The goal of application and systems engineers should be to take away the mundane and repetitive tasks so they can focus on more interesting problems. They need to have the skills to develop software that can contain their business logic and decisions. There needs to be enough engineers to write the needed software, and more importantly, maintain it.

最关键的方面是他们需要共同努力。 在没有另一方支持的情况下，工程的一方无法迁移到运行和管理应用程序的新方法上。 团队组织和沟通结构很重要。

The most critical aspect is that they need to work together. One side of engineering cannot migrate to a new way of running and managing applications without the support of the other. Team organization and communication structure is important.

我们很快就会解决团队的准备问题，但首先我们必须确定基础设施系统何时为云原生基础设施做好准备

We will address team readiness soon, but first we must decide when infrastructure systems are ready for cloud native infrastructure.

Systems（系统）

云原生应用程序需要系统抽象。 应用程序不应该使用单独的硬编码的主机名相互联系。 如果您的应用程序没有在某个主机上小心放置，就无法运行，那么对于云本机基础设施，您的系统尚未准备好。

Cloud native applications need system abstractions. The application should not be concerned with an individual, hardcoded hostname. If your applications cannot run without careful placement on individual hosts, then your systems are not ready for cloud native infrastructure.

将运行操作系统的单个服务器（虚拟或物理）转换为访问资源的方法，这就是我们所说的“抽象”的意思。单个系统不应该成为应用程序部署的目标。所有可用的机器资源（CPU、RAM和磁盘）应该集在“池子”里，然后由平台根据应用程序的请求进行分配。

Taking a single server (virtual or physical) running an operating system and turning it into a method by which to access resources is what we mean when we say “abstractions.” Individual systems should not be the target of deployment for an application. Resources (CPU, RAM, and disk) should be pooled across all available machines and then divvied up by the platform from applications’ requests.

在云原生基础设施中，您必须隐藏底层系统以提高可靠性。 与应用程序一样，云基础设施接受底层组件发生故障，并在设计上，能够优雅地处理这些故障。 这是必需的，因为基础设施工程师不再能够控制体系中的每个内容。

Kubernetes是云原生基础设施吗？

Kubernetes是一个可以更轻松地管理应用程序的框架，促进你以云原生的方式去做。 但是，您也能够以非常原始的方式使用Kubernetes。

Kubernetes构建其核心功能之上，暴露扩展性，但它不是您的基础设施的最终目标。其他项目（如Openshift）构建在它之上，从开发人员和应用程序中抽象出Kubernetes。

如果你的应用是动态的，但是你的基础设施是静态的，那么你很快就会陷入一个无法单靠Kubernetes解决的僵局。

In cloud native infrastructure, you must hide underlying systems to improve reliability. Cloud infrastructure, like applications, expects failures of underlying components to occur and is designed to handle such failures gracefully. This is needed because the infrastructure engineers no longer have control of everything in the stack.

Is Kubernetes Cloud Native Infrastructure?

Kubernetes is a framework that makes managing applications easier and promotes doing so in a cloud native way. However, you can also use Kubernetes in a very uncloud-native way.

Kubernetes exposes extensions to build on top of its core functionality, but it is not the end goal for your infrastructure. Other projects (e.g., OpenShift) build on top of it to abstract away Kubernetes from the developer and applications.

Platforms are where your applications should run. Cloud native infrastructure supports them but also encourages ways to run infrastructure.

If your applications are dynamic but your infrastructure is static, you will soon reach an impasse that cannot be addressed with Kubernetes alone.