《Migrating to Cloud-Native Application Architectures》学习笔记之Chapter 2. Changes Needed

2019独角兽企业重金招聘Python工程师标准>>>

Cultural Change 文化变革

A great deal of the changes necessary for enterprise IT shops to adopt cloud-native architectures will not be technical at all. They will be cultural and organizational changes that revolve around eliminating structures, processes, and activities that create waste.

企业IT团队采用云原生架构所需变革的并不是技术上的。而是围绕造成产生浪费的结构、过程和活动的文化和组织变革。

From Silos to DevOps 从独立组织到DevOps

企业IT通常被组织成以下许多独立组织:

软件开发
质量保证
数据库管理
系统管理
IT操作
发布管理
项目管理

These silos were created in order to allow those that understand a given specialty to manage and direct those that perform the work of that specialty. These silos often have different management hierarchies, toolsets,communication styles, vocabularies, and incentive structures.

这些独立的组织的创建是为了让那些了解特定专业的人能够管理和指导执行该专业工作的人。这些组织通常具有不同的管理层次结构、工具集、沟通方式、

Collaboration, communication, and simple handoff of work product becomes tedious and painful at best, and absolutely chaotic (even dangerous) at worst. Enterprise IT often tries to “fix” the situation by creating heavyweight processes driven by ticket-based systems and committee meetings. And the enterprise IT value stream slows to a crawl under the weight of all of the nonvalue-adding waste.

低效地协作、沟通和简单的工作产品交接方式，往好了说是乏味和痛苦的，往坏了说是绝对混乱的(甚至是危险的)。企业IT经常试图通过创建由投票方式和委员会会议驱动的重量级流程来“修复”改变这种情况。企业IT价值流在所有非增值浪费的重压下步履瞒珊。

At its heart, DevOps represents the idea of tearing down these silos and building shared toolsets, vocabularies, and communication structures in service of a culture focused on a single goal: delivering value rapidly and safely. Incentive structures are then created that reinforce and award behaviors that lead the organization in the direction of that goal. Bureaucracy and process are replaced by trust and accountability.

DevOps的核心思想是拆除独立组织，构建共享的工具集、词汇表和通信结构，以服务于一个专注于单一目标的文化:快速安全地交付价值。然后建立激励结构，以强化和奖励那些引导组织朝着目标前进的行为。官僚主义和流程被信任和责任所取代。

From Punctuated Equilibrium to Continuous Delivery 从间断均衡到持续交付

Rather than each iteration resulting in value delivered to the customer and valuable feedback pouring back into the development team, we continue a “punctuated equilibrium” style of delivery. Punctuated equilibrium actually short-circuits two of the key benefits of agile delivery:

ustomers will likely go several weeks without seeing new value in the software. They perceive that this new agile way of working is just “business as usual,” and do not develop the promised increased trust relationship with the development team.
Teams may go several weeks without real feedback.That feedback provides valuable course corrections that enable teams to “build the right thing.” By delaying this feedback, the likelihood that the wrong thing gets built only increases, along with the associated costly rework.

我们不是每次迭代都向客户交付价值，并将有价值的反馈反馈回开发团队，而是继续“间断均衡”交付风格。间断的均衡实际上会缩短敏捷交付的两个关键好处:

客户可能会在数周内看不到该软件的新价值。他们认为这种新的敏捷的工作方式只是“照常工作”，并没有与开发团队建立承诺的信任关系。
团队可能几周都没有真正的反馈。这种反馈提供了有价值的课程修正，使团队能够“构建正确的东西”。通过延迟这种反馈，错误的东西被构建的可能性只会增加，随之而来的是代价高昂的返工。

Gaining the benefits of cloud-native application architectures requires a shift to continuous delivery. Rather than punctuated equilibrium driven by a water scrumfall organization, we embrace the principles of value from end to end.

获得云原生应用程序架构的好处需要转向持续交付。我们不是由一个水瀑布组织驱动的间断均衡，而是从头到尾拥抱价值原则。

