Архитектура микросервисов: что можно, а что нельзя включать в них
Достаточно долгое время самым популярным стилем сборки приложений был «монолит», при котором все включенные в процесс элементы неразделимы, а в итоге составляют одно общее целое. Но технологии развиваются: появляются «облака», увеличивается количество требуемых обновлений, убыстряется скорость жизни, выхода новых девайсов. В этом случае сложно внести даже самые небольшие изменения, поскольку необходимо пересобирать весь монолит. При каждом его развертывании теряется сохранность структуры, а также появляются непредвиденные ошибки. Эта ситуация приводит к спаду популярности монолитных серверов, а также появлению альтернатив.
Одной из популярных и стали микросервисы, чья архитектура полностью противопоставлена монолитным серверам. При этом подходе приложения представляют из себя набор небольших сервисов, каждый из которых работает по собственным установкам, несомненно находясь в коммуникации с остальными механизмами. Однако эти сервисы могут быть созданы с использованием разных языков и технологий хранения данных, что позволяет процессам развертывания и масштабирования стать более независимыми.
Наличие четкой границы каждого объекта — это главный плюс архитектуры микросервисов. Более того, разделение делается в соответствии с потребностями современного бизнеса и его структуризацией. Если ранее чаще встречалось строгое деление в связи с рабочими задачами, где одним сотрудникам отдавался в полное ведение UX или UI, другим — администрирование баз данных, третьим — проджект-менеджмент, то сейчас рабочие группы реже формируются согласно этим канонам. Все чаще можно встретить специалистов с «T-shaped экспертизой», работающих в связке с такими же джунами, синьорами или миддлами. Самый простой пример для объяснения новых законов работы: прежде за барной стойкой могли налить исключительно односолодовый виски, ром или водку, а сейчас каждый может собрать коктейль на свой вкус, опираясь на базовые виды алкогольных напитков.
Почему такой подход допустим в микросервисах? Во-первых, это помогает команде увидеть продукт в процессе его жизнедеятельности и предотвращать ошибки еще на первых этапах его создания. Мы подбираем компоненты систем вместе с заказчиком, и детализация процесса только упрощает задачу. Прежде дизайнер отправлял макет менеджеру и приступал к следующей задаче, сейчас же ему будет доступна аналитика: удобен ли макет для пользователя, сочетается ли с обновлениями, отвечает ли запросам.
Одновременно с этим, микросервисами занимаются разные команды с разными предпочтениями в работе и ведении процессов. Далеко не всегда имеет значение способ, используемый для решения задачи, если получается правильный ответ в конце. Потому команды создают индивидуальные полезные инструменты, и им нужно позволить работать с ними, а не с привычными стандартами. То же касается и использования единого языка. Как мы уже писали выше, архитектура микросервисов может сочетать в себе несколько разных языков, в отличие от «монолита».
Команда xdol следит за новинками рынка и IT-сферы, реагируя на все нововведения и изменения. Изучению трендов и собственному развитию мы уделяем не менее 10% рабочего времени. Архитектура микросервисов — это новинка, способная улучшить бизнес. И ее мы поможем внедрить в ваши процессы без сложностей и долгих сроков.