Memanfaatkan DevOps untuk Mengatasi Tantangan Perangkat Lunak Terdiri
DevOps dianggap cara terbaik untuk memenuhi permintaan pasar perangkat lunak terpadu untuk lebih banyak aplikasi dan fitur baru, semuanya tersedia dalam waktu yang lebih pendek.
Sejumlah kondisi menyatu untuk pengembangan perangkat lunak perangkat terpadu. Perangkat terpadu semakin berkembang, terutama seiring dengan opsi konektivitas baru seperti 5G yang memungkinkan aplikasi perangkat terhubung inovatif, dan penggunaannya semakin meluas, memanfaatkan kemampuan analitik dan kecerdasan buatan baru. Pada saat yang sama, kebutuhan siklus hidup perangkat, seperti merespons ancaman siber yang berkembang, membuatnya perlu untuk segera menciptakan dan menerapkan perubahan perangkat lunak.
Kondisi ini menempatkan tuntutan baru pada staf pengembangan dan operasi. Secara berkala, DevOps dianggap cara terbaik untuk memenuhi tuntutan pasar untuk lebih banyak aplikasi dan fitur baru, semuanya tersedia dalam waktu yang lebih pendek. RTInsights baru-baru ini duduk bersama Graham Morphew, Senior Director of Product Management di Wind River. Kami membahas tantangan pengembangan perangkat lunak perangkat terpadu, perbedaan antara DevOps untuk lingkungan tradisional dan perangkat terpadu, dan lebih banyak.
Berikut adalah ringkasan percakapan kami.
RTInsights: Bagaimana DevOps untuk perangkat terpadu berbeda dari pendekatan DevOps tradisional dalam mengembangkan perangkat lunak?
Morphew: Ketika Anda melihat DevOps tradisional dalam lingkungan perusahaan IT berbasis, Anda memiliki lingkungan eksekusi yang seragam. Anda berjalan pada server Intel di cloud, atau Anda memiliki sesuatu yang berjalan pada PC Intel. Terdapat sangat berbeda. Lingkungan eksekusi akhir Anda biasanya 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 akan masuk ke lingkungan Google Cloud, Azure, atau AWS. Saat Anda membangun perangkat lunak terpadu, keragaman pilihan untuk lingkungan penerapan hampir tak terbatas, dan Anda juga mungkin memiliki perangkat di lokasi terpencil.
Jadi, ada banyak perbedaan dalam hal cara Anda memikirkan perangkat lunak dan bagaimana perbedaan ini diterjemahkan menjadi tantangan implementasi DevOps.
Anda harus berhadapan dengan perangkat keras khusus, cross-compiling, cross-debugging, memori footprint, dan isu keamanan. Anda tidak memiliki sumber daya yang hampir tak terbatas di ujung jari Anda seperti yang Anda miliki dalam lingkungan cloud. Ada pulau eksekusi yang perlu Anda ingat saat merancang sistem ini. Anda juga memiliki keamanan untuk dikhawatirkan. Anda tidak selalu memiliki kontrol fisik atas keamanan perangkat. Anda mungkin harus berhadapan dengan manipulasi fisik perangkat.
Tantangan lain adalah data dari perangkat ini lebih sulit untuk dikumpulkan. Dalam lingkungan DevOps, Anda ingin loop umpan balik berkelanjutan. Itu mudah jika pengembangan ada pada server yang berada di bawah kontrol Anda. Saat Anda berbicara tentang perangkat, mereka kemungkinan besar terdistribusi secara jarak jauh, dan mereka mungkin tidak selalu online. Jadi, banyak masalah berbeda masuk ke dalam perbandingan antara DevOps tradisional Anda dan DevOps untuk perangkat lunak terpadu.
RTInsights: Mengapa komunitas perangkat terpadu akan bergerak menuju DevOps? Mengapa ini menjadi menarik, dan apa yang terjadi di pasar untuk mendorong ini?
Morphew: Dengan perangkat lunak terpadu, ada kebutuhan yang meningkat untuk pembaruan yang lebih sering dan kualitas yang lebih tinggi. Untuk sampai ke sana, Anda membutuhkan otomatisasi untuk membantu Anda di sepanjang jalan. Otomatisasi akan memainkan peran besar di masa depan DevOps dan perangkat lunak terpadu. Jika Anda kembali satu atau dua dekade lalu, ada banyak fokus pada perangkat keras yang mendorong kemampuan perangkat. Sekarang, lebih banyak lagi dari teknologi yang membedakan di antara vendor perangkat adalah perangkat lunak.
Faktor lain yang mendorong perusahaan menuju DevOps untuk sistem terpadu adalah sesuatu yang kami lihat cukup banyak di Wind River: demografi pengembangan perangkat lunak yang berubah.
Ada dua kamp yang sangat berbeda. Anda memiliki pengembang perangkat lunak terpadu tradisional dan lulusan baru atau pengembang yang memasuki domain perangkat cerdas dari domain perangkat lunak lainnya. Pengembang tradisional cenderung lebih tua, dan banyak yang pensiun. Seperti saya, ada orang yang memasuki pasar saat kuliah pada waktu di mana Anda akan melihat manual perangkat keras, memprogram register, dan hal-hal serupa. Itu bukan sesuatu yang program kuliah luangkan banyak waktu padanya sekarang.
Saya memiliki seorang anak yang baru saja kuliah. Dia memprogram dalam Python. Dia baru saja mempelajari C untuk pertama kalinya, dan itu adalah pembukaan mata yang besar. Python menawarkan tingkat abstrak yang jauh lebih tinggi.
DevOps dapat membantu mengatasi hambatan ini antara lingkungan aplikasi dan ingin membuatnya terlihat seperti lingkungan yang familiar bagi pengembang perangkat lunak. Kebutuhan untuk melakukan ini adalah perusahaan yang membangun perangkat kesulitan mendapatkan talenta pengembangan perangkat lunak baru.
Saya sedang berbicara dengan seseorang yang kami sebut sebagai magang baru-baru ini, dan dia memberitahu 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 aerospace dan pertahanan, mungkin lebih menarik untuk menarik talenta perangkat lunak yang dibutuhkan yang akan masuk dan memprogram perangkat terpadu dalam lingkungan C yang dasar.
Untuk mengatasi ini, beberapa perusahaan berpikir bahwa memberikan generasi baru pengembang perangkat lunak lingkungan yang mereka kenal akan membantu. Dan itu salah satu alasan mengapa Wind River mengadopsi lingkungan Visual Studio Code. Visual Studio Code adalah lingkungan yang telah melihat pertumbuhan popularitas yang cepat sejak hadir ke pasar. Semua orang yang kami bicara, dari sudut pandang lulusan baru, sangat familiar dengan VS Code, dan kami melihat pengalaman yang lebih sedikit dari pengembang baru dengan lingkungan lama seperti Eclipse. Jadi, terkadang Anda harus berada di mana audiens Anda sudah ada.
RTInsights: Apa masalah yang dihadapi perusahaan saat mereka mencoba mengadopsi solusi DevOps? Dan apa tantangan utama untuk domain perangkat terpadu dibandingkan dengan domain lainnya?
Morphew: Tantangan terbesar adalah perpindahan budaya yang harus terjadi di dalam perusahaan. Dan ini tidak tentu tantangan spesifik terpadu. Ini lebih dalam tertanam dalam beberapa praktik pengembangan perangkat lunak.
Anda memiliki tim kecil, dan dalam banyak kasus, Anda memiliki individu yang melakukan tugas yang sangat spesifik. Anda membutuhkan tingkat kolaborasi dan kerja sama dengan DevOps yang kadang mengeluarkan orang dari lingkungan yang mereka nyamai selama beberapa tahun. Anda harus mengatakan, "Semua orang bekerja bersama."
Bagian Ops dari DevOps untuk terpadu adalah tantangan karena, dalam lingkungan DevOps tradisional untuk cloud, Ops cukup standar. Anda menjalankan situs web atau mengembangkan aplikasi yang melakukan sesuatu melalui antarmuka berbasis cloud. Saat Anda berbicara tentang terpadu, Anda berbicara tentang perangkat di lapangan, dan apa yang dilakukan perangkat tersebut spesifik untuk perusahaan Anda. Dalam banyak kasus, pabrikan perangkat bukanlah perusahaan yang mengoperasikan perangkat. Pabrikan peralatan mungkin menjual perangkatnya kepada perusahaan listrik besar atau pabrikan besar. Perusahaan inilah yang mengoperasikan perangkat. Kadang ada bantuan dari pabrikan perangkat, tetapi itu bukan loop tertutup sepenuhnya seperti yang Anda lihat dengan solusi berbasis cloud.
Ada masalah kompatibilitas toolset. Memiliki lingkungan pengembangan yang sama kadang bertemu resistensi. Jadi itu kembali ke beberapa dukungan budaya dan manajemen yang Anda butuhkan untuk menerapkan sistem ini.
Dan kemudian ada masalah perangkat keras lagi. Itu adalah tema umum di pasar terpadu. Bagaimana Anda mendapatkan cukup perangkat keras untuk membangun lingkungan otomatisasi yang diperlukan untuk menjadikan DevOps kenyataan? Itu tantangan berkelanjutan. Biasanya, pelanggan yang sukses memiliki campuran perangkat keras dan simulasi untuk meningkatkan proses pengujian mereka.
RTInsights: Apakah ada alat yang akan membuat transisi ke DevOps lebih mudah?
Morphew: Salah satu hal yang membantu perusahaan melewati revolusi ini adalah ketersediaan alat. Banyak alat ini adalah open source atau memiliki versi gratis. Apa yang sering Anda lihat adalah konsolidasi di sekitar beberapa varian Manajemen Kode Sumber, sering varian Git. Sekarang, organisasi telah beralih dari memiliki solusi yang sangat berpusat pada Manajemen Kode Sumber untuk mencakup lebih dan lebih alat jenis DevOps dalam solusi mereka. Itu membantu perusahaan melakukan transisi.
Ada banyak pilihan. Anda mungkin berpendapat terkadang ada terlalu banyak pilihan. Tantangan yang kami lihat pelanggan hadapi sekarang adalah, ya, ada banyak alat. Bagaimana saya menyatukan mereka ke dalam solusi yang bekerja untuk saya?
Hari ini, banyak perusahaan memulai proyek di mana mereka membentuk tim internal untuk mengelola transisi mereka ke lingkungan pengembangan yang lebih berfokus digital. Kami melihat transisi yang sedang terjadi sekarang di ruang terpadu seperti yang kami lihat dengan transisi teknologis lainnya. Dalam banyak kasus, itu sangat mental do-it-yourself dari, "Ayo buat sistem yang sempurna untuk kita, ayo kustomisasi untuk kebutuhan kita." Upaya semacam ini menghabiskan lebih dan lebih sumber daya dari perusahaan hanya untuk memelihara hal-hal ini di masa depan. Itu tidak tentu di mana mereka ingin berinvestasi. Pendekatan itu kemungkinan akan berevolusi menjadi satu di mana orang mencari perusahaan lain untuk memelihara lebih banyak lingkungan mereka seiring waktu.
Area lain di mana, pada akhirnya, perusahaan dapat membuat hidup mereka lebih mudah adalah dengan memiliki pemisahan yang jelas antara pengembangan aplikasi dan memelihara platform perangkat lunak yang mereka jalankan. Dulu Anda memiliki tim kecil yang melakukan keduanya, dan aplikasi serta platform bergabung satu sama lain. Tetapi sekarang, Anda perlu pemisahan yang jelas untuk memodularisasi perangkat lunak Anda dan memiliki orang yang bekerja pada apa yang paling sesuai dengan keterampilan mereka.
RTInsights: Apa driver industri untuk solusi yang memudahkan mengembangkan dan menguji perangkat lunak untuk perangkat terpadu?
Morphew: Ada konvergensi dunia IT dan OT. Anda memiliki perangkat yang terhubung ke Internet. Ini telah menjadi driver besar untuk perusahaan untuk mengevaluasi ulang cara mereka menyampaikan perangkat lunak. Juga, ada beberapa industri di mana Anda memiliki persyaratan terkait kepatuhan untuk memperbarui perangkat lunak di perangkat. Anda melihat ini di bidang medis, di mana sekarang Anda harus membuktikan bahwa Anda dapat memperbarui perangkat Anda jika kerentanan keamanan diketahui. Ini dapat menjadi skenario hayat atau mati. Anda perlu dapat membuktikan bahwa Anda dapat mengatasi masalah semacam itu jika muncul.
Driver semacam ini mendorong perusahaan untuk melihat proses yang mereka gunakan terkait dengan kemampuan mereka untuk melakukan pembaruan jarak jauh. Apa yang kami lihat adalah banyak perusahaan besar merasa ancaman dari perusahaan baru yang lahir digital dan sedang naik daun ini. Ada istilah yang mereka gunakan untuk menggambarnya. Anda mendengar istilah Teslafication. Mereka mengatakan mereka perlu lebih seperti Tesla dan menjadi bisnis yang sangat, sangat berfokus perangkat lunak, alih-alih pemikiran jenis batu bata dan mortar, baja, dan besi yang lebih terkait dengan perangkat keras. Semakin banyak, mereka harus membedakan produk mereka pada perangkat lunak yang berjalan pada hal yang mereka bangun.
Pandemi juga telah mempercepat tren ini. Sebagian besar tenaga kerja berfokus perangkat lunak bekerja dari rumah. Dan dalam banyak kasus, sejumlah signifikan karyawan tidak akan kembali ke kantor setelah ini berakhir. Itu adalah perpindahan besar. Jadi, Anda perlu mengubah cara Anda memikirkan pekerjaan untuk membuat situasi ini produktif bagi pengembang. Itu adalah tantangan. Ini memanggil, hingga sejauh ini, untuk lebih banyak alat kolaborasi dan lebih banyak standarisasi dalam hal cara hal dilakukan karena Anda tidak memiliki banyak orang yang bekerja face-to-face dan berkolaborasi dengan cara yang lebih tradisional.
RTInsights: Beralih ke masalah yang berbeda, mengapa iterasi perangkat lunak yang cepat telah menjadi keunggulan kompetitif yang krusial di setiap industri? Dan bagaimana itu terkait dengan kebutuhan akan pengujian otomatis?
Morphew: Saya telah melalui beberapa proyek yang bertransisi dari model waterfall ke model yang lebih agile. Kemampuan untuk melakukan pengujian berkelanjutan, pengujian otomatis sering kali adalah faktor pembatas dalam hal meningkatkan produktivitas Anda. Jika Anda akan berjalan cepat dan Anda masih ingin mempertahankan kualitas Anda, itu adalah keharusan. Ini adalah area khusus di mana memiliki digital twin dari perangkat akhir Anda memungkinkan Anda melakukan banyak pengujian padanya, dan Anda dapat melakukannya dalam skala besar.
Salah satu kemajuan besar yang kami lihat dalam hal DevOps yang dapat diterapkan pada terpadu adalah kemampuan untuk mengambil simulasi dari perangkat terpadu dan kemudian menggunakannya dalam skala besar dalam lingkungan berbasis cloud. Dengan cara itu, Anda dapat memiliki seratus pengujian yang berjalan secara bersamaan. Anda hanya terbatas oleh sumber daya cloud. Itu salah satu transformasi yang kami lihat sejumlah perusahaan melalui dan sesuatu yang pada akhirnya mereka hargai cukup tinggi.
Kami memiliki bisnis simulasi di Wind River selama bertahun-tahun. Beberapa adopter awal banyak melakukan ini pada server mereka, meningkatkan sejumlah besar simulasi. Tetapi saat Anda memindahkannya ke cloud, Anda tidak perlu membeli server baru setiap enam bulan.
Anda memiliki kontrol atas jenis perangkat keras yang Anda gunakan dan jumlahnya. Anda dapat menambah atau menguranginya tergantung pada apa yang Anda butuhkan pada setiap saat, alih-alih memiliki biaya modal perangkat keras besar dan tim IT untuk memeliharanya. Sekarang, kami melihat keseimbangan atau jenis lingkungan cloud hibrid, di mana sebagian pengujian dilakukan secara lokal di on-premises, dan sebagian ada di cloud publik.
RTInsights: Apakah ada poin lain yang ingin Anda sampaikan yang kami tinggalkan?
Morphew: Saat Anda berbicara tentang DevOps dan memindahkan pengembangan perangkat lunak terpadu ke lingkungan yang lebih cloud-native dan berfokus cloud, ada beberapa hal yang telah saya lihat secara pribadi sebagai product manager yang merupakan perubahan besar.
Salah satunya adalah kolaborasi. Saya mencoba menyelesaikan build Linux. Saya bukan insinyur Linux yang handal. Saya mengalami beberapa masalah untuk membuat build berjalan dengan benar. Dan saat saya melakukan ini, salah satu arsitek perangkat lunak Linux kami dapat melihat bahwa saya telah memiliki beberapa build yang gagal. Dan dia menghubungi saya melalui aplikasi pesan instan dan mengatakan, "Hey, saya melihat Anda mengalami beberapa masalah, saya telah melihat, dan Anda hanya perlu mengganti pengaturan, dan Anda akan baik-baik saja. Dan saya telah memperbaikinya untuk Anda."
Jika saya mengembangkan di lingkungan yang berbeda di mana saya menginstal perangkat lunak di PC saya, tidak ada yang akan pernah tahu bahwa saya mengalami masalah. Saya harus pergi dan bertanya. Juga, kemungkinan besar saya tidak akan dapat menciptakan skenario yang sama lagi. Kemungkinan besar, saya akan macet padanya sepanjang hari. Dan, saya mungkin akan menyerah setelah beberapa waktu. Jadi, kemampuan untuk mendapatkan akses cepat ke perangkat lunak yang Anda tidak perlu instal secara lokal, dan dapat bermain dalam kotak pasir bersama, bagi saya, adalah pembukaan mata besar tentang bagaimana ini mengubah cara Anda bekerja, hanya dari pada memiliki aset bersama semacam itu di antara tim Anda.
RTInsights: Ada yang lain?
Morphew: Satu hal yang kami tunggu di masa depan yang tidak terlalu jauh adalah memiliki loop umpan balik digital di mana Anda mengambil data dari perangkat, mengambil data dari lingkungan pengembangan Anda, dan memberi kembali untuk meningkatkan perangkat lunak Anda. AI dan machine learning juga terlibat dalam hal ini. Apa macam informasi yang bisa saya dapatkan dari perangkat ini? Bagaimana saya dapat menganalisisnya potensial dengan model atau mesin tipe big data skala cloud besar, dan kemudian memberi kembali ke dalam pengembangan perangkat lunak di masa depan? Itu dapat membantu saya mengoptimalkan sistem secara keseluruhan.