The idea of “Concept to Cash”considers all of the activities necessary to carry a business idea from its conception to the point where it generates profit, and constructs a value stream aligning people and process toward the optimal achievement of that goal.

“从概念到现金”的概念考虑了将业务概念从概念到产生利润点所必需的所有活动，并构建了一个价值流，将人员和流程调整到实现该目标的最佳状态。

We technically support this way of working with the engineering practices of continuous delivery, where every iteration (in fact, every source code commit!) is proven to be deployable in an automated fashion.We construct deployment pipelines which automate every test which would prevent a production deployment should that test fail.

我们在技术上支持这种与持续交付的工程实践一起工作的方式，在这种情况下，每个迭代(实际上，每个源代码提交!)都被证明可以以自动化的方式部署。我们构建了自动化每个测试的部署管道，这将防止在测试失败时进行生产部署。

Centralized Governance to Decentralized Autonomy 集中治理到分散自治

"瀑布文化"已经成为阻碍cloud-native发展的障碍。

Enterprises normally adopt centralized governance structures around application architecture and data management, with committees responsible for maintaining guidelines and standards, as well as approving individual designs and changes. Centralized governance is intended to help with a few issues:

It can prevent widespread inconsistencies in technology stacks,decreasing the overall maintenance burden for the organization.
It can prevent widespread inconsistencies in architectural choices, allowing for a common view of application development across the organization.
Cross-cutting concerns like regulatory compliance can be handled in a consistent way for the entire organization
Ownership of data can be determined by those who have a broad view of all organizational concerns

企业通常采用围绕应用架构和数据管理的集中治理结构，委员会负责维护指导方针和标准，以及批准单独的设计和更改。集中式治理旨在帮助解决以下几个问题:

它可以防止技术栈大范围出现不一致，减少组织的整体维护负担。
它可以防止架构选型出现大范围不一致，从而在整个组织中形成应用程序开发的公共观点。
对于整个组织，可以一致地处理跨部门关切。
数据所有权可由具有全局视野的人来决定

These structures are created with the belief that they will result in higher quality, lower costs, or both. However, these structures rarely result in the quality improvements or cost savings desired, and further prevent the speed of delivery sought from cloud-native application architectures.

之前说提到的那些措施，是因为我们相信它们将有助于提高质量、降低成本或两者兼而有之。然而，这些结构很少能带来所需的质量改进或成本节约，并且进一步阻碍了从云原生应用程序架构中寻求的交付速度。

Adoption of cloud-native application architectures is almost always coupled with a move to decentralized governance. The teams building cloud-native applications own all facets of the capability they’re charged with delivering.They own and govern the data, the technology stack, the application architecture, the design of individual components, and the API contract delivered to the remainder of the organization. If a decision needs to be made, it’s made and executed upon autonomously by the team.

采用云原生应用程序架构通常伴随着向分散治理的迁移。构建云原生应用程序的团队拥有他们负责交付的功能的所有方面。它们拥有并管理数据、技术堆栈、应用架构、每个组件的设计以及交付给组织的API接口。如果需要做出决策，则由团队自主制定并执行。

The decentralization and autonomy of individual teams is balanced by minimal, lightweight structures that are imposed on the integration patterns used between independently developed and deployed services (e.g., they prefer HTTP REST JSON APIs rather than many different styles of RPC).

独立开发和部署的服务之间使用的集成模式(例如，他们更喜欢HTTP REST JSON api，而不是许多不同风格的RPC)上使用轻量级交互模式平衡各个团队的分散和自治需要。

Organizational Change 组织变革

设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。

—Melvyn Conway

利用『康威定律』进行组织变革。

Our solution is to create a team combining staff with many disciplines around each long-term product,instead of segregating staff that have a single discipline in each own team, such as testing.

我们的解决方案是在长周期的产品开发中，创建一个包含了各方面专业员工的团队，而不是将他们分离在单一的团队中，例如测试人员。

Business Capability Teams 业务能力团队

Each of these tiers spans multiple identifiable business capabilities,making it very difficult to innovate and deploy features related to one business capability independently from the others.Companies seeking to move to cloud-native architectures like microservices segregated by business capability have often employed what Thoughtworks has called the Inverse Conway Maneuver.

