Опасности модели forward deployed engineer в AWS, Google Cloud и Microsoft Azure
Модель forward deployed engineer стремительно захватывает корпоративный IT-рынок, и меня беспокоит, что многие компании не до конца понимают, на что подписываются.
Начнем с громких цифр. AWS объявила о вложении 1 млрд долларов в новую организацию Forward Deployed Engineering. Google Cloud пообещала 750 млн долларов на расширение похожих программ. Microsoft уже много лет развивает встроенные инженерные команды, ориентированные на Azure, в том числе в партнерстве с Accenture для масштабирования практик forward deployed engineering. Все трое продают одну и ту же идею: мы пришлем инженеров, которые будут работать напрямую с вашими командами, помогут внедрить ИИ и ускорить вашу цифровую трансформацию. Вы получаете первоклассных технических специалистов бесплатно, а мы — партнерство на вашем пути.
На первый взгляд это звучит разумно. Это выглядит как сотрудничество, даже щедрое предложение. Но я достаточно давно работаю в отрасли, чтобы понимать: когда многомиллиардная компания предлагает вам что-то бесплатно, она почти наверняка получит от этого гораздо больше, чем отдаст.
Что вы на самом деле получаете
Модель forward deployed engineer сама по себе не нова. Консалтинговая индустрия десятилетиями использует похожий подход. Но здесь все иначе из-за масштаба и прямого финансового стимула.
Эти инженеры работают на поставщика облака. Они не ваши сотрудники. Они не независимые консультанты. Это технически сильные специалисты, которым платят за решение ваших текущих проблем, одновременно выстраивая отношения и архитектуру, выгодные экосистеме их работодателя. Посмотрите на это их глазами. Эти forward engineers оцениваются по тому, насколько успешно клиенты используют платформу их работодателя. Их вознаграждают, когда предприятия подключают больше сервисов этой платформы. Их карьерный рост зависит от того, чтобы AWS, Google Cloud или Microsoft Azure стали очевидным выбором для всех ваших технических решений.
Это не критика самих инженеров. Многие из них действительно талантливы и искренне хотят помочь. Но они работают внутри системы, которая поощряет определенные результаты, а эти результаты соответствуют финансовым интересам вендора, а не обязательно вашим.
Проблема, о которой никто не говорит
Сейчас в компаниях я вижу следующее. Предприятие понимает, что ему нужна помощь во внедрении ИИ. Поставщик облака предлагает встроить инженеров без дополнительной платы. Эти инженеры работают вместе с внутренними командами, дают архитектурные рекомендации и помогают строить системы. Через шесть месяцев у компании уже есть production-система ИИ, работающая на одной облачной платформе и созданная людьми с глубокой экспертизой именно в этой платформе.
Проблема? Никто не проверял, была ли эта платформа действительно лучшим выбором для бизнеса. Никто не изучал альтернативы. Никто не спрашивал, не дала бы multicloud-архитектура или подход best-of-breed лучшие результаты при меньших затратах.
Инженеры, встроенные в такие программы, не будут рекомендовать распределить рабочие нагрузки между несколькими провайдерами. Они не предложат использовать open source-инструменты там, где это имеет смысл. Они не укажут на конкурента, если решение их работодателя и так «достаточно хорошее». Так эти программы не устроены. В итоге вы получаете архитектуру, оптимизированную под один облачный бренд, а не архитектуру, оптимизированную под ваш бизнес.
Финансовая реальность все равно настигнет
Счета все равно придут — и будут болезненными. Я видел этот сценарий раньше. Когда предприятия привязываются к одному облачному провайдеру через такие встроенные инженерные программы, через два или три года они нередко обнаруживают, что платят премию, которой их более независимые конкуренты избежали.
Причины просты. Когда вы проектируете системы вокруг одной платформы, вы неизбежно попадаете в модели использования, которые выгодны ее ценовой структуре. Вы используете их managed databases вместо переносимых альтернатив. Вы подключаете их AI-сервисы, не сравнивая с решениями третьих сторон. Вы строите рабочие процессы, которые работают только внутри их экосистемы. А когда приходит время пересматривать контракт или сравнивать условия с альтернативами, оказывается, что миграция обойдется дороже, чем согласие на любые предложенные цены.
Последние десять лет я помогаю компаниям распутывать такие ситуации. Я видел организации с облачными счетами в 15–20 раз выше, чем следовало бы, которые не могли мигрировать, потому что вся их инфраструктура ИИ построена на проприетарных сервисах, работающих только на одной платформе. Программы forward deployed engineer ускоряют именно эту проблему. Они упрощают вход в такие зависимости и усложняют выход из них.
Подумайте, прежде чем соглашаться
Прежде чем принять участие в такой программе, стоит учесть три рекомендации.
Во-первых, с первого дня требуйте независимого архитектурного контроля. Наймите или привлечите архитекторов, которые работают на вашу компанию, а не на вашего облачного провайдера. Они должны оценивать каждую рекомендацию встроенных инженеров с точки зрения бизнес-требований и сравнивать варианты между провайдерами. Дело не в недоверии к инженерам. Дело в том, чтобы решения принимались с учетом ваших интересов.
Во-вторых, заранее требуйте четкую стратегию выхода. Попросите облачного провайдера задокументировать, какие проприетарные сервисы вы используете, какие есть пути миграции и сколько будет стоить переход на альтернативную платформу. Если он не может предоставить эту информацию или если стоимость миграции выглядит запредельной, это признак того, что вы накапливаете технический долг, обслуживание которого позже обойдется очень дорого.
В-третьих, постоянно сравнивайте свои затраты с рынком. Настройте внутренние процессы так, чтобы сопоставлять расходы на облако с отраслевыми бенчмарками и с тем, сколько, вероятно, платят ваши конкуренты за похожие нагрузки. Не ждите продления контракта, чтобы обнаружить, что вы платите премиальные цены. Контролируйте расходы с самого начала и будьте готовы спорить с облачным провайдером, если вы не получаете ценности, которая оправдывает стоимость.
Главный вывод
Forward deployed engineers действительно решают реальные задачи. Предприятиям и правда сложно внедрять ИИ, и доступ к опытным инженерам полезен. Я не утверждаю, что эти программы по сути плохие. Однако их продают как нейтральные партнерства, хотя на деле это стратегические программы продаж, созданные для привязки предприятий к конкретным платформам. Полезные инженеры, которые приходят к вам в офис, создают зависимости, разорвать которые будет очень трудно. «Бесплатная» техническая помощь оплачивается маржой на сервисах, которые вы будете покупать годами.
Входите в это с открытыми глазами. Используйте такие программы, но добавляйте собственный независимый контроль. Стройте архитектуры, из которых вы сможете выйти при необходимости. И не позволяйте немедленному удовольствию от решенных сегодня проблем затмить финансовые последствия, которые придут завтра.

Материал — перевод статьи с английского.
Оригинал: A cloud deal too good to be true