Как и многие другие, раньше я думал, что микросервисную архитектуру применяют только гики из инновационных калифорнийских компаний, таких как Netflix, Uber, Spotify, PayPal и Twitter. Однако, недавно я осознал, что это путь, по которому рано или поздно пойдут все организации, которые развиваются в канве цифровой трансформации.
На анимированной картинке показано как Netflix мониторит свои 500 серверов в реальном времени. Белые точки это запросы. Слева изображен балансировщик нагрузки, справа базы данных, а наиболее плотные потоки запросов посередине — это API.
Предыстория
Каждый раз когда появляется новая технология возникает ощущение, что теперь придется все изучать с самого начала. Обычно это не так. Например, когда появились мобильные приложения, почти все технологии которые мы знали раньше, остались без изменений.
Нам пришлось разбираться только с новой клиентской частью, в связи с появлением новых операционных систем и языков программирования. А когда возник Интернет Вещей, помимо железа и встроенного кода, несколько изменилась еще и серверная часть — появились новые протоколы и новые способы обработки больших объемов данных в реальном времени. Но вот когда дело дошло до построения микросервисной архитектуры, реально серьезные изменения возникли сразу на многих уровнях, причем не только на технологических.
Переход на микросервисы
Начиная переход к микросервисам, первая минимальная вещь, с которой придется столкнуться это разделение старого монолитного кода на небольшие сервисы и размещение их в уже известную нам архитектуру (например, SOA). Это не особо сложно.
Сложности начинаются при настройке балансировки нагрузки, восстановления и автоматического масштабирования этих сервисов на уровне контейнеров, представляющих собой подуровни операционной системы. Тут требуются новые подходы для автоматического обнаружения сервисов, управления версиями и множества аспектов безопасности, например аутентификации.
Данные в микросервисах
После того как вы разберетесь со всем этим, придет осознание того, что следующее препятствие на пути масшабируемости это монолитная, по своей сути, реляционная база данных. Не смотря на её фантастическую способность адаптироваться под любые новые требования, связанные с созданием запросов, во многих случаях она больше не применима (лично я, как представитель олдскула, очень расстроен по этому поводу).
Каждому сервису требуется доступ к определенным данным и, чтобы обеспечить их актуальность, нужно подключить каждый сервис к центральному потоку данных, через который проходят все изменения. Если говорить конкретнее, то у Microsoft эта задача решается при совместном использовании продуктов Azure Service Fabric, DocumentDB и Event Hub, а у IBM — это, в основном, Containers, Cloudant, and MQLight в BlueMix.
Использование DevOps инструментов в Перфоманс Лаб
Мы, в Перфоманс Лаб, в рамках практики DevOps, применяем инструменты с открытым кодом — Docker/Swarm, DynamoDB и Apache Kafka. Интересный момент — нет каких то ограничений на использование языков программирования.
Вы можете использовать разные языки для написания разных сервисов, правда это может привести уже к организационным сложностям, связанным с переиспользованием кода и ненужным фрагментированием команды. Если хотите разобраться в предмете получше и умеете читать по-английски, я рекомендую бесплатную книгу Microservice Architecture.
Заключение
Помимо изменений в технологиях, и это более важно, меняется подход к работе людей. На смену крупным подразделениям эксплуатации, разработки и тестирования придут небольшие автономные команды, каждая из которых заинтересована в быстром выпуске продукта, от идеи до предоставления пользователям, с обеспечением высокого уровня качества.
Думали ли вы уже об этом раньше, или прочли впервые — я желаю всем начать экспериментировать с этим подходом, технологией и способом организации труда.