Rather than building an architecture that matches their org chart, they determine the architecture they want and restructure their organization to match that architecture. If you do that, according to Conway, the architecture that you desire will eventually emerge.

每一层都跨越多个业务能力领域，因此很难独立于其他业务功能创新和部署新功能。寻求迁移到云本地架构(如按业务能力划分的微服务)的公司，常常采用Thoughtworks所称的逆康威策略。

他们没有建立一个与其组织结构图相匹配的架构，而是决定了他们想要的架构，并重组组织以匹配该架构。按照Conway的说法，如果你这样做，你想要的架构最终会出现。

So, as part of the shift to a DevOps culture, teams are organized as crosfunctional, business capability teams that develop products rather than projects. Products are long-lived efforts that continue until they no longer provide value to the business.

因此，作为转向DevOps文化的一部分，我们组织了跨职能、业务能力的团队，开发的是产品而不再是项目。产品是长期存在的工作，直到它们不再为业务提供价值为止。

All of the roles necessary to build, test, deliver, and operate the service delivering a business capability are present on a team, which doesn’t hand off code to other parts of the organization.

构建、测试、交付和操作交付业务功能的服务所需的所有角色都存在于团队中，团队不会将代码传递给组织的其他部分。

Business capability teams own the entire development-to-operations lifecycle for their applications.

业务能力团队掌握应用程序从开发到运营的整个生命周期。

The Platform Operations Team 平台运营团队

业务能力团队需要依赖于自助敏捷基础设施。

we can express a special business capability defined as “the ability to develop, deploy, and operate business capabilities.” This capability is owned by the platform operations team.

我们可以将一种特殊的业务能力定义为“开发、部署和运营的能力”。这个功能属于平台运营团队。

The platform operations team operates the self-service agile infrastructure platform leveraged by the business capability teams. This team typically includes the traditional system, network, and storage administrator roles. If the company is operating the cloud platform on premises, this team also either owns or collaborates closely with teams managing the data centers themselves, and understands the hardware capabilities necessary to provide an infrastructure platform.

平台运营团队操作业务能力团队利用的自助敏捷基础架构平台。这个团队通常包括传统的系统、网络和存储管理员角色。如果公司在本地运行云平台，那么这个团队还拥有或与管理数据中心本身的团队紧密合作，并且了解提供基础设施平台所需的硬件功能。

Just as the business capability teams collaborate with one another around defined API contracts, the platform operations team presents an API contract for the platform. Rather than queuing up requests for application environments and data services to be provisioned, business capability teams are able to take the leaner approach of building automated release pipelines that provision environments and services on-demand.

正如业务能力团队围绕已定义的API接口彼此协作一样，平台操作团队也为平台提供API接口。业务能力团队能够采用更精简的方法来构建自动发布管道，以按需提供环境和服务，而业务能力团队不需要排队等待应用程序环境和数据服务的服务。

Technical Change 技术变革

Decomposing Monoliths 拆分单体应用

Traditional n-tier, monolithic enterprise applications rarely operate well when deployed to cloud infrastructure, as they often make unsupportable assumptions about their deployment environment that cloud infrastructures simply cannot provide.

传统的n层单体企业架构应用程序在部署到云基础设施时很少能很好地运行，因为它们常常对部署环境做出云基础设施无法提供的不可支持的需求。

Most of these assumptions are coupled with the fact that monoliths are typically deployed to long-lived infrastructure.

单体架构应用通常部署在寿命较长的基础设施上并与之紧密结合。

But let’s assume that we could build a monolith that does not make any of these assumptions. We still have trouble:

Monoliths couple change cycles together such that independent business capabilities cannot be deployed as required, preventing speed of innovation.
Services embedded in monoliths cannot be scaled independently of other services, so load is far more difficult to account for efficiently.
Developers new to the organization must acclimate to a new team, often learn a new business domain, and become familiar with an extremely large codebase all at once. This only adds to the typical 3–6 month ramp up time before achieving real productivity.
Attempting to scale the development organization by adding more people further crowds the sandbox, adding expensive coordination and communication overhead.
Technical stacks are committed to for the long term. Introducing new technology is considered too risky, as it can adversely affect the entire monolith.

