Menggunakan DevOps untuk Mengatasi Tantangan Perangkat Lunak Tertanam
DevOps dianggap sebagai cara terbaik untuk memenuhi permintaan pasar perangkat lunak yang disematkan untuk lebih banyak aplikasi dan fitur baru, semuanya tersedia dalam waktu yang lebih singkat.
Badai sempurna sedang terjadi untuk pengembangan perangkat lunak perangkat tertanam. Perangkat tertanam berkembang biak, terutama karena opsi konektivitas baru, seperti 5G, memungkinkan aplikasi perangkat terhubung yang inovatif, dan penggunaannya berkembang, memanfaatkan kemampuan analitik dan kecerdasan buatan baru. Pada saat yang sama, kebutuhan siklus hidup perangkat, seperti merespons serangan siber yang terus berkembang, membuatnya perlu untuk membuat dan menerapkan perubahan perangkat lunak dengan cepat.
Kondisi ini menempatkan tuntutan baru pada staf pengembangan dan operasi. Semakin lama, DevOps dianggap sebagai cara terbaik untuk memenuhi permintaan pasar akan lebih banyak aplikasi dan fitur baru, semuanya tersedia dalam waktu yang lebih singkat. RTInsights baru-baru ini duduk bersama Graham Morphew, Direktur Senior Manajemen Produk di Wind River. Kami membahas tantangan pengembangan perangkat lunak perangkat yang disematkan, perbedaan antara DevOps untuk lingkungan tradisional dan perangkat yang disematkan, dan banyak lagi.
Berikut ringkasan percakapan kami.
RTInsights:Apa perbedaan DevOps untuk perangkat yang disematkan dengan pendekatan DevOps tradisional untuk mengembangkan perangkat lunak?
Morfe: Saat Anda melihat DevOps tradisional di lingkungan berbasis perusahaan TI, Anda memiliki lingkungan eksekusi di mana-mana. Anda sedang menjalankan server Intel di cloud, atau Anda menjalankan sesuatu di PC Intel. tertanam sangat berbeda. Lingkungan eksekusi akhir Anda biasanya merupakan arsitektur yang berbeda dari yang Anda gunakan untuk pengembangan. Ada lebih banyak tantangan karena keragaman perangkat keras akhir dan cara Anda menerapkannya. Misalnya, saat Anda membangun perangkat lunak untuk lingkungan berbasis cloud, Anda tahu itu terjadi di lingkungan Google Cloud, Azure, atau AWS. Saat Anda membuat perangkat lunak yang disematkan, keragaman pilihan untuk lingkungan penerapan hampir tidak terbatas, dan Anda juga dapat memiliki perangkat di lokasi yang jauh.
Jadi, ada banyak perbedaan dalam hal cara Anda berpikir tentang perangkat lunak dan bagaimana perbedaan ini diterjemahkan ke dalam tantangan implementasi DevOps.
Anda harus bersaing dengan perangkat keras khusus, kompilasi silang, debug silang, jejak memori, dan masalah keamanan. Anda tidak memiliki sumber daya yang hampir tak terbatas di ujung jari Anda seperti yang Anda lakukan di lingkungan cloud. Ada pulau eksekusi yang perlu Anda ingat saat merancang sistem ini. Anda juga memiliki keamanan yang perlu dikhawatirkan. Anda tidak perlu memiliki kontrol fisik atas keamanan perangkat. Anda mungkin harus menghadapi gangguan fisik pada perangkat.
Tantangan lainnya adalah data dari perangkat ini lebih sulit dikumpulkan. Di lingkungan DevOps, Anda menginginkan loop umpan balik berkelanjutan. Itu mudah jika pengembangan ada di server yang berada di bawah kendali Anda. Ketika Anda berbicara tentang perangkat, mereka kemungkinan akan didistribusikan dari jarak jauh, dan mereka mungkin tidak online sepanjang waktu. Jadi, banyak masalah berbeda yang muncul saat membandingkan DevOps dan DevOps tradisional Anda untuk perangkat lunak yang disematkan.
RTInsights:Mengapa komunitas perangkat yang disematkan akan beralih ke DevOps? Mengapa ini menjadi menarik, dan apa yang terjadi di pasar untuk mendorong ini?
Morfem: Dengan perangkat lunak yang disematkan, ada kebutuhan yang meningkat untuk pembaruan yang lebih sering dan kualitas yang lebih tinggi. Untuk sampai ke sana, Anda memerlukan otomatisasi untuk membantu Anda di sepanjang jalan. Otomatisasi akan memainkan peran besar di masa depan perangkat lunak yang disematkan DevOpsand. Jika Anda kembali satu atau dua dekade, ada banyak fokus pada perangkat keras yang mendorong kemampuan perangkat. Sekarang, lebih banyak lagi teknologi pembeda di antara vendor perangkat adalah perangkat lunak.
Faktor lain yang mendorong perusahaan menuju DevOps untuk sistem tertanam adalah sesuatu yang kita lihat di Wind River sedikit:perubahan demografi pengembangan perangkat lunak.
Ada dua kubu yang sangat berbeda. Anda memiliki pengembang perangkat lunak tertanam tradisional dan lulusan baru atau pengembang yang memasuki domain perangkat cerdas dari domain perangkat lunak lain. Pengembang tradisional cenderung lebih tua, dan banyak yang pensiun. Seperti saya, ada orang yang masuk ke pasar setelah lulus dari perguruan tinggi pada saat Anda akan melihat manual perangkat keras, register program, dan hal-hal seperti itu. Itu bukan sesuatu yang program perguruan tinggi menghabiskan banyak waktu sekarang.
Saya memiliki seorang putra yang usia kuliah sekarang. Dia memprogram dengan Python. Dia baru belajar C untuk pertama kalinya, dan itu sangat membuka mata. Python menawarkan tingkat abstraksi yang jauh lebih tinggi.
DevOps dapat membantu mengatasi hambatan ini antara lingkungan aplikasi dan ingin membuatnya terlihat seperti lingkungan yang akrab bagi pengembang perangkat lunak perangkat. Kebutuhan untuk melakukan ini adalah bahwa perusahaan yang membangun perangkat mengalami kesulitan memperoleh bakat pengembangan perangkat lunak baru.
Saya sedang berbicara dengan seseorang yang baru-baru ini kami pekerjakan sebagai magang, dan dia memberi tahu kami bahwa banyak teman sekelasnya ingin pergi ke Silicon Valley dan bekerja untuk perusahaan seperti Facebook, Google, Apple, dan Tesla. Untuk perusahaan di segmen industri atau kedirgantaraan dan pertahanan, mungkin lebih sulit untuk menarik bakat perangkat lunak yang dibutuhkan yang akan datang dan memprogram perangkat tertanam di lingkungan C yang belum sempurna.
Untuk mengatasi ini, beberapa perusahaan berpikir bahwa memberikan generasi baru pengembang perangkat lunak lingkungan yang mereka kenal akan membantu. Dan itulah salah satu alasan mengapa Wind River mengadopsi lingkungan Visual Studio Code. Visual Studio Code adalah lingkungan yang telah mengalami pertumbuhan pesat dalam popularitas sejak masuk ke pasar. Setiap orang yang kami ajak bicara, datang dari perspektif lulusan baru, sangat akrab dengan VS Code, dan kami melihat lebih sedikit pengalaman dari pengembang baru dengan lingkungan yang lebih lama seperti Eclipse. Jadi, terkadang Anda harus berada di posisi audiens Anda.
RTInsights:Masalah apa yang dihadapi perusahaan saat mereka mencoba mengadopsi solusi DevOps? Dan apa tantangan utama untuk ranah perangkat tersemat versus domain lain?
Morfe: Tantangan terbesar adalah pergeseran budaya yang harus terjadi di dalam perusahaan. Dan ini belum tentu merupakan tantangan khusus yang disematkan. Ini lebih mendarah daging dalam beberapa praktik pengembangan perangkat lunak.
Anda memiliki tim kecil, dan dalam banyak kasus, Anda memiliki individu yang melakukan tugas yang sangat spesifik. Anda memerlukan tingkat kolaborasi dan kerja sama dengan DevOps yang terkadang membawa orang keluar dari ranah yang sudah nyaman bagi mereka selama beberapa tahun. Anda harus mengatakan, “Semua orang bekerja sama.”
Bagian Ops dari DevOps untuk disematkan merupakan tantangan karena, dalam lingkungan DevOps tradisional untuk cloud, Opsi cukup standar. Anda menjalankan situs web atau mengembangkan aplikasi yang melakukan sesuatu melalui antarmuka berbasis cloud. Saat Anda berbicara tentang tertanam, Anda berbicara tentang perangkat di lapangan, dan apa yang dilakukan perangkat itu khusus untuk perusahaan Anda. Dalam banyak kasus, produsen perangkat bukanlah perusahaan yang mengoperasikan perangkat tersebut. Pabrikan peralatan mungkin menjual perangkatnya ke perusahaan listrik besar atau pabrikan besar. Perusahaan-perusahaan itu adalah orang-orang yang mengoperasikan perangkat. Terkadang ada bantuan dari produsen perangkat, tetapi itu bukan loop tertutup seperti yang mungkin Anda lihat dengan solusi berbasis cloud.
Ada masalah kompatibilitas toolset.Memiliki lingkungan pengembangan yang sama terkadang menemui hambatan. Jadi kembali ke beberapa dukungan budaya dan manajemen yang Anda butuhkan untuk mengimplementasikan sistem ini.
Dan kemudian ada masalah perangkat keras lagi. Ini adalah tema umum di pasar tertanam. Bagaimana Anda mendapatkan cukup perangkat keras untuk membangun lingkungan otomatisasi yang diperlukan untuk membuat DevOps menjadi nyata? Itu adalah tantangan yang berkelanjutan. Biasanya, pelanggan yang sukses memiliki campuran perangkat keras dan simulasi untuk meningkatkan proses pengujian mereka.
RTInsights:Apakah ada alat yang akan mempermudah transisi ke DevOps?
Morfem: Satu hal yang membantu perusahaan melewati revolusi ini adalah ketersediaan alat. Banyak dari alat ini adalah opensource atau memiliki versi gratis. Apa yang sering Anda lihat adalah konsolidasi di sekitar beberapa rasa Manajemen Kode Sumber, sering kali rasa Git. Sekarang, organisasi telah beralih dari solusi yang sangat berpusat pada Manajemen Kode Sumber menjadi memasukkan lebih banyak jenis alat DevOps ke dalam solusi mereka. Itu membantu perusahaan melakukan transisi.
Ada banyak pilihan. Anda mungkin berdebat terkadang ada terlalu banyak pilihan. Tantangan yang kami lihat pelanggan miliki sekarang adalah, ya, ada banyak alat. Bagaimana cara menyatukannya menjadi solusi yang cocok untuk saya?
Saat ini, banyak perusahaan memulai proyek di mana mereka membentuk tim secara internal untuk mengelola transisi mereka ke lingkungan pengembangan yang lebih berfokus pada digital. Kami melihat transisi terjadi sekarang di ruang tertanam seperti apa yang kami lihat dengan transisi teknologi lainnya. Dalam banyak kasus, ini adalah mentalitas do-it-yourself, "Mari kita bangun sistem yang sempurna untuk kita, mari kita sesuaikan dengan kebutuhan kita." Upaya semacam itu menguras semakin banyak sumber daya dari perusahaan hanya untuk mempertahankan hal-hal ini di masa mendatang. Itu belum tentu mereka ingin berinvestasi. Pendekatan itu kemungkinan akan berkembang menjadi pendekatan di mana orang mencari agar perusahaan lain mempertahankan lebih banyak lingkungan mereka dari waktu ke waktu.
Area lain di mana, pada akhirnya, perusahaan dapat membuat hidup mereka lebih mudah adalah memiliki pemisahan yang jelas antara pengembangan aplikasi dan pemeliharaan platform perangkat lunak yang mereka jalankan. Dulu Anda memiliki tim kecil yang melakukan keduanya, dan aplikasi serta platform bergabung satu sama lain. Namun sekarang, Anda memerlukan pemisahan yang jelas untuk memodulasi perangkat lunak Anda dan membuat orang-orang mengerjakan keahlian terbaik mereka.
RTInsights:Apa pendorong industri untuk solusi yang mempermudah pengembangan dan pengujian perangkat lunak untuk perangkat yang disematkan?
Morphew :Ada konvergensi dunia TI dan PL. Anda memiliki perangkat yang terhubung ke Internet. Ini telah menjadi pendorong besar bagi perusahaan untuk memeriksa ulang bagaimana mereka memberikan perangkat lunak. Juga, ada beberapa industri di mana Anda memiliki persyaratan terkait kepatuhan untuk memperbarui perangkat lunak di perangkat. Anda melihat bahwa di bidang medis, di mana sekarang Anda harus membuktikan bahwa Anda dapat memperbarui perangkat Anda jika kerentanan keamanan diketahui. Ini bisa menjadi skenario hidup atau mati. Anda harus dapat membuktikan bahwa Anda dapat mengatasi masalah seperti itu jika ada yang muncul.
Driver semacam itu mendorong perusahaan untuk melihat proses yang mereka gunakan terkait kemampuan mereka untuk melakukan pembaruan jarak jauh. Apa yang kami lihat adalah banyak perusahaan besar merasakan ancaman dari perusahaan baru dan yang akan datang secara digital asli ini. Bahkan ada istilah yang mereka gunakan untuk menggambarkannya. Anda mendengar istilah Teslafikasi. Mereka mengatakan bahwa mereka perlu menjadi lebih seperti Tesla dan menjadi bisnis yang sangat, sangat berfokus pada perangkat lunak, sebagai lawan dari jenis pemikiran bata dan mortir, baja, dan besi yang lebih terkait dengan perangkat keras. Semakin banyak, mereka harus membedakan produk mereka pada perangkat lunak yang berjalan pada hal-hal yang mereka bangun.
Pandemi juga mempercepat tren ini. Anda memiliki sebagian besar tenaga kerja yang berfokus pada perangkat lunak yang bekerja dari rumah. Dan dalam banyak kasus, sejumlah besar karyawan tidak akan kembali ke kantor setelah ini selesai. Itu perubahan besar. Jadi, Anda perlu mengubah cara berpikir Anda tentang bekerja untuk membuat situasi itu produktif bagi pengembang. Itu tantangan. Ini menuntut, sampai batas tertentu, untuk lebih banyak alat kolaborasi dan lebih banyak standarisasi dalam hal cara menyelesaikan sesuatu karena Anda tidak memiliki banyak orang yang bekerja tatap muka dan berkolaborasi dengan cara yang lebih tradisional.
RTInsights:Pindah ke masalah yang berbeda, mengapa iterasi perangkat lunak yang cepat menjadi keunggulan kompetitif yang kritis di setiap industri? Dan bagaimana hubungannya dengan kebutuhan akan pengujian otomatis?
Morfe: Saya telah melalui beberapa proyek yang beralih dari model air terjun ke model yang lebih gesit. Kemampuan untuk melakukan pengujian berkelanjutan, pengujian otomatis sering kali menjadi faktor pembatas dalam hal meningkatkan produktivitas Anda. Jika Anda ingin berlari cepat dan Anda masih ingin mempertahankan kualitas Anda, itu adalah suatu keharusan. Ini adalah area tertentu di mana memiliki kembaran digital dari perangkat akhir memungkinkan Anda melakukan banyak pengujian pada perangkat tersebut, dan Anda dapat melakukannya dalam skala besar.
Salah satu kemajuan besar yang kami lihat dalam hal DevOps dapat diterapkan pada perangkat yang disematkan adalah kemampuan untuk mengambil simulasi perangkat yang disematkan dan kemudian menggunakannya dalam skala besar di lingkungan berbasis cloud. Dengan cara itu, Anda dapat menjalankan seratus tes secara bersamaan. Anda hanya dibatasi oleh sumber daya cloud. Itulah salah satu transformasi yang kami lihat dialami sejumlah perusahaan dan sesuatu yang pada akhirnya sangat mereka hargai.
Kami telah memiliki bisnis simulasi di WindRiver selama bertahun-tahun. Beberapa pengadopsi awal melakukan banyak hal ini di server mereka, meningkatkan simulasi dalam jumlah besar. Namun saat Anda memindahkannya ke cloud, Anda tidak perlu membeli server baru setiap enam bulan.
Anda memiliki kendali atas jenis perangkat keras yang Anda gunakan dan jumlahnya. Anda dapat melakukan dial up dan dial down tergantung pada apa yang Anda butuhkan pada satu waktu, daripada harus mengeluarkan modal besar untuk perangkat keras dan tim TI untuk memeliharanya. Saat ini, kami melihat keseimbangan atau semacam lingkungan cloud hybrid, di mana beberapa pengujian dilakukan secara lokal di tempat, dan beberapa di antaranya di cloud publik.
Wawasan RT:Apakah ada poin lain yang ingin Anda kemukakan yang belum kami sampaikan?
Morfe: Ketika Anda berbicara tentang DevOps dan memindahkan pengembangan perangkat lunak yang disematkan ke lingkungan yang lebih cloud-native dan berfokus pada cloud, ada beberapa hal yang saya lihat secara pribadi sebagai manajer produk yang merupakan perubahan besar.
Salah satunya adalah kerjasama. Saya mencoba menyelesaikan build Linux. Saya bukan insinyur Linux yang terbukti benar. Saya mengalami beberapa masalah dalam membuat build berfungsi dengan benar. Dan ketika saya melakukan ini, salah satu arsitek perangkat lunak Linux kami dapat melihat bahwa saya memiliki beberapa build yang gagal. Dan dia menghubungi saya melalui aplikasi perpesanan instan dan berkata, “Hei, saya telah melihat bahwa Anda mengalami beberapa masalah, saya telah melihat, dan Anda hanya perlu mengubah pengaturan, dan Anda akan baik-baik saja. Dan saya baru saja melanjutkan dan memperbaikinya untuk Anda.”
Jika saya berkembang di lingkungan yang berbeda di mana saya memiliki perangkat lunak yang diinstal pada PC saya, tidak ada yang akan tahu bahwa saya mengalami masalah. Saya harus keluar dan bertanya. Juga, kemungkinan besar saya tidak akan dapat membuat ulang skenario yang sama. Kemungkinan besar, saya akan terjebak di dalamnya sepanjang hari. Dan, saya mungkin baru saja menyerah setelah beberapa saat. Jadi, kemampuan untuk mendapatkan akses cepat ke perangkat lunak yang tidak perlu Anda instal secara lokal, dan kemampuan untuk bermain di kotak pasir umum, bagi saya, adalah pembuka mata yang besar tentang bagaimana perubahan ini menunjukkan Anda bekerja, hanya dari dasarnya memiliki jenis ini aset bersama di antara tim Anda.
RTInsights:Ada lagi?
Morfem: Satu hal yang kami nantikan dalam waktu yang tidak terlalu lama adalah memiliki loop umpan balik digital di mana Anda mengambil data dari perangkat, mengeluarkan data dari lingkungan pengembangan Anda, dan memasukkannya kembali untuk meningkatkan perangkat lunak Anda. AI dan pembelajaran mesin juga berperan dalam hal ini. Informasi apa yang bisa saya dapatkan dari perangkat ini? Bagaimana saya bisa menganalisisnya secara potensial dengan skala besar, tipe data besar dari model atau mesin, dan kemudian memasukkannya kembali ke dalam pengembangan perangkat lunak di masa depan? Itu bisa membantu saya mengoptimalkan sistem secara keseluruhan.
