Архитектура

В настоящий момент Микросервисная Архитектура является самый популярным подходом в Web-разработке. Но являются ли Микросервисы серебряной пулей, которая решит все ваши проблемы? В ходе доклада обсудим, действительно ли так нужны микросервисы в нашем проекте, и, если да, то с какими сложностями мы столкнемся. Мы сравним Микросервисную Архитектуру с Монолитным Приложением и разберемся, когда следует переходить на Микросервисы, а когда оставить все как есть.

Рост количества компонентов в микросервисных проектах и рост скорости изменений требуют пересмотра подхода к внедрению.

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

Необходима полностью автоматическая система внедрения микросервисов.

Система работающая по принципу "внедрение как услуга", обрабатывающая планы внедрения записанные в виде декларативных инструкций.

В докладе представлена архитектура такой системы внедрения с использованием популярных проектов ArgoCD, CrossPlane, AtlasGo и некоторого кол-ва расширений необходимых для полностью автоматического внедрения в микросервисных проектах

1. В классической системной инженерии чрезвычайно мощным инструментом является иерархическое разбиение системы по отношению "часть-целое". Для материальных систем такое деление "естественно" за счет 3D-природы материала.

2. В программных системах нет такого "естественного" деления и в результате мы теряем мощнейшее средство организации мышления и управления сложностью.

3. Современные ООЯП по историческим причинам загоняют нас в программную "флатландию", не давая выразительных средств для качественного структурирования программных систем.

4. Заметный всем глубокий "разрыв" между разработчиками и архитекторами обусловлен не только разными целями и задачами, но и разницей в мышлении, вызванной ограничениями ЯП. Архитекторы должны переучиваться думать, чтобы выбраться из "флатландии".

5. Все прежние меры, призванные преодолеть этот разрыв (тесты архитектуры, архитектура/диаграмма "как код", etc) не решают глубинную причину и поэтому паллиативны

6. Нужны широкие, масштабные, разнообразные эксперименты и исследования следующей парадигмы в ЯП, которая бы устраняла этот недостаток и добавляла бы в ЯП надежные средства иерархической функциональной декомпозиции. Тогда многие важные архитектурные решения будут воплощены в исполняемом коде (не в диаграммах-как-код и не в "тестах архитектуры" которые легко игнорировать).

Покажу пример такого эксперимента в виде DSL на Rust.

Для многих разработчиков позиция архитектора и его деятельность все ещё остаются загадочными и вызывают множество вопросов.

Мы позвали на круглый стол трех практикующих архитекторов из разных отраслей и попросили их честно отвечать (в рамках NDA, конечно) на все ваши самые каверзные вопросы.

Краснеть и бледнеть на сцене от ваших вопросов будут:

Вадим Щемелинин, СИБУР Цифровой, более десяти лет в разработке, пять лет занимается цифровизацией нефтехимии в части продуктов Индустрии 4.0

Игорь Беспальчук, работал в EPAM над eCom и EdTech проектами, учил архитекторов в Luxoft

Филипп Дельгядо, последние лет 15 занимается финтехом, сейчас строит процессинги в lekton.io

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

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

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

Мастер-класс проводит Филипп Дельгядо, архитектор компании lekton.io.