单体架构应用面临的问题:

整体架构将变更周期耦合在一起，这样独立的业务功能就无法按需部署，从而阻碍了创新的速度。
嵌入到单体应用中的服务不能独立于其他服务进行伸缩，因此要有效地计算负载要困难得多。
新加入组织的开发人员必须适应新的团队，经常要学习新的业务领域，并且一次熟悉一个非常大的代码库。这只会增加通常3-6个月的加速时间，然后才能实现真正的生产力。
试图通过增加更多的人员来扩展开发组织会进一步拥挤沙箱，增加昂贵的协调和通信开销。
技术栈是长期致力于此的。引进新技术被认为风险太大，因为它会对整个整体产生不利影响。

The decomposition of the organization into business capability teams also requires that we decompose applications into microservices. Only then can we harness the maximum benefit from our move to cloud infrastructure.

将组织分解为业务能力团队还需要将应用程序分解为微服务。只有这样，我们才能最大地享受到向云基础设施迁移的好处。

Decomposing Data 拆分数据

前面拆分了单体应用，但这还远远不够，数据模型也必须解耦。

For a domain model to be effective, it must also be internally consistent—we should not find terms or concepts with inconsistent definitions within the same model.

要使域模型有效，它还必须具有内部一致性——我们不应该在同一个模型中发现定义不一致的术语或概念。

It is incredibly difficult and costly (and arguably impossible) to create a federated domain model that does not suffer from such inconsistencies. Evans refers to internally consistent subsets of the overall domain model of the business as bounded contexts.

想要创建一个不受不一致性影响的领域模型是极其困难的(可以说是不可能的)。Evans将业务的整个域模型的内部一致子集称为有界上下文。

Bounded contexts allow you to keep inconsistent definitions of a single concept across the organization, as long as they are defined consistently within the contexts themselves.

有界上下文允许您在整个组织中保持单个概念的不一致定义，只要它们在上下文中定义一致即可。

So we begin by identifying the segments of the domain model that can be made internally consistent. We’re then able to align business capability teams with these contexts, and those teams build microservices providing those capabilities.

首先确定可以在内部保持一致的域模型的各个部分，将业务能力团队与领域驱动中上下文联系起来，这些团队构建提供这些功能的微服务。

This definition of microservice provides a useful rubric for defining what your twelve-factor apps ought to be. Twelve-factor is primarily a technical specification, whereas microservices are primarily a business specification. We define our bounded contexts, assign them a set of business capabilities, commission capability teams to own those business capabilities, and have them build twelve-factor applications. The fact that these applications are independently deployable provides business capability teams with a useful set of technical tools for operation.

微服务的这一定义为定义12个因素的应用程序提供了一个有用的准则。12因素主要是技术规范，而微服务主要是业务规范。我们定义我们的边界上下文，为它们分配一组业务功能，委托功能团队拥有这些业务功能，并让它们构建12个因素的应用程序。这些应用程序是可独立部署的，这一事实为业务能力团队提供了一组有用的操作技术工具。

We couple bounded contexts with the database per service pattern,where each microservice encapsulates, governs, and protects its own domain model and persistent store. In the database per service pattern, only one application service is allowed to gain access to a logical data store, which could exist as a single schema within a multitenant cluster or a dedicated physical database. Any external access to the concepts is made through a well-defined business contract implemented as an API (often REST but potentially any protocol).

我们将有界上下文与每个服务模式的数据库结合起来，其中每个微服务封装、管理和保护自己的域模型和持久存储。在每个服务模式的数据库中，只允许一个应用程序服务访问逻辑数据存储，逻辑数据存储可以作为多租户集群或专用物理数据库中的单个模式存在。对概念的任何外部访问都是通过定义良好的业务契约实现的(通常是REST，但可能是任何协议)。

