Eugeny Shtoltc - From programmer to architects. Practical way

Здесь есть возможность читать онлайн «Eugeny Shtoltc - From programmer to architects. Practical way» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Год выпуска: 2021, Жанр: Интернет, Прочая околокомпьтерная литература, Программирование, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

From programmer to architects. Practical way: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «From programmer to architects. Practical way»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

In this book, the chief Architect of the Cloud Native Competency Architecture Department at Sberbank shares the knowledge and experience with readers gained in developing their own and evaluating other people's architectures, providing a basis for professional and career growth.

From programmer to architects. Practical way — читать онлайн ознакомительный отрывок

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «From programmer to architects. Practical way», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Eugeny Shtoltc

From programmer to architects. Practical way

Varieties of architects

Architecture

ISO / IEC / IEEE 42010 defines architecture as the Basic concepts and properties of a system in the environment embodied in its elements, relationships and specific principles of its design and development. There are quite a few varieties of it, but we will single out the main ones according to the level of abstraction: application architecture (Application Architecture), software architecture (Software Architecture), application architecture Solution Architecture and business architecture (Enterprise architecture). The application architect develops the application architecture (design patterns, task allocation) and often combines his role with the role of Team-Lead and the leading developer of critical components. Software Architect does the same thing as the build architect, but works with several teams, adding the unification of the technologies they use. Often this position is in demand in outsourcing, where there are many projects and it is possible to take the load off Team-Lead so that they communicate more with customers and the team. This position is characterized by the requirements for a vacancy in knowledge of the programming language and the main stack used on projects. In such a situation, the architect is limited in choosing technologies and hiring new employees. Since its appearance in 1959, the architect has been engaged in the decomposition of the system, the distribution of parts by developers, and was responsible for the subsequent integration of the developed components into the initially required system. Now the situation is simplified with the advent of micro-services.

The corporate architect designs the relationships between the systems using the enterprise data integration bus, and the application architect designs the systems themselves, decomposing them into applications. The boundaries between applications are determined by the boundaries of use: development, deployment, provision to the supplier. Previously, applications were also united by technological platforms and technologies, but with the advent of containerization, the situation may contain components created on different platforms, languages and stacks, enclosed in containers. Also, the formation of borders based on rolling out the application has lost its relevance due to the fact that the components (container) are rolled out and are already being tested in the environment of other components. Ideally, a group of micro services is grouped by the function of the business and the team developing it, but often common components participate in business processes, which blurs the boundaries of applications. This specificity led to the emergence of a separate specialization – Cloud Solution Architect.

Based on the level of architecture that is supposed to be designed, it is possible to turn from an abstract question – how to become an architect – into a set of requirements necessary for solving the task: from purely technical to organizational. So a software architect can delegate all organizational activities to Team Lead and focus purely on the technical description of the program structure, and often he is a pure techie and part-time Tex-Lead, but he can not delegate the technical one. In contrast, a corporate architect may not be a technical specialist, for example, a director, conducting communication to organize communications of automated systems and meet these systems with the needs of customers. Based on this, one can guess that the question – how do they become architects – can be answered that architects before Solution Architect are evolutionary in technical branch, and corporate, either in technical branch, or managerial, including business analytics. At the same time, you can become an architect at any number of years.

Solution Architect and microservices

The introduction of microservices begins with the business, when marketing begins to do experiments – request features in the form of MVP, then test on the market, after which either reject (which is rare) or modify it. Refinement is required both after confirmation of the assumption, and erroneous in the form of adjustments. For the maintenance service, this means rolling out a huge number of features that were developed in a hurry and can bring down the main application – the monolith. This service tries to run these changes in an isolated environment as a separate functionality, for which the development department asks for it, to develop them separately – in the form of microservices.

It is necessary to separate two levels of separation: technological and domain. Technological features in the work are the same, because the services, what its components, if it is divided into its components, are technologically launched and maintained the same way. But, unlike services, which should be minimally interconnected with other services and must provide a certain API and SLA, the components are strongly connected. The reason for the separation into components are of a technological nature. For example, an online store contains services such as the online showcase itself, payment services, storage services, and the online showcase is a service on CMS Joomla! and MySQL database management system (DBMS). Here the division of the service into its constituent parts was due to different software products written in different programming languages. At the same time, for the customer this is a single service on CMS Joomla !, performing the single function of providing an interface for ordering to users online, provided by the hosting as a single service (it will not work separately), can work as a catalog of goods without other services (payment, order) . From a technological point of view, service components:

1. singles are not functional;

2. strongly connected, since for each request to the CMS a lot of requests are generated;

3. interaction interfaces are complex and diverse – not even the API is used here, but the SQL interaction language;

4. are strongly connected functionally through a complex technical API – for the user only the supported compatibility of some versions of CMS with other versions of the DBMS is known.

The division of the 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 the world services with a combination of the need:

1. Technological need, for example, a large load that is difficult to withstand without separation, for example, scaling, another type of support (SLA);

2. For business, the allocated service is already a separate and little dependent function – then we’ll consider DDD (model-driven design + ubiquitous language) approach to the implementation of microservices;

3. Need to change technology platform.

Microservice meets the following characteristics, according to M. Fowler (martinfowler.com). They can be reduced to:

1. Must be a component or service. Each microservice is a complete, fully-fledged independent service from the point of view of the developer, system administrator and user. It should have the ability to be easily replaced with another one, both in the developer code, both in the process of work (should be) and presented to others or removed in the user interface. Failure to meet the replaceability conditions at different levels leads to one service divided into parts – a distributed monolith.

2. Organization of business opportunities.

3. Products are not projects.

4. Smart endpoints and stupid connections. Not requiring complex integration with debugged services (service-oriented SOA architecture is involved in the integration of complex systems)

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «From programmer to architects. Practical way»

Представляем Вашему вниманию похожие книги на «From programmer to architects. Practical way» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «From programmer to architects. Practical way»

Обсуждение, отзывы о книге «From programmer to architects. Practical way» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x