Masa Depan Karir Ops

Pernahkah Anda melihat Lambda: A Serverless Musical ?

Jika tidak, Anda benar-benar harus melakukannya. Saya suka Hamilton, saya suka tanpa server, dan saya tidak mencoba menjadi orang yang kasar atau mematikan atau polisi. TAPI, sayangnya, paduan suara memilih untuk melipatgandakan salah satu kecenderungan terbodoh dan paling berbahaya yang dimiliki gerakan tanpa server sejak hari pertama: kesalahpahaman dan operasi omong kosong.

“Saya akan mengurangi… ops
Saya akan mengurangi… operasi Anda ”

Yah, aku benci memberitahumu, tapi…

“Tidak, saya tidak akan membuang… ops saya.
Dan Anda tidak akan membuang… ops saya. ”

Atau siapa pun dalam hal ini.

Meskipun Anda tidak menjalankan server apa pun atau memiliki infrastruktur sendiri, Anda masih harus menghadapi masalah pengoperasian dan teknik pengoperasian. Saya benci menjadi pembawa berita buruk (tidak juga), tetapi peran operasi tidak akan hilang. Paling banter, pergeseran yang seharusnya mengurangi operasi Anda hanya mendelegasikan pengoperasian tumpukan Anda kepada seseorang yang melakukannya dengan lebih baik. Kenyataan bagi sebagian besar tim adalah bahwa teknik operasi lebih diperlukan daripada sebelumnya.

Di balik tepuk tangan Hamilton, perbedaan itu penting karena memiliki konsekuensi karier nyata bagi para insinyur yang, seperti saya, sangat berpikiran operasional. Kemana tujuan karir Ops?

Di Mana Saja Ops Cocok?

Di beberapa sudut teknik, “operasi” langsung digunakan sebagai sinonim untuk kerja keras dan kerja manual. Tidak ada operasi yang bagus, hanya operasi yang mati. Keberadaan ops adalah kegagalan teknis: cacat untuk diotomatiskan, diberantas dengan menambahkan lebih banyak kode. Kode mengalahkan kerja keras. Dev membuat operasi menjadi usang. #TidakOps!

Jika ini adalah perjalanan yang tak terhindarkan menuju utopia, mungkin seseorang dapat menjelaskan kepada saya mengapa toko-toko yang paling menggoda dengan #NoOps, tanpa kecuali, bencana kemanusiaan seperti itu?

Atau, saya akan mulai. Operasi sangat penting. Ketika Anda merendahkan dan menguranginya, itu pertanda pertama bahwa Anda tidak melakukannya dengan baik. Cara untuk melakukan sesuatu dengan baik biasanya dimulai dengan menambahkan fokus dan ketelitian, bukan menghapusnya.

Pertimbangkan Pengembangan dan Operasi Bisnis. Bisnis adalah alasannya, pengembangan adalah apa, operasi adalah bagaimana. Operasi adalah konstelasi memori organisasi Anda: pola, praktik, kebiasaan, default, aspirasi, keahlian, alat, dan segala sesuatu yang digunakan untuk menyampaikan nilai bisnis kepada pengguna.

Nilai tanpa server tidak ditemukan di “operasi yang lebih sedikit”. Operasi yang lebih sedikit tidak menghasilkan sistem yang lebih baik daripada lebih banyak operasi, semakin sedikit baris kode berarti perangkat lunak yang lebih baik. Nilai tanpa server dibuka oleh abstraksi yang jelas dan kuat yang memungkinkan Anda mendelegasikan pengoperasian sebagian besar infrastruktur Anda kepada orang lain yang dapat melakukannya lebih baik daripada Anda – ya, karena skala ekonomi, tetapi lebih dari itu karena itulah model bisnis inti mereka. Model bisnis inti ANDA mungkin tidak ada hubungannya dengan infrastruktur.

Karena itu, masalah besar sekarang terjadi antara rekayasa perangkat lunak, operasi infrastruktur, dan nilai bisnis inti.

Apa Itu Infrastruktur?