This decomposition allows for the application of polyglot persistence, or choosing different data stores based on data shape and read/write access patterns. However, data must often be recomposed via event-driven techniques in order to ask cross-context questions. Techniques such as command query responsibility segregation (CQRS) and event sourcing, beyond the scope of this report, are often helpful when synchronizing similar concepts across contexts.

这种分解允许应用多语言持久性，或者根据数据形状和读写访问模式选择不同的数据存储。然而，为了提出跨上下文的问题，通常必须通过事件驱动技术重新组合数据。在跨上下文同步类似概念时，命令查询责任隔离(command query responsibility离析，CQRS)和事件来源等超出本报告范围的技术通常很有用。

Containerization 容器化

Containers leverage modern Linux kernel primitives such as control groups (cgroups) and namespaces to provide similar resource allocation and isolation features as those provided by virtual machines with much less overhead and much greater portability. Application developers will need to become comfortable packaging applications as container images to take full advantage of the features of modern cloud infrastructure.

容器利用现代Linux内核原语，如控制组(control groups, cgroups)和名称空间，提供与虚拟机提供的资源分配和隔离特性类似的资源分配和隔离特性，开销小得多，可移植性强得多。应用程序开发人员需要将应用程序轻松地打包为容器映像，以便充分利用现代云基础设施的特性。

From Orchestration to Choreography 从编制到编排

Not only must service delivery, data modeling, and governance be decentralized, but also service integration. Enterprise integration of services has traditionally been accomplished via the enterprise service bus (ESB). The ESB becomes the owner of all routing, transformation, policy, security, and other decisions governing the interaction between services. We call this orchestration, analogous to the conductor who determines the course of the music performed by an orchestra during its performance. ESBs and orchestration make for very simple and pleasing architecture diagrams, but their simplicity is deceiving. Often hiding within the ESB is a tangled web of complexity. Managing this complexity becomes a full-time occupation,

and working with it becomes a continual bottleneck for the application development team. Just as we saw with a federated data model,a federated integration solution like the ESB becomes a monolithic hazard to speed.

不仅服务交付、数据建模和治理必须分散，而且服务集成也必须拆解。传统上，服务的企业集成是通过企业服务总线(ESB)完成的。ESB成为控制服务之间交互的所有路由、转换、策略、安全性和其他决策的所有者。我们称之为管弦乐编排，类似于指挥家在管弦乐队的演奏中决定音乐的进程。ESB和业务流程可以生成非常简单体系结构图，但它们的简单性具有欺骗性。通常隐藏在ESB中的是一个错综复杂的web。管理这种复杂性成为一项全职工作，使用它成为应用程序开发团队的持续瓶颈。正如我们在领域数据模型中看到的那样，ESB这样的集成解决方案会对速度造成巨大的危害。

Cloud-native architectures, such as microservices, tend to prefer choreography, akin to dancers in a ballet. Rather than placing the smarts in the integration mechanism, they are placed in the endpoints, akin to the dumb pipes and smart filters of the Unix architecture. When circumstances on stage differ from the original plan,there’s no conductor present to tell the dancers what to do. Instead,they simply adapt. In the same way, services adapt to changing circumstances in their environment via patterns such as client-side load balancing and circuit breakers .

云原生架构，如微服务，更倾向于编排，类似于芭蕾舞中的舞者。它们不是将智能放在集成机制中，而是放在端点中，类似于Unix体系结构中的管道和过滤器。当舞台上的情况与最初的计划不同时，没有指挥在场告诉舞者该做什么。相反,他们只是适应。同样，服务通过客户端负载均衡和断路器等模式来适应环境中的变化。

Choreography simply acknowledges and exposes the essential complexity of the system. Once again this shift is in support of the autonomy required to enable the speed sought from cloud-native architectures. Teams are able to adapt to their changing circumstances without the difficult overhead of coordinating with other teams, and avoid the overhead of coordinating changes with a centrally-managed ESB.

编排只是承认并公开了系统的本质复杂性。这种转变再次支持实现从云原生架构中寻求的速度所需的自主性。团队能够适应其不断变化的环境，而无需与其他团队协调的困难开销，并避免使用集中管理的ESB协调更改的开销。