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