Использование DevOps для преодоления сложностей встроенного ПО

DevOps считается лучшим способом удовлетворить спрос рынка встроенного ПО на большее количество приложений и новые функции, доступные в более короткие сроки.

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

Эти условия создают новые требования к командам разработки и эксплуатации. Все чаще DevOps считается лучшим способом удовлетворить рыночный спрос на большее количество приложений и новые функции, доступные в более короткие сроки. RTInsights недавно беседовал с Грэмом Морфью, старшим директором по управлению продуктами в Wind River. Мы обсудили проблемы разработки встроенного ПО, различия между DevOps для традиционных сред и встроенных устройств, и многое другое.

Вот краткое содержание нашего разговора.

RTInsights: Чем DevOps для встроенных устройств отличается от традиционных подходов DevOps к разработке ПО?

Морфью: Если посмотреть на традиционный DevOps в ИТ-среде предприятия, там существует единая среда выполнения. Вы либо работаете на серверах Intel в облаке, либо у вас что-то запущено на ПК Intel. Встроенные системы совершенно иные. Ваша конечная среда выполнения обычно имеет другую архитектуру, чем та, что используется для разработки. Вызывают больше сложностей разнообразие конечного «железа» и способы развертывания на нем. Например, когда вы создаете ПО для облачной среды, вы знаете, что оно попадет в Google Cloud, Azure или AWS. Когда вы создаете встроенное ПО, разнообразие выбора среды развертывания практически бесконечно, и устройства могут находиться в удаленных локациях.

Поэтому существует множество различий в том, как вы думаете о ПО и как эти различия преобразуются в вызовы при внедрении DevOps.

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

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

RTInsights: Почему сообщество встроенных устройств перейдет к DevOps? Почему это становится привлекательным, и что происходит на рынке, что это движет?

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

Другой фактор, толкающий компании к DevOps для встроенных систем — меняющаяся демография разработки ПО, которую мы видим в Wind River.

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

У меня сын студенческого возраста. Он программирует на Python. Он только что выучил C в первый раз, и это было большим открытием. Python предлагает гораздо более высокие уровни абстракции.

DevOps может помочь преодолеть это препятствие между средой приложения и желанием сделать ее похожей на знакомую среду для разработчиков ПО устройств. Необходимость в этом заключается в том, что компаниям, создающим устройства, трудно привлекать новых талантов в разработке ПО.

Я разговаривал с недавним стажером, и он сказал, что многие его одногруппники хотят уйти в Кремниевую долину и работать в Facebook, Google, Apple, Tesla. Для компаний в промышленных или аэрокосмических секторах может быть сложнее привлечь нужных разработчиков, которые пришли бы и программировали встроенные устройства в примитивной среде C.

Чтобы преодолеть это, некоторые компании думают, что предоставление новому поколению разработчиков знакомой им среды поможет. И это одна из причин, почему Wind River внедряет среду Visual Studio Code. VS Code — среда, которая с момента выхода на рынок быстро набрала популярность. Все, с кем мы говорили с точки зрения новых выпускников, очень знакомы с VS Code, а с более старыми средами, вроде Eclipse, у новых разработчиков меньше опыта. Иногда нужно быть там, где уже находится ваша аудитория.

RTInsights: Какие проблемы у компаний при попытке внедрить решения DevOps? И какие ключевые вызовы для области встроенных устройств по сравнению с другими доменами?

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

У вас есть небольшие команды, и во многих случаях отдельные люди выполняют очень специфические задачи. Вам нужен уровень сотрудничества и кооперации в DevOps, который иногда выводит людей из зоны комфорта, в которой они жили годами. Нужно сказать: «Все работают вместе».

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

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

И снова проблема железа. Это общая тема для рынка встроенных систем. Как получить достаточно железа для построения сред автоматизации, необходимых для реализации DevOps? Это постоянный вызов. Обычно успешные клиенты используют смесь железа и симуляции для масштабирования тестовых процессов.

RTInsights: Есть ли инструменты, которые облегчат переход к DevOps?

Морфью: Одна вещь, помогающая компаниям пройти через эту революцию — доступность инструментов. Многие из них открыты или имеют бесплатные версии. Часто видели консолидацию вокруг какой-то системы управления исходным кодом, часто вариации Git. Сейчас организации перешли от решения, ориентированного только на управление исходным кодом, к включению все большего числа инструментов DevOps в свои решения. Это помогает компаниям сделать переход.

