Из разработчика в архитекторы. Практический путь

Из разработчика в архитекторы. Практический путь
Евгений Сергеевич Штольц

В этой книге главный Архитектор Департамента Архитектуры компетенций Cloud Native в Сбербанк делится знанием и опытом с читателей, накопленным при разработке своих и оценке чужих архитектур, предоставляя базис для профессионального и карьерного роста.

Об авторе

Ныне автор занимает позицию главного Архитектора Cloud Native компетенций Департамента Управления Архитектуры компетенции Сбербанка. На данной позиции, автор занимается исследованием внедрения и использования технологий, который уже сейчас становятся или самое ближайшее время станут стандартом де факто, такими как безсервеными теологиями и CloudEvents, и c которыми он делится с читателем. Также, автор, на регулярной основе производит оценку существующий систем и планируемых к внедрению по соответствию их современным стандартам, например, CloudNative. Об этом, в книге, автор рассказывает об сфере применения и проводит читателя по внедрению их. Автор, уделяет этому особое внимание – поиску практичных решений в сформированной экосистеме, которые упрощают жизнь как разработчикам, так и службе поддержке, при этом заказчик остаётся заинтересованным в них. Сотрудники получают знания актуальных технологий в которы уже решены проблемы, которые присутствуют в устаревших и выводимых из использования. Это решает проблемы проблемы как разработчиков, так и заказчиков. Автор не останавливается на какой-то одной технологии приглянувшийся му ли с которой он столкнулся, а приводит универсальные технологии cистемном и практическом виде, или знакомит читателя с набором используемых, так автор приводит код на зыках Go, NodeJS, PHP и Java зависимости от актуальности. опыт более чем 10-летний в различных областях и на различных позиций позволяет выделить актуальные и востребованные, а также проходя обучение в Яндекс, Сбербанк EPAM и получая множество профильных сертификатов. Автор опил опыт, как в отечественных компаниях, так и в зарубежных, как в стартапах, так и в энтепразе, как создававший собственные ко коммерческие продукты, так и работающих на продуктовой ра работке и аутсорс, производящих потоковый продукты, так и сложные собственные программные решения. Кроме систем типизации и практической помощи, автор приводит организационный минимум. Внутренне видении позволят опыт работы на различных технических позициях, таких как back-end и full-stack разработчик, DevOps и Team-Lead, включая Software Architect. Взглянуть организационно позволяет опыт работы не только в качестве наёмного сотрудника. Автор работал как в качестве наёмного сотрудника, но и в качестве индивидуального предпринимателя и официального партнёра крупного поставщика массового программного обеспечения на территории России и СНГ (Технологический партнёр Битрикс), делая и собирая под заказные и масштабируемые решения.

Архитектура

ГОСТ Р 57100-2016 (docs.cntd.ru/document/1200139542) на основе ISO/IEC/IEEE 42010 даёт определение архитектуры как Основные понятия и свойства системы в окружающей среде, воплощённых в её элементах, отношениях и конкретных принципах её проекта и развития. Разновидностей её существует довольно много, но выделим основные по уровню абстракции: архитектуру приложения (Application Architecture), программною архитектуру (Software Architecture), архитектуру приложений Solution Architecture и бизнес архитектуру (Enterprise architecture). Архитектор приложения занимается разработкой архитектуры приложения (паттерны проектирования, распределение задач) и зачастую совмещает свою роль с ролью Team-Lead и ведущего разработчика ответственных компонентов. Software Architect занимается тем же, что и архитектор проложения, но работает с несколькими командами, добавляя унификацию используемых ими технологиями. Часто это позиция востребована в аутсорсинге, где много проектов и есть возможность снять нагрузку с Team-Lead, чтобы они больше общались с заказчиками и командой. Для этой позиции характерны требования для вакансии по знанию языка программирования и основного стека используемых на проектах. В такой ситуации архитектор ограничен в выборе технологий и найме им новых сотрудников. Начиная с появления в 1959 году, архитектор занимался декомпозицией системы, распределением частей по разработчикам и отвечал за последующую интеграцию разработанных компонентов в изначально требуемую систему. Ныне ситуация упростилась с появление микросервисов.

Корпоративный архитектор проектирует взаимосвязи между системами использую интеграционную шину данных предприятия, а архитектор приложений проектирует сами системы, декомпозируя их на приложения. Границы между приложениями определяются границами использования: разработки, развёртывания, предоставлению поставщику. Ранее, приложения, также объединялись по технологическим платформам и технологиями, но с приходом контейнеризации, положение могут содержать компоненты созданные на разных платформах, языках и стеках, заключённые в контейнерах. Также потеряла актуальность формирования границ на основе выкатки приложения в силу того, что выкатываются компоненты (контейнера) и уже тестируются в окружении других компонентов. В идеале группа микро сервисов сгруппирована по выполняемой функцией бизнесом и командой разрабатывающей ею, но зачастую в бизнес процессах участвуют общие компоненты, что размывает границы приложений. Подобная специфика привела к появлению отдельной специализации – Cloud Solution Architect.

Solution Architect и микросервисы

Внедрение микросервисов начинается с бизнеса, когда маркетинг начинает делать эксперименты – запрашивать фичи в виде MVP, потом тестировать на рынке, после либо браковать (что редко), либо дорабатывать. Доработка требуется как после подтверждения предположения, так и ошибочного в виде корректировки. Для службы эксплуатации это означает выкатку огромного количества фич, которые были разработаны впопыхах и могут обрушить основное приложение – монолит. Эта служба пытается запускать эти изменения в изолированной среде в виде отдельного функционала, для чего просит отдел разработки, разрабатывать их отдельно – в виде микросервисов.

Нужно разделять два уровня разделения: технологическое и доменное. Технологические особенности в работе едины, так как что сервисы, что его компоненты, если он разбит на составные части технологически запускаются и поддерживается одинаково. Но, в отличии от сервисов, которые должны быть минимально взаимосвязанны с другими сервисами и должны обеспечивать определённое API и SLA, то компоненты сильно связанны. Причиной разделения на компоненты имеют технологическую природу. Например, интернет магазин содержит сервисы, такие как сама интернет витрина, сервисы оплаты, складские сервисы, а интернет витрина представляет из себя сервис на CMS Joomla! и систему управления базой данных (СУБД) MySQL. Здесь разделение сервиса на составные части произошло из-за разных программных продуктов написанных на разных языках программирования. При этом, для заказчика это единый сервис на CMS Joomla!, выполняющий единую функцию предоставления интерфейса для заказа пользователям в онлайне, предоставляемый хостингом как единый сервис (по отдельности не будет работать), может работать как каталог товаров без других сервисов (оплаты, заказа). С технологической точки зрения компоненты сервисы:

по одиночки не функциональны;

сильно связанны, так как на каждый запрос к CMS формируется множество запросов;

интерфейсы взаимодействия сложны и разнообразны – тут применяется даже не API, а язык взаимодействия SQL;

сильно связанны функционально через сложное техническое API – для пользователя известно лишь поддерживаемая совместимость одних версий CMS с другими версиями СУБД.

Разделение системы на микросервисы начинается с анализа их границ, анализ выгод от разделения и привнесённых сложностей распределённой системой. Отделять миркросервисы лучше при комбинации необходимости:

* Технологической необходимости, например, большая нагрузка, которую сложно выдержать без отделения, например,

масштабированием, другой вид поддержки (SLA)

* Для бизнеса выделяемый сервис уже является отдельной и мало зависимой функцией – далее рассмотрим

подход DDD (model-driven design + ubiquitous language) к реализацию микрсервисов

* Необходима смена технологической платформы

Микросервис отвечает следующим характеристикам, по мнению М. Фаулера (martinfowler.com). Их можно свести к:

1. Должен из себя представляеть компонент или сервис. Каждый микросервис – законченный полноценны независимый сервис с точки зрения разработчика, системного администратора и пользователя. Он должен обладать возможностью быть легко заменённым на другой, как в коде разработчика, как в процессе работы (должны быть ), так и представлен другим или убран в интерфейсе пользователя. Не выполнения условий заменимости на разных уровнях приводят к одному сервису разделённому на части – распределённому монолиту.

2. Организация бизнес возможностей.

3. Продукты – не проекты.

4. Умные конечные точки и глупые связи. Не требующая сложной интеграции с отлаженными сервисами (интеграцию сложных систем занимается сервис ориентированная архитектура SOA)

5. Децентрализованное управление. Здесь имеется в виду оркестрация, например, Kubernetes, управление сетью, например, Istio, управление доставкой, например, Knative.

6. Децентрализованное управление данными. В силу самодостаточности сервиса и независимости от других он должен иметь независимое состояние – базу данных, а чтобы и выбор системы управления базой данных был независим – есть и её свою.

7. Автоматизированная инфраструктура. Процесс деплоя, масштабирования и откатов должен быть автоматизированы, что позволяет быстро автоматически откатываться, фиксировать в коде изолированность работы сервиса.

8. Предусмотрен отказ в работе. Для визуализации отказов можно посмотреть на Jaeger и Prometheus, для локализации проблем сервисы должны быть изолированны, представлять один единый сервис, что позволяет изолировать, ограничить пагубное воздействия на другие сервисы при отказе и автоматизировать откат.

9. Эволюционирующийся дизайн. Система наращивает отростки в виде сервисов – обрастает ими, при этом не требуется изменение её структуры. Neal Ford и Rebeca Parsons в "Микросервисы как эволюционирующая архитектура" ориентируются на постоянные улучшения.

Взгляд со высоты бизнеса и бизнес архитектора

Бизнес архитектура (Enterprise Architect) – это IT архитектура всей компании. Она оперирует абстракциями и сущностями на уровне бизнеса, это стратегии, бизнес процессы, услуги и тому подобного. Системы и взаимосвязи, обеспечивающие работу бизнеса именуют ИТ ландшафтом, потому что она содержит множество систем, не образующих единое целое, связанные бизнес процессами, в которых они участвуют и которые не ограничиваются ими. Бизнес- архитектора (Enterprise Architect) работает на этом уровне, подстраивая текущий ландшафт под текущую потребности бизнеса. Зачастую, для традиционных компаний, которые развивались не в высокотехнологической сфере в синем океане, он привлекается когда ИТ ландшафт сложился и возникают сложности его развития и адаптации под изменившиеся условия, в технологический стартапах создаётся минимально способный продукт (MVP). Бизнес архитектор корпоративного ИТ ландшафта должна решать проблемы с низкой скоростью внесения изменений (из-за невозможности локального тестирования, откладывания распределённых изменений, иском поломки после накатки распределённых изменений) – time to market, быстрой адаптаций к ожиданиям пользователей – customer experience и стоимость – cost. Первая решается последовательными активностями архитектора по наведению порядка, снижая связанность и запутанность, что упрощает и ускоряет процесс внесения изменений и как и в любой наукоемкой сфере, где основной затратой является человеко-часы работников, уменьшает стоимость. Архитектору всё чаще и чаще не предоставляются требования, он подключается на самых ранних этапах их формирования, после его возможности сильно ограниченны. Для этого ему нужно активно участвовать в переговорах и собраниях, чтобы корректировать требования. Далее сформировать несколько возможных решений с разным уровнем сложности, от простого и быстрого но не эффективного ("решения на коленке"), через оптимальное, и до масштабного и гибкого. Далее сформировать архитектурный комитет, на котором предложить решения для выбора и скорректировать выбор в сторону оптимального.

Изменение существующий архитектуры может осуществляться тремя способами: сопровождение текущей, полной заменой текущей, дополнение текущей. Замена текущей требует проведение долгого и длительного исследования функционала текущей системы, далее выяснения функционала, который на текущий момент востребован и проведения поиска отличий между текущем функционалом и ожидаемым, после этого рассчитывается стоимость и время разработки. При презентации, в большинстве случав будет получен отказ в разработке системы, так как заказчику не нужно техническое обновление существующего функционала, а ему нужен новы и корректировка старого, и тем более не за время и средства, которые были потрачены на создание текущей системы. При последовательном улучшении системы нельзя добиться фундаментальных изменений системы, так как архитектурно отличающийся функционал одной части противоречить другим и изменения архитектурного стиля не достигается последовательными улучшениями частей из-за комплексной природы.

