Использование 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. Visual Studio Code — это среда, популярность которой быстро растет с момента выхода на рынок. Все, с кем мы разговаривали, с точки зрения нового выпускника, хорошо знакомы с VS Code, и мы видим, что у нового разработчика меньше опыта работы со старыми средами, такими как Eclipse. Так что иногда вам нужно быть там, где уже есть ваша аудитория.

RTInsights. С какими проблемами сталкиваются компании, пытающиеся внедрить решения DevOps? И каковы основные проблемы в области встроенных устройств по сравнению с другими областями?

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

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

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

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

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

RTInsights:существуют ли инструменты, облегчающие переход на DevOps?

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

Есть большой выбор. Вы можете возразить, что иногда выбор слишком велик. Проблема, с которой, как мы видим, сейчас сталкиваются клиенты, заключается в том, что существует множество инструментов. Как объединить их в решение, которое мне подходит?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RTInsights:что-нибудь еще?

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