Infrastruktur adalah dukungan perangkat lunak. Ini adalah prasyarat yang Anda harus lakukan, untuk mendapatkan hal-hal yang Anda inginkan melakukan. Ini bukanlah hal yang ingin Anda lakukan, namun tujuan bisnis Anda mengasumsikan keberadaannya.

Kualitas infrastruktur yang penting adalah biasanya infrastruktur tersebut lebih jarang berubah dan lebih stabil daripada perangkat lunak yang membentuk nilai bisnis inti Anda. Fitur yang Anda kirimkan ke pelanggan biasanya dalam pengembangan yang konstan atau sering, dan fitur tersebut berubah sesuai dengan tingkat permintaan dan komitmen tarik (sebenarnya, kecepatan perubahan ini dapat menjadi keunggulan kompetitif yang kritis). Infrastruktur, di sisi lain, berubah dengan kecepatan yang lebih glasial – dengan kecepatan manajer paket, pembaruan OS, dan image mesin baru. Detik-ke-menit versus jam-ke-hari.

Garis pemisah antara infrastruktur dan nilai bisnis inti ini bahkan berlaku untuk perusahaan yang model bisnisnya adalah membangun infrastruktur untuk perusahaan lain. Misalnya, perusahaan penyedia email berfokus pada produk yang terdiri dari fitur alur kerja email yang terus dikembangkan dan dikirimkan ke pengguna. Tidak banyak nilai bisnis baru yang harus diperas dari memodifikasi lapisan transportasi SMTP komoditas atau mengoptimalkan server IMAP.

Untuk kreditnya, tanpa server mungkin merupakan tren pertama yang benar-benar memahami dan memanfaatkan dengan kuat garis pemisah itu. IaaS, PaaS, dan suite dengan layanan lengkap seperti Gitlab semuanya adalah bentuk asal dari pergeseran ini. “Cloud native” juga, bisa dibilang, merupakan gangguan lain ke arah itu. Tapi kemana hal itu membawa industri kita?

– As-a-Service Benar-benar Hanya Kode untuk “Outsourcing”

IaaS, PaaS, dan bahkan FaaS / tanpa server sebenarnya semuanya hanya jenis outsourcing. Namun kami tidak menyebutnya “outsourcing” saat kami mengandalkan perusahaan seperti AWS untuk menjalankan pusat data kami dan menyediakan komputasi atau penyimpanan, atau saat kami menggunakan aplikasi Google untuk email, dokumen, dan spreadsheet kami?

Secara historis, “outsourcing” adalah apa yang kami sebut sebagai shift kerja di luar lokasi ketika kami belum merasa nyaman dengan pengaturannya; apakah karena kecocokannya tidak tepat, dukungannya tidak lengkap, atau layanannya tidak sesuai dengan apa yang dapat kami lakukan sendiri. Dengan outsourcing infrastruktur, kualitas layanan kini semakin meningkat. Subsistem yang semakin kompleks menjadi komponen komoditas: dan perusahaan lain memanfaatkannya untuk membangun bisnis mereka sendiri (atau infrastruktur lainnya!) Di atas.

Ketika saya memulai karir saya, saya adalah orang yang memiliki sistem jack-of-all-trade. Saya menjalankan email, web, db, DNS, cache, menyebarkan, CI / CD, sistem operasi yang ditambal, debs dan rpms yang dibangun, dll, dll. Kebanyakan teknisi tidak melakukan hal-hal itu sekarang, dan saya juga tidak. Mengapa saya, ketika saya dapat membayar orang lain untuk mengabstraksi detail itu, sehingga saya dapat menghabiskan waktu saya berfokus pada memberikan nilai pelanggan?

Semakin banyak, sebagai sebuah industri, kami melakukan outsourcing apapun yang kami bisa.

Sebagai contoh yang lebih pribadi, mengapa Anda ingin menjalankan tim pengamatan Anda sendiri atau membuat perangkat lunak pemantauan internal Anda sendiri, jika itu bukan bisnis inti Anda? Mengapa memisahkan fokus Anda untuk membangun versi yang dipesan lebih dahulu dan tidak berkelanjutan ketika Anda dapat dengan mudah membeli versi kelas dunia? Jika perusahaan saya memiliki sepuluh atau dua puluh insinyur penuh waktu yang mengerjakan solusi itu, berapa lama waktu yang dibutuhkan sampai tim Anda yang terdiri dari tiga atau lima orang dapat mengejar ketinggalan?

