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

Чтение книги онлайн.

СКАЧАТЬ безсервеными теологиями и 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, потом тестировать на рынке, после либо браковать (что редко), либо дорабатывать. Доработка требуется как после подтверждения предположения, так и ошибочного в виде корректировки. Для службы эксплуатации это означает выкатку огромного количества фич, которые были разработаны впопыхах и могут обрушить основное приложение – монолит. Эта служба пытается запускать эти изменения в изолированной среде в виде отдельного СКАЧАТЬ