Anton Weiss, pendiri dan direktur Otomato Software, salah satu penggagas dan instruktur sertifikasi DevOps pertama di Israel, berbicara pada tahun lalu tentang teori chaos dan prinsip-prinsip utama rekayasa chaos, serta menjelaskan cara kerja organisasi DevOps yang ideal di masa depan.
Kami telah menyiapkan laporan versi teks.
Good morning!
DevOpsDays di Moskow untuk tahun kedua berturut-turut, ini adalah kedua kalinya saya berada di panggung ini, banyak dari Anda berada di ruangan ini untuk kedua kalinya. Apa artinya? Artinya gerakan DevOps di Rusia sedang berkembang, berlipat ganda, dan yang terpenting, ini berarti sudah waktunya untuk membicarakan apa itu DevOps di tahun 2018.
Angkat tangan siapa yang mengira DevOps sudah menjadi profesi di tahun 2018? Ada seperti itu. Apakah ada teknisi DevOps di ruangan tersebut yang deskripsi tugasnya mengatakan “Insinyur DevOps”? Apakah ada manajer DevOps di ruangan itu? Tidak ada yang seperti itu. Arsitek DevOps? Juga tidak. Tidak cukup. Benarkah tidak ada yang mengatakan bahwa mereka adalah insinyur DevOps?
Jadi sebagian besar dari Anda menganggap ini anti pola? Bahwa profesi seperti itu seharusnya tidak ada? Kita dapat memikirkan apa pun yang kita inginkan, namun saat kita berpikir, industri ini dengan sungguh-sungguh bergerak maju menuju suara terompet DevOps.
Siapa yang pernah mendengar topik baru bernama DevDevOps? Ini adalah teknik baru yang memungkinkan kolaborasi efektif antara pengembang dan pengembang. Dan tidak terlalu baru. Dilihat dari Twitter, mereka sudah mulai membicarakan hal ini 4 tahun lalu. Dan hingga saat ini minat terhadap hal tersebut semakin meningkat, yaitu terdapat permasalahan. Masalahnya perlu diselesaikan.
Kami adalah orang-orang kreatif, kami tidak mudah tenang. Kami mengatakan: DevOps bukanlah kata yang cukup komprehensif; ia masih kekurangan berbagai elemen yang menarik. Dan kami pergi ke laboratorium rahasia kami dan mulai menghasilkan mutasi menarik: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logikanya sangat kuat, bukan? Sistem pengiriman kami tidak berfungsi, sistem kami tidak stabil dan pengguna kami tidak puas, kami tidak punya waktu untuk meluncurkan perangkat lunak tepat waktu, kami tidak sesuai dengan anggaran. Bagaimana kita menyelesaikan semua ini? Kami akan menemukan kata baru! Ini akan diakhiri dengan "Ops" dan masalahnya terpecahkan.
Jadi saya menyebut pendekatan ini - “Ops, dan masalahnya terpecahkan.”
Ini semua memudar jika kita mengingatkan diri kita sendiri mengapa kita melakukan semua ini. Kami menciptakan seluruh hal DevOps ini untuk membuat pengiriman perangkat lunak dan pekerjaan kami sendiri dalam proses ini tanpa hambatan, tanpa rasa sakit, efisien, dan yang paling penting, senyaman mungkin.
DevOps tumbuh dari rasa sakit. Dan kami lelah menderita. Dan agar semua ini terjadi, kami mengandalkan praktik yang selalu ada: kolaborasi yang efektif, praktik aliran, dan yang paling penting, pemikiran sistem, karena tanpanya, DevOps tidak akan berfungsi.
Apa itu sistem?
Dan jika kita sudah berbicara tentang pemikiran sistem, mari kita ingatkan kembali apa itu sistem.
Jika Anda seorang hacker revolusioner, maka bagi Anda sistem ini jelas jahat. Itu adalah awan yang menyelimuti Anda dan memaksa Anda melakukan hal-hal yang tidak ingin Anda lakukan.
Dari sudut pandang pemikiran sistem, sistem adalah suatu keseluruhan yang terdiri dari bagian-bagian. Dalam pengertian ini, kita masing-masing adalah sebuah sistem. Organisasi tempat kami bekerja adalah sistem. Dan apa yang Anda dan saya bangun disebut sebuah sistem.
Semua ini adalah bagian dari satu sistem sosio-teknologi yang besar. Dan hanya jika kita memahami bagaimana sistem sosio-teknologi ini bekerja sama, barulah kita dapat benar-benar mengoptimalkan sesuatu dalam hal ini.
Dari perspektif pemikiran sistem, suatu sistem memiliki berbagai sifat yang menarik. Pertama, terdiri dari bagian-bagian, artinya tingkah lakunya bergantung pada tingkah laku bagian-bagian itu. Apalagi seluruh bagiannya juga saling bergantung. Ternyata semakin banyak bagian yang dimiliki suatu sistem, semakin sulit memahami atau memprediksi perilakunya.
Dari sudut pandang perilaku, ada fakta menarik lainnya. Sistem dapat melakukan sesuatu yang tidak dapat dilakukan oleh bagian-bagian individualnya.
Russell Ackoff (salah satu pendiri pemikiran sistem), hal ini cukup mudah dibuktikan dengan eksperimen pemikiran. Misalnya, siapa di ruangan itu yang tahu cara menulis kode? Tangannya banyak, dan ini wajar, karena ini salah satu syarat utama profesi kita. Apakah Anda tahu cara menulis, tetapi bisakah tangan Anda menulis kode secara terpisah dari Anda? Ada orang yang akan berkata: “Bukan tanganku yang menulis kodenya, tapi otakku yang menulis kodenya.” Bisakah otak Anda menulis kode secara terpisah dari Anda? Yah, mungkin tidak.
Otak adalah mesin yang luar biasa, kita bahkan tidak mengetahui 10% cara kerjanya, tetapi otak tidak dapat berfungsi secara terpisah dari sistem yaitu tubuh kita. Dan ini mudah dibuktikan: buka tengkorak Anda, keluarkan otak Anda, letakkan di depan komputer, biarkan dia mencoba menulis sesuatu yang sederhana. "Halo, dunia" dengan Python, misalnya.
Jika suatu sistem dapat melakukan sesuatu yang tidak dapat dilakukan oleh bagian-bagiannya secara terpisah, berarti perilakunya tidak ditentukan oleh perilaku bagian-bagiannya. Lalu ditentukan oleh apa? Hal ini ditentukan oleh interaksi antara bagian-bagian tersebut. Oleh karena itu, semakin banyak bagian, semakin kompleks interaksinya, semakin sulit untuk memahami dan memprediksi perilaku sistem. Dan hal ini membuat sistem seperti itu menjadi kacau, karena perubahan apa pun, bahkan yang paling kecil sekalipun, dan tidak terlihat di bagian mana pun dari sistem dapat menyebabkan hasil yang sama sekali tidak terduga.
Sensitivitas terhadap kondisi awal ini pertama kali ditemukan dan dipelajari oleh ahli meteorologi Amerika Ed Lorenz. Selanjutnya disebut “efek kupu-kupu” dan mengarah pada berkembangnya gerakan pemikiran ilmiah yang disebut “teori chaos”. Teori ini menjadi salah satu perubahan paradigma besar dalam sains abad ke-20.
Teori kekacauan
Orang yang mempelajari chaos menyebut dirinya ahli chaosologi.
Sebenarnya, alasan dibuatnya laporan ini adalah, saat bekerja dengan sistem terdistribusi yang kompleks dan organisasi internasional yang besar, pada titik tertentu saya menyadari bahwa seperti inilah perasaan saya. Saya seorang ahli kekacauan. Ini pada dasarnya adalah cara cerdas untuk mengatakan: "Saya tidak mengerti apa yang terjadi di sini dan saya tidak tahu apa yang harus saya lakukan."
Saya rasa banyak dari Anda juga sering merasakan hal ini, jadi Anda juga ahli chaosologi. Saya mengundang Anda ke serikat ahli chaosologi. Sistem yang Anda dan saya, rekan-rekan ahli chaosologi, akan pelajari disebut “sistem adaptif yang kompleks.”
Apa itu kemampuan beradaptasi? Kemampuan beradaptasi berarti bahwa perilaku individu dan kolektif dari bagian-bagian dalam sistem adaptif tersebut berubah dan mengatur dirinya sendiri, merespons peristiwa atau rangkaian peristiwa mikro dalam sistem. Artinya, sistem beradaptasi terhadap perubahan melalui pengorganisasian mandiri. Dan kemampuan untuk mengatur diri sendiri ini didasarkan pada kerja sama sukarela dan terdesentralisasi sepenuhnya dari agen-agen otonom yang bebas.
Properti menarik lainnya dari sistem tersebut adalah bahwa sistem tersebut dapat diskalakan secara bebas. Apa yang pastinya menarik minat kita, sebagai insinyur-ahli chaosologi. Jadi, jika kita mengatakan bahwa perilaku suatu sistem yang kompleks ditentukan oleh interaksi bagian-bagiannya, lalu apa yang perlu kita perhatikan? Interaksi.
Ada dua temuan menarik lainnya.
Pertama, kita memahami bahwa suatu sistem yang kompleks tidak dapat disederhanakan dengan menyederhanakan bagian-bagiannya. Kedua, satu-satunya cara untuk menyederhanakan sistem yang kompleks adalah dengan menyederhanakan interaksi antar bagian-bagiannya.
Bagaimana kita berinteraksi? Anda dan saya adalah bagian dari sistem informasi besar yang disebut masyarakat manusia. Kita berinteraksi melalui bahasa yang sama, jika kita memilikinya, jika kita menemukannya.
Namun bahasa itu sendiri adalah sistem adaptif yang kompleks. Oleh karena itu, untuk berinteraksi lebih efisien dan sederhana, kita perlu membuat beberapa jenis protokol. Artinya, beberapa rangkaian simbol dan tindakan yang akan membuat pertukaran informasi di antara kita menjadi lebih sederhana, lebih dapat diprediksi, dan lebih dapat dipahami.
Saya ingin mengatakan bahwa kecenderungan menuju kompleksitas, menuju kemampuan beradaptasi, menuju desentralisasi, menuju kekacauan dapat ditelusuri dalam segala hal. Dan dalam sistem yang Anda dan saya sedang bangun, dan dalam sistem di mana kita menjadi bagiannya.
Dan agar tidak berdasar, mari kita lihat bagaimana sistem yang kita buat berubah.
Anda sedang menunggu kata ini, saya mengerti. Kami berada di konferensi DevOps, hari ini kata ini akan terdengar sekitar seratus ribu kali dan kemudian kami akan memimpikannya di malam hari.
Layanan mikro adalah arsitektur perangkat lunak pertama yang muncul sebagai reaksi terhadap praktik DevOps, yang dirancang untuk membuat sistem kami lebih fleksibel, lebih terukur, dan memastikan pengiriman berkelanjutan. Bagaimana dia melakukan ini? Dengan mengurangi volume layanan, mengurangi cakupan masalah yang diproses oleh layanan ini, dan mengurangi waktu pengiriman. Artinya, kita mengurangi dan menyederhanakan bagian-bagian sistem, menambah jumlahnya, dan karenanya, kompleksitas interaksi antara bagian-bagian ini selalu meningkat, yaitu, muncul masalah baru yang harus kita pecahkan.
Layanan mikro bukanlah akhir, layanan mikro secara umum sudah kemarin, karena Tanpa Server akan hadir. Semua server terbakar, tidak ada server, tidak ada sistem operasi, hanya kode murni yang dapat dieksekusi. Konfigurasinya terpisah, statusnya terpisah, semuanya dikendalikan oleh peristiwa. Keindahan, kebersihan, keheningan, tidak ada kejadian, tidak terjadi apa-apa, keteraturan lengkap.
Dimana kompleksitasnya? Kesulitannya tentu saja ada pada interaksinya. Berapa banyak yang dapat dilakukan suatu fungsi dengan sendirinya? Bagaimana cara berinteraksi dengan fungsi lain? Antrian pesan, database, penyeimbang. Bagaimana cara membuat ulang suatu peristiwa ketika terjadi kegagalan? Banyak pertanyaan dan sedikit jawaban.
Layanan mikro dan Tanpa Server adalah apa yang kami para geek hipster sebut sebagai Cloud Native. Ini semua tentang awan. Namun cloud juga memiliki keterbatasan dalam skalabilitasnya. Kami terbiasa menganggapnya sebagai sistem terdistribusi. Faktanya, di mana server penyedia cloud berada? Di pusat data. Artinya, kita mempunyai semacam model tersentralisasi, sangat terbatas, dan terdistribusi di sini.
Saat ini kita memahami bahwa Internet of Things bukan lagi sekedar kata-kata besar yang bahkan menurut prediksi sederhana, miliaran perangkat yang terhubung ke Internet menanti kita dalam lima hingga sepuluh tahun ke depan. Sejumlah besar data berguna dan tidak berguna yang akan digabungkan ke dalam cloud dan diunggah dari cloud.
Cloud tidak akan bertahan lama, jadi kita semakin sering membicarakan sesuatu yang disebut komputasi tepi. Atau saya juga menyukai definisi luar biasa dari "komputasi kabut". Itu diselimuti mistisisme romantisme dan misteri.
Komputasi kabut. Intinya awan adalah gumpalan air, uap, es, dan batu yang terpusat. Dan kabut adalah tetesan air yang tersebar di sekitar kita di atmosfer.
Dalam paradigma kabut, sebagian besar pekerjaan dilakukan oleh tetesan ini secara mandiri atau bekerja sama dengan tetesan lain. Dan mereka beralih ke cloud hanya ketika mereka benar-benar terdesak.
Artinya, sekali lagi desentralisasi, otonomi, dan, tentu saja, banyak dari Anda sudah memahami ke mana arah semua ini, karena Anda tidak dapat berbicara tentang desentralisasi tanpa menyebutkan blockchain.
Ada yang percaya, mereka adalah mereka yang pernah berinvestasi di cryptocurrency. Ada yang percaya tapi takut, seperti saya misalnya. Dan ada juga yang tidak percaya. Di sini Anda dapat memperlakukannya secara berbeda. Ada teknologi, ada hal baru yang belum diketahui, ada masalah. Seperti teknologi baru lainnya, teknologi ini menimbulkan lebih banyak pertanyaan daripada jawaban.
Kehebohan seputar blockchain dapat dimengerti. Terlepas dari demam emas, teknologi itu sendiri menjanjikan masa depan yang lebih cerah: kebebasan yang lebih besar, otonomi yang lebih besar, dan kepercayaan global yang terdistribusi. Apa yang tidak diinginkan?
Oleh karena itu, semakin banyak insinyur di seluruh dunia yang mulai mengembangkan aplikasi terdesentralisasi. Dan ini adalah kekuatan yang tidak dapat diabaikan hanya dengan mengatakan: “Ahh, blockchain hanyalah database terdistribusi yang diimplementasikan dengan buruk.” Atau seperti yang sering dikatakan oleh para skeptis: “Tidak ada aplikasi nyata untuk blockchain.” Kalau dipikir-pikir, 150 tahun yang lalu mereka mengatakan hal yang sama tentang listrik. Dan mereka bahkan benar dalam beberapa hal, karena apa yang dimungkinkan oleh listrik saat ini tidak mungkin dilakukan pada abad ke-19.
Ngomong-ngomong, siapa yang tahu logo apa yang ada di layar? Ini adalah Hyperledger. Ini adalah proyek yang dikembangkan di bawah naungan The Linux Foundation dan mencakup serangkaian teknologi blockchain. Ini benar-benar kekuatan komunitas open source kami.
Rekayasa Kekacauan
Jadi, sistem yang kita kembangkan menjadi semakin kompleks, semakin kacau, dan semakin adaptif. Netflix adalah pionir sistem layanan mikro. Mereka termasuk orang pertama yang memahami hal ini, mereka mengembangkan seperangkat alat yang mereka sebut Tentara Simian, yang paling terkenal adalah . Dia mendefinisikan apa yang kemudian dikenal sebagai .
Ngomong-ngomong, saat mengerjakan laporan, kami bahkan menerjemahkan teks ini ke dalam bahasa Rusia, jadi lanjutkan , membaca, berkomentar, memarahi.
Secara singkat, prinsip-prinsip rekayasa chaos mengatakan sebagai berikut. Sistem terdistribusi yang kompleks pada dasarnya tidak dapat diprediksi dan memiliki bug. Kesalahan tidak bisa dihindari, yang berarti kita harus menerima kesalahan ini dan bekerja dengan sistem ini dengan cara yang benar-benar berbeda.
Kita sendiri harus mencoba memasukkan kesalahan-kesalahan ini ke dalam sistem produksi kita untuk menguji sistem kita terhadap kemampuan beradaptasi yang sama, kemampuan untuk mengatur diri sendiri, untuk bertahan hidup.
Dan itu mengubah segalanya. Tidak hanya cara kami meluncurkan sistem ke dalam produksi, tetapi juga cara kami mengembangkannya, cara kami mengujinya. Tidak ada proses stabilisasi atau pembekuan kode; sebaliknya, ada proses destabilisasi yang konstan. Kami mencoba mematikan sistem dan melihatnya terus bertahan.
Protokol Integrasi Sistem Terdistribusi
Oleh karena itu, hal ini memerlukan perubahan pada sistem kami. Agar mereka menjadi lebih stabil, mereka memerlukan beberapa protokol baru untuk interaksi antar bagian mereka. Sehingga bagian-bagian ini bisa sepakat dan sampai pada semacam pengorganisasian mandiri. Dan segala macam alat baru, protokol baru muncul, yang saya sebut “protokol untuk interaksi sistem terdistribusi.”
Apa yang saya bicarakan? Pertama, proyek . Beberapa upaya untuk membuat protokol pelacakan terdistribusi umum, yang merupakan alat yang sangat diperlukan untuk men-debug sistem terdistribusi yang kompleks.
Selanjutnya - . Kami mengatakan bahwa kami tidak dapat memprediksi apa yang akan terjadi pada sistem, oleh karena itu, kami perlu meningkatkan kemampuan observasinya, kemampuan observasinya. Opentracing termasuk dalam rangkaian alat yang memberikan kemampuan observasi pada sistem kami. Namun kita memerlukan kemampuan observasi untuk menentukan apakah sistem berperilaku seperti yang kita harapkan atau tidak. Bagaimana kita mendefinisikan perilaku yang diharapkan? Dengan mendefinisikan beberapa jenis kebijakan, beberapa aturan. Proyek Agen Kebijakan Terbuka berupaya untuk mendefinisikan serangkaian aturan ini di berbagai spektrum mulai dari akses hingga alokasi sumber daya.
Seperti yang kami katakan, sistem kami semakin berorientasi pada peristiwa. Tanpa server adalah contoh bagus dari sistem berbasis peristiwa. Agar kita dapat mentransfer peristiwa antar sistem dan melacaknya, kita memerlukan bahasa yang sama, protokol umum tentang cara kita membicarakan peristiwa, cara kita mengirimkannya satu sama lain. Inilah yang disebut dengan proyek .
Aliran perubahan yang terus-menerus melanda sistem kami, yang terus-menerus mengganggu kestabilannya, merupakan aliran artefak perangkat lunak yang terus-menerus. Agar kita dapat mempertahankan aliran perubahan yang konstan ini, kita memerlukan semacam protokol umum yang melaluinya kita dapat membicarakan apa itu artefak perangkat lunak, bagaimana pengujiannya, verifikasi apa yang telah dilewatinya. Inilah yang disebut dengan proyek . Artinya, protokol metadata umum untuk artefak perangkat lunak.
Dan yang terakhir, jika kita ingin sistem kita benar-benar mandiri, adaptif, dan terorganisir secara mandiri, kita harus memberi mereka hak untuk melakukan identifikasi diri. Proyek dipanggil Inilah yang dia lakukan. Ini juga merupakan proyek yang berada di bawah naungan Cloud Native Computing Foundation.
Semua proyek ini masih muda, semuanya membutuhkan cinta kita, validasi kita. Ini semua open source, pengujian kami, implementasi kami. Mereka menunjukkan kepada kita ke mana arah teknologi.
Namun DevOps tidak pernah melulu tentang teknologi, namun selalu tentang kolaborasi antarmanusia. Oleh karena itu, jika kita ingin sistem yang kita kembangkan berubah, maka kita sendirilah yang harus berubah. Faktanya, kita tetap berubah; kita tidak punya banyak pilihan.
Ada yang luar biasa Penulis Inggris Rachel Botsman, di mana dia menulis tentang evolusi kepercayaan sepanjang sejarah manusia. Dia mengatakan bahwa pada awalnya, dalam masyarakat primitif, kepercayaan bersifat lokal, yaitu kita hanya mempercayai orang-orang yang kita kenal secara pribadi.
Lalu terjadilah masa yang sangat panjang – masa kelam ketika kepercayaan menjadi terpusat, ketika kita mulai mempercayai orang-orang yang tidak kita kenal atas dasar fakta bahwa kita adalah anggota lembaga publik atau negara yang sama.
Dan inilah yang kita lihat di dunia modern: kepercayaan menjadi semakin terdistribusi dan terdesentralisasi, dan hal ini didasarkan pada kebebasan arus informasi, pada ketersediaan informasi.
Jika dipikir-pikir, aksesibilitas inilah, yang memungkinkan kepercayaan ini terwujud, adalah apa yang Anda dan saya terapkan. Ini berarti cara kita berkolaborasi dan cara kita melakukannya harus berubah, karena organisasi TI yang terpusat dan hierarkis sudah tidak berfungsi lagi. Mereka mulai mati.
Dasar-dasar Organisasi DevOps
Organisasi DevOps yang ideal di masa depan adalah sistem terdesentralisasi dan adaptif yang terdiri dari tim otonom, yang masing-masing terdiri dari individu otonom. Tim-tim ini tersebar di seluruh dunia, berkolaborasi secara efektif satu sama lain menggunakan komunikasi asinkron, menggunakan protokol komunikasi yang sangat transparan. Sangat indah, bukan? Masa depan yang sangat indah.
Tentu saja semua ini tidak mungkin terjadi tanpa adanya perubahan budaya. Kita harus memiliki kepemimpinan transformasional, tanggung jawab pribadi, motivasi internal.
Ini adalah dasar dari organisasi DevOps: transparansi informasi, komunikasi asinkron, kepemimpinan transformasional, desentralisasi.
Keletihan
Sistem tempat kita menjadi bagiannya dan sistem yang kita bangun semakin kacau, dan sulit bagi kita sebagai manusia untuk mengatasi pemikiran ini, sulit untuk melepaskan ilusi kendali. Kami mencoba untuk terus mengendalikannya, dan ini sering kali menyebabkan kelelahan. Saya mengatakan ini dari pengalaman saya sendiri, saya juga mengalami luka bakar, saya juga menjadi cacat karena kegagalan produksi yang tidak terduga.
Burnout terjadi ketika kita mencoba mengendalikan sesuatu yang pada dasarnya tidak dapat dikendalikan. Ketika kita kehabisan tenaga, segalanya kehilangan maknanya karena kita kehilangan keinginan untuk melakukan sesuatu yang baru, kita menjadi defensif dan mulai mempertahankan apa yang kita miliki.
Profesi insinyur, seperti yang sering saya ingatkan pada diri saya sendiri, adalah profesi kreatif yang pertama dan terutama. Jika kita kehilangan keinginan untuk menciptakan sesuatu, maka kita berubah menjadi abu, berubah menjadi abu. Orang-orang kehabisan tenaga, seluruh organisasi kehabisan tenaga.
Menurut pendapat saya, hanya menerima kekuatan kreatif dari kekacauan, hanya membangun kerjasama sesuai prinsip-prinsipnya yang akan membantu kita untuk tidak kehilangan apa yang baik dalam profesi kita.
Inilah yang saya harapkan dari Anda: mencintai pekerjaan Anda, mencintai apa yang kami lakukan. Dunia ini memakan informasi, kita mendapat kehormatan untuk memberinya makan. Jadi mari kita pelajari chaos, mari menjadi ahli chaosologi, mari berikan nilai, ciptakan sesuatu yang baru, ya, masalah, seperti yang telah kita ketahui, tidak bisa dihindari, dan ketika masalah itu muncul, kita cukup berkata “Ops!” Dan masalahnya terpecahkan.
Apa lagi selain Chaos Monkey?
Faktanya, semua instrumen ini masih sangat muda. Netflix yang sama membuat alat untuk dirinya sendiri. Bangun alat Anda sendiri. Bacalah prinsip-prinsip rekayasa kekacauan dan jalankan prinsip-prinsip tersebut daripada mencoba mencari alat lain yang telah dibuat oleh orang lain.
Cobalah untuk memahami bagaimana sistem Anda rusak dan mulailah menghancurkannya dan lihat bagaimana sistem tersebut bertahan. Ini yang pertama. Dan Anda bisa mencari alatnya. Ada berbagai macam proyek.
Saya kurang paham saat Anda mengatakan bahwa sistem tidak dapat disederhanakan dengan menyederhanakan komponen-komponennya, dan segera beralih ke layanan mikro, yang menyederhanakan sistem dengan menyederhanakan komponen itu sendiri dan memperumit interaksi. Ini pada dasarnya adalah dua bagian yang saling bertentangan.
Benar sekali, layanan mikro secara umum adalah topik yang sangat kontroversial. Faktanya, menyederhanakan bagian-bagian meningkatkan fleksibilitas. Apa yang disediakan oleh layanan mikro? Mereka memberi kita fleksibilitas dan kecepatan, namun tentu saja tidak memberi kita kesederhanaan. Mereka meningkatkan kesulitannya.
Jadi, dalam filosofi DevOps, layanan mikro bukanlah hal yang baik?
Setiap kebaikan memiliki sisi negatifnya. Manfaatnya adalah meningkatkan fleksibilitas, memungkinkan kita membuat perubahan lebih cepat, namun meningkatkan kompleksitas dan kerapuhan keseluruhan sistem.
Namun, apa yang lebih ditekankan: menyederhanakan interaksi atau menyederhanakan bagian-bagian?
Penekanannya tentu saja pada penyederhanaan interaksi, karena jika dilihat dari cara kami bekerja dengan Anda, maka pertama-tama kita perlu memperhatikan penyederhanaan interaksi, bukan penyederhanaan pekerjaan. masing-masing dari kita secara terpisah. Karena menyederhanakan pekerjaan berarti berubah menjadi robot. Di sini, di McDonald's, ini berfungsi normal jika Anda mendapat instruksi: di sini Anda menaruh burgernya, di sini Anda menuangkan saus di atasnya. Ini sama sekali tidak berhasil dalam karya kreatif kami.
Benarkah semua yang Anda katakan hidup di dunia tanpa persaingan, dan kekacauan di sana begitu baik, dan tidak ada kontradiksi dalam kekacauan ini, tidak ada yang mau memakan atau membunuh siapa pun? Bagaimana seharusnya persaingan dan DevOps berjalan?
Ya, itu tergantung pada jenis kompetisi yang kita bicarakan. Apakah soal persaingan di dunia kerja atau persaingan antar perusahaan?
Tentang persaingan jasa yang ada karena jasa tidak banyak perusahaannya. Kami menciptakan lingkungan informasi jenis baru, dan lingkungan mana pun tidak dapat hidup tanpa persaingan. Ada persaingan di mana-mana.
Netflix yang sama, kami menjadikan mereka sebagai panutan. Mengapa mereka melakukan hal ini? Karena mereka harus kompetitif. Fleksibilitas dan kecepatan pergerakan ini merupakan persyaratan yang sangat kompetitif; hal ini menimbulkan kekacauan dalam sistem kita. Artinya, kekacauan bukanlah sesuatu yang secara sadar kita lakukan karena kita menginginkannya, melainkan sesuatu yang terjadi karena dunia menuntutnya. Kami hanya perlu beradaptasi. Dan kekacauan justru merupakan akibat dari persaingan.
Apakah ini berarti kekacauan adalah tidak adanya tujuan? Atau tujuan-tujuan yang tidak ingin kita lihat? Kami berada di rumah dan tidak memahami tujuan orang lain. Persaingan, pada kenyataannya, disebabkan oleh fakta bahwa kami memiliki tujuan yang jelas dan kami tahu di mana kami akan berakhir pada saat berikutnya. Dari sudut pandang saya, inilah inti dari DevOps.
Lihat juga pertanyaannya. Saya pikir kita semua memiliki tujuan yang sama: untuk bertahan hidup dan melakukannya
kesenangan terbesar. Dan tujuan kompetitif organisasi mana pun adalah sama. Kelangsungan hidup sering kali terjadi melalui persaingan, tidak ada yang dapat Anda lakukan untuk mengatasinya.
Konferensi tahun ini akan berlangsung pada 7 Desember di Technopolis. Kami menerima permohonan laporan hingga 11 November. kami jika Anda ingin berbicara.
Pendaftaran peserta dibuka, harga tiket 7000 rubel. Bergabunglah dengan kami!
Sumber: www.habr.com