Dalam dunia pasca-cloud, kami telah belajar bahwa biasanya jauh lebih baik dan jauh lebih mudah untuk membeli daripada membangun hal-hal yang tidak menambah nilai bisnis.

Cara Melakukan Alih Daya dengan Baik

Dalam contoh pribadi saya, membeli tidak berarti Anda tidak boleh memiliki tim observasi. Artinya, tim observabilitas harus mengalihkan pandangan mereka ke dalam. Tim tersebut harus mengambil halaman dari SRE atau menguji buku komunitas dan fokus pada memberikan nilai bagi pengembang organisasi Anda setiap kali mereka berinteraksi dengan solusi outsourcing ini.

Tim tersebut harus menulis perpustakaan, menghasilkan contoh, dan mendorong standardisasi; mengantarkan konsistensi, prediktabilitas, dan kegunaan. Mereka harus bermitra dengan tim internal untuk mengevaluasi kasus penggunaan. Mereka harus bermitra dengan vendor Anda sebagai pemangku kepentingan peta jalan. Mereka mungkin juga menulis kode perekat dan modul pembantu untuk menghubungkan sumber data yang berbeda dan membuat visualisasi yang kohesif. Pada dasarnya, tim tersebut menjadi titik integrasi antara organisasi Anda dan pekerjaan outsourcing.

Kami sudah tahu dari penelitian industri bahwa kunci sukses ketika melakukan outsourcing adalah dengan menanamkan kontribusi off-premis tersebut dalam tim lintas fungsi , yang mengelola pengintegrasian pekerjaan itu kembali ke organisasi yang lebih luas.

Jumlah pekerjaan teknik yang luar biasa menciptakan tumpukan yang memberikan nilai kepada pelanggan Anda. Mencoba menghemat pekerjaan, beberapa tim membuat mesin Rube Goldberg rumit yang brutal untuk dijalankan, diubah, dan di-debug. Jauh lebih sulit untuk membangun platform sederhana dengan komponen yang dapat dioperasikan dan dapat dipahami yang memberikan pengalaman pengguna yang manusiawi. Menjembatani kesenjangan itu membutuhkan rekayasa operasi yang berkualitas untuk merampingkan outsourcing itu untuk adopsi pengguna yang sukses.

Itulah sebabnya meskipun Anda tidak menjalankan server dan tidak memiliki infrastruktur sendiri, Anda masih memiliki masalah pengoperasian dan pengoperasian yang harus dihadapi. Sampai pada titik di mana organisasi Anda berhasil tidak memiliki infrastruktur sendiri membutuhkan banyak keahlian operasi kelas dunia. Lebih sulit lagi tinggal di sana. Orang brengsek mana pun yang memiliki kartu kredit dapat langsung menjalankan server yang sekarang Anda tanggung. Cobalah menjadi penghalang pandang apa pun dan lihat seberapa cepat hal itu terjadi.

Apa Artinya Ini Bagi Insinyur yang Berpikiran Secara Operasional

Kenyataannya adalah bahwa pekerjaan infrastruktur sistem jack-of-all-trade perlahan menghilang: dunia tidak membutuhkan ribuan orang yang dengan ahli dapat menyesuaikan postfix, SpamAssassin dan ClamAV – dunia memiliki Gmail. Anda dapat menemukan pekerjaan Anda selanjutnya dengan mengikuti jejak teknologi yang Anda ketahui, seperti dipekerjakan sebagai pakar MySQL. Tetapi teknologi datang dan pergi, jadi Anda harus berpikir dengan hati-hati sebelum memasang keranjang Anda ke perangkat lunak tertentu. Apa artinya ini bagi karier Anda?