Архитектор приложения и паттерны проектирования

Архитектор конкретного приложения или как его ещё называют Application архитектор разрабатывает архитектуру конкретного приложения и отвечает за техническую реализацию. Именно он опускается на самый низкий уровень – уровень реализации, определяя на каких технология из доступных и как будет реализовано приложение, чтобы оно выполнено возложены на него задачи. Он работает в связке с командой для объяснения, каким образом его задумка должна быть реализована и почему именно так. Он не ограничивается разработчиками, а работает со всей командой, продумывая как программный код будет стыковаться с экосистемой, например, с базой данных. Так, решение, поместить логику с код приложения или в базу данных определяет он, и ему возможно потребуется создать прототипы для принятия правального решения. Для внедрения незнакомых технологий в команду, обычно, он изучает и экспериментирует с набором сходных технологий, создаёт тестовый стенд и демонстрируя команде, продвигает применение её.

Важно отметить, что архитектор полностью отвечает за техническую успешность проекта и только он определяет как проект должен быть реализован. Архитектор может не знать всех технологий, которые он запланировал к реализации, и может привлекать узкоспециализированных специалистов, но ответственность за правильный выбор остаётся на нём. Например, он, если для хранения логов была взята БД MySQL, потому что нет специалистов знакомых с нужными, и она не выдерживает нагрузки, то в провале виноват архитектор. Если же архитектор сделал правильный выбор, но его некому реализовывать, то это задача подбора персонала, а не проблема архитектуры. Архитектор нужно учитывать текущую ситуацию с кадрами и технологическим стеком, если у не на это есть возможность. Если есть реальный риск, что архитектура не может быть вписана в текущие ограничения, то проект признаётся не выполнимым, так как менеджер проекта, когда он не может вписать проект в сроки, бюджиет и функционал. После того, как проект признан не выполнимым при данных ограничениях, руководство начинает принимать меры по корректировке ограничений, например, увеличивает бюджет для найма новых специалистов, или пересматривает весь проект заново, например, из добавления логов для отслеживания ошибок в существующей системе принимается решение купить готовое решение, которое подобных ограничений не имеет.

Основными инструментами является код и готовые решения. Программный код или связывает готовые решения, такие как БД, или реализует недостающий функционал. От сюда вытекает два технических направления развития – знание организации кода и знания готовых технологий. Для организации кода используются паттерны проектирования, реализация которых обсуждается с командой разработки для того, чтобы они могли их реализовать. Паттерны не являются готовыми решениями, а шаблонами для построения архитектуры. GoF – наиболее популярный сборник паттернов проектирования, являющийся базовым требованием к разработчикам, а от архитектора ожидается знания не только объектно-ориентированных паттернов программирования, но и паттернов уже ставшего трендом – функционального программирования. Знание продуктов и их особенностей, таких базы данных и очереди, умение быстро накидать тестовый стенд для проверки, – необходимость.

Практически всегда, эту роль на себя берёт или Team-Lead, или Tex-Lead, но это основа ступенька для более высоких позиций. Рассмотрим их по подробнее.

DevOps как составляющая архитектора

Зачастую в маленьких организациях DevOps это единственный человек, понимающий устройство на всех уровнях, и как системный администратор инфраструктуру и устанавливаемые приложения, и как программист разрабатываемую прикладную программную часть, и как автоматизатор – бизнес процессы разработки. Позиция архитектора в крупных компаниях предполагает знакомство с методологиями управления архитектурой:

* TOGAF (The Open Group Architecture Framework) c программой Archimade

* Zachman Framework

* DoDAF

* ARIS (Architecture of Integrated Information Systems) с программой ARIS Express

Для DevOps важны общие концепции процесса создания продукта и его внедрения, поэтому возьмём общее из популярных. Если в компании есть специалист занимающийся реализации, в качесве которого обычно выступает или Tex-Lead, или Team-Lead, который в деталях видит как будет устроенна и создаваться его приложение его командой, то он может выполнять роль Application Application. Эта частая практика и необходимое условие, так как приложение является сильно взаимосвязанным, и нужен человек, который знает в деталях как оно устроенно и как изменения в одной его части повлияют на другие. Если же такой экспертизы найти не получается, приложение необходимо делить на части и фиксировать связи интерфейсами. Для деления проекта на части нужно разделить саму команду, разрабатывающую его, на части в соответствии с законом Конвея ("Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации"). При такой организации, когда приложение всё ещё остаётся одним, но разделённым на части, Tex-Leid и Team-Lead имея понимание в каждой части и могут объять реализацию всего приложения, могут получить экспертизу у более узких членов их команд, когда их экспертизы не хватает. Если речь идёт о Software Architect или Technology Architect, то ныне эту роль берёт унификации, соответственно, в виде контейнеров и виртуальных машин. Если же речь идёт о системе приложений, то необходимо оперировать более высоким уровнем проектирования, таким как Information Architect (System Architect и Solution Architect), при котором не получается совмещать проектирование и реализацию, так как необходимо спроектировать группу систем, который будут разрабатывать разные команды. Если взаимосвязи простые, а это решается при согласовании лидов этих отделов и архитектор не требуется. Архитектор нужен, когда разрабатывается система целиком и требуется в текущей системе заменить на несовместимый с текущей сисетмой компонент, когда нужно изменить организацию компонентов, а экспертизы специалиста занимающегося реализаций не хватает тогда нужно видении всей системы целиком, формированием которого и занимается архитектор. Для него крайне важно понимать различные программы, и как они могут взаимодействовать между собой, при этом глубокой экспертизы во всех областях и текущей ситуации обстановки в командах трудно достичь, но для этого имеются лиды этих команд. Раз было решение производить столь масштабные изменения и критические изменение, архитектору необходимо плотно взаимодействовать с бизнесом (заинтересованными сторонами), чтобы новая система удовлетворяла возложенным ожиданиям, а переход был не столь болезненным. Начиная с 1962 "Master Plan for Information System" предлагала определение необходимой инфраструктуры, анализ текущей, выявление различий, составления плана перехода и реализация перехода. Следование плану и его детального описания является ключевым требованием для успешности перехода и достижения конечного состояния системы. Из-за разнородности природы реализации в 1988 году Stategic Information Planing разделяет архитектуру на технологическую, системную, функциональную и архитектуру данных. В 1992 году появись слои в EAP детализации: планирование, бизнес слой, информационны ( данные, приложения и технологии) и слой реализации и миграции, что позволило говорить с бизнесом и ИТ на их языке. Далее, в 1995 для уменьшения рисков изменений и устаревания требований к конечной системе TOGAF предлагает разделить весь процесс на части ("циклы"), каждый из которых будет представлен отдельным проектом реализации для отдельного менеджера и объединены в "программу проектов", за которую отвечает уполномоченный менеджер. Сама интерактивность архитектурного цикла близка к спиральному походу в разработке и также требует неизменность результата в проекта. На текущем итеративном цикле нельзя принимать изменения от заинтересованных лиц, но можно их учитывать на следующей итерации этого цикла. Важным моментом, является то, что TOGAF преподносится как архитектурный фреймворк требующий адаптации и выбора необходимых элементов, а не готовый процесс и свод правил описания и следованию плану. Что с одной стороны дискредитирует идею его как серебряной пули в необходимый набор из сотни документов (артефактов) связанных общим правилом применения (архитектурным циклом), а с другой стороны показывает его гибкость как сродни набор программ в Linux. С переходом к облачной инфраструктуре, даже если компания не планирует использовать публичные облака, часто стремится сделать у себя приватное для стандартизации управления и применения. Таким образом, из разработке решений на базе облака физический (сети, сервера) и технологический (виртуальные мшаны, контейнера) переносятся из приложения в экосистему облака, оставляя бизнес уровень, ИТ уровень и уровень для миграции. Архитектор защищает свой проект перед бизнесом для получения бюджетирования на его реализацию.