Страница 2 из 7
It is necessary to separate two levels of separation: technological and domain. Technological features in the work are the same, since that services, that its components, if it is divided into component parts, are technologically launched and supported in the same way. But, unlike services, which must be minimally interco
* Singles are not functional;
* Strongly co
* Interaction interfaces are complex and varied – not even the API is used here, but the SQL interaction language;
* Strongly co
Dividing a system into microservices begins with an analysis of their boundaries, an analysis of the benefits of separation and the added complexity of a distributed system. It is better to separate microservices when there is a combination of need:
* Technological necessity, for example, a large load that is difficult to withstand without separation, for example, scaling, another type of support (SLA);
* For business, the dedicated service is already a separate and little dependent function – further we will consider the DDD (model-driven design + ubiquitous language) approach to the implementation of microservices;
* Requires change of technology platform.
Microservice meets the following characteristics, according to M. Fowler (martinfowler.com). They can be summarized as:
* 1. Must be a component or service. Each microservice is a complete, full-fledged independent service from the point of view of the developer, system administrator and user. It should be able to be easily replaced with another, both in the developer's code, both in the process of work (should be), and presented to another or removed in the user interface. Failure to fulfill the conditions of interchangeability at different levels lead to one service divided into parts – a distributed monolith;
* 2. Organization of business opportunities;
* 3. Products are not projects;
* 4. Smart endpoints and silly co
* 5. Decentralized management. This refers to orchestration like Kubernetes, network management like Istio, delivery management like KNative;
* 6. Decentralized data management. Due to the self-sufficiency of the service and independence from others, it must have an independent state – a database, and so that the choice of a database management system is independent – there is its own;
* 7. Automated infrastructure. The process of deployment, scaling and rollbacks should be automated, which allows you to quickly automatically rollback, fix the isolation of the service in the code;
* 8. Provided for refusal to work. To visualize failures, you can look at Jaeger and Prometheus, to localize problems, services must be isolated, represent one single service, which allows you to isolate, limit the harmful effects on other services in case of failure and automate rollback;
* 9. Evolving design. The system grows outgrowths in the form of services – it becomes overgrown with them, while its structure does not need to be changed. Neal Ford and Rebeca Parsons in "Microservices as Evolving Architecture" focus on continuous improvement.
Business architecture (Enterprise Architect) is the IT architecture of the entire company. It operates with abstractions and entities at the business level, these are strategies, business processes, services, and the like. The systems and interco
Changing the existing architecture can be carried out in three ways: supporting the current one, completely replacing the current one, complementing the current one. Replacing the current one requires a long and lengthy study of the functionality of the current system, then finding out the functionality that is currently in demand and searching for differences between the current functionality and the expected one, after which the cost and development time are calculated. During the presentation, in most cases, a refusal will be received in the development of the system, since the customer does not need a technical update of the existing functionality, but he needs new ones and the correction of the old, and even more so not for the time and funds that were spent on creating the current system. With the consistent improvement of the system, fundamental changes to the system ca
The Enterpris Architect strategy implements different company strategies in different ways:
* Growth (scaling) strategy when the market is free – the architecture unifies and debugs processes;