Industri ini bercabang di sepanjang garis gangguan infrastruktur, dan ketidakmampuan untuk membedakan antara insinyur yang berorientasi infrastruktur dan insinyur yang berpikiran operasional dengan cepat terkikis. Ini menjadi dua peran dan jalur karier yang berbeda di dua jenis perusahaan: penyedia infrastruktur, dan yang lainnya. Kita yang suka mengoptimalkan, debugging, memelihara, dan mengatasi masalah sistem yang aneh lebih dari sekadar menulis kode greenfield baru, sekarang memiliki pilihan untuk dibuat: mendalami dan berspesialisasi dalam infrastruktur, atau memperluas pengoperasian.

Jika misi perusahaan Anda adalah memecahkan masalah kategori dengan menyediakan infrastruktur kepada dunia, maka operasi akan selalu menjadi bagian inti dari misi tersebut: perusahaan Anda berkembang dengan memecahkan masalah pengoperasian tertentu lebih baik daripada siapa pun. Jadi Anda dibenarkan untuk mendalami dan berspesialisasi di dalamnya, dan mencari tahu cara melakukannya dengan lebih baik dan lebih efisien daripada siapa pun di dunia ini – sehingga orang lain tidak perlu melakukannya. Tetapi ketahuilah bahwa pekerjaan backend yang padat infrastruktur ini juga membutuhkan pekerjaan desain, manajemen produk, dan rekayasa perangkat lunak – seperti perusahaan yang tidak berfokus pada infrastruktur!

Jika perusahaan yang Anda pilih tidak memecahkan masalah infrastruktur untuk dunia, masih ada banyak peluang untuk generalis operasi di sini juga. Tetapi ketahuilah bahwa bagian inti dari pekerjaan Anda adalah memeriksa secara kritis siklus yang dikhususkan perusahaan Anda untuk operasi infrastruktur dan menemukan cara efektif untuk melakukan outsourcing atau meminimalkan siklus pengembang in-house mereka. Tugas Anda tidak mendalam jika ada alternatif lain.

Saya melihat insinyur yang berpikiran operasional bekerja secara lintas fungsi dengan tim pengembangan perangkat lunak untuk membantu mereka berkembang di beberapa bidang utama: membuat outsourcing berhasil, mempercepat waktu untuk menilai, dan meningkatkan kualitas produksi mereka.

Mereka mengembangkan argumen industri “bangun vs. beli” yang sangat kasar (sering kali didasarkan pada gagasan yang tidak biasa) menjadi pemahaman yang canggih tentang bagaimana dan kapan memanfaatkan abstraksi yang secara radikal mempercepat pembangunan. Mereka membangun dan memelihara jembatan yang membuat outsourcing berhasil.

Mereka mengembangkan teknik rilis untuk memenuhi bagian pengiriman CI / CD. Terlalu banyak tim yang sangat kompeten dalam menulis perangkat lunak, namun memperbaiki secara sempurna dalam hal pengiriman perangkat lunak itu dengan cepat dan aman.

Mereka juga meningkatkan keterampilan operasional produksi insinyur perangkat lunak dengan membuat rotasi sesuai panggilan, tim konseling tentang instrumentasi, dan observasi pengajaran. Saat tim meninggalkan metrik dan log tertanggal, mereka mulai menggunakan observabilitas untuk menggali diri mereka sendiri dari lubang besar yang terus meningkat di mana setiap orang terus-menerus mengirimkan perangkat lunak yang tidak mereka pahami ke sistem produksi yang tidak pernah mereka pahami.

Setiap orang membutuhkan keterampilan operasional; bahkan tim yang tidak menjalankan infrastruktur mereka sendiri. Ops adalah konstelasi keterampilan yang diperlukan untuk perangkat lunak pengiriman; itu bukan opsional. Jika Anda mengirimkan perangkat lunak, Anda memiliki pekerjaan operasi yang perlu diselesaikan. Pekerjaan itu tidak akan hilang. Itu hanya meningkatkan tumpukan dan menjadi lebih canggih, dan Anda mungkin tidak mengenalinya.

Saya menantikan paduan suara Lambda Serverless Musical yang ditingkatkan:

Saya akan meningkatkan… ops.
Ya, saya akan meningkatkan… ops!

Baca selengkapnya tentang Metodologi perekrutan Honeycomb . P.S. Kami merekrut !

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments