Большой инфраструктурный переход

С начала 2000-х гг. многие наши заказчики заметно продвинулись по шкале вправо. Процесс назывался по-разному: автоматизация, информатизация, цифровая трансформация (согласитесь, тяжело просить денег на одно и то же 20 лет подряд), — но в результате роль ИТ в бизнесе этих компаний неуклонно росла. Пандемия 2020 г. ускорила процесс: во время локдауна цифровые сервисы приняли на себя роль основных генераторов денежных потоков в условиях кардинально изменившегося поведения клиентов, а сотрудники перешли на удаленную модель работы, что поставило точку в вопросе значимости ИТ для бизнеса.

У этого процесса есть очевидные последствия: чем дальше по шкале продвигается организация, тем более «бизнесовые» требования начинают предъявляться к ИТ-службе. Если раньше требовалось лишь приемлемое качество внутренних услуг по минимальной цене, то теперь на ИТ сыплются новые вызовы: внезапно становятся актуальными скорость адаптации к внешним условиям и быстрая реакция на изменения спроса. К сервисному подразделению подобные требования предъявлялись редко.

Классическая ИТ-служба (когда она была просто бэк-офисом), как правило, использовала коробочные продукты. Нужны ERP-система, интернет-банкинг или интернет-магазин? Проводим конкурс на выбор соответствующей «коробки» у вендора/интегратора, который слегка доведет ее до ума! Но при таком подходе ИТ-системы оказывались жестко завязанными на релизные циклы и дорожные карты вендоров. Насколько скорость и направление разработки такого продукта будут соответствовать новым требованиям к скорости изменений? Чем ближе компания к правой части шкалы, тем меньше это соответствие.

Разумеется, произошло неизбежное: бизнес начал самостоятельно разрабатывать программные продукты, чтобы успевать за потребностями — сегодня в основном в части сервисов, с которыми непосредственно взаимодействуют клиенты, но первые проекты по созданию постмодерновых учетных систем (ERP, CRM, HR и т.п.) уже не за горами. Однако большинство организаций не владели соответствующей экспертизой. Откуда у ресурсодобывающего предприятия, ритейлера или логистической компании навыки разработки, тестирования и обкатки ИТ-продуктов? Вакуум экспертизы корпоративный сектор заполнил знаниями ИТ-гигантов из правой части шкалы. Организации начали перенимать Agile-практики, подходы и стек технологий, которые формируют то, что мы называем Инфраструктурой 3.0. Это сплав двух разных миров, новая ветвь эволюции, сформированная технологиями интернет-гигантов, попавших в параллельную реальность корпоративного окружения с его жесткими требованиями, ограничениями и сложившимися за 20 лет практиками. О главных признаках этого феномена я расскажу ниже.

Микросервисная архитектура приложений и контейнеры

Программные продукты имеют модульную структуру (поверьте, очень тяжело написать что-то длиннее 1000 строк кода, не имеющее модульной структуры) — в отношении архитектуры ПО часто говорят о функциональных модулях и различных «слоях». Эти компоненты программ взаимодействуют между собой, они связаны логикой, но чаще всего она недостаточно формализована и со временем растет число неявных связей между различными элементами. Как правило, разработка компонентов ведется параллельными командами, но если одной команде разработки что-то нужно изменить в своем модуле, нередко выясняется, что нужны изменения и в смежных (и хорошо, если это вовремя вскрылось) — и теперь нужно ждать, пока соседи смогут выделить время и доработать свою часть кода. А как известно, главный враг параллелизации (а значит, ускорения) любой работы — частая синхронизация потоков ее выполнения.

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

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

Первая — инструменты упаковки приложений в контейнеры, не требующие установки, включающие все необходимые зависимости и готовые к запуску образы. Помните картриджи для приставок, которые достаточно вставить в разъем и включить питание, чтобы игрушка запустилась? Не надо разбираться, как ее проинсталлировать на ПК и какая версия DirectX ей нужна. Новый подход очень похож на этот пример,  только и приставка, и картридж — программные. Но суть та же: полная унификация формата поставки и процедуры запуска компонентов ПО.

Вторая — платформа оркестрации на базе технологии Kubernetes, которая автоматически собирает «пазл»:  размещает компоненты в контейнерах на управляемых ресурсах ИТ-инфраструктуры в соответствии с заложенными правилами и связывает микросервисы в единое приложение. Она в чем то похожа на систему планирования загрузки грузового транспорта, у которой на входе перечень грузов, а на выходе — план погрузки с учетом габаритов, центра тяжести, возможности штабелирования, частичной разгрузки на промежуточных точках маршрута и т.п. Только тут вместо грузов контейнеры, а вместо фур — кластер серверов, место на СХД и сетевые ресурсы, на которые нужно правильным образом разложить нагрузки в соответствии с их требованиями без участия человека и поддерживать их в целевом состоянии, реагируя на изменения.

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

Многие наши заказчики, попробовав свои силы в самостоятельном дизайне контейнерных сред, сегодня обращаются к готовым платформам от Red Hat, VMware и других производителей для стандартизации и тиражирования технологии Kubernetes в масштабе организации, чтобы быстрее переходить от «изобретения велосипедов» к продуктивной эксплуатации.

Open Source

Когда вы развиваете цифровые сервисы в режиме постоянного экспериментирования, странно строить и запускать свой продукт на дорогостоящих вендорских решениях: ведь вы даже не уверены в том, что он «выстрелит» или проживет достаточно долгое время, чтобы отбить инвестиции в лицензии или специфическое оборудование. Да, вендорские решения лучше по многим показателям, но что делать с этими инвестициями, если «не выстрелит» или не приживется?

Думаю, именно такие размышления обеспечили начальный интерес к ПО с открытым исходным кодом (конечно, в РФ к ним добавились и размышления на тему «импортозамещения»), а сейчас открытые решения активно замещают казавшиеся долгое время незаменимыми тяжелые продукты в сфере СУБД, MQ, хранилищ данных, сетевой балансировки нагрузки, мониторинга и т.п. В новой парадигме место лицензий в ИТ-бюджетах заменяют подписки на техническую поддержку продуктов Open Source. По нашим наблюдениям, применение исключительно открытых компонентов становится де-факто стандартом для новых «цифровых» проектов.

Безусловно, немаловажен и тот факт, что Open Source давно стал основой технологических стеков ИТ-гигантов, на текущем этапе выступающих донорами ноу-хау для корпоративного сектора. А как известно, нельзя зачерпнуть рыбу без воды: перенимая практики, компании вольно или невольно перенимают и стек технологий.

Основная сложность, с которой сталкиваются заказчики сегодня, — отсутствие накопленной экспертизы и типовых архитектурных решений для компонентов Open Source. Обеспечение нефункциональных требований (надежности, сохранности данных, катастрофоустойчивости, безопасности, масштабируемости и т.п.) для новых типов инфраструктурных элементов — терра инкогнита, в которой живут драконы потерянных и слитых налево данных, длительных простоев, ушедших клиентов и упущенной прибыли.

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

Новые модели владения и потребления

Это составной тренд: меняются модели и владения ресурсами, и потребления ресурсов бизнесом.

Тема экспериментов и их последствий, безусловно, находит свое продолжение и в поиске заказчиками новых моделей владения аппаратными ресурсами. Многие начинают активно использовать облачные сервисы, но в крупных компаниях масштабы собственной инфраструктуры по-прежнему на порядки превосходят объемы размещенных у сервис-провайдеров систем. Этому способствуют и вынужденное отсутствие на российском рынке глобальных игроков из «большой облачной тройки» (Amazon, Microsoft, Google), и сложности с выбором локальных поставщиков (кстати, мы запустили услугу облачного консалтинга, помогающую заказчикам сориентироваться на рынке и выбрать правильное облако), и паранойя служб ИБ, и развитие услуг класса DCaaS, позволяющих получить серверы и СХД в собственном ЦОДе по облачной модели — по арендной схеме, с обязательным запасом неиспользуемых ресурсов и обновлением оборудования по окончании его жизненного цикла. В общем — чем дальше, тем больше востребованы модели владения инфраструктурой по различным арендным схемам.

Параллельно активно идут проекты создания частных облаков: в крупнейших компаниях внедряются платформы самообслуживания и учета затрат, позволяющие потребителям ИТ-инфраструктуры получать ресурсы и сервисы так, как это происходит в публичных облаках — по клику в портале или через API, а не через систему тикетов и ручной труд цепочки администраторов, ведь, как мы говорили выше, скорость изменений теперь превыше всего. Кардинально ускорить разработку и каждый раз при этом спотыкаться о многодневные сроки выделения ресурсов в инфраструктуре — потеря инвестиций. Повсеместная автоматизация и модель «инфраструктура как код» — новая норма.

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