Интервью о конференции ArchDays

Недавно я присоединился к программному комитету конференции ArchDays, идейным инициатором которой выступил Сергей Баранов из Scrumtrek. Конференция будет еще не скоро, но нам хотелось обсудить тематику конференции уже сейчас. Именно поэтому мы решили провести небольшое интервью, где вопросы задавал Сергей, а отвечал ваш покорный слуга.

Интересный вопрос, который содержит в себе сразу несколько сложных моментов с определением: архитектуры, микросервисов и микросервисной архитектуры. Задав определение архитектуры и микросервисов, мы сможем синтезировать из них определение микросервисной архитектуры. Стандарт ISO/IEC/IEEE 15288 по системной инженерии говорит, что архитектуры системы это “принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию”. В то же время, Сэм Ньюман, автор книги “Создание микросервисов”, определяет микросервисы как “небольшие, автономные, совместно работающие сервисы”. В итоге, мое определение микросервисной архитектуры звучит так:

Микросервисная архитектура — это организация системы в виде группы сервисов, взаимодействующих друг с другом посредством четко специфицированных API (синхронных/асинхронных), которые позволяют проектировать системы в виде автономных частей, которые можно разрабатывать отдельными командами и эволюция которых возможна в виде отдельных подсистем пока они остаются в рамках контрактов на API.

Хороший вопрос, т.к. микросервисная архитектура как раз позволяет правильно разделить ответственность между top-level архитекторами и командами разработки. На верхнем уровне остаются вопросы, связанные со стратегией:

  • технологический стек компании — подробнее можно почитать про подход technology radar от ThoughWorks
  • поддерживаемые провайдеры инфраструктуры — например, оркестратор kubernetes, превратившийся в фреймворк для cloud native приложений
  • правила коммуникации сервисов между собой — например, использование grpc и protocol buffers для коммуникации сервисов
  • общие фреймворки и библиотеки для создания сервисов и их инфраструктурные обвязки в виде логгирования, мониторинга и т.д, что позволяет сократить совокупную стоимость владения (TCO) — подробнее можно почитать в книге SRE от Google

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

Да, я считаю, что соблюдение архитектурной целостности возможно. Этому должно способствовать четкое разделение принимаемых решений на уровни, которые я перечислил в предыдущем вопросе. Интересно, что команда может отклоняться от курса партии, заданного top-level видением, если у них есть валидные аргументы и они готовы нести повышенную стоимость эксплуатации своего решения. Главное, чтобы эти отличия были инкапсулированы внутри сервисов, за которые отвечает команда, и не прорывались на уровень контрактов взаимодействия. Например, впилить в свой сервис другую бд — это ок, а сменить формат api для общения с потребителями с grpc на graphql — это уже не ок:)

Это интересный вопрос. Если смотреть ретроспективно, то причины появления SOA как предвестника микросервисной архитектуры были в том, что сложность систем, необходимая скорость разработки и нагрузка на сервисы росла большими темпами. Это в свою очередь привело к созданию распределенных систем, где со сложностью боролись подходом “разделяй и властвуй”, скорость обеспечивали путем привлечения отдельных команд на разные сервисы, а нагрузку побеждали вертикальным и горизонтальным масштабированием. Кажется, что в дальнейшем исходные тенденции будут проявляться все ярче и ярче, а поэтому у нас наступает время распределенных систем. Возможно, в дальнейшем микросервисная архитектура сменит свое название на новое, но суть останется той же. Если обратится к более приближенным к реальности примера, то сейчас набирают популярность подходы serverless и faas, когда ты думаешь о сервисах в рамках выполняемых им функций безотносительно underlay слоя исполнения.

Да, я люблю читать как профессиональную литературу, так и научно-популярные и художественные книги. Рекомендую каждому архитектору ознакомиться с творчеством замечательного пилота и писателя Антуана де Сент-Экзюпери. Ведь именно его перу принадлежит цитата, которая как нельзя подходит нашей профессии “Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать”:) Если же говорить про профессиональные книги, то рекомендую следующий перечень книг из тех, что я прочел за последние пару лет и которые относились к области разработки программного обеспечения:

До 26 августа у вас есть уникальная возможность купить билет по минимальной стоимости или до 8 сентября подать доклад на эту конференцию и в дальнейшем уже обсудить его с программным комитетом:)

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store