Translation of a little rotten, welcomed the proposed amendments, if it is at the end of the text could not stand, please read the text.
Highlights:
- Hurry micro service may occur stability of the gap between architecture and counter mode.
- Learn the history of warnings and pitfalls paradigm shift, we will be able to learn from previous mistakes and make our organization can flourish in the latest wave of technology.
- It is important to understand the different architectural styles (such as monolithic applications, services, and no micro server function) the pros and cons.
- Architecture Evolution repetition cycle: the initial stage do not understand the new paradigm of best practice, which accelerates the technical burden. As the industry developed new models to address the gap, the team adopted new standards and models.
- Architectural patterns conducive to rapid technological development and protect business applications from fluctuations.
In recent years, micro-service, and cloud computing technologies such as containerization trend has been rapidly upgrading that technology has become the most senior IT engineers, architects, and part of the daily responsibilities of a leader. We live in a world of cloud support. However, that does not mean to become cloud-enabled features native cloud. In fact, if you do not have a cloud or native, it is very dangerous.
In our study these trends and discuss whether before take full advantage of cloud-based architecture and organizational change, it is important to understand the architecture of the past, present and future. Understand the drawbacks and pitfalls of historical paradigm shift, we will be able to learn from previous mistakes and make our organization can flourish in the latest wave of technology.
Antipattern
When we briefly describe the evolution of this process, we will explore the concept of anti-pattern, anti-pattern is a common way to deal with recurring problems of these coping styles are usually ineffective and potentially counterproductive. Anti-pattern mentioned in this series of articles will be described.
Architecture evolution
In the past about 50 years time, software architecture and application hosting model has undergone a major shift from the mainframe to the micro-service and no servers.
Centralized
In the 1970s and 1980s, the mainframe is the way computing. Mainframe-based centralized data storage and computational model, data input and data terminal are displayed on the original screen. The initial large-scale computer punch cards, and most calculations are carried out in a batch process. No online processing, and the delay is 100%, because there is no real-time processing. With the introduction of online processing and user interface of the terminal, mainframe paradigm has changed. However, the overall paradigm of large-scale central processing unit is included in the four walls of a single organization is still using the method "one size fits all", and can only provide part of the required majority of business application functionality.
Centralized -> decentralized
The client / server architecture, most of the logic on the server side, and some processing on the client. Client / server computing is distributed in the first attempt to replace the mainframe business applications as the main hosting model. In the early years of the architecture, the development community is still using the same mainframe development process, a single-layer principle to write software for client / server, resulting in anti-patterns, such as spaghetti code and Blob and the like. This organic growth software also produces other anti-patterns, such as a large mud. The industry must find ways to prevent these bad practices of the team to follow, it is necessary to study the contents of well-written client / server code required.
Several anti-planning model and best practice design and coding mode this research work. It introduces an example of a significant improvement called object-oriented programming (OOP), which has improved inheritance, polymorphism and encapsulation functions, and distributed data processing (as opposed to having a real version of the mainframe), and provides guidelines on how to develop the industry, can respond to new challenges.
Client / server model based on three-tier architecture, comprising a display (the UI), business logic and data layer. But most applications are written using a two-tier model, fat client will show all of the business logic and data access package together, direct access to the database. Although the industry has begun to show and discuss the need to access data and services separately, but this practice really become critical until the advent of Internet-based applications.
Typically, this model is an improvement on the mainframe restrictions, but the industry quickly met its limitations, such as the need to install a client application on each user's computer, and can not be extended as a fine-grained business functions .
To the center -> association / sharing (www)
In the mid-1990s, the Internet revolution took place, and the emergence of a new paradigm. Web browser becomes the client software, and Web and application servers hosting all the processing and logic. World Wide Web (www) paradigm to promote true three-tier architecture, which on the Web server hosting the show (UI) code hosting business logic (API) on the application server, and the data stored in the database server.
Development community began to migrate from fat (Desktop) client to a thin (Web) clients, mainly from the idea, such as service-oriented architecture (SOA) and the like promoted, strengthened the idea of three-tier architecture needs, and by the rapid development of technology to improve the client as well as to promote a web browser. The move to speed up the time to market, and no need to install client software. But software developers are still designed to be tightly coupled design, leading to confusion and other anti-patterns. As a workaround, the industry put forward a three-tier architecture and practices, such as domain-driven design (DDD), Enterprise Integration Patterns (EIP), SOA loosely coupled and technology.
VM hosting -> cloud hosting
10 years of the 21st century witnessed significant changes hosted cloud computing as a service available when hosting forms of when. Some applications need the ability, such as: distributed computing, networking, storage and computing, compared to traditional infrastructure, cloud-hosted mode provided a reasonable cost will be easier. In addition you can adjust the size according to the needs of flexible resources. They only pay for the storage and computing resources they use. Elastic capability introduced in Iaas and Paas can make a single instance of on-demand expansion, and flexibility in order to eliminate the duplicate instances. But repeated instances of these capabilities can not compensate for other purposes to do, such as holding more than one version, or as a byproduct of a single deployment. Cloud-based Managed way attractive place is the development and operation and maintenance engineers no longer need to focus on infrastructure. It offers three different hosting options:
- Infrastructure as a Service (IaaS): Developers select the server specifications to host their applications, and the cloud provides hardware, operating systems and networks. This is the most flexible of the three forms of one, but it does give you must specify the server development team has brought some of the burden.
- Platform as a Service (PaaS): Developers only need to worry about their application and configuration. Cloud provider is responsible for all server infrastructure, network and monitoring tasks.
- Software as a Service (SaaS): cloud hosting providers offer practical applications on the cloud, so the client organization can use the entire application, even for application code does not bear any responsibility. This option provides software and services out of the box, but if the customer requires providers to provide functionality beyond any custom business functions, this option is not flexible.
PaaS cloud options become the best choice, because it allows developers to host your custom business applications, without having to worry about provisioning or maintenance of infrastructure. Although cloud hosting encourage modular application design and deployment, but many organizations find that it has not been designed to induce the resilient distributed architecture legacy application migration and direct migration to the cloud, resulting in a technique known as " integral "modern anti-patterns hell." to meet these challenges, the industry put forward a new architecture models, such as micro-elements of service and 12 applications. migrate to the cloud industry to bring back the management of third-party libraries and technical applications program dependencies challenge developers to start too many choices is struggling, do not have enough criteria to select third-party tools, we are beginning to see some of the dependency hell.
Dependency hell can occur at different levels:
- Library: library dependencies (Java world JAR and .NET DLL world) mismanagement can cause problems. For example, a typical Spring Boot application 140 comprises a plurality of library JAR files. Ensure that no unnecessary packaging in the application library.
- Categories: clarify the application of all internal object dependencies. For example, the Controller class depends on Business Service class and Repository Service class in turn depends on the class. Spend some time dependencies within the application code checks during inspections and ensure that no incorrect dependencies.
- Service: If you use a micro service in the system, make sure that there is no direct dependencies between different services.
Dependency-based library is a packaging challenge, the latter two are design challenges. Subsequent articles in this series looked at in more detail these dependency hell scenes, and provides design patterns to avoid unintended consequences.
Micro services: fine-grained reusability
Software design practices such as DDD and EIP and the like have been around since 2003, can be used, then some team will serve as a modular application development, but the traditional infrastructure (such as Java applications and heavyweight J2EE application server. IIS NET application) does not help modular deployment. . With the advent of cloud-hosted, especially the emergence of PaaS Cloud Foundry and Heroku products such as a developer community has a truly modular deployment and scalability required for all business applications. This led to the development of micro-services. Micro service provides fine-grained, reusable possibility of functional and non-functional services.
Micro Services from 2013 to 2014 becoming increasingly popular. Powerful micro-services, you can make a smaller team with a full cycle development of specific business and technical functions. Developers can deploy or upgrade code at any time, without other parts of the system will (client applications or other services) adversely affected. Also on a single service level scaled on demand service.
The use of micro-services developers to write from scratch solutions or solutions packaged as an application library, you can directly call the appropriate solution. Micro-service approach encourages service contract-driven development between service providers and users. This can shorten development time and reduce dependence between the teams. In other words, micro-services make the link between the team more loose, and accelerate the development of solutions for this organization, especially in terms of business start-ups is essential. Micro service also helps to establish clear boundaries (eg, customers, orders, inventory) between business processes and domains. Indie vertical module which may be referred to as "context-bounded" in the organization. This evolution also speed up other good practices (such as DevOps) evolution, and provide the agility and faster time to market at the organization level. Each team will have one or more micro-services in their domain, and is responsible for the design, coding, deployment to the entire process of production and post-production support and maintenance.
However, similar to the previous architecture model, micro-service method encounters his own question: bottom-up legacy applications not designed for the micro-services began to be eroded, trying to force them into the micro-services architecture, which led to the anti-called monolithic model of hell. Other attempts to try to artificially monolithic application into multiple micro-services, even if they ultimately micro-service functionally not isolated, is still heavily dependent on other services from the decomposition of the same micro-chip application out. This is called micro anti-stone pattern. It is noteworthy that, as a whole, and micro-services are two different modes, which is not always possible to replace the former. If we are not careful, it may eventually create tightly coupled, mixed micro-services. The right choice depends on the application functionality and scalability requirements of the business.
Another explosion of micro-services do not want to side effects of the so-called "Death Star" anti-pattern. In service interactions, and service to the security (authentication and authorization) aspects of the service, if there is no governance model, the proliferation of micro-services usually leads are free to call any service to any other services. Different monitoring client application is using the service but how many of these uncoordinated service calls has become a challenge. The following figure shows an organization like Netflix and Twitter how to get into this nightmare, and had to come up with a new model to deal with the "Star of Death death".
Although the example shown in the figure above looks like an extreme case occurs only in the giant body, but do not underestimate the destructive power of cloud anti index mode. The industry must learn how to do more than ever the world is much larger weapon. Franklin Roosevelt said: "The strong power involves great responsibility." Services such as grids, sidecar, service orchestration and new architectural pattern of the container and the like can effectively defend misconduct cloud-based world. Organizations should understand these patterns, and to promote adoption as soon as possible.
Quickly understand cloud design priority mode
Services Network (Service mesh)
With the advent of cloud platforms, especially like Kubernetes container orchestration technology, service grid has attracted much attention. Is the bridge between the service grid service applications, to add other functions such as flow control, service discovery, load balancing, resilient, observability, safety and the like. It allows applications to offload these functions from the application level library, and allows developers to focus on business logic. Such as Istio certain services like grid technology also supports features such as Chaos injection and the like, so that developers can test the resilience and robustness of their applications and their potential micro dozens of interdependent services. Service Grid is very suitable place on the platform as a service (PaaS) and the container as a Service (CaaS), and enhances the experience by using the general-purpose cloud platform services. Future articles will delve into service-based architecture of the grid, and discuss specific use cases, and compare whether the service grid solutions.
No server architecture (Serverless architecture)
在过去的几年中，另一个备受关注的趋势是无服务器架构，也称为无服务器计算。 Serverless比PaaS模型更进一步，因为它完全从应用程序开发人员中抽象了服务器基础结构。在无服务器中，我们将业务服务编写为功能并将这些功能部署到云基础架构中。无服务器技术的一些示例是Amazon Lambda，Spring Cloud Function，Google Cloud Functions和Microsoft Azure Functions。无服务器模型位于云托管范围内的PaaS和SaaS之间，如下图所示。
与关于单服务与微服务的讨论类似的结论中，并非所有解决方案都应实现为功能。此外，我们不应使用无服务器功能替换所有微服务，就像我们不应替换所有单片应用程序或将其分解为微服务一样。仅将诸如用户身份验证或客户通知之类的细粒度的业务和技术功能设计为无服务器功能。根据我们的应用程序功能和非功能性要求（例如性能和可伸缩性以及事务边界），我们应该为每个特定用例选择适当的整体式，微服务或无服务器模型。通常，我们可能需要在解决方案体系结构中使用所有这三种模式。如果设计不当，无服务器解决方案最终将变成纳米片，其中每个功能都与其他功能或微服务紧密结合，并且无法独立运行。
容器技术（Container technologies）
类似于容器技术的互补趋势与微服务同时出现，以帮助在微服务器环境中部署服务和应用程序，从而实现业务服务的真正隔离和单个服务的可扩展性。Docker，contained，rkt和Kubernetes等容器技术可以很好地补充微服务的开发。如今，我们不能不提及其中之一-微服务或容器。
整体、微服务与无服务器对比
如前所述，了解三种体系结构样式的优缺点非常重要：整体式应用程序，微服务和无服务器功能。关于整体服务与微服务的书面案例研究详细描述了避免微服务的一个决定。
| 架构风格 | 什么时候使用 | 什么时候不实用 | 例子 |
|---|---|---|---|
| 整体 | 应用程序具有不同的模块，这些模块在事务上下文中完全相互依赖。需要所有数据操作的即时一致性。 | 应用程序模块可以分为原子业务或技术功能。 | ERP或CRM系统 |
| 微服务 | 应用程序模块在其运行时生命周期和事务管理中彼此独立。可以以无状态方式执行每个模块中的数据操作。如果模块之间存在任何依赖关系，它们仍然可以与最终的一致性支持松散地结合在一起。注意：有时，团队会人为地将相关功能分解为微服务，并遇到微服务模型的局限性。 | 如果不严格依赖其他模块，则无法独立部署和使用应用程序模块。 | 客户服务、订购服务、库存服务 |
| 无服务器 | 具有完全独立性和单独可伸缩性策略的应用程序模块可以分解为业务或技术的单个功能。没有流量时，应用程序将完全关闭。开发团队不必关心基础架构。 | 长时间运行的作业，CRUD服务或有状态服务。 | 认证方式、通知、事件流 |
稳定差距
对于我们而言，务必注意随着时间的流逝，我们的软件架构和代码中可能会出现的反模式。反模式不仅造成技术债务，而且更重要的是，它们可能将主题专家赶出组织。一个组织只能与那些不关心架构偏差或反模式的人一起找到自己。回顾以上简短的历史后，让我们集中讨论在匆忙使用微服务时可能会出现的稳定漏洞和反模式。诸如组织中的团队结构，业务领域以及团队中的技能等特定因素决定了哪些应用程序应实现为微服务，哪些应保留为整体解决方案。但是我们可以考虑选择将解决方案设计为微服务的一些一般注意事项。
Eric Evans的著作《域驱动设计（DDD）》改变了我们开发软件的方式。埃里克（Eric）提倡从域的角度而不是基于技术的角度看业务需求的想法。该书认为微服务是聚合模式的派生。但是，许多软件开发团队通过尝试将其所有现有应用程序转换为微服务，将微服务设计概念推向了极致。这导致了反模式，例如整体式地狱，微晶石等。以下是架构和开发团队需要注意的一些反模式：
- 整体地狱：monolithic hell
- 微石：microliths
- 积木塔：Jenga tower
- 科学怪人：logo slide (also known as Frankenstein)
- 方轮：square wheel
- 死亡之星：Death Star
不断发展的架构模式
为了弥补在不同的应用程序托管模型中发现的稳定差距和反模式，业界提出了不断发展的体系结构模式和最佳实践来弥补差距。下表总结了这些体系结构模型，稳定差距和模式
| 托管模式 | 描述 | 稳定差距/反模式 | 模式 |
|---|---|---|---|
| 集中式 | 中央数据存储和计算模型。客户终端仅用于数据输入和数据显示。 | ||
| 去中心化 | 客户端/服务器体系结构，其中大多数应用程序逻辑在服务器端处理。基本验证和某些处理在客户端上进行。 | 意大利面条代码，混乱 | OOP |
| 连接/共享 | Web应用程序通过在Web服务器上承载的表示逻辑（UI），在应用程序服务器上承载的业务逻辑（API）和数据库服务器中的数据来促进三层体系结构。 | 混乱 | DDD、SOA、企业集成模式 |
| 云托管 | 云计算模型改变了托管和扩展应用程序的方式。除了旧的“购买还是构建”选项之外，还为我们提供了“在云上托管”的第三个选项。 | 整体地狱，依赖地狱 | 微服务 |
| 微服务 | 细粒度的服务模型，将特定的业务功能封装到轻量级应用程序（微服务）中，并在业务域之间建立清晰的边界。 | 整体地狱，微石，死亡之星 | 服务网格，边车，服务编排 |
下图展示了所有这些体系结构模型，反模式形式的稳定性差距以及不断发展的设计模式和最佳实践。
历史告诉我们什么
下图列出了体系结构演进的步骤，包括不了解新范例中的最佳实践的初始阶段，这会加速技术负担。随着行业开发新的设计模式来解决稳定性方面的差距，团队在其体系结构中采用了新的标准和模式。
IT领导者必须在不断发展和优化的技术基础上提供稳定的业务应用程序的同时，保护其投资免受不断增长的技术快速变革的影响。全球IT主管已经越来越频繁地处理此问题。他们和我们应该拥抱技术的发展，但不应以支持业务的应用程序持续不稳定的代价为代价。纪律严明的系统架构应该能够做到这一点。将本系列文章中讨论的模式视为有利于技术快速发展并保护业务应用程序免受波动影响的策略。让我们在下一篇文章中探讨如何做到这一点。
总结
From the mainframe to the latest cloud-native architecture, hosting a variety of models will affect our development, deployment and maintenance of the way business applications. Every time when the industry found a new hosting model, the team in getting the full benefit of Architecture will face challenges. This has led to unintended consequences, such as architecture bias and anti-patterns, leading to enormous technical burden. As time goes by, new design patterns evolving to address new stable gap hosted model brings. Technical debt management plays a vital role in the health of the entire system as well as the team. IT leaders are not timely processing of technical debt is likely to result in software-related damage and tissue damage. Technical debt can be self-sufficient and generate more debt, which leads to bad practices of institutionalization and exclusion top talent.
If these signs occur, stop immediately and evaluated. Then take firm action. Make sure that you authorize teams to address all forms of technical debt. Subsequent articles in this series will examine the common service platform for my organization during the use of micro-service architecture development. We will also discuss how the company is using different native cloud infrastructure components, such as container, PaaS and service grid. The next article will delve into the team should pay attention to anti-pattern design and cloud native mode should be used in the schema. We will discuss the details of the use of native enterprise cloud service grid policy, the policy will help many of these features. Finally, we will share some suggestions for architecture and organization.
Original Address: https: //www.infoq.com/articles/cloud-native-architecture-adoption-part1/#idp_register/
