Eugeny Shtoltc - Notes of an IT Architect

In this book, we will cover the following sections:

* Architecture;

* Solution Architect and microservices;

* View from the height of the business and business architect;

* Corporate architecture;

* Service architect;

* Use in the management of ITIL 4, PMBOOK and COBIT 5;

* Application architect and design patterns;

* DevOps as a component of an architect;

* Architect and basic patterns;

* Corporate data bus;

* Service Oriented Architect;

* Applications in the cloud;

* Infrastructure for the cloud;

* Edge scaling sizes: data centers, cluster, sizes;

* Architect in business processes;

* Waterfall;

* Scrum;

* Kanban;

* Varieties of teams;

* Selection and growth of personnel;

* TeamLead & leading specialist;

* Virtualization;

* Features of development in Windows – Vagrant;

* Containerization;

* Podman and Docker;

* Stacks;

* Languages and paradigms of programming;

* Front-end: single page web applications.

Now the author holds the position of the Chief Architect of Cloud Native Competencies of the Architecture Department of Sberbank Competence. In this position, the author is engaged in research on the implementation and use of technologies that are already or very soon will become the de facto standard, such as servoless theologies and CloudEvents, and with which he shares with the reader. Also, the author, on a regular basis, evaluates existing systems and those planned for implementation in accordance with their modern standards, for example, CloudNative. About this, in the book, the author talks about the scope and guides the reader to implement them. The author pays special attention to this – finding practical solutions in the formed ecosystem that make life easier for both developers and the support service, while the customer remains interested in them. Employees gain knowledge of current technologies in which problems that are present in obsolete and retired ones have already been solved. This solves the problems of both developers and customers. The author does not dwell on any one technology that he has come across, but gives universal technologies in a systemic and practical form, or introduces the reader to the set of used ones, as the author gives the code in the languages of Go, NodeJS, PHP and Java depending on the relevance. more than 10 years of experience in various fields and in various positions allows us to highlight the relevant and popular ones, as well as undergoing training at Yandex, Sberbank EPAM and receiving many specialized certificates. The author has collected experience, both in domestic and foreign companies, both in startups and in enteprase, both creating his own co-commercial products and working in grocery development and outsourcing, producing streaming products, as well as complex proprietary software solutions… In addition to typing systems and practical help, the author gives an organizational minimum. Internally, the vision will enable work experience in various technical positions such as back-end and full-stack developer, DevOps and Team-Lead, including Software Architect. Experience of work not only as a hired employee allows us to take a look at the organizational level. The author worked both as a hired employee, but also as an individual entrepreneur and an official partner of a large supplier of mass software in Russia and the CIS (Bitrix Technology Partner), making and assembling customized and scalable solutions.

GOST R 57100-2016 (docs.cntd.ru/document/1200139542) based on the international standard ISO / IEC / IEEE 42010 defines architecture as "Basic concepts and properties of a system in the environment, embodied in its elements, relationships and specific principles of its project and development". There are quite a few varieties of it, but we will highlight the main ones in terms of abstraction level: Application Architecture, Software Architecture, Solution Architecture and Enterprise architecture. An application architect develops the architecture of the application itself using design patterns and task allocation, and often combines his role with the role of Team-Lead or Lead Developer of Responsible Components (Tex-Lead). Software Architect does the same thing as an application architect, but works with multiple teams to add unification to the technologies they use. This position is often in demand in outsourcing, where there are many projects and there is an opportunity to take the load off Team-Lead so that they communicate more with customers and the team. This position is characterized by 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 his choice of technologies and hiring new employees. Since its inception in 1959, the architect has dealt with the decomposition of the system, the distribution of parts among the developers, and was responsible for the subsequent integration of the developed components into the originally required system. Now the situation has been simplified with the advent of microservices.

An enterprise architect designs interconnections between systems using an enterprise data integration bus, and an 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 vendor. Previously, applications were also combined by technology platforms and technologies, but with the advent of containerization, provisions can contain components created on different platforms, languages and stacks, enclosed in containers. It has also lost its relevance to the formation of boundaries based on the deployment of the application due to the fact that components (containers) are rolled out and are already being tested in the environment of other components. Ideally, a group of micro-services is grouped by function performed by the business and the team that develops it, but often business processes involve common components, which blur the boundaries of applications. This specificity has 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 a given problem: 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 structure of the program, and often he is a pure techie and also Tex-Lead, but cannot delegate the technical one in any way. In contrast, the corporate architect can be a non-technical specialist, for example, a director, conducting communication to organize the connections of automated systems and satisfy these systems to the needs of customers. Based on this, one can guess that when asked how they become architects, one can answer that architects before Solution Architect are evolutionary along the technical branch, and corporate, either according to the technical branch, or according to the managerial branch, including business analytics. At the same time, you can become an architect at any number of years.

The introduction of microservices begins with a business, when marketing starts doing experiments – requesting features in the form of MVP, then testing in the market, then either rejecting (which is rare) or refining. Improvement is required both after confirmation of the assumption, and erroneous in the form of an adjustment. For the operations department, 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 it asks the development department 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, 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 interconnected with other services and must provide a specific API and SLA, the components are tightly coupled. The reason for the separation into components is of a technological nature. For example, an online store contains services such as the online storefront itself, payment services, warehouse services, and the online storefront is a service on the CMS Joomla! and a database management system (DBMS) MySQL. Here, the division of the service into its component parts occurred 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 a 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, ordering)… From a technological point of view, the components are services:

* Singles are not functional;

* Strongly connected, as many requests are generated for each request to the CMS;

* Interaction interfaces are complex and varied – not even the API is used here, but the SQL interaction language;

* Strongly connected functionally through a complex technical API – only known to the user supported compatibility of some CMS versions with other DBMS versions.

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 connections. Does not require complex integration with debugged services (the integration of complex systems is handled by a service oriented SOA architecture);

* 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;