Kesenjangan bakat pengembang sangat nyata. Menurut IDC, akan terjadi kekurangan global sebanyak empat juta pengembang pada tahun 2025. Analisis lain yang lebih mengerikan, memperkirakan kekurangan saat ini mencapai 40 juta pengembang di seluruh dunia dan diperkirakan akan mencapai lebih dari 85 juta pada tahun 2030.
Sementara Biro Statistik Tenaga Kerja AS saat ini menunjukkan ada lebih dari 1,6 juta pengembang yang bekerja di AS, jumlah ini diperkirakan akan tumbuh sebesar 25 persen menjadi lebih dari dua juta pada tahun 2031, jauh lebih cepat daripada rata-rata untuk semua pekerjaan. Terlepas dari pertumbuhan ini, permintaan pengembang diperkirakan akan melebihi ketersediaan keterampilan untuk beberapa tahun mendatang. Ada banyak penyebab untuk ini, termasuk pesatnya pertumbuhan transformasi digital, meningkatnya kompleksitas pengembangan perangkat lunak dan banyak lagi. Tapi satu hal yang pasti – pertarungan untuk mendapatkan bakat akan sengit, dan penting bagi organisasi untuk fokus menjaga agar bakat pengembang mereka tetap bahagia dan berada di tempatnya.
Mengidentifikasi Stres yang Dapat Dihindari
Semua ini datang pada saat organisasi menghadapi tekanan yang lebih luar biasa dari sebelumnya untuk mendigitalkan operasi dan menciptakan pengalaman yang berbeda. Pada akhirnya, pengembanglah yang memikul tanggung jawab untuk ini, dan menurut statistik, 83 persen dari mereka melaporkan merasa lelah. Pengembang adalah orang yang memegang kunci sebagian besar pengetahuan institusional Anda, jadi sangat penting untuk mempertahankannya. Dalam banyak kasus, ini berarti meminimalkan sebanyak mungkin sumber stres dan perselisihan yang dapat dihindari.
Beberapa sumber stres pengembang tidak dapat dihindari — akan selalu ada tenggat waktu yang ketat, bug yang harus diperbaiki, dan permintaan akan fitur baru. Tetapi ada penyebab stres lain yang dapat dihindari dan organisasi mungkin bergulat dengan hal yang tidak perlu. Salah satunya adalah pendekatan yang sudah ketinggalan zaman untuk observasi. Lebih khusus lagi, tim pengembang harus secara reaktif menyaring tumpukan data log, mencari “jarum di tumpukan jerami” setiap kali ada masalah dengan layanan mereka. Dan mengingat lonjakan besar dalam data log, ada banyak kasus di mana mereka tidak memiliki akses ke data yang mereka butuhkan.
Apa itu Observabilitas?
Observabilitas mengacu pada kemampuan untuk menyimpulkan kesehatan internal aplikasi atau sistem dari data yang tersedia dan dihasilkan secara eksternal. Lima tahun yang lalu, mungkin saja bagi pengembang untuk memanfaatkan dan memanfaatkan semua data ini dengan tujuan memajukan dan memberikan kinerja pengguna yang luar biasa (kecepatan dan ketersediaan), tetapi ini sedang berubah.
Volume data yang membengkak saat ini sebagian besar didorong oleh pertumbuhan cloud dan layanan mikro; jumlah pengguna global yang dilayani; dan semakin banyak aplikasi gabungan (setiap API yang ada dalam aplikasi tunggal mana pun akan menghasilkan data). Dengan cepat menjadi tidak mungkin secara manusiawi untuk memanfaatkan dan memanfaatkan gelombang besar ini. Ironisnya, karena volume data telah meningkat (yang, menurut orang, akan berfungsi untuk memandu dan menginformasikan tim dengan lebih baik jika terjadi penurunan kinerja), jumlah pemadaman berkepanjangan yang berlangsung lebih dari 24 jam sebenarnya telah meningkat tajam. Pengembang memiliki begitu banyak data sehingga mereka sering menemukan diri mereka mengarunginya tanpa tujuan, sia-sia dan tanpa ide samar dari mana harus mulai mencari akar masalah kinerja.
Jalan lurus
Untungnya, ada cara untuk mengatasi keruwetan ini, memberdayakan pengembang untuk sepenuhnya memanfaatkan dan memanfaatkan semua data yang mereka miliki untuk benar-benar menjadi lebih cepat dan lebih efisien dalam menemukan dan memperbaiki masalah kinerja pengguna – dan dengan demikian mengurangi sumber stres yang signifikan. Secara tradisional, pendekatan observabilitas mensyaratkan “pengumpulan” semua data dalam repositori pusat untuk analisis, tetapi pendekatan ini menjadi terlalu mahal (dari perspektif biaya penyimpanan) dan juga terlalu lambat (karena repositori bertambah gemuk, mereka cenderung melambat menjadi crawl dalam mengembalikan kueri).
Jawabannya terletak pada membalikkan paradigma observabilitas ini, menganalisis data dalam potongan-potongan kecil yang semuanya diproses secara paralel, karena dibuat pada titik asalnya. Ada beberapa manfaat dari pendekatan ini. Pertama, saat data dianalisis pada sumbernya, saat sedang dibuat, proses mengidentifikasi hambatan menjadi jauh lebih intuitif dan cepat. Organisasi dapat secara efektif mengawasi semua data mereka (yang penting, karena masalah yang berdampak pada kinerja dapat muncul di mana saja), sambil menghindari biaya besar dan latensi yang terjadi saat semuanya dimasukkan ke dalam repositori pusat.
Kedua, dengan menerapkan analitik real-time di sumbernya, organisasi dapat menampilkan wawasan dari volume data yang sangat besar sehingga pengembang tidak perlu menghabiskan waktu berjam-jam memilah-milah data untuk menemukan apa yang mereka cari. Ini, tentu saja, membuat mereka jauh lebih efisien dalam mendeteksi dan merespons penurunan kinerja.
Satu keuntungan penting lainnya di era cloud dan layanan mikro ini adalah analitik real-time dapat diterapkan secara otomatis dan mulai menghasilkan wawasan begitu instans dibuat atau aplikasi ditayangkan. Ini dikenal sebagai penemuan otomatis, dan ini dapat mengurangi banyak kerja keras yang tidak perlu terkait dengan tim yang harus menambahkan instance baru secara manual ke inisiatif pengamatan mereka, setiap kali yang baru dibuat. Tanpa kemampuan ini, pengembang akan selalu tertinggal satu langkah karena instans baru akan beroperasi dan menghasilkan data sebelum data tersebut memiliki kesempatan untuk ditangkap dan dianalisis. Hal ini dapat meninggalkan titik buta yang sangat besar dan menyebabkan tim tertangkap basah selama beberapa menit atau jam pertama dari sistem yang aktif, ketika masalah kinerja paling cenderung muncul di kepala mereka yang jelek.
Kesimpulan
Saat persaingan memperebutkan talenta pengembang semakin intensif, organisasi perlu melakukan segala daya mereka untuk meningkatkan kepuasan dan retensi pekerjaan. Tidak diragukan lagi bahwa peran-peran ini pada dasarnya membebani, tetapi pasti ada kendala yang dapat dihilangkan untuk membuat pengembang merasa tidak terlalu stres, lebih efisien dan produktif, dan lebih terkendali. Memecah data observabilitas adalah contoh utama dan ini bisa sangat membantu menghindari kejenuhan pengembang dan membantu organisasi mempertahankan sumber daya yang paling berharga ini.
Kredit Foto: ollyy/Shutterstock
Ozan Unlu adalah CEO, Edge Delta.
