DevOps를 사용하여 임베디드 소프트웨어 문제 해결

DevOps는 더 많은 애플리케이션과 새로운 기능에 대한 임베디드 소프트웨어 시장의 요구를 충족하는 가장 좋은 방법으로 간주되며 모든 것이 더 짧은 시간에 제공됩니다.

임베디드 장치 소프트웨어 개발에 폭풍이 몰아치고 있습니다. 임베디드 장치는 특히 5G와 같은 새로운 연결 옵션이 혁신적인 연결 장치 응용 프로그램을 가능하게 하고 새로운 분석 및 인공 지능 기능을 활용하여 사용이 확대됨에 따라 확산되고 있습니다. 동시에 진화하는 사이버 공격에 대응하는 것과 같은 장치 수명 주기 요구 사항으로 인해 소프트웨어 변경 사항을 신속하게 생성하고 배포해야 합니다.

이러한 조건은 개발 및 운영 직원에게 새로운 요구 사항을 제시합니다. 점점 더 DevOps는 더 많은 애플리케이션과 새로운 기능에 대한 시장 요구를 충족하는 가장 좋은 방법으로 간주되고 있으며 모두 더 짧은 시간에 사용할 수 있습니다. RTIinsights는 최근 Wind River의 제품 관리 수석 이사인 Graham Morphew와 함께 했습니다. 임베디드 디바이스 소프트웨어 개발의 과제, 기존 환경을 위한 DevOps와 임베디드 디바이스 간의 차이점 등에 대해 논의했습니다.

다음은 우리의 대화를 요약한 것입니다.

RTInsights:임베디드 장치용 DevOps는 소프트웨어 개발에 대한 기존 DevOps 접근 방식과 어떻게 다릅니까?

모피: IT 엔터프라이즈 기반 환경에서 기존 DevOps를 보면 유비쿼터스 실행 환경이 있습니다. 클라우드의 Intel 서버에서 실행 중이거나 Intel PC에서 실행 중인 것이 있습니다. 임베디드는 매우 다릅니다. 최종 실행 환경은 일반적으로 개발에 사용하는 것과 다른 아키텍처입니다. 최종 하드웨어의 다양성과 하드웨어에 배포하는 방법으로 인해 더 많은 문제가 있습니다. 예를 들어 클라우드 기반 환경용 소프트웨어를 구축할 때 소프트웨어가 Google Cloud, Azure 또는 AWS 환경에서 실행되고 있다는 것을 알 수 있습니다. 임베디드 소프트웨어를 구축할 때 배포 환경에 대한 선택의 다양성은 거의 무한하며 원격 위치에 장치가 있을 수도 있습니다.

따라서 소프트웨어에 대해 생각하는 방식과 이러한 차이점이 DevOps 구현 문제로 변환되는 방식에는 많은 차이점이 있습니다.

전문화된 하드웨어, 크로스 컴파일, 크로스 디버깅, 메모리 공간 및 보안 문제와 씨름해야 합니다. 클라우드 환경에서와 같이 손끝에서 거의 무한한 리소스를 사용할 수 없습니다. 이러한 시스템을 설계할 때 염두에 두어야 할 실행의 섬이 있습니다. 당신은 또한 걱정할 보안이 있습니다. 장치의 보안을 물리적으로 제어할 필요는 없습니다. 기기의 물리적 변조와 씨름해야 할 수도 있습니다.

또 다른 문제는 이러한 장치의 데이터를 수집하기가 더 어렵다는 것입니다. DevOps 환경에서는 지속적인 피드백 루프가 필요합니다. 개발자가 제어할 수 있는 서버에서 개발하는 경우 쉽습니다. 장치에 대해 이야기할 때 장치는 원격으로 배포될 가능성이 높으며 항상 온라인 상태가 아닐 수 있습니다. 따라서 임베디드 소프트웨어에 대한 기존 DevOps와 DevOps를 비교할 때 다양한 문제가 발생합니다.

TInsights:임베디드 장치 커뮤니티가 DevOps로 이동하는 이유는 무엇입니까? 이것이 왜 설득력이 있고 이를 추진하는 시장에서 무슨 일이 일어나고 있습니까?

모퓨: 임베디드 소프트웨어를 사용하면 더 빈번한 업데이트와 더 높은 품질에 대한 요구가 증가하고 있습니다. 거기에 도달하려면 자동화가 필요합니다. 자동화는 DevOpsand 임베디드 소프트웨어의 미래에서 큰 역할을 할 것입니다. 10~20년 전으로 돌아가 보면 장치의 기능을 구동하는 하드웨어에 많은 초점이 맞춰져 있었습니다. 이제 장치 공급업체 간의 훨씬 더 많은 차별화 기술은 소프트웨어입니다.

기업이 DevOpsfor 임베디드 시스템을 선택하도록 하는 또 다른 요인은 Wind River에서 많이 볼 수 있는 소프트웨어 개발 인구 통계의 변화입니다.

두 개의 매우 뚜렷한 캠프가 있습니다. 기존의 임베디드 소프트웨어 개발자와 새로운 졸업생 또는 개발자가 다른 소프트웨어 영역에서 지능형 장치의 영역으로 진입했습니다. 전통적인 개발자는 나이가 많고 많은 사람들이 은퇴하는 경향이 있습니다. 저처럼 하드웨어 매뉴얼, 프로그램 레지스터 등을 보던 시기에 대학을 졸업하고 시장에 나온 사람들이 있습니다. 그것은 대학 프로그램이 지금 많은 시간을 할애하는 것이 아닙니다.

이제 대학생이 된 아들이 있습니다. 그는 Python으로 프로그래밍하고 있습니다. 그는 방금 C를 처음 배웠고 그것은 눈을 크게 뜨게 했습니다. Python은 훨씬 더 높은 수준의 추상화를 제공합니다.

DevOps는 애플리케이션 환경과 디바이스 소프트웨어 개발자에게 친숙한 환경처럼 보이도록 하려는 애플리케이션 환경 사이의 이러한 장애를 극복하는 데 도움이 될 수 있습니다. 이를 수행해야 하는 이유는 장치를 구축하는 회사가 새로운 소프트웨어 개발 인재를 확보하는 데 어려움을 겪기 때문입니다.

나는 최근에 우리가 산 인턴을 고용한 사람과 이야기를 나누었고, 그는 그의 급우 중 많은 사람들이 실리콘 밸리에 가서 Facebook, Google, Apple, Tesla와 같은 회사에서 일하기를 원한다고 말했습니다. 산업 또는 항공우주 및 방위 산업 분야의 회사의 경우 기본 C 환경에서 임베디드 장치를 프로그래밍하고 필요한 소프트웨어 인재를 유치하는 것이 더 어려울 수 있습니다.

이를 극복하기 위해 일부 기업은 차세대 소프트웨어 개발자에게 친숙한 환경을 제공하는 것이 도움이 될 것이라고 생각합니다. 이것이 Wind River가 Visual Studio Code 환경을 채택한 이유 중 하나입니다. Visual Studio Code는 시장에 출시된 이후 빠르게 인기를 얻은 환경입니다. 새로운 대학원 관점에서 이야기한 모든 사람들은 VS Code에 매우 익숙하며 Eclipse와 같은 이전 환경을 사용하는 새로운 개발자의 경험이 적습니다. 따라서 때로는 청중이 이미 있는 곳에 있어야 합니다.

RTIInsights:기업이 DevOps 솔루션을 채택하려고 할 때 어떤 문제가 있습니까? 임베디드 장치 영역과 다른 영역의 주요 과제는 무엇입니까?

모피: 가장 큰 도전은 기업 내에서 일어나야 하는 문화적 변화입니다. 그리고 이것은 반드시 임베디드 전용 챌린지일 필요는 없습니다. 일부 소프트웨어 개발 관행에 더 깊이 뿌리를 내리고 있습니다.

소규모 팀이 있고 대부분의 경우 매우 구체적인 작업을 수행하는 개인이 있습니다. 때때로 사람들을 수년 동안 익숙해져 온 영역에서 벗어나게 하는 DevOps와의 수준의 협업 및 협력이 필요합니다. "모두가 함께 일하고 있습니다."라고 말해야 합니다.

임베디드용 DevOps의 Ops 부분은 도전 과제입니다. 클라우드용 기존 DevOps 환경에서 Opsis는 꽤 표준이기 때문입니다. 웹 사이트를 실행하거나 클라우드 기반 인터페이스를 통해 작업을 수행하는 애플리케이션을 개발 중입니다. 임베디드에 대해 이야기할 때 현장에 있는 장치에 대해 이야기하는 것이며 해당 장치가 수행하는 작업은 회사에 따라 다릅니다. 대부분의 경우 장치 제조업체는 장치를 작동하는 회사가 아닙니다. 장비 제조업체는 대형 전기 회사나 대형 제조업체에 장치를 판매할 수 있습니다. 그 회사는 장치를 운영하는 회사입니다. 때때로 기기 제조업체의 지원이 있기는 하지만 클라우드 기반 솔루션에서 볼 수 있는 것처럼 완전히 폐쇄된 루프는 아닙니다.

도구 세트 호환성 문제가 있습니다. 공통 개발 환경을 갖는 것은 때때로 저항을 받습니다. 따라서 이러한 시스템을 구현하는 데 필요한 일부 문화 및 관리 지원으로 돌아갑니다.

그리고 하드웨어 문제가 다시 발생합니다. 임베디드 시장의 공통 테마입니다. DevOps를 현실화하는 데 필요한 자동화 환경을 구축할 수 있는 충분한 하드웨어를 어떻게 확보합니까? 그것은 지속적인 도전입니다. 일반적으로 성공적인 고객은 테스트 프로세스를 확장하기 위해 하드웨어와 시뮬레이션을 함께 사용합니다.

RTIInsights:DevOps로 더 쉽게 전환할 수 있는 도구가 있습니까?

모퓨: 기업이 이 혁명을 극복하는 데 도움이 되는 한 가지는 도구의 가용성입니다. 이러한 도구 중 대부분은 오픈 소스이거나 무료 버전이 있습니다. 당신이 흔히 볼 수 있는 것은 소스 코드 관리의 일부 형태, 종종 Git의 특징을 중심으로 한 통합이었습니다. 이제 조직은 소스 코드 관리 중심의 솔루션에서 솔루션 내에 점점 더 많은 DevOps 유형의 도구를 포함하게 되었습니다. 기업이 전환하는 데 도움이 됩니다.

선택의 폭이 넓습니다. 선택의 폭이 너무 넓다고 주장할 수도 있습니다. 현재 고객이 겪고 있는 문제는 많은 도구가 있다는 것입니다. 나에게 적합한 솔루션으로 이들을 통합하려면 어떻게 해야 합니까?

오늘날 많은 기업이 디지털 중심의 개발 환경으로의 전환을 관리하기 위해 내부적으로 팀을 구성하는 프로젝트를 시작하고 있습니다. 우리는 다른 기술 전환에서 보았던 것과 같이 임베디드 공간에서 전환이 일어나고 있는 것을 봅니다. 많은 경우에 "우리를 위한 완벽한 시스템을 구축하고 우리의 필요에 맞게 맞춤화하자"는 DIY 정신과 매우 흡사합니다. 이러한 노력은 단지 앞으로 이러한 것들을 유지하기 위해 회사에서 점점 더 많은 자원을 소모하고 있습니다. 그들이 반드시 투자하고 싶은 곳은 아닙니다. 그 접근 방식은 사람들이 다른 회사가 시간이 지남에 따라 더 많은 환경을 유지하도록 하는 방식으로 진화할 것입니다.

궁극적으로 기업이 삶을 더 쉽게 만들 수 있는 또 다른 영역은 애플리케이션 개발과 실행 중인 소프트웨어 플랫폼 유지 관리를 명확하게 구분하는 것입니다. 이전에는 두 가지 작업을 모두 수행하는 소규모 팀이 있었고 애플리케이션과 플랫폼이 서로 통합되었습니다. 하지만 지금은 소프트웨어를 모듈화하고 사람들이 최고의 기술을 가진 일을 하도록 하려면 명확한 분리가 필요합니다.

RTIInsights:임베디드 장치용 소프트웨어를 더 쉽게 개발하고 테스트할 수 있게 해주는 솔루션의 업계 동인은 무엇입니까?

모퓨 :IT 세계와 OT 세계의 융합이 있습니다. 인터넷에 연결된 장치가 있습니다. 이것은 기업이 소프트웨어를 제공하는 방법을 재검토하게 된 큰 동인이었습니다. 또한 장치의 소프트웨어를 업데이트해야 하는 규정 준수 관련 요구 사항이 있는 여러 산업이 있습니다. 이제 의료 분야에서 보안 취약점이 알려지면 장치를 업데이트할 수 있음을 증명해야 합니다. 이것은 생사를 가르는 시나리오가 될 수 있습니다. 그러한 문제가 발생하면 해결할 수 있음을 증명할 수 있어야 합니다.

이러한 드라이버는 기업이 원격 업데이트를 수행할 수 있는 능력과 관련하여 사용 중인 프로세스를 보도록 압박하고 있습니다. 우리가 보고 있는 것은 많은 대기업들이 이러한 디지털 기반의 신규 및 떠오르는 기업으로부터 위협을 느끼고 있다는 것입니다. 설명하는 데 사용하는 용어도 있습니다. 테슬라화(Teslafication)라는 말을 들어보셨을 겁니다. 그들은 하드웨어와 더 관련된 벽돌과 박격포, 강철 및 철 유형의 사고와 달리 Tesla처럼되고 매우 소프트웨어 중심의 비즈니스가되어야한다고 말합니다. 점점 더 그들은 자신이 구축하고 있는 사물에서 실행되는 소프트웨어에서 제품을 차별화해야 합니다.

팬데믹은 또한 이러한 추세를 가속화했습니다. 대부분의 소프트웨어 중심 인력은 재택근무를 하고 있습니다. 그리고 많은 경우에 상당수의 직원이 이 일이 끝난 후에도 사무실로 돌아가지 않을 것입니다. 큰 변화입니다. 따라서 개발자에게 이러한 상황을 생산적으로 만들려면 작업에 대한 생각을 바꿔야 합니다. 도전입니다. 더 많은 사람들이 직접 대면하고 더 전통적인 방식으로 협업하지 않기 때문에 작업 수행 방식 측면에서 더 많은 협업 도구와 표준화가 필요합니다.

인사이트:다른 문제로 넘어가겠습니다. 빠른 소프트웨어 반복이 모든 산업에서 중요한 경쟁 우위를 차지하는 이유는 무엇입니까? 그리고 이것이 자동화 테스트의 필요성과 어떤 관련이 있습니까?

모피: 폭포수 모델에서 보다 민첩한 모델로 전환한 여러 프로젝트를 거쳤습니다. 지속적인 테스트를 수행하는 능력, 자동화된 테스트는 종종 생산성 향상 측면에서 제한 요소입니다. 빨리 달리고 여전히 품질을 유지하려면 필수품입니다. 이것은 최종 장치의 디지털 트윈을 사용하여 많은 테스트를 수행하고 대규모로 수행할 수 있는 특정 영역입니다.

임베디드에 적용할 수 있는 DevOps 측면에서 볼 수 있는 큰 발전 중 하나는 임베디드 장치의 시뮬레이션을 수행한 다음 클라우드 기반 환경에서 대규모로 사용할 수 있다는 것입니다. 그런 식으로 수백 개의 테스트를 동시에 실행할 수 있습니다. 클라우드 리소스에 의해서만 제한됩니다. 이는 많은 회사가 겪고 있는 변화 중 하나이며 궁극적으로 매우 높게 평가하는 것입니다.

우리는 수년 동안 WindRiver에서 시뮬레이션 사업을 해왔습니다. 얼리 어답터 중 일부는 서버에서 많은 수의 시뮬레이션을 확장하면서 많은 작업을 수행했습니다. 하지만 클라우드로 이전하면 6개월마다 새 서버를 구입할 필요가 없습니다.

사용 중인 하드웨어의 유형과 양을 제어할 수 있습니다. 대규모 하드웨어 및 IT 팀에서 유지 관리하는 데 드는 자본 비용을 들이지 않고 필요할 때 언제든지 전화를 걸고 줄일 수 있습니다. 현재 우리는 일부 테스트가 온프레미스에서 로컬로 수행되고 일부는 공용 클라우드에서 수행되는 균형 또는 일종의 하이브리드 클라우드 환경을 보고 있습니다.

RTI인사이트:우리가 빼먹은 다른 요점이 있습니까?

모피: DevOps와 임베디드 소프트웨어 개발을 보다 클라우드 네이티브, 클라우드 중심 환경으로 이동하는 것에 대해 이야기할 때, 개인적으로 제품 관리자로서 본 몇 가지 큰 변화가 있습니다.

그 중 하나가 협업입니다. Linux 빌드를 완료하려고 했습니다. 저는 검증된 Linux 엔지니어가 아닙니다. 빌드가 올바르게 작동하도록 하는 데 몇 가지 문제가 있었습니다. 이 작업을 수행하는 동안 Linux 소프트웨어 설계자 중 한 명이 내가 빌드에 여러 번 실패한 것을 볼 수 있었습니다. 그리고 그는 인스턴트 메시징 앱을 통해 저에게 연락하여 "이봐, 나는 당신이 어떤 문제를 겪고 있는 것을 보았고, 나는 살펴보았고, 당신은 단지 설정을 전환하기만 하면, 당신은 좋아질 것입니다. 그리고 방금 해결해 드렸습니다.”

내 PC에 소프트웨어가 설치된 다른 환경에서 개발 중이라면 아무도 내가 문제를 겪고 있다는 사실을 모를 것입니다. 나가서 물어봐야 겠습니다. 또한 같은 시나리오를 재현할 수는 없을 것입니다. 아마, 나는 하루 종일 붙어 있었을 것입니다. 그리고 얼마 지나지 않아 포기했을 수도 있습니다. 따라서 로컬에 설치할 필요가 없는 소프트웨어에 빠르게 액세스하고 일반적인 샌드박스에서 재생할 수 있는 기능은 본질적으로 이러한 종류를 가지고 있다는 것만으로도 이 변경 사항이 어떻게 작동하는지에 대한 큰 눈을 뜨게 했습니다. 팀 간의 공유 자산 수

RTIInsights:다른 것이 있습니까?

모퓨: 멀지 않은 미래에 우리가 기대하는 한 가지는 장치에서 데이터를 가져오고, 개발 환경에서 데이터를 가져오고, 소프트웨어를 개선하기 위해 다시 피드백하는 디지털 피드백 루프를 갖는 것입니다. AI와 머신 러닝도 여기에 영향을 미칩니다. 이러한 장치에서 어떤 종류의 정보를 얻을 수 있습니까? 모델이나 엔진의 대규모 클라우드 규모의 빅 데이터 유형으로 잠재적으로 분석한 다음 이를 향후 소프트웨어 개발에 제공하려면 어떻게 해야 합니까? 그러면 전체적으로 시스템을 최적화하는 데 도움이 될 수 있습니다.