Выбора много. Можно даже сказать, что иногда выбора слишком много. Вызов, который мы видим у клиентов сейчас: да, инструментов много. Как собрать их вместе в решение, которое работает для меня?

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

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

RTInsights: Каковы отраслевые драйверы для решений, облегчающих разработку и тестирование ПО для встроенных устройств?

Морфью: Есть сходимость миров ИТ и OT. У вас есть устройства, подключенные к интернету. Это был большой драйвер для компаний пересмотреть, как они поставляют ПО. Также есть несколько отраслей, где есть требования соответствия для обновления ПО в устройствах. Вы видите это в медицинской сфере, где теперь вы должны доказать, что можете обновить свое устройство, если станет известна уязвимость безопасности. Это может быть вопросом жизни и смерти. Вам нужно иметь возможность доказать, что можете решить такую проблему, если она возникнет.

Такие драйверы толкают компании посмотреть на их процессы относительно их способности делать удаленные обновления. Что мы видим — многие крупные компании чувствуют угрозу от этих цифровых нативных новых и растущих компаний. Есть даже термины для описания этого. Вы слышите термин «теслафикация». Они говорят, что им нужно быть больше как Tesla и быть очень-очень ПО-ориентированным бизнесом, в отличие от мышления в категориях кирпича и 모르тара, стали и железа, более ассоциируемого с железом. Все больше они должны дифференцировать свой продукт на ПО, работающем на том, что они строят.

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

RTInsights: Перейдем к другой проблеме, почему быстрые итерации ПО стали критическим конкурентным преимуществом во всех отраслях? И как это связано с потребностью в автоматизированном тестировании?

Морфью: Я прошел через несколько проектов, переходивших от водопадной модели к более гибкой. Способность делать непрерывное тестирование, автоматизированное тестирование часто является ограничивающим фактором в плане повышения вашей продуктивности. Если вы собираетесь бегать быстро и все еще хотите сохранить качество, это необходимость. Это конкретная область, где наличие цифрового двойника вашего конечного устройства позволяет делать много тестирования на нем, и вы можете делать это в масштабе.

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

У нас в Wind River был бизнес по симуляции много лет. Некоторые ранние последователи делали много этого на своих серверах, масштабируя большие количества симуляций. Но когда вы переносите это в облако, вам не нужно покупать новые серверы каждые полгода.

У вас есть контроль над типом используемого железа и его количеством. Вы можете наращивать и уменьшать в зависимости от того, что вам нужно в данный момент, вместо капитальных затрат на большое железо и ИТ-команды для его поддержки. Сейчас мы видим баланс или своего рода гибридную облачную среду, где часть тестирования делается локально on-premises, а часть — в публичном облаке.

RTInsights: Есть ли другие моменты, которые вы хотите поднять, которые мы упустили?

Морфью: Когда вы говорите о DevOps и переходе разработки встроенного ПО к более cloud-native, cloud-фокусированной среде, есть несколько вещей, которые я видел лично как менеджер продукта, которые являются большими изменениями.

Одно из них — сотрудничество. Я пытался завершить сборку Linux. Я не опытный Linux-инженер. У меня были проблемы с тем, чтобы сборка заработала правильно. И пока я это делал, один из наших архитекторов Linux видел, что у меня было несколько неудачных сборок. И он связался со мной через мессенджер и сказал: «Эй, я вижу, что у тебя проблемы, я посмотрел, тебе просто нужно переключить настройку, и все будет хорошо. И я просто пошел и исправил это за тебя».

Если бы я разрабатывал в другой среде, где ПО установлено на моем ПК, никто бы никогда не узнал, что у меня проблемы. Мне пришлось бы выйти и спросить. Скорее всего, я бы не смог воспроизвести тот же сценарий. Скорее всего, я бы застрял на этом на весь день. И, возможно, я бы просто сдался через некоторое время. Так что способность быстро получить доступ к ПО, которое не нужно устанавливать локально, и иметь возможность поиграть в общем песочнице, для меня было большим открытием о том, как это меняет то, как вы работаете, просто от наличия таких общих активов среди вашей команды.

RTInsights: Есть что-то еще?

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