Neil Ford's translation of Microservices as an Evolutionary Architecture

Original author: Neal Ford
  • Transfer
We have prepared a translation of an article by Neil Ford, a systems architect and ideological mastermind at ThoughtWorks, a software development company that automates software testing and deployment processes.

Neil is a recognized software development expert who works at the crossroads of agile design and systems architecture. He is the author of numerous articles, books, dozens of video presentations, speaks at leading developer conferences. You can see his work on nealford.com .

Microservices as evolutionary architecture


Microservice architecture is rapidly conquering the world. In March, O'Reilly publishing company organized its first O'Reilly Software Architecture Conference. And almost 60% of the reports were devoted to certain aspects of the use of microservices. Why did this particular architectural style suddenly become so popular?

Microservice architecture is a new architectural design style that emerged after DevOps and incorporates continuous software delivery practices. It is also an example of an evolutionary architecture that follows the principle of gradual, continuous changes in several dimensions at the structural level of an application. This article discusses some of the salient features and principles of this family of architectural styles.

Evolutionary architecture


It was previously believed that the elements of architecture "are very difficult to change after its creation." Gradual change is the main principle of evolutionary architecture. It attracts general attention precisely because changes in architecture have always been difficult to foresee and very costly to make. If the possibility of evolutionary changes is built into the architecture itself, then their implementation becomes much simpler and cheaper, contributing to changes in software development and release practices, as well as increasing the level of overall process flexibility.

Microservice architecture is fully consistent with this idea due to the fact that it has limited contexts (Bounded Context), logically allocated according to Eric Evans Domain Driven Design, are implemented as physically separately 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 characteristics. All of these features will be described in a forthcoming book on evolutionary architecture. In this article we give only some of them.

Modularity and connectivity


The ability to share components within well-defined boundaries gives developers the benefit of continuous change if necessary. If the architecture was not designed and the system looks like a big ball of mud ( Big Ball of Mud architecture ), then evolutionary changes are impossible, since there are no distinguished parts in such a structure.


[The relationship between the classes (points around the perimeter) in a large lump of dirt from an unnamed client project.]

Incorrect connection of the components impedes the evolution of the system due to the fact that changes can affect other parts of the system in an unpredictable way. All evolutionary architectures provide some level of modularity, usually at the level of technical architecture (for example, layered architecture).

Organization around business opportunities


Influenced by the principles of subject-oriented design in modern successful architectures, modularity at the domain level is increasingly being used. A service-based architecture differs from a traditional service-oriented architecture (SOA) primarily in its service allocation strategy. Service-oriented architecture is strictly divided by technical levels, while service-based architectures are built mainly in parts of the subject area defined by microservices.

The experiments


Carrying out experiments is one of the significant advantages that evolutionary architecture gives to business. The ability to easily make small changes to applications provides the use of common continuous deployment practices such as A / B testing, testing for a limited group of users (Canary release), and others. Microservice architectures are often built on the basis of routing service calls, which makes it possible to use several versions of the service within an entire ecosystem. This in turn opens up great opportunities for experimentation and changes in existing functionality. Ultimately, when developing business applications, less time is spent discussing plans and backlogs, and development is carried out mainly in the mode of quick hypothesis testing.

Principles of Evolutionary Architecture


A more complete picture of evolutionary architecture can be obtained by becoming acquainted with its basic principles. These principles relate to various characteristics of both the architecture itself and its design methods. Part of the principles relates to the choice of the moment of making architectural decisions in the process of system design.

Fitness function


It is necessary to distinguish between emergent (formed as a result of the design process) and evolutionary architecture - this is extremely important. Like evolutionary computation methods (such as genetic algorithms), the architectural fitness function sets a goal in architectural design. For some systems, the main requirement is a long uptime, for others, high performance or security.


[Radar chart used to highlight important fitness functions relevant to this software system.]

If you pre-determine the fitness function for a particular system, this will help in the future to make the right decisions in a timely manner. For different architectural solutions, you can calculate fitness functions, and if its value becomes better, this means that architecture is developing in the right direction.

Attention to pain points


Many of the working methods used in the continuous supply of software and the development of an evolving architecture are based on the principle of “attention to pain points” formulated by the eXtreme Programming community. When moments arise in the design work that can become sources of problems (pain points), it is necessary to pay attention to them as soon as possible. This will help to identify potential problems in advance and eliminate them in a working order. Common continuous delivery practices, such as the deployment pipeline, automatic provisioning of virtual machines, and database migration, when designing an evolutionary architecture, greatly simplify the elimination of pain points during the change phase.

Decision point


The main difference between traditional and evolutionary architecture is when significant decisions are made. These decisions may relate to application structure, 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 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 costs of this method include the costs of a possible refinement of the architecture after a decision is made. These costs can be reduced using suitable abstractions, but they can still occur. However, the costs of making decisions 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 necessary, we get an ill-conceived architecture that will inevitably require further development. This "technical debt", arising from the selection of the wrong tool, will be an additional burden for developers.

Of course, the main problem with the last possible moment of making a decision is to determine when it comes. To do this, focus on the function of fitness. First of all, it is necessary to make decisions that can have a significant impact on the choice of architecture or design elements, 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 explain the decisions made about the design of the systems being developed, as a rule, using various kinds of diagrams. Architecture developers often fall into the trap of presenting software architecture as the equation they need to solve. Many commercial tools offered by software architects allow you to formally describe the architecture in the form of squares, lines and arrows. Although such diagrams may be useful, they offer only two-dimensional display, a snapshot of the ideal world, but we live in four-dimensional reality.

To fill such a two-dimensional diagram with life, it is necessary to specify it. The ORM label on a two-dimensional chart becomes Hibernate v4.2.17making the imagined world three-dimensional. When you have a plan for its implementation in production and updates six months later to the inevitable version of Hibernate v4.3.0.1 , you will be ready for the four-dimensional world. Many architects do not realize that a static view of architecture has a short lifespan. The software universe exists in a stream state; it is dynamic, not static. Architecture is not an equation, but rather a snapshot of an ongoing process.

Practices of continuous software delivery and DevOps have shown problems growing out of a lack of understanding of the efforts that are needed to implement and support the architecture. Implementing architecture is just the first step. Architecture remains an abstraction until it is put into action.In other words, the viability of any architecture in the long term can be judged only when you not only implemented, but also modified it at least once. And maybe they managed to cope with the surprises along the way.
A software architect's understanding of operational capabilities is critical to developing 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 completion. The requirements of the continuous delivery process for the architecture are aimed at improving its visualization and simplifying changes. In this way, continuous delivery enhances the capabilities of evolutionary architecture.

November 19, Neil Ford arrives in Moscow with a master classto create an evolutionary software architecture .

Also popular now: