《Migrating to Cloud-Native Application Architectures》学习笔记之Chapter 1. The Rise of Cloud-Native

2019/02/20 08:42
阅读数 144


  • Speed of innovation (快速的创新)
  • Always-available services (服务高可用)
  • Web scale (web高可扩展)
  • Mobile-centric user experiences (以移动为中心的体验)


Moving to the cloud is a natural evolution of focusing on software,and cloud-native application architectures are at the center of how

these companies obtained their disruptive character. By cloud, we mean any computing environment in which computing, networking, and storage resources can be provisioned and released elastically in an on-demand, self-service manner.



Why Cloud-Native Application Architectures?


Speed 高速




The elasticity and self-service nature of cloud-based infrastructurenaturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed.



The ability to innovate, experiment, and deliver value more quickly than our competitors.



Safety 安全

Cloud-nativeapplication architectures balance the need to move rapidly with theneeds of stability, availability, and durability. It’s possible and essen‐tial to have both.




Cloud native 安全特点:

1.可视性 Visibility:

Feature-rich metrics, monitoring, alerting, and datavisualization frameworks and tools are at the heart of all cloudnative application architectures.


2. Fault isolation故障隔离:

By composing systems from microservices, we can limit the scope of a failure in any one microservice to just thatmicroservice, but only if combined with fault tolerance.



3. Fault tolerance 容错:

It’s not enough to decompose a system into independentlydeployable components; we must also prevent a failure in one ofthose components from causing a cascading failure across itspossibly many transitive dependencies.




4. Automated recovery自动恢复:

healthy orunhealthy, up or down. Many times we’ll take the same courseof action every time we encounter failures like these. In the caseof the failed health check, we’ll often simply restart or redeploythe service in question. Cloud-native application architecturesdon’t wait for manual intervention in these situations.



The ability to move rapidly but also maintain stability, availability, and durability



Scale 扩展性


Innovative companies dealt with this problem through two pioneering moves:

• Rather than continuing to buy larger servers, they horizontally scaled application instances across large numbers of cheaper commodity machines. These machines were easier to acquire(or assemble) and deploy quickly.

• Poor utilization of existing large servers was improved by virtualizing several smaller servers in the same footprint and deploying multiple isolated workloads to them.





The virtualization effort was delegated to the cloud provider, and the consumer focused on horizontal scale of its applications across large numbers of cloud server instances. Recently another shift has happened with the move from virtual servers to containers as the unit of application deployment.



Unfortunately all of these benefits come with a cost. Applications must be architected differently for horizontal rather than vertical scale. The elasticity of the cloud demands ephemerality.





Another hallmark of cloud-native application architectures is the externalization of state to in-memory data grids, caches, and persistent object stores, while keeping the application instance itself essentially stateless. Stateless applications can be quickly created and destroyed, as well as attached to and detached from external state managers, enhancing our ability to respond to changes in demand.



The ability to elastically respond to changes in demand.



Mobile Applications and Client Diversity 移动应用程序和客户端多样性



At any time customers may want to interact with our systems from devices produced by multiple different vendors, running multiple different operating platforms, running multiple versions of the same operating platform, and from devices of different form factors (e.g., phones vs. tablets).Not only does this place various constraints on the mobile application developers, but also on the developers of backend services.




Mobile applications often have to interact with multiple legacy systems as well as multiple microservices in a cloud-native application architecture.

These services cannot be designed to support the unique needs of each of the diverse mobile platforms used by our customers.

Forcing the burden of integration of these diverse services on the mobile developer increases latency and network trips,leading to slow response times and high battery usage, ultimately leading to users deleting your app.

Cloud-native application architectures also support the notion of mobile-first development through design patterns such as the API Gateway, which transfers the burdenof service aggregation back to the server-side.






The ability for our customers to interact with us seamlessly from any location, on any device, and at any time.



Defining Cloud-Native Architectures 设计云原生架构

Cloud-Native Architectures特征

Twelve-Factor Applications 十二因子

Twelve-Factor Applications describe an application archetype that optimizes for the “why” of cloud-native application architectures. They focus on speed, safety, and scale by emphasizing declarative configuration,stateless/shared-nothing processes that horizontally scale, and an overall loose coupling to the deployment environment.



In the context of twelve-factor, application (or app) refers to a single

deployable unit. Organizations will often refer to multiple collaborating deployables as an application. In this context, however, we will refer to these multiple collaborating deployables as a distributed system.









Each deployable app is tracked as one codebase tracked in revision control. It may have many deployed instances across multiple environments.




An app explicitly declares and isolates dependencies via appropriate tooling (e.g., Maven, Bundler, NPM) rather than depending on implicitly realized dependencies in its deployment environment.




Configuration, or anything that is likely to differ between deployment environments (e.g., development, staging, production) is injected via operating system-level environment variables.



后台服务(Backing services)

Backing services, such as databases or message brokers, are treated as attached resources and consumed identically across all environments.




The stages of building a deployable app artifact, combining that artifact with configuration, and starting one or more processes from that artifact/configuration combination, are strictly separated.




The app executes as one or more stateless processes (e.g., master/workers) that share nothing. Any necessary state is externalized to backing services (cache, object store, etc.).



端口绑定(Port binding)

The app is self-contained and exports any/all services via port binding (including HTTP).




Concurrency is usually accomplished by scaling out app processes horizontally (though processes may also multiplex work via internally managed threads if desired).




Robustness is maximized via processes that start up quickly and shut down gracefully. These aspects allow for rapid elastic scaling, deployment of changes, and recovery from crashes.



环境一致性(Dev/prod parity)

Continuous delivery and deployment are enabled by keeping development, staging, and production environments as similar as possible.




Rather than managing logfiles, treat logs as event streams,allowing the execution environment to collect, aggregate, index,and analyze the events via centralized services.



管理流程(Admin processes)

Administrative or managements tasks, such as database migrations, are executed as one-off processes in environments identical to the app’s long-running processes.




  • 符合十二因子的特性非常适合快速部署应用程序,因为应用程序很少甚至不需要关注部署它们环境的差异。
  • 符合十二因子的特性很好地支持了“短暂性”的概念,即我们可以以极低的成本“抛弃”的应用程序。
  • 可处置性让底层平台能够非常快速地将应用程序从故障中自动恢复
  • 日志作为事件流处理,极大地支持在运行时查看应用程序的底层行为
  • 环境之间强制的一致性、配置机制的一致性和支持服务管理使云平台能够对应用程序运行时结构的所有方面提供丰富的可见性和安全性。


The application environment itself is 100% disposable, as any application state, be it in-memory or persistent, is extracted to some backing service.

This allows the application to be scaled up and down in a very simple and elastic manner that is easily automated.




In most cases, the underlying platform simply copies the existing environment the desired number of times and starts the processes.



Scaling down is accomplished by halting the running processes and deleting the environments, with no effort expended backing up or otherwise preserving the state of those environments. In this way, the twelve-factor application patterns enable us to optimize for scale.



A set of patterns that optimize application design for speed, safety, and scale.



Microservices 微服务

Microservices represent the decomposition of monolithic business systems into independently deployable services that do “one thing well.” That one thing usually represents a business capability, or the smallest, “atomic” unit of service that delivers business value.




  • As we decouple the business domain into independently deployable bounded contexts of capabilities, we also decouple the associated change cycles. As long as the changes are restricted to a single bounded context, and the service continues to fulfill its existing contracts, those changes can be made and deployed independent of any coordination with the rest of the business. The result is enablement of more frequent and rapid deployments, allowing for a continuous flow of value.


  • Development can be accelerated by scaling the development organization itself. It’s very difficult to build software faster by adding more people due to the overhead of communication and coordination. Fred Brooks taught us years ago that adding more people to a late software project makes it later. However, rather than placing all of the developers in a single sandbox, we can create parallel work streams by building more sandboxes through bounded contexts.

可以通过扩展开发组织本身来加速开发。由于通信和协调的开销,通过增加人员来更快地构建软件是非常困难的。Fred Brooks多年前就告诉我们,向一个延迟的软件项目中添加更多的人员会使其延迟。然而,与其将所有开发人员都放在一个团队中,我们还不如通过有界上下文构建更多的团队来创建并行开发。

  • The new developers that we add to each sandbox can ramp up and become productive more rapidly due to the reduced cognitive load of learning the business domain and the existing code,and building relationships within a smaller team.


  • Adoption of new technology can be accelerated.更快的使用新技术。
  • Microservices offer independent, efficient scaling of services.

Monolithic architectures can scale, but require us to scale all components, not simply those that are under heavy load. Microservices can be scaled if and only if their associated load requires it.




An architecture pattern that helps us align our units of deployment with business capabilities, allowing each capability to move independently and autonomously, and in turn faster and safer.



Self-Service Agile Infrastructure 自助服务敏捷的基础设施

Successful adopters of cloud-native applications have empowered teams with self-service platforms.



The best of these platforms raise the primary abstraction layer for their consumers. With infrastructure as a service (IAAS) we asked the API to create virtual server instances, networks, and storage, and then applied various forms of configuration management and automation to enable our applications and supporting services to run.Platforms are now emerging that allow us to think in terms of applications and backing services.



Application code is simply “pushed” in the form of pre-built artifacts (perhaps those produced as part of a continuous delivery pipeline) or raw source code to a Git remote. The platform then builds the application artifact, constructs an application environment, deploys the application, and starts the necessary processes. Teams do not have to think about where their code is running or how it got there, as the platform takes care of these types of concerns transparently.



The same model is supported for backing services.



Simply ask the platform to provision one that fits your needs. Platforms now support a wide range of SQL/NoSQL data stores, message queues, search engines, caches, and other important backing services. These service instances can then be “bound” to your application, with necessary credentials automatically injected into your application’s environment for it to consume. A great deal of messy and error-prone bespoke automation is thereby eliminated.




  • Automated and on-demand scaling of application instances 应用程序实例的自动化和按需扩展
  • Application health management 应用健康管理
  • Dynamic routing and load balancing of requests to and across application instances 请求的动态路由和跨应用程序实例的负载平衡
  • Aggregation of logs and metrics 日志和监控指标的聚合


Cloud platforms that enable development teams to operate at an application and service abstraction level, providing infrastructure-level speed, safety, and scale.



API-Based Collaboration 基于api的协作

The sole mode of interaction between services in a cloud-native application architecture is via published and versioned APIs.



Teams are able to deploy new functionality whenever there is a need,without synchronizing with other teams, provided that they do not break any existing API contracts. The primary interaction model for the self-service infrastructure platform is also an API, just as it is with the business services. Rather than submitting tickets to provision, scale, and maintain application infrastructure, those same requests are submitted to an API that automatically services the requests.



Contract compliance can be verified on both sides of a service-toservice interaction via consumer-driven contracts. Service consumers are not allowed to gain access to private implementation details of their dependencies or directly access their dependencies’ data stores. In fact, only one service is ever allowed to gain direct access to any data store. This forced decoupling directly supports the cloud-native goal of speed.



An architecture pattern that defines service-to-service interaction as automatically verifiable contracts, enabling speed and safety through simplified integration work.


Antifragility 抗脆弱性

By explicitly seeking out weaknesses in the application architecture, injecting failures, and forcing their remediation, the architecture naturally converges on a greater degree of safety over time.




0 收藏
0 评论
0 收藏