Анил Инамдар, руководитель Data Services в NetApp Instaclustr, рассказывает на портале The New Stack о том, почему консолидация стека данных создает скрытый архитектурный долг и как инженерные руководители могут защитить автономию своих команд.

Когда IBM объявила о приобретении Confluent (вскоре после поглощения DataStax) за 11 млрд. долл., большая часть комментариев была сосредоточена на том, что это означает для дорожной карты Kafka или сможет ли IBM реализовать стратегию нативно-облачной интеграции. Хотя это и разумные вопросы, инженерные руководители, вероятно, видят тему слишком узко.

Что происходит с автономией инженеров, когда Open Source-инструменты, от которых зависит команда, перестают быть нейтральными?

Мы уже видели это кино раньше

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

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

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

Неправильно обозначенный риск

Когда в разговорах руководителей поднимается вопрос о консолидации, обычно это воспринимается как проблема закупок. Ценовые рычаги и условия контрактов имеют значение, но они являются следствием более серьезной проблемы. Консолидация со временем и незаметно создает то, что я бы назвал архитектурным долгом. Разработчики говорят о техническом долге как об обходных путях в коде, которые нужно переделывать, но здесь все иначе. Архитектурный долг накапливается на уровне инфраструктуры, и его сложнее предвидеть.

Когда поставщик интегрирует такой инструмент, как Apache Kafka, в свое собственное облако, он добавляет дополнительные уровни удобства. К ним могут относиться пользовательские API, специально разработанные коннекторы и механизмы безопасности, которые связаны с его более широкой платформой. Каждый из них сам по себе разумен, но в совокупности за 3-5 лет вы получаете нечто, что больше не является переносимой или стандартизированной инфраструктурой. Теперь у вас есть собственная реализация платформы конкретного поставщика, даже если она никогда не была разработана для этого.

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

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

Затраты, которые не видны в вашей организационной структуре

По мере углубления архитектурного долга он тянет за собой многое другое.

В нейтральной Open Source-среде ваши инженеры изучают основные технологии. Например, они понимают, как работает Kafka на уровне разделов и как Cassandra обеспечивает согласованность данных под нагрузкой. Это переносимые знания, принадлежащие инженеру, а не платформе.

Однако в сильно управляемой, проприетарной среде команды перестают изучать потоковые данные и начинают изучать потоковый сервис поставщика X. Со временем экспертиза в базовой технологии атрофируется. Чем меньше команда способна работать с исходными технологиями, тем больше она зависит от управляемого уровня поставщика. Цикл замыкается сам на себя. Институциональные знания вашей организации незаметно превращаются в знания, специфичные для службы поддержки вашего поставщика ПО. Этот риск редко фигурирует в каком-либо реестре рисков и со временем накапливается.

Как на самом деле выглядит преднамеренная нейтральность

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

Руководителям необходимо понимать, что архитектурная нейтральность раньше автоматически обеспечивалась Open Source-инструментами. Сейчас это уже не так, и инженерные руководители, которые считают это само собой разумеющимся, принимают решение, которое заключается в том, что они его не принимают.

Это имеет реальные последствия. Когда ваша команда оценивает управляемый сервис данных, вопрос о том, хороша ли технология сегодня, — это лишь часть обсуждения. Более полезный вопрос — будут ли создаваемые точки интеграции по-прежнему переносимыми через три года. Один из практических тестов — сможет ли ваша команда осуществить миграцию, если вам придется сменить поставщика через 18 месяцев, без многолетних усилий. Значительное сомнение само по себе является ответом.

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

Правило по умолчанию, не более того

Стек данных будет продолжать консолидироваться. Такова природа зрелого рынка, и инженерным руководителям придется принимать решения в рамках этой реальности.

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