Translation of Neil Ford's article "Microservices as an Evolutionary Architecture"
We have prepared a translation of an article by Neil Ford, a systems architect and ideological inspirer at ThoughtWorks, which develops software for automating software testing and deployment processes.
Neil is a recognized expert in software development, working at the interface of flexible design and system architecture. He is the author of numerous articles, books, dozens of video presentations, and speaks at leading developer conferences. His work you can see on the site nealford.com .
Microservice architecture is rapidly conquering the world. In March, the publishing company O'Reilly organized its first conference on software architecture (O'Reilly Software Architecture Conference). And almost 60% of the reports were devoted to one or another aspect of using microservices. Why did this particular architectural style suddenly become so popular?
Microservice architecture is a new architecture design style that emerged after DevOps and incorporated the practice of continuous software delivery. In addition, it is an example of an evolutionary architecture that follows the principle of gradual continuous changes in several dimensions at the structural level of the application. This article discusses some of the characteristics and principles of this family of architectural styles.
')
Previously it was thought that the elements of the architecture were “very difficult to change after its creation”. Gradual change is the main principle of evolutionary architecture. It attracts everyone's attention precisely because changes in architecture have always been difficult to foresee and make very expensive. If the possibility of evolutionary changes is embedded in the architecture itself, then their implementation becomes much easier and cheaper, contributing to changes in software development and release practices, as well as increasing the level of overall process flexibility.
The microservice architecture is fully consistent with this idea due to the fact that it has limited contexts (Bounded Context) , logically distinguished in accordance with Domain Driven Design (Domain Driven Design) by Eric Evans, implemented as physically separate deployable components. This separation is achieved through the implementation of DevOps practices such as virtual machine provisioning, testing, and automated deployment. Since each service is separated from all other services (at the structural level), replacing one microservice with another is as easy as swapping Lego cubes.
Evolutionary architectures have a number of common features. All these features will be described in an upcoming book on evolutionary architecture. In this article we present only some of them.
The ability to separate components within well-defined boundaries gives developers the advantage if continuous changes are needed. If the architecture has not been designed and the system looks like a big clump of dirt ( Big Ball of Mud architecture ), then evolutionary changes are impossible, since there are no dedicated parts in such a structure.
[Communication between classes (points around the perimeter) in a large wad of dirt from an unnamed client project.]
Improper connectivity of components prevents the system from evolving because changes can unpredictably affect other parts of the system. All evolutionary architectures provide some level of modularity, usually at the level of technical architecture (for example, multi-tier architecture).
Influenced by the principles of domain-specific design in modern successful architectures, modularity at the domain level is increasingly used. A service-based architecture differs from a traditional service-oriented architecture (SOA) primarily in the service allocation strategy. Service-oriented architecture is strictly divided by technical levels, while service-based architectures are mainly built in parts of the domain defined by microservices.
Experimenting is one of the significant advantages that an evolutionary architecture gives to business. The ability to easily make small changes to applications ensures the use of such common continuous deployment practices as A / B testing, testing for a limited group of users (Canary release) and others. Microservice architectures are often built on the basis of the routing of calls to services, which makes it possible to use several versions of the service within an entire ecosystem. This in turn opens up opportunities for experimentation and changes to existing functionality. Ultimately, when developing business applications, less time is spent discussing plans and backlog, and the development is conducted mainly in the quick hypothesis testing mode.
A more complete picture of evolutionary architecture can be obtained by becoming acquainted with its basic principles. These principles concern the various characteristics of both the architecture itself and its design methods. Some of the principles relate to the choice of the moment of making architectural decisions in the system design process.
It is necessary to distinguish the emergent (formed as a result of the design process) and the evolutionary architecture - this is extremely important. Like evolutionary computing methods (such as genetic algorithms), the architectural fitness function sets a goal in architecture design. For some systems, the main requirement is a long uptime, for others - high performance or security.
[Radar diagram used to highlight important fitness functions corresponding to this software system.]
If you determine in advance the function of fitness for a particular system, it will help you in the future to make the right decisions in a timely manner. For different architectural solutions, it is possible to calculate fitness functions, and if its value becomes better, it means that the architecture is developing in the right direction.
Many of the methods of work used in the process of continuous software delivery and the development of an evolving architecture are based on the principle of “attention to pain points” formulated by the community of eXtreme Programming. When in the project work there are moments that can become sources of problems (pain points), it is necessary to pay attention to them as soon as possible. This will help identify potential problems in advance and fix them in working order. The usual continuous delivery practices such as the deployment pipeline, the automatic allocation of virtual machines, and the transfer of databases, in the case of designing an evolutionary architecture, greatly simplify the removal of pain points during the change phase.
The main difference between traditional and evolutionary architecture is when significant decisions are made. These solutions may concern the structure of the application, the technology stack, individual tools or communication patterns. In the case of designing a traditional architecture, such decisions are made at the initial stage, before writing the code. In the process of developing an evolutionary architecture, any decisions are made as late as possible, at the last moment, when it is still acceptable. The advantage of later decision making is that additional information may be available at this point. The cost of this method should include the cost of a possible refinement of the architecture after the decision is made. These costs can be reduced using suitable abstractions, but they can still occur. However, the costs of decision-making at the initial stage are also quite real. Take, for example, the decision to choose a messaging tool. Different tools support different functions. If we choose a more powerful tool than is necessary, we will get an ill-conceived architecture, which will inevitably require further work in the future. This “technical debt”, resulting from the selection of an inappropriate tool, will be an additional burden for developers.
Of course, the main problem with the last possible decision-making moment is to determine when it comes. To do this, focus on the function of fitness. First of all, you need to make decisions that can have a significant impact on the choice of elements of architecture or design, as well as decisions that significantly affect the overall success of the project. The negative impact of delaying such a decision often outweighs the possible benefits of a later decision.
Software architects should clarify decisions made about the design of systems under development, usually with the help of various kinds of diagrams. Architects often fall into the trap, presenting the software architecture as an equation to be solved. The many commercial tools offered by software architects make it possible to formally describe the architecture in the form of squares, lines, and arrows. Although such diagrams may be useful, they offer only a two-dimensional display, a snapshot of a perfect world, but we live in a four-dimensional reality.
To fill such a two-dimensional diagram with life, it is necessary to concretize it. The ORM label on a two-dimensional diagram becomes Hibernate v4.2.17 , making the present world three-dimensional. When you have a plan for its implementation in production and updates in six months to the inevitable version of Hibernate v4.3.0.1 , you will be ready for a four-dimensional world. Many architects do not understand that a static view of architecture has a short lifespan. The software universe exists in a state of flow, it is dynamic, not static. Architecture is not an equation, but rather a snapshot of a continuing process.
Practices of continuous software delivery and DevOps showed problems growing out of the lack of understanding of the efforts that are needed to implement and support the architecture. The implementation of architecture is only the first step. Architecture remains an abstraction until it is activated. In other words, the viability of any architecture in the long run can be judged only when you have not only implemented, but at least once modified it. And maybe they managed to cope with surprises along the way.
An understanding by the software architect of operational capabilities is extremely important for the development of an evolutionary architecture. The evolutionary development of architecture affects the features of its implementation, and therefore they must be taken into account in the process of refinement. The requirements of the continuous delivery process to the architecture are aimed at improving its visualization and simplifying the introduction of changes. In this way, continuous delivery provides an enhanced evolutionary architecture.
November 19 Neil Ford arrives in Moscow with a master class on the creation of an evolutionary software architecture .
Neil is a recognized expert in software development, working at the interface of flexible design and system architecture. He is the author of numerous articles, books, dozens of video presentations, and speaks at leading developer conferences. His work you can see on the site nealford.com .Microservices as an evolutionary architecture
Microservice architecture is rapidly conquering the world. In March, the publishing company O'Reilly organized its first conference on software architecture (O'Reilly Software Architecture Conference). And almost 60% of the reports were devoted to one or another aspect of using microservices. Why did this particular architectural style suddenly become so popular?
Microservice architecture is a new architecture design style that emerged after DevOps and incorporated the practice of continuous software delivery. In addition, it is an example of an evolutionary architecture that follows the principle of gradual continuous changes in several dimensions at the structural level of the application. This article discusses some of the characteristics and principles of this family of architectural styles.
')
Evolutionary architecture
Previously it was thought that the elements of the architecture were “very difficult to change after its creation”. Gradual change is the main principle of evolutionary architecture. It attracts everyone's attention precisely because changes in architecture have always been difficult to foresee and make very expensive. If the possibility of evolutionary changes is embedded in the architecture itself, then their implementation becomes much easier and cheaper, contributing to changes in software development and release practices, as well as increasing the level of overall process flexibility.
The microservice architecture is fully consistent with this idea due to the fact that it has limited contexts (Bounded Context) , logically distinguished in accordance with Domain Driven Design (Domain Driven Design) by Eric Evans, implemented as physically separate deployable components. This separation is achieved through the implementation of DevOps practices such as virtual machine provisioning, testing, and automated deployment. Since each service is separated from all other services (at the structural level), replacing one microservice with another is as easy as swapping Lego cubes.
Features of evolutionary architecture
Evolutionary architectures have a number of common features. All these features will be described in an upcoming book on evolutionary architecture. In this article we present only some of them.
Modularity and connectedness
The ability to separate components within well-defined boundaries gives developers the advantage if continuous changes are needed. If the architecture has not been designed and the system looks like a big clump of dirt ( Big Ball of Mud architecture ), then evolutionary changes are impossible, since there are no dedicated parts in such a structure.
[Communication between classes (points around the perimeter) in a large wad of dirt from an unnamed client project.]
Improper connectivity of components prevents the system from evolving because changes can unpredictably affect other parts of the system. All evolutionary architectures provide some level of modularity, usually at the level of technical architecture (for example, multi-tier architecture).
Organization around business opportunities
Influenced by the principles of domain-specific design in modern successful architectures, modularity at the domain level is increasingly used. A service-based architecture differs from a traditional service-oriented architecture (SOA) primarily in the service allocation strategy. Service-oriented architecture is strictly divided by technical levels, while service-based architectures are mainly built in parts of the domain defined by microservices.
Experiments
Experimenting is one of the significant advantages that an evolutionary architecture gives to business. The ability to easily make small changes to applications ensures the use of such common continuous deployment practices as A / B testing, testing for a limited group of users (Canary release) and others. Microservice architectures are often built on the basis of the routing of calls to services, which makes it possible to use several versions of the service within an entire ecosystem. This in turn opens up opportunities for experimentation and changes to existing functionality. Ultimately, when developing business applications, less time is spent discussing plans and backlog, and the development is conducted mainly in the quick hypothesis testing mode.
Principles of Evolutionary Architecture
A more complete picture of evolutionary architecture can be obtained by becoming acquainted with its basic principles. These principles concern the various characteristics of both the architecture itself and its design methods. Some of the principles relate to the choice of the moment of making architectural decisions in the system design process.
Fitness functions
It is necessary to distinguish the emergent (formed as a result of the design process) and the evolutionary architecture - this is extremely important. Like evolutionary computing methods (such as genetic algorithms), the architectural fitness function sets a goal in architecture design. For some systems, the main requirement is a long uptime, for others - high performance or security.
[Radar diagram used to highlight important fitness functions corresponding to this software system.]
If you determine in advance the function of fitness for a particular system, it will help you in the future to make the right decisions in a timely manner. For different architectural solutions, it is possible to calculate fitness functions, and if its value becomes better, it means that the architecture is developing in the right direction.
Attention to pain points
Many of the methods of work used in the process of continuous software delivery and the development of an evolving architecture are based on the principle of “attention to pain points” formulated by the community of eXtreme Programming. When in the project work there are moments that can become sources of problems (pain points), it is necessary to pay attention to them as soon as possible. This will help identify potential problems in advance and fix them in working order. The usual continuous delivery practices such as the deployment pipeline, the automatic allocation of virtual machines, and the transfer of databases, in the case of designing an evolutionary architecture, greatly simplify the removal of pain points during the change phase.
Moment of decision
The main difference between traditional and evolutionary architecture is when significant decisions are made. These solutions may concern the structure of the application, the technology stack, individual tools or communication patterns. In the case of designing a traditional architecture, such decisions are made at the initial stage, before writing the code. In the process of developing an evolutionary architecture, any decisions are made as late as possible, at the last moment, when it is still acceptable. The advantage of later decision making is that additional information may be available at this point. The cost of this method should include the cost of a possible refinement of the architecture after the decision is made. These costs can be reduced using suitable abstractions, but they can still occur. However, the costs of decision-making at the initial stage are also quite real. Take, for example, the decision to choose a messaging tool. Different tools support different functions. If we choose a more powerful tool than is necessary, we will get an ill-conceived architecture, which will inevitably require further work in the future. This “technical debt”, resulting from the selection of an inappropriate tool, will be an additional burden for developers.
Of course, the main problem with the last possible decision-making moment is to determine when it comes. To do this, focus on the function of fitness. First of all, you need to make decisions that can have a significant impact on the choice of elements of architecture or design, as well as decisions that significantly affect the overall success of the project. The negative impact of delaying such a decision often outweighs the possible benefits of a later decision.
Conclusion
Software architects should clarify decisions made about the design of systems under development, usually with the help of various kinds of diagrams. Architects often fall into the trap, presenting the software architecture as an equation to be solved. The many commercial tools offered by software architects make it possible to formally describe the architecture in the form of squares, lines, and arrows. Although such diagrams may be useful, they offer only a two-dimensional display, a snapshot of a perfect world, but we live in a four-dimensional reality.
To fill such a two-dimensional diagram with life, it is necessary to concretize it. The ORM label on a two-dimensional diagram becomes Hibernate v4.2.17 , making the present world three-dimensional. When you have a plan for its implementation in production and updates in six months to the inevitable version of Hibernate v4.3.0.1 , you will be ready for a four-dimensional world. Many architects do not understand that a static view of architecture has a short lifespan. The software universe exists in a state of flow, it is dynamic, not static. Architecture is not an equation, but rather a snapshot of a continuing process.
Practices of continuous software delivery and DevOps showed problems growing out of the lack of understanding of the efforts that are needed to implement and support the architecture. The implementation of architecture is only the first step. Architecture remains an abstraction until it is activated. In other words, the viability of any architecture in the long run can be judged only when you have not only implemented, but at least once modified it. And maybe they managed to cope with surprises along the way.
An understanding by the software architect of operational capabilities is extremely important for the development of an evolutionary architecture. The evolutionary development of architecture affects the features of its implementation, and therefore they must be taken into account in the process of refinement. The requirements of the continuous delivery process to the architecture are aimed at improving its visualization and simplifying the introduction of changes. In this way, continuous delivery provides an enhanced evolutionary architecture.
November 19 Neil Ford arrives in Moscow with a master class on the creation of an evolutionary software architecture .
Source: https://habr.com/ru/post/424445/
All Articles