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.
From Silos to DevOps 从独立组织到DevOps
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.
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.
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 集中治理到分散自治
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.
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 组织变革
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.
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.
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.
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.
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.
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.
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.
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).
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)和事件来源等超出本报告范围的技术通常很有用。
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.
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 .
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.
Culturally the overall theme is one of decentralization and autonomy:
- Decentralization of skill sets into cross-functional teams.
- Continuous delivery
- Decentralization of the release schedule and process.
- Decentralization of decision making.
We codify this decentralization into two primary team structures:
- Business capability teams
Cross-functional teams that make their own decisions about design, process, and release schedule
- Platform operations teams
Teams that provide the cross-functional teams with the platform they need to operate.
And technically, we also decentralize control:
- Monoliths to microservices
Control of individual business capabilities is distributed to individual autonomous services.
- Bounded contexts
Control of internally consistent subsets of the business domain model is distributed to microservices.
Control of application packaging is distributed to business capability teams.
Control of service integration is distributed to the service endpoints.