Идея микросервиса заключается в том, чтобы строить приложение как набор небольших сервисов с выделенной функциональностью, каждый из которых работает в собственном процессе. Такой подход имеет ряд преимуществ, но не это тема сегодняшнего рассказа, а то, как идея микросервисной архитектуры выглядит с точки зрения российского корпоративного бизнеса и управленцев IT на предприятиях.
Вместе с Игорем Беспальчуком постараемся посмотреть на этот тренд с трех разных ракурсов, что очень полезно для понимания природы того, с чем мы имеем дело, и, как следствие, для того, чтобы сделать правильные выводы и принять правильное решение.
Микросервисы — одна из самых важных и значимых составляющих Web-scale архитектуры, имеющая наибольшие последствия для переделки устройства техник и паттернов в Enterprise. Трудно сейчас сказать, на каком участке сейчас находится сама технология — может быть, на самом верхнем пике, и нам предстоит еще десять раз разочароваться. Но, тем не менее, это не повод не изучать её прямо сейчас.
О спикере: Игорь Беспальчук — архитектор приложений в группе компаний CUSTIS, которая разрабатывает заказной софт для крупного корпоратива и государственных структур. До этого Игорь тоже работал с корпоративными компаниями и ритейлом, так что имел возможность наблюдать, как происходят процессы развития в корпоративном секторе и как устроена система управления, а также, как те или иные изменения постепенно просачиваются туда.
Далее — расшифровка доклада Игоря на Web-Scale IT Conference 2017.
Мое знакомство с темой MSA
Я впервые столкнулся с микросервисной архитектурой в ноябре 2012 года, когда мне попалась замечательная презентация Джеймса Льюиса с QCon «Services: Java, the Unix Way». Он рассказывал о том, как они работали над большим, сложным, нагруженным проектом с огромным объемом данных: распилили на отдельные функциональные элементы, и решили их реализовывать как отдельные сервисы. Это было так удивительно и необычно, в том числе и для нашей практики архитектурного проектирования, что прямо будоражило воображение. И в то же время это сильно пересекалось с концепциями Domain Driven Design (DDD), которые мы много лет достаточно глубоко использовали в нашей практике, но в монолитных системах.
А в 2014 году на сайте Мартина Фаулера появилась большая статья «Microservices», где он прояснял, что такое микросервисы и зачем они нужны, статья переведена на русский.
Говоря в двух словах, раньше мы разнородную функциональность делали вместе, была одна система или приложение, и оно исполнялась как единый процесс. Если же нужно было масштабировать систему, это делалось путем горизонтального масштабирования, но однородно по всей функциональности.
Если супер-коротко, то центральная идея микросервисов заключается в том, что мы начинаем класть в отдельный процесс отдельный вид функциональности — Bounded Context, как это называется в DDD. Если нужно, мы можем масштабировать эти куски независимо, потому что они обособлены в отдельный процесс. Можно запустить 5, 10 или 20 — столько, сколько нужно, каталогов товаров, блоков авторизации пользователей или чего-то еще.
Получаются очень маленькие, по сравнению с тем, как это раньше проектировалось, сервисы.
Такой подход имеет ряд преимуществ, о которых мы поговорим чуть позже, но вообще это не тема сегодняшнего рассказа.
В 2014–2015 годах я решил поискать, есть ли в российском корпоративном секторе живой опыт применения такого рода архитектур. Тогда среди моих знакомых и коллег ничего не находилось — было интересно поболтать теоретически, но практики не было ни у кого.
В 2016 году «что-то» начало находиться. В некоторых банках можно было услышать, что «мы пробуем применять микросервисную архитектуру, у нас Docker и прочее». Было интересно, что же из этого получится.
В 2017 мы в CUSTIS решили провести митап «Микросервисы для Enterprise». Это было полузакрытое мероприятие, в основном позвали знакомых архитекторов из Enterprise.
На этом митапе обнаружилось, что по-прежнему есть очень много непонимания, особенно со стороны IT-управленцев. Они не понимают, зачем это вообще нужно. Им кажется, что это какая-то «очередная выдумка программистов», от которой только лишние хлопоты. Поэтому я еще раз попытался взглянуть на это явление с точки зрения, которая, может быть, будет более понятна не технарям, а людям в позиции IT-директора или директора по разработке. Ну, а если вы — технический специалист, возможно, этот рассказ поможет вам объяснить руководству смысл и пользу микросервисного подхода.
Интерес в сети
Можно долго не останавливаться на том, что интерес в сети к теме микросервисов за последние годы здорово возрос.
С 2014 года проходят уже несколько международных конференций конкретно по микросервисам.
Выходит огромное количество литературы на эту тему.
Информации просто кладезь, но, тем не менее, в российском корпоративе, если смотреть в общей массе, об этом только-только начинают говорить. Конечно, все неоднородно — где-то практика применения больше, где-то меньше, где-то совсем еще ни сном, ни духом.
Поэтому я пытаюсь восполнить этот пробел.
Мой рассказ будет построен как три разные истории развития. Мы вместе постараемся посмотреть на этот тренд с трех разных ракурсов. Мне кажется, это очень полезно для понимания природы того, с чем мы имеем дело, и, как следствие, для того, чтобы сделать правильные выводы и принимать правильные решения в отношении тренда микросервисов.
История первая. Enterprise и Web как два мира
В первой истории мы пойдем снаружи внутрь, как положено в системной инженерии, и будем говорить про рынок и про потребность — про Enterprise и Web как два мира.
В 2014 году Gartner выпустил аналитический отчет, в котором говорилось, что к 2017 году 50% главных компаний обязательно должны использовать Web-scale архитектуру, но было вообще не очень понятно, что это такое. Когда мы решили устроить Web-scale IT Conference, то пытались определить, что такое Web-scale технологии, что такое Enterprise и как-то увидеть разницу.
Пути развития
Тогда для себя я нарисовал примерно такую картину. Условный «Web» и условный «Enterprise» — это две большие отрасли, или два больших сегмента отрасли, с точки зрения IT сегодня выглядят сильно по-разному из-за того, что у них были существенно разные пути развития:
- Enterprise-компании развивались из классического бизнеса, в котором предоставляются в основном материальные товары и услуги, а IT существует, как средство автоматизации этого бизнеса.
- В Web с самого начала и товар, и услуга зачастую имели цифровую форму, или, как в случае с Amazon, очень существенная доля в самой услуге носит цифровую форму.
Изначально эти два мира были почти полностью разделены. Интернет появлялся, как что-то обособленное, и в течении 10-20 лет испытывал колоссальное эволюционное давление на этом своем островке.
Эволюционное давление в Web
- Отсутствие физических ограничений на рост
Вам не нужно покупать недвижимость, чтобы открыть новый магазин.
- Взрывной рост новых видов услуг, в том числе цифровых.
Обнаружилось, что в этом дивном новом мире интернета можно торговать картинками и вообще бог знает чем, видов новых услуг оказалась очень много. Это привело к взрывному росту и к жесткой конкуренции.
- Жесткая конкуренция за неограниченный объем клиентов, который охватывает весь мир, независимо от территориального положения.
Причем это борьба не с конкурентами с соседней улицы, а вообще со всеми, кто представлен в интернет-пространстве, поэтому надо повышать качество своих сервисов, в том числе пользовательских интерфейсов.
- Требования к UI/UX, нагрузке и масштабированию, развиваемости.
Тут и появилась специализация user experience. Раньше ничего подобного не было. В корпоративном софте юзабилити пользовательских интерфейсов оставляло желать лучшего, да и сейчас оставляет желать — особенно для наемных работников. Также увеличились требования к нагрузке, масштабированию и развиваемости. Если вы не поспеваете за бегом технологий, вы погибаете.
- Частая смена технологий, поэтому устойчивая однородная инфраструктура и архитектурный стиль не успевает сформироваться.
В этом мире все растет, как грибы после дождя, и в интернет-компаниях не успевает формироваться устойчивая однородная инфраструктура и некоторый архитектурный стиль — так, как это было в Enterprise. Здесь к этому моменту были уже некоторые крупные паттерны — архитектурные стили, во многом поддержанные вендорскими разработками: у нас от этого вендора база данных, а от этого — серверная стойка, и это не меняется десятилетиями.
- Волна развития Open Source, не сформирован культ тяжелого вендора.
В интернет мире все кипело, но культуры вендора не образовывалось. Все можно было построить почти с нуля.
- Результат: некоторые выжили, породив ряд технических и организационных паттернов, отвечающих на эти требования.
Как результат любого эволюционного процесса, закончилось все тем, что некоторые выжили. Причем выжили именно за счет того, что смогли породить специфические организационные, управленческие и технические практики, которые отвечают на эти жесточайшие требования.
Столкновение материков рынков
С чем же связаны интересы и опасения классического бизнеса, которые, похоже, оправданы? Мне нравится метафора двух столкнувшихся материков.
Был материк Enterprise — рынок классических услуг с автоматизацией, со своей неспешной эволюцией. И вдруг обнаруживается, что на столкновение идет другой материк — другой мир, в котором тоже идет эволюционный процесс, свой и в своем темпе. И может оказаться, что для нас, обитателей привычного Enterprise-мирка, результаты этого эволюционного процесса будут не очень дружелюбны — как на картинке.
Мы уже видим, как Google занимается автомобилями, Airbnb — отелями, Amazon — offline-магазинами и т.д.
Таким образом, оказывается, что если мы, как IT-отделы корпораций или как подрядчики мира Enterprise, сейчас никак не будем на эти факторы обращать внимание, то можем очень сильно потом пожалеть.
Разбирая техническую сторону того, как же работают интернет-гиганты, называют очень много разных паттернов и механизмов, входящих в Web-scale архитектуру.
На мой взгляд, микросервисы здесь одна из самых важных, сложных, и значимых составляющих, имеющая наибольшие последствия для переделки устройства техник и паттернов в Enterprise.
Резюме первой истории
Конечно, как любое новшество, тема микросервисов не может избежать своего периода хайпа. Есть компании, которые с радостью прибегут и внедрят за денежку — так все закручивается, и возникают завышенные ожидания.
Трудно сейчас сказать, на каком участке сейчас находится сама технология — может быть, на самом верхнем пике ожиданий, и нам предстоит еще десять раз в ней разочароваться. Но, тем не менее, это не повод не изучать её прямо сейчас.
Резюмируя первую историю про рынки и потребности:
- MSA — один из технических паттернов, появившийся в процессе жесткого конкурентного развития в «параллельном мире» Web-технологий.
- Во многом в этом «параллельном мире» выжили те, кто научился обеспечивать:
- удержание онлайн-клиента высоким качеством сервиса;
- высокие нагрузки и объемы данных, совершенно не характерные для Enterprise;
- быструю изменчивость к технологиям, независимость от вендоров.
Это и есть те преимущества, которые микросервисная архитектура потенциально может принести в Enterprise. Если в какой-то области вашего бизнеса вы намерены или думаете, что придется, конкурировать с интернет-компаниями, то очень может быть, что надо заимствовать их технологии и именно в этих областях пробовать применять самим, растить компетенции и ставить такого же рода задачи — повышать нагрузки и изменчивость. Иначе потом просто съедят.
3. Они уже здесь.
Если вы сами из мира Enterprise, то видите, насколько здесь все живо, динамично и не похоже на то, с чем мы имеем дело в классическом предприятии.
История вторая. Архитектурные стили ПО предприятия
Мы снова идем снаружи — внутрь: от рынка, то есть от окружения отдельного предприятия переходим к устройству техники на этом отдельном предприятии. Поговорим о том, как менялись архитектурные стили ПО предприятия, как вообще строилось IT на предприятии.
Развитие архитектурных стилей
Как любые системы и паттерны, развитие IT на предприятии идет от проблемы к проблеме. Мы решаем одну проблему за счет некоего паттерна и зачастую приносим какие-то другие проблемы, это неизбежный путь. При этом мы всегда переходим от более простого к более сложному, это общие законы развития.
В свое время, мы с коллегами обсуждали — как же так, мы же все время хотим сделать, чтобы людям было проще. Почему наоборот все усложняется и усложняется?
Родилось понимание того, что сложность систем, в том числе технических, никогда не уменьшается, как иногда может показаться — она «выпадает в осадок» в виде инфраструктуры.
То есть то, за что раньше приходилось бороться большим количеством трудо-часов, в какой-то момент мы просто начинаем получать, как инфраструктуру, иногда индифферентную к нашим прикладным задачам. Этот «осадок» все время увеличивается, но и сложность систем только растет со временем.
Давным-давно (наверняка вы, как и я, не застали эти времена) все IT на предприятиях делалось на одном большом компьютере. Из инфраструктуры там была только аппаратура, операционная система и файлы. Все остальное, что нужно для расчетов (хранение данных, логика вычислений, интерфейс командной строки и т.д.), нашим предшественникам приходилось писать руками.
Время шло, менялись возможности IT, и вот уже на каждом столе стоит персональный компьютер, общие данные как-то связываются в сеть и хранятся на общем файловом сервере. В инфраструктуре появляется больше возможностей: мы уже не придумываем сами, как обращаться по сети, есть средства для работы с файлами на файловом сервере, первые базы данных и прочее.
Но конечно, мы все равно пишем более сложные задачи руками: надо хранить что-то в базе данных; по-прежнему надо обсчитывать бизнес логику; делать уже более сложный графический интерфейс и прочее.
Следующий шаг — реляционные базы данных. Был длительный период времени, когда IT на предприятиях строилось по клиент-серверной архитектуре, как архитектурному стилю. Это было поддержано всеми вендорами: вот база данных, вот быстрое средство разработки.
Здесь часть сложности того, что мы на предыдущем шаге писали руками, «выпадает в некоторый осадок», в инфраструктуру. Её мы получаем из коробки, но работы всегда хватает. Мы пишем схемы данных все более сложной структуры, языки запросов все более абстрактны, появился SQL. Мы разрабатываем бизнес-логику, пользовательские интерфейсы и т.д.
Еще через какое-то время трехзвенная архитектура захватила умы и интересы разработчиков корпоративного софта. Для отображения, например, есть чуть больше заготовок в форме браузера и библиотеки компонентов. Тем не менее, все равно остается много ручного труда, возникает огромное количество интеграционных задач. Сервер приложений во многом занимается интеграцией, зато он легче масштабируется.
Этот процесс продолжается — сервисно-ориентированная архитектура. Корпоративный IT, в какой-то момент начинает выходить в Web, пусть даже в B2B системы, появляются специализированные Web-серверы и корпоративные шины, чтобы интегрировать множество решений между собой, системы для оркестрации сложных процессов взаимодействия между всеми этими системами. И каждый раз история повторяется — что-то мы получаем из коробки, но по-прежнему многое дописываем руками.
Разделение функций
После такой ретроспективы можно заметить, что каждый раз у нас встают все более и более амбициозные задачи, нарастает их сложность и нефункциональные требования. В результате IT-системы начинают гранулироваться:
- Децентрализация становится выгодной.
- Повышение автономности отдельных функций. Если один клиентский компьютер упал, база данных остается в порядке.
- Масштабирование по производительности. Уже никого не устраивают неэластичные системы, которые нельзя легко масштабировать.
- Специализация вычислительных функций.
- Интеграция разделенного. Возникает отдельная специализация по интеграции всех многочисленным образом разрезанных кусочков.
Нетрудно предположить, что этот процесс не остановится вдруг на трехзвенных и сервисно-ориентированных архитектурах. Моя гипотеза, что он продолжается как раз в микросервисную архитектуру.
Что мы имеем на сегодняшний момент?
- Клиенты, за которых мы боремся, и сотрудники с повышенными требованиями к юзабилити, приходят с разными устройствами (браузерами, мобильными устройствами и т.д.)
- Прикладные сервисы, в которых мы реализуем бизнес-задачи, по-прежнему остаются.
- Базы данных специализируются и разделяются. Нас уже не устраивает одна универсальная база данных, которая все делает плохо. Нам, как минимум, хочется, чтобы одна была очень быстрая, а другая — очень большая.
- Появляются специализированные узлы для того, чтобы адаптировать приложение под разные платформы (Application-level gateway).
- Наработки, связанные с оркестрацией и обменом сообщениями, по-прежнему необходимы.
Разнообразие сервисов, входящих даже в одно приложение, поражает воображение и даже пугает.
Общие сервисы, которые нужны разным приложениям, сейчас уже предоставляются из облака, например, там вы можете найти формочки авторизации. Это немножко взрывает , но идет в канве тех же самых принципов развития — выделяется, специализируется и относится в некоторую инфраструктуру.
Огромное количество возможностей, которые раньше приходилось делать руками для каждой ответственной системы, теперь все чаще хочется делать универсально для любых сервисов. Опять-таки очень хочется, чтобы это все предоставлялось «из коробки» — все, что касается автоматического масштабирования, мониторинга систем, высокой доступности, журналирования, которое уже надо делать централизованным, потому что иначе невозможно по десяткам и сотням машин лазить, чтобы понять, что произошло.
То есть одновременно происходит огромный запрос на инфраструктуру, и потихонечку, с запаздыванием, подтягивается рынок вендоров, предоставляющих ее.
На самом деле, удивительно, насколько много возникает инфраструктурных задач. Это действительно огромный объем работы, например, Авито рассказывает, что сделать систему мониторинга для микросервисов — это 1 человеко-год работы.
Думаю, что лет через пять мы все-таки увидим хорошие инфраструктуры для поддержки микросервисов из коробки от разных производителей. Но пока это все еще достаточно сыро. Хотя и без этого дальше никуда — инфраструктура становится все толще, сервисы и функции все гранулярнее.
Происходит интересный момент. Когда теперь пользователи приходят к вам и начинают взаимодействовать с тем или иным устройством, даже трудно сказать, что такое «приложение». Раньше были разные приложения на предприятии, и их границы были четко понятны.
Сейчас пользователь заходит с одного устройства, а потом — с другого — это то же самое приложение или нет? Мы смотрим вглубь — там какие-то App Gw, которые в свою очередь взаимодействуют с разными сервисами. Где тут приложение? Есть ощущение, что через какое-то время понятие приложения может очень сильно размыться.
Может быть, только границы бизнес-функций будут как-то сдерживать это смешение. И то, при наличии большого числа инфраструктурных сервисов их глупо плодить. Все, что в ваших системах будет не привязано жестко к бизнес-функциям, судя по всему, будет делаться в общей инфраструктуре предприятия. Но сейчас это не так, и в ближайшие 5-10 лет еще будет не так, наверное.
Очень интересный момент в этом всем процессе — а нужно ли вам, конкретному среднему или даже большому предприятию, вообще это все — микросервисы и сопутствующее усложнение? Может быть, можно переждать и не ходить в эту гору?
Проблема общей лодки
Думаю, к счастью или к сожалению, но выпрыгнуть из этого процесса не получится. Это тренд, который сильнее нас, и несет всех. У нас остается выбор — либо попытаться переждать в стороне, либо все-таки встроиться.
Беда в том, что появляющиеся новые инфраструктурные стили в масштабах предприятия начинают вас толкать к новым архитектурам, даже если конкретно на вашем предприятии потребности в этом сегодня нет. Например, вам не нужны супер масштабируемые системы и big data, у вас относительно небольшой бизнес, который прекрасно работает. С этим, возможно, на деле спокойно справляется двухзвенное приложение на Delphi.
Но важно то, что весь фокус внимания вендоров и исследователей, которые развивают технологии, направлен сейчас сюда — на это острие. Вроде бы это вас напрямую не касается, но выясняется, что вся индустрия разворачивается сюда.
Вектор устремления ваших работников тоже направлен в эту сторону, потому что это модно, это хайп, это книжки, конференции и все-все остальное. Если вы не будете пытаться как-то в это движение встраиваться, через некоторое время вы осознаете, что вам придется работать с очень специфическими кадрами, которых новое вообще не волнует. Я не говорю, что это плохие работники. Но часть очень хороших людей будет у вас вымываться, если вы не будете хоть в какой-то степени соответствовать тренду.
Поэтому я считаю, что раньше или позже вливаться придется, даже если очень не хочется, поэтому лучше сделать это управляемо в рамках вашего предприятия. То есть возглавить, если уж невозможно бороться.
Резюме второй истории
Подводя резюме истории про эволюцию архитектурных стилей на предприятии, мы можем зафиксировать следующее:
- MSA — очередной шаг в развитии архитектурных стилей сложных программных систем предприятия.
- MSA продолжает ту логику, которая была и раньше — общее движение в сторону специализации, грануляризации и выделения общих инфраструктур.
- Как и все предыдущие шаги, MSA решает часть проблем, которые возникают в предшествующих стилях, и порождает ряд новых. С этим ничего невозможно сделать и придется с этим жить — осваивать и в очередной раз через них проходить.
- Бесплатных завтраков, конечно, не бывает!
История третья. Роль и специализации архитектора
И мы идем еще дальше вглубь. Мы поговорили про рынки и про то, почему стоит об этом подумать, и как это вписывается в общий тренд Web-scale. Теперь я хочу поговорить про то, как будут меняться сами роли архитекторов и их специализации в связи с трендом микросервисной архитектуры.
Давным-давно разработкой софта занималась команда разработчиков и максимум один менеджер-руководитель, который управлял и работами, и ресурсами. Если же система была большой, то вдруг выяснялось, что если не заботиться об архитектуре (раньше и слова такого не было в отношении софта), и не управлять ей, то она вырастет «как-то сама», и потом, закостенев, начнет управлять вашим проектом вместо вас.
Стало понятно, что позиция архитектора все-таки нужна, повторюсь — на относительно больших системах.
В рамках крупного предприятия все еще немного сложнее.
Сначала обходились какими-то отдельными независимыми самописными системами. Потом вдруг выяснилось, что таких систем много, зачастую они поставляются вендорами уже готовыми, и их нужно интегрировать между собой. Здесь профессия именно софтверного архитектора уже не очень нужна, а нужна такая специфическая позиция человека, который бы внедрил следующую систему, доделал бы к ней что-то небольшое и завязал бы все это между собой. Появляется позиция интеграционного архитектора (специалиста по интеграционным решениям) и возникает понятие solution.
Это интересная специализация, когда архитектором решений может быть человек, выросший из аналитиков, и не знающий, как программируется отдельный софт, но выполняющий большую, сложную и полезную работу.
Очень интересно, как в этот период, до микросервисов, обычно проводится работа с инфраструктурой на предприятии. Она почти полностью отгорожена заборчиком, отдельные люди совершенно в своем темпе, в своем жизненном цикле изменений обеспечивают единообразную, стандартную и очень стабильную инфраструктуру для всех приложений предприятия:
— Вот вам база данных Oracle, вот виртуальные машины — работайте, а мы все это поддерживаем в порядке, в жестких стандартах.
Это философия IT-служб на крупных предприятиях — у них уже много лет все направлено на повышение эффективности работы, а потому все стандартизовано — заказать что-то необычное просто невозможно.
Это же и некоторая система управления — мы отдельно управляем приложениями и отдельно — инфраструктурой, и на каждую часть есть отдельные начальники.
В этой картине, которая достаточно долго держалась на предприятиях, возникают неприятные моменты:
Первое. Очень трудно приносить новые технологии, потому что в инфраструктурном блоке работают, пытаясь снизить затраты и сделать все стандартным.
И второе. Вендору выгоднее принести вам как можно более крупный продукт, в котором есть «все, что нужно для вашего бизнеса». И тогда функциональной архитектурой приложений на вашем предприятии в конечном счете начинают управлять несколько крупных вендоров, а не вы сами.
В функциях вашего приложения будет то, что придумали вендоры. Или вам нужно тратить большое количество сил, времени и драгоценного управленческого ресурса на то, чтобы отстроить собственное IT.
Складывается очень неприятный для некоторых игроков рынка паритет. Если вы — бизнес второго эшелона, вас это может устраивать. Если же вы пытаетесь работать на лидерских позициях, вам нужно конкурировать, чему весьма мешает тот факт, что любые изменения шаблонов — это страшная боль.
Если тренд микросервисов действительно разовьется так, как можно предположить, мы увидим, что большие продукты поделятся на довольно большое число отдельных сервисов, управляемых квазинезависимо, примерно, как на следующей картинке.
Конечно, останется понятие решения, которое описывает целостную сборку нескольких сервисов, направленных на решение одной задачи.
Позиция интеграционного архитектора, конечно, останется, но, может быть, больше сместится в сторону именно технической архитектуры. Если сейчас зачастую интеграционный архитектор занимается еще и информационной архитектурой на предприятии, разбирается с тем, какие данные куда ходят, то в дальнейшем, скорее всего, эти функции разделятся, потому что объем работы увеличится — чем больше микросервисов, тем больше работы по интеграции.
Конечно, останется и позиция архитектора отдельного сервиса. Она никуда не денется — и со стороны вендоров, и со стороны предприятия. Причем, на мой взгляд, спрос на нее, с одной стороны усилится, потому что «кубиков» становится все больше, а с другой стороны, обеспечить эту позицию станет чуть-чуть проще, так как «кубики» становятся мельче.
Раньше, чтобы сделать архитектуру крупной монолитной ERP системы нужен был человек с просто колоссальным опытом. В ситуации, когда сервисы более друг от друга изолированы, а микросервисная архитектура хорошо очерчивает их границы и прописывает контракты, эта позиция станет легче обеспечиваться. Люди с меньшей квалификацией смогут пополнить эту потребность. На мой взгляд, это здорово.
Сильные изменения произойдут в управлении инфраструктурой, в том, для чего сейчас часто можно услышать термин DevOps. Многие говорят, что это соединение программистов с администраторами. Мне кажется, это не схватывает сути. На самом деле, изменилось сама задача: у вас уже не просто кто-то один предоставляет всю инфраструктуру, и она работает стабильно и одинаково. Для каждого такого решения, для каждого сервиса сейчас уже требуется что-то свое — свои базы данных, отличающиеся средства мониторинга, и так далее. Огромная потребность в инфраструктуре, которая не идет из коробки, а ее надо собирать руками и часто — другую, новую, отличающуюся.
То есть в принципе характер этой работы и характер управления людьми меняется. Вы уже не можете этим управлять по ITSM. Вам нужно управлять этим зачастую в проектной форме, потому что проект включает в себя огромный кусок совершенно уникальной инфраструктуры под конкретное решение.
Поэтому появляется DevOps как разработчик инфраструктуры, и рядом может появиться инфраструктурный архитектор.
Интересно, что в последнее время я иногда вижу, что архитектором еще называют человека, которого в этой ситуации кипящего разнообразия технологий зовут и говорят:
— Завяжи нам, пожалуйста, все это вместе, чтобы оно «просто начало работать». А дальше наши прикладники уже разберутся.
То есть это даже не совсем архитектор софта в полном смысле. Это специалист по технологическому каркасу, можно сказать, технолог. Его задача — разобраться и заставить работать большое разнообразие сырых опенсорсных технологий. Судя по всему, такая специализация тоже выделяется сейчас, может быть, не в форме штатного сотрудника, а человека, который пришел, помог, завел и дальше консультирует.
Выводы
Подведу коротко итог всему докладу. Я постарался дать представление о том, как тренд MSA выглядит при взгляде «из мира Enterprise» с трех сторон и в историческом разрезе из прошлого в будущее, с точки зрения:
- рыночных потребностей в мирах Web и Enterprise, откуда все это берется и чем нам грозит, если мы не будем это осваивать;
- архитектурных стилей программных систем предприятия — и почему вам, скорее всего, выпрыгнуть из этой лодки не удастся;
- специализаций роли архитектора, которые тоже интенсивно меняются и делятся.
Мне кажется, такое, объемное видение поможет ИТ-директорам лучше спозиционироваться в тренде MSA и понимать, что с ним делать конкретной компании — отгораживаться или, наоборот, встраиваться.
Новости
Фестиваль конференций Российские-интернет технологии уже не за горами, в этом году мы решили распределить доклады конференции на стыке enterprise и web-технологий Web-Scale IT по другим конференциям — технические доклады пойдут в Backend Conf РИТ++, управленческие в Whale Rider. На настоящий момент есть несколько интересных заявок, например:
- Готовность организации к изменениям или куда приводят мечты / Денис Кочергин (Ярмарка Мастеров)
- Как большая IT команда может меняться сразу по всем фронтам и при этом не умереть? / Александр Андронов (Додо Пицца)
- Кто живет на облаках или что такое cloud-native infrastructure / Антон Вайс (Отомато)
- Собственное облако, доступное каждому: цикл жизни типового микросервиса и его зависимостей в kubernetes / Максим Вихарев (Alytics)
Статусы докладов будут актуализироваться в течение апреля, но мы обещаем отобрать самые классные, поэтому ждать совсем не обязательно — можно уже бронировать билеты.
Автор: mi5ha6in
