Авиатор спонсировал этот пост.
Платформа Engineering была помечена эволюцией DevOps, основой производительности разработчиков, решением для узких мест доставки и того, что могло быть самой горячей тенденцией в индустрии программного обеспечения прямо сейчас, если бы это не для ИИ.
Но большая часть того, что называется «Инженерная платформа» сегодня, представляет собой смесь старых идей, иногда просто со свежим слоем краски. Официальное определение инженерии платформы:
«… Дисциплина проектирования и создания инструментов и рабочих процессов, которые обеспечивают возможности самообслуживания для организаций по разработке программного обеспечения в облачную эру нативного.
Но что такое инженерия платформы, на самом деле?
Мы потратили годы на создание платформ, которые все еще используются сегодня, поэтому мы решили сесть и обсудить наше мнение о разработке платформы, в том числе о том, почему компании терпят неудачу и куда мы идем в ближайшие пять лет. Мы приглашаем вас прочитать это краткое изложение наших идей, а затем посмотреть видео нашего разговора, встроенного ниже.
DevOps жив и здоров
Мы потеряли счет того, сколько людей утверждают, что DevOps мертв. Это не. Определение DevOps:
«… Союз людей, процессов и продуктов, чтобы обеспечить непрерывную доставку ценности нашим конечным пользователям».
Инженерная инженерия платформы — очень небольшая подмножество DevOps.
На самом деле, этот разговор о «DevOps vs. Platform Engineering» является чем -то вроде красной сельди. То, что имеет значение, не название команды, независимо от того, называется ли она командой платформы, опытом разработчиков, инженерным моментом или чем -то совершенно другим. Важно его функция.
Если вы помогаете разработчикам поставить программное обеспечение с меньшим трением, поздравляю! Вы уже делаете какую -то форму инженерии платформы. По своей сути, платформная инженерия проста: речь идет о разработчиках, создающих инструменты для других разработчиков, чтобы им было легче выполнять свою работу.
Инженерная инженерия платформы, или что бы мы ни называли, означает спрашивать себя каждый день: «Как мне сделать разработчикам действительно легко выполнять свою работу и очень трудно сделать ошибки?»
Это звучит прямо, но это не так. Потому что сделать вещи легкими и защищенными от ошибки в то же время противоречиво.
Мы не строим платформу. Мы строим продукт.
Что важно: лучше ли работы разработчиков сейчас, чем до существования команды платформы? Если команда платформы не может ответить на это с уверенностью, платформа не доставляет. Следует ли мы отслеживать, улучшились ли жизнь разработчиков с тех пор, как мы начали? Знаем ли мы, почему наша команда существует? Если причина в том, чтобы «улучшить инструменты, которые мы построили в прошлом году», этого недостаточно.
Здесь большинство организаций не хватает: они не относятся к платформе как к настоящему продукту. И это именно то, что это такое.
Внутренние платформы — это продукты с реальными клиентами: наши разработчики. Если бы мы не отправили наполовину выпеченную функцию внешнему пользователю, почему бы мы думали, что нормально раздвинуть набор инструментов на разработчиков и требовать их использования, независимо от того, знают ли они, как-или даже нужны эти инструменты вообще?
Что важно: лучше ли работы разработчиков сейчас, чем до существования команды платформы?
Команды платформы нуждаются в управлении продуктом, отзывы клиентов, использовании телеметрии и, возможно, даже — приготовьте себя — внутренний маркетинг.
Да, маркетинг. Даже злые птицы нуждались в маркетинге!
Когда мы работали в команде платформы, мы раздавали футболки и наклейки, бегали обед, учились и делали внутренние шов. Мы были очень прозрачными с нашими намерениями, открыты для обратной связи и очень частью сообщества. Команда платформы не может существовать в башне из слоновой кости, которая просто выбрасывает инструкции всем.
Инженерная инженерия платформы не работа в полиции
Команды платформы — это включение, а не полицейская деятельность. Но иногда они становятся полицейской. Нет, вы не можете использовать Дженкинс. Нет, мы не поддерживаем эту библиотеку. Вы должны использовать это, потому что мы так сказали.
Если что -то сломано на платформе, у нас будет законно злые внутренние клиенты. Последнее, что мы хотим, — это иметь гневных клиентов, когда ничего не сломано. Мы не хотим усыновления, потому что люди загнаны в угол. Мы хотим внедрения, потому что инструменты, которые мы создали, на самом деле лучше.
Мы описываем наши платформы как «Мощеные тропинки с местом для не внедряют». Команды платформы создают золотой путь, который легкий, безопасный и хорошо поддерживаемый, но оставьте дверь открытой для команд, у которых есть веские основания сделать что-то другое.
Стандартизация имеет значение — это уменьшает поддержку бремени и режимов отказа. Но стандартизация силой просто приводит к сопротивлению, теневой инструменте и обиде.
Остерегайтесь метрик тщеславия
Давайте также рассмотрим слона в комнате метрик: Эффективность команды платформы часто измеряется с помощью использования. Использование — это не то же самое, что воздействие, особенно если оно обязательно.
Когда команды платформы стимулируются на внутреннее внедрение инструмента вместо воздействия, они неизбежно в конечном итоге приводят к изменению вместо того, чтобы зарабатывать.
Сказать: «Наша платформа сэкономила 1500 часов разработчика», не является бессмысленной, если мы не знаем, во что превратились эти 1500 часов. Были ли поставлены больше функций? Улучшена ли удовлетворенность клиентов? Увеличилась ли скорость продукта?
Возврат инвестиций (ROI) в инженерии платформы трудно измерить. Мы ничего не можем сделать в краткосрочной перспективе, и счастье разработчика очень трудно измерить, независимо от того, сколько вы делаете опросы.
Мы можем взглянуть на отстающие индикаторы, такие как время выполнения доставки, качество, надежность и доход от новых функций. Но опять же, мы должны выполнять тяжелую работу по управлению продуктами и поговорить с нашими клиентами. Разработчики используют платформу, но могут ли они лучше выполнять свою работу?
Порталы не решат все ваши проблемы
Внутренние порталы разработчиков — все это в моде. И, как и большинство блестящих инструментов, они перепроданы. Портал разработчика — это просто инструмент. Полезный, если он помогает разработчикам быстро начать, найти документацию и запрашивать ресурсы, не прося о слабых.
Но инструмент не является платформой. Инструмент не фиксирует сломанную культуру, плохое общение или отсутствие мышления продукта. За кулисами не спасет вас. Это работало для Spotify, потому что он решил свои проблемы. Вы должны понять свой.
Вы хотите знать, хорошо ли ваша платформа? Проверьте год. Сила хорошей платформы определяется только тем, как долго она поддерживает: она все еще используется? Это все еще полезно? Разработчики добровольно приняли это? Вы развивали это на основе их отзывов? Или никто не использует его, и вы решили закрыть его, потому что это слишком много, чтобы поддерживать?
Aviator-это разработчик с низким содержанием конфигурации, работающий с AI, который автоматизирует владение, обзоры кода, слияния и развертывание. Он создает организационный график знаний для упрощения назначения билетов, резюме проекта и поддержки внутренней разработчиков. Узнайте больше последних из Aviator Trending Stories YouTube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Вилас является опытным инженерным лидером, который управляет платформой, продуктами и разработчиком инноваций в Comcast, Netflix, Walmart, Bill и Truckstop. Он создает высокопроизводительные команды, которые выполняют эффективную доставку программного обеспечения распределенных рабочих нагрузок в облаке, Chaos Engineering, CI/CD … Подробнее от Vilas Vieraraghavan Bryan Finster является страстным защитником для непрерывной доставки с более чем двух десятилетий опыта построения и управления миссионерскими системами для очень больших въездов. Он является основателем и бывшим лидером Walmart DevOps Dojo с практическим опытом оба … Подробнее от Брайана Финстера
