Коротко об обучении ИТ-архитекторов

Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей.

Пара слов о дидактике «больших идей» с примерами. Обычно в такой идее выделяют четыре элемента:

  1. Интеллектуальные преодоления (большие), сформировавшие новые концепты и представления
  2. Технологический пакет. (Рядом с большой идеей возникает сразу несколько сценариев её использования)
  3. Применение. Максимально практичное и востребованное в конкретной ситуации
  4. Новые вызовы.

Берем микросервисы вместе с архитектурой ИТ-решений и проходимся по пунктам

  1. Функциональная декомпозиция информационных систем – то чем люди регулярно занимаются последние полвека. Всё, что рекомендуется микросервисная архитектура: вынесите такой функционал за границы процесса (но не смешивайте его с чем-либо другим, это вам не SOA). Но вы не сможете этого рассказать, не вспомнив архитектуру развертывания, интеграционную архитектуру, 4+1 и т.д. Впрочем, это не единственное преодоления. Тут же возникает вопрос и с данными и с выбором технологического стека и с автоматизацией развертывания.
  2. Зачем? В 2007 году micro-web-services появились как способ разделения на модули веб-приложения. Правильного, хорошего разделения, в традиции unix-way. Потом микросервисами решали задачу масштабирования. Затем обратили внимание на независимость от тех.стека и СУБД. Да и развертывать отдельные процессы проще, особенно после появления контейнеров. А потом пришло понимание проектирования с учетом возможного сбоя, эволюционного развития приложений и т.п. Но все перечисленное выше и есть архитектура решения: выбор систем, технологий, сценариев взаимодействия
  3. Применение. Для моей аудитории — это обычно добавление нового функционала в унаследованные приложения с минимальным риском что-либо сломать. Хотя, всё зависит от конкретных потребностей.
  4. И наконец — новые вызовы. Кстати, часть из них решается на наших глазах. Развертывание kubernetes-ом, проблема service discovery влечет появления service mesh и т.д. Прям даже проверяй перед каждым новым потоком, а не изобрели что-либо еще

В общем, хороший подход. Присмотритесь к нему!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s