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

1. ПРОГРАММА ВСТРЕЧИ
| Максим Смирнов, свободный эксперт, ex: Вымпелком, Банк России
Барьеры микросервисной архитектуры
| Юрий Веретельников, Solit Clouds
Почему в нашем решении никогда не появятся микросервисы
| Андрей Солощак, Бинбанк
Опыт построения микросервисной архитектуры в цифровом банке
Wi-Fi: CUSTIS | Public@CUSTIS | Facebook.com/CUSTIS.Russia
1 | 30

2. ТРИ ИСТОРИИ МИКРОСЕРВИСОВ
Игорь Беспальчук
Руководитель проектов
CUSTIS Meetup
16 марта 2017 года

3. МОЕ ЗНАКОМСТВО С ТЕМОЙ
| Ноябрь 2012 – первые упоминания:
“Micro Services: Java, the Unix Way”, QCon, Джеймс Льюис
| 2014 – большая статья “Microservices” на сайте Мартина Фаулера
| 2014–2015 – попытки найти живой опыт в российском
корпоративном секторе
| 2016 – «что-то» начало находиться
3 | 30

4. ИНТЕРЕС В СЕТИ
4 | 30

5. КОНФЕРЕНЦИИ И КНИГИ
5 | 30

6. 6 | 30

7. ИСТОРИЯ ПЕРВАЯ
Enterprise и Web как два мира
7 | 30

8. 8 | 30

9. 9 | 30

10. ПУТИ РАЗВИТИЯ
| Enterprise – из классического бизнеса с предоставлением
товаров и услуг через автоматизацию все большего числа
внутренних функций
| Web – из предоставления чисто цифровых услуг
или с существенной долей цифровых услуг
10 | 30

11. ЭВОЛЮЦИОННОЕ ДАВЛЕНИЕ В WEB
| Отсутствие физических ограничений на рост
| Взрывной рост новых видов услуг
| Жесткая конкуренция за неограниченный объем клиентов
| Требования к UI/UX, нагрузке и масштабированию, развиваемости
| Частая смена технологий, не успевает сформироваться устойчивая
инфраструктура и архитектурный стиль (мало: LAMP)
| Волна развития Open Source, не сформирован культ тяжелого вендора
| Результат: некоторые выжили, породив ряд технических
и организационных паттернов, помогающих отработать требования
11 | 30

12. Web-scale
architecture
Micro-
services
CQRS
Event
Driven
Event
Sourcing
Actor
Model
Polyglot
Persistence
NoSQL
Domain
Driven
Design
12 | 30

13. 13 | 30

14. ИСТОРИЯ ВТОРАЯ
Архитектурные стили ПО предприятия
14 | 30

15. РАЗВИТИЕ АРХИТЕКТУРНЫХ СТИЛЕЙ
| От проблемы к проблеме
| Через решение (паттерн)
| От более простого к более сложному
* Сложность никогда не уменьшается, как иногда может
показаться, она «выпадает в осадок» в виде инфраструктуры
15 | 30

16. All-in-one
computer
Хранение Логика UI
Аппаратура
ОС, файлы
16 | 30

17. Client PC
File server Client PC
Хранение Логика UI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Хранение и доступ к данным
17 | 30

18. Client PC
RDBMS Client PC
SQL Логика UI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Схемы данных
Хранение данных Доступ к данным
SP
18 | 30

19. App ServerRDBMS Client PC
Логика
UI
Аппаратура
ОС, файлы
Сетевой доступ
Аппаратура
ОС, файлы
Сетевой доступ
Хранение данных
Схемы данных SP
SQL UI
UI-компоненты
HTML-браузер
Логика
Аппаратура
ОС, файлы
Сетевой доступ
Доступ к данным
Интеграция
19 | 30

20. App ServerRDBMS Client PC
Логика
UI
Хранение данных
SQL
UI-компоненты
HTML-браузер
Логика
Доступ к данным
Интеграция
Web Server
Логика UI
ESB
Сообщения
BPMS
Workflow
Аппаратура + VM
ОС, файлы Сетевой доступ
Маршрутизация
… …
Схемы данных SP
20 | 30

21. ПРИЧИНЫ РАЗДЕЛЕНИЯ ФУНКЦИЙ
| Децентрализация
| Повышение автономности
| Масштабирование по производительности
| Специализация
| Интеграция разделенного
21 | 30

22. Custom App ServiceБД (разные) Client Device
Логика UI
Хранение данных
Схемы данных SP
Composite UI
Логика
Доступ к данным
Интеграция
App Gateway
Представление
Messaging BPMS
Workflow
Аппаратура (+VM)
ОС, файлы, clouds, distributed FS Сетевой доступ
Discovery Monitoring HA Logging Auto scaling …
Common App
Services
Common App
Services
Common App
Services
Маршрутизация
22 | 30

23. Service 3
RDBMS Service 2
Пользователь
Fast DB
Rich
Browser
Service 1
Big DB App Gw 1
App Gw 2
Doc DB
Пользователь
Mobile
DeviceApp Gw 3
Spec DB
23 | 30

24. РЕЗЮМЕ О СТИЛЯХ
| MSA – очередной шаг в развитии архитектурных стилей
сложных программных систем предприятия
| MSA продолжает общее движение в сторону специализации,
грануляризации и выделения общих инфраструктур
| Как и все предыдущие шаги, MSA решает часть проблем, которые
возникают (обычно) в предшествующих стилях, и порождает ряд новых
* Появляющиеся новые инфраструктуры могут подталкивать
к переходу к новым архитектурным стилям,
даже если реальной потребности еще не возникло
24 | 30

25. ИСТОРИЯ ТРЕТЬЯ
Роль и специализации архитектора
25 | 30

26. SW
Dev
Arch
Mgr
А
26 | 30

27. Информационная архитектураИнтеграция приложений
Инфраструктура (техническая архитектура)
27 | 30

28. Информационная архитектура
Решение
Архитектура сервиса
Инфраструктура
Технологический каркас
28 | 30

29. ТРИ ИСТОРИИ РАЗВИТИЯ
| Рыночных потребностей в мирах Web и Enterprise
| Архитектурных стилей программных систем предприятия
| Специализаций роли архитектора
…подводящие к появлению микросервисной архитектуры?
29 | 30

30. СПАСИБО ЗА ВНИМАНИЕ!
Игорь Беспальчук
Руководитель проектов
www.facebook.com/CUSTIS.Russia
ibespalchuk@custis.ru