DevOps and Chaos: Pengiriman Perangkat Lunak di Dunia yang Terdesentralisasi

Pendiri dan direktur Otomato Software, salah satu penggagas dan instruktur sertifikasi DevOps pertama Israel, Anton Weiss, berbicara tentang teori chaos dan prinsip-prinsip utama teknik chaotic di DevOpsDays Moscow tahun lalu, dan juga menjelaskan bagaimana organisasi DevOps yang ideal untuk masa depan bekerja.

Kami telah menyiapkan versi teks laporan.



Selamat pagi

DevOpsDays di Moskow untuk tahun kedua berturut-turut, saya yang kedua kalinya di panggung ini, banyak dari Anda yang kedua kalinya di ruangan ini. Apa artinya ini? Ini berarti bahwa gerakan DevOps di Rusia tumbuh, berkembang biak, dan yang paling penting, ini berarti bahwa sudah waktunya untuk berbicara tentang apa itu DevOps pada tahun 2018.

Angkat tangan Anda, mereka yang berpikir bahwa pada 2018 DevOps sudah menjadi profesi? Ada beberapa. Apakah ada insinyur DevOps di ruangan yang memiliki "insinyur DevOps" yang tertulis dalam uraian tugas? Apakah ada manajer DevOps di ruangan itu? Tidak ada Arsitek DevOps? Tidak juga. Tidak cukup Apa, sebenarnya, tidak ada yang menulis bahwa ia adalah seorang insinyur DevOps?

Jadi, sebagian besar dari Anda berpikir ini antipattern? Apa yang seharusnya tidak menjadi profesi seperti itu? Kita bisa memikirkan apa saja, tetapi untuk saat ini kita berpikir industri sedang bergerak maju dengan suara pipa DevOps.

Siapa yang mendengar tentang topik baru bernama DevDevOps? Ini adalah teknik baru, yang memungkinkan kerja sama yang efektif antara pengembang dan pengembang. Dan tidak begitu baru. Dinilai oleh twitter, lalu 4 tahun lalu mereka mulai membicarakannya. Dan masih tertarik pada ini tumbuh dan berkembang, yaitu, ada masalah. Masalahnya harus dipecahkan.



Kami adalah orang-orang kreatif, jadi jangan tenang. Kami mengatakan: DevOps bukan kata yang cukup komprehensif, masih belum cukup dari semua jenis elemen yang berbeda dan menarik. Dan kami pergi ke laboratorium rahasia kami dan mulai menghasilkan mutasi yang menarik: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.



Logikanya besi, kan? Sistem pengiriman kami tidak berfungsi, sistem kami tidak stabil dan pengguna tidak puas, kami tidak punya waktu untuk meluncurkan perangkat lunak tepat waktu, kami tidak sesuai dengan anggaran. Bagaimana kita menyelesaikan semua ini? Kami akan datang dengan kata baru! Itu akan berakhir di Ops dan masalahnya teratasi.

Jadi saya sebut pendekatan ini - "Ops, dan masalahnya sudah teratasi."

Ini semua memudar ke latar belakang jika kita mengingatkan diri kita sendiri mengapa kita datang dengan semua ini. Kami datang dengan semua DevOps ini untuk membuat pengiriman perangkat lunak dan pekerjaan kami sendiri dalam proses ini sebagai tidak terhalang, tidak menyakitkan, efektif, dan yang paling penting, menyenangkan.

DevOps telah tumbuh dari rasa sakit. Dan kami lelah menderita. Dan agar ini terjadi, kami bergantung pada praktik hijau: kolaborasi yang efektif, praktik aliran, dan yang paling penting, pemikiran sistemik, karena tanpa itu, tidak ada DevOps yang berfungsi.

Apa itu sistem?

Dan jika kita sudah berbicara tentang pemikiran sistemik, mari kita ingatkan diri kita apa itu sistem.



Jika Anda adalah seorang hacker revolusioner, maka bagi Anda sistem itu adalah kejahatan yang jelas. Ini adalah awan yang menggantung Anda dan membuat Anda melakukan apa yang tidak ingin Anda lakukan.



Dari sudut pandang pemikiran sistemik, sistem adalah keseluruhan yang terdiri dari bagian-bagian. Dalam pengertian ini, kita masing-masing adalah sebuah sistem. Organisasi tempat kami bekerja adalah sistem. Dan apa yang kita bangun adalah apa namanya - sistem.

Semua ini adalah bagian dari satu sistem sosioteknologi besar. Dan hanya jika kita memahami bagaimana sistem sosioteknologi ini bekerja bersama, hanya dengan begitu kita dapat benar-benar mengoptimalkan sesuatu dalam hal ini.

Dari sudut pandang pemikiran sistemik, sistem memiliki berbagai sifat menarik. Pertama, terdiri dari bagian-bagian, yang berarti bahwa perilakunya tergantung pada perilaku bagian-bagian itu. Apalagi semua bagiannya juga saling bergantung. Ternyata semakin banyak bagian sistem, semakin sulit untuk memahami atau memprediksi perilakunya.

Dalam hal perilaku, ada fakta menarik lainnya. Sistem dapat melakukan sesuatu yang tidak dapat dilakukan oleh setiap bagiannya.

Seperti yang dikatakan Dr. Russell Akoff (salah satu pendiri pemikiran sistemik), ini cukup mudah untuk dibuktikan dengan bantuan eksperimen pemikiran. Misalnya, siapa di antara hadirin yang dapat menulis kode? Banyak tangan, dan ini normal, karena ini adalah salah satu persyaratan dasar untuk profesi kita. Bisakah Anda menulis, dan tangan Anda dapat menulis kode secara terpisah dari Anda? Ada orang yang mengatakan: "Tangan saya tidak menulis kode, otak saya menulis kode." Bisakah otak menulis kode secara terpisah dari Anda? Yah, kemungkinan besar tidak.

Otak adalah mesin yang luar biasa, 10% dari kita tidak tahu cara kerjanya di sana, tetapi tidak dapat berfungsi secara terpisah dari sistem tubuh kita. Dan ini mudah dibuktikan: buka kotak tengkorak Anda, keluarkan otak Anda, letakkan di depan komputer, biarkan ia 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, maka ini berarti bahwa perilakunya tidak ditentukan oleh perilaku bagian-bagiannya. Lalu apa yang ditentukan olehnya? Itu ditentukan oleh interaksi antara bagian-bagian ini. Dan karenanya, semakin banyak bagian, semakin sulit interaksi, semakin sulit untuk memahami dan memprediksi perilaku sistem. Dan ini membuat sistem seperti ini kacau, karena siapa pun, yang terkecil, tidak terlihat oleh perubahan mata di bagian mana pun dari sistem dapat menyebabkan hasil yang sama sekali tidak dapat diprediksi.

Kepekaan terhadap kondisi awal ini pertama kali ditemukan dan diselidiki oleh ahli meteorologi Amerika Ed Lorenz. Selanjutnya, itu disebut "efek kupu-kupu" dan menyebabkan perkembangan gerakan pemikiran ilmiah yang disebut "teori chaos". Teori ini telah menjadi salah satu pergeseran paradigma utama dalam sains abad ke-20.

Teori kekacauan

Orang yang mempelajari kekacauan menyebut diri mereka chaosologist.



Sebenarnya, alasan dari laporan ini adalah, bekerja dengan sistem terdistribusi yang kompleks dan organisasi internasional besar, pada titik tertentu saya menyadari bahwa inilah yang saya rasakan. Saya seorang chaosologist. Secara umum, ini adalah cara cerdik untuk mengatakan: "Saya tidak mengerti apa yang terjadi di sini dan saya tidak tahu apa yang harus saya lakukan dengan itu."

Saya pikir banyak dari Anda yang sering merasakan diri Anda sendiri, jadi Anda juga ahli chaosologis. Saya mengundang Anda ke guild of chaosologist. Sistem yang akan kita, rekan sejawat dari ahli chaosologis, pelajari, disebut "sistem adaptif yang kompleks."

Apa itu kemampuan beradaptasi? Adaptabilitas berarti bahwa perilaku individu dan kolektif dari bagian-bagian dalam suatu sistem adaptif berubah dan mengatur diri sendiri, merespons peristiwa atau rantai peristiwa mikro dalam sistem. Artinya, sistem beradaptasi dengan perubahan melalui pengorganisasian diri. Dan kemampuan pengorganisasian diri ini didasarkan pada kerja sama sukarela, sepenuhnya terdesentralisasi dari agen-agen otonom gratis.

Properti lain yang menarik dari sistem tersebut adalah bahwa mereka dapat diskalakan secara bebas. Bahwa kita, sebagai chaosologist-engineer, pasti akan menarik. Jadi, jika kita mengatakan bahwa perilaku sistem yang kompleks ditentukan oleh interaksi bagian-bagiannya, lalu apa yang harus kita minati? Interaksi

Ada dua kesimpulan yang lebih menarik.


Pertama, kami memahami bahwa sistem yang kompleks tidak dapat disederhanakan dengan menyederhanakan bagian-bagiannya. Kedua, satu-satunya cara untuk menyederhanakan sistem yang kompleks adalah menyederhanakan interaksi antara bagian-bagiannya.

Bagaimana cara kita berinteraksi? Kita semua adalah bagian dari sistem informasi besar yang disebut masyarakat manusia. Kita berinteraksi melalui bahasa yang sama, jika kita memilikinya, jika kita menemukannya.



Tetapi bahasa itu sendiri adalah sistem adaptif yang kompleks. Dengan demikian, untuk berinteraksi lebih efisien dan sederhana, kita perlu membuat beberapa jenis protokol. Artinya, beberapa urutan simbol dan tindakan yang akan membuat pertukaran informasi di antara kita lebih sederhana, lebih dapat diprediksi, lebih dapat dimengerti.

Saya ingin mengatakan bahwa kecenderungan komplikasi, adaptasi, desentralisasi, keacakan dilacak dalam segala hal. Dan dalam sistem yang kita bangun, dan dalam sistem yang kita menjadi bagiannya.

Agar tidak berdasar, mari kita lihat bagaimana sistem yang kita buat berubah.



Anda menunggu kata ini, saya mengerti. Kita berada di konferensi DevOps, hari ini kata ini akan terdengar di suatu tempat seratus ribu kali dan kemudian kita akan bermimpi di malam hari.

Microservices 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 terus menerus. Bagaimana dia melakukan ini? Dengan mengurangi volume layanan, mengurangi batasan masalah yang diproses layanan ini, mengurangi waktu pengiriman. Artinya, kita mengurangi, menyederhanakan bagian-bagian sistem, menambah jumlahnya, sehingga kompleksitas interaksi antara bagian-bagian ini terus meningkat, yaitu timbul masalah baru yang harus kita pecahkan.



Layanan microser bukanlah akhirnya, layanan microser, secara umum, sudah kemarin, karena Serverless akan datang. Semua server terbakar, tidak ada server, tidak ada sistem operasi, hanya kode yang dapat dieksekusi bersih. Konfigurasi terpisah, keadaan terpisah, semuanya dikendalikan oleh peristiwa. Kecantikan, kemurnian, keheningan, tidak ada peristiwa, tidak ada yang terjadi, urutan lengkap.

Di mana kesulitannya? Kompleksitas, tentu saja, dalam interaksi. Berapa banyak fungsi yang dapat dilakukan sendiri? Bagaimana cara berinteraksi dengan fungsi lain? Antrian pesan, basis data, penyeimbang. Bagaimana cara membuat ulang suatu peristiwa ketika kegagalan terjadi? Banyak pertanyaan dan beberapa jawaban.

Microservices dan Serverless adalah apa yang kita sebut sebagai hipster komputer Cloud Native. Ini semua tentang awan. Tetapi cloud pada dasarnya juga dapat diskalakan. Kita terbiasa menganggapnya sebagai sistem terdistribusi. Bahkan, di mana server penyedia cloud tinggal? Di pusat data. Artinya, di sini kita memiliki model terdistribusi, sangat terbatas, tertentu.

Hari ini kita memahami bahwa Internet hal-hal tidak lagi hanya kata-kata besar itu, bahkan menurut prediksi konservatif, miliaran perangkat yang terhubung ke Internet sedang menunggu kita dalam lima hingga sepuluh tahun ke depan. Sejumlah besar data berguna dan tidak berguna yang akan bergabung ke dalam cloud dan membanjiri dari cloud.

Awan tidak akan tahan, jadi kita semakin berbicara tentang apa yang disebut "komputasi periferal." Atau saya juga suka definisi indah dari komputasi kabut. Itu sobek dengan mistisisme romantisme dan misteri.



Komputasi berkabut. Intinya adalah bahwa awan adalah gumpalan air, uap, es, batu yang tersentralisasi. Dan kabut adalah tetesan air yang tersebar di sekitar kita di atmosfer.

Dalam paradigma berkabut, sebagian besar pekerjaan dilakukan oleh tetesan ini sepenuhnya secara mandiri atau bekerja sama dengan tetesan lain. Dan mereka beralih ke cloud hanya ketika mereka benar-benar melakukannya.

Sekali lagi, desentralisasi, otonomi, dan, tentu saja, banyak dari Anda sudah memahami apa ini semua, karena Anda tidak dapat berbicara tentang desentralisasi dan tidak menyebutkan blockchain.



Ada orang yang percaya, ini adalah mereka yang telah berinvestasi dalam cryptocurrency. Ada yang percaya, tapi takut, seperti saya, misalnya. Dan ada orang yang tidak percaya. Di sini Anda dapat berhubungan secara berbeda. Ada teknologi, bisnis baru yang tidak bisa dipahami, ada masalah. Seperti halnya teknologi baru apa pun, itu menimbulkan lebih banyak pertanyaan daripada jawaban.

Hype di sekitar blockchain bisa dimengerti. Bahkan jika Anda mengesampingkan demam emas, teknologinya sendiri menjanjikan janji-janji indah tentang masa depan yang lebih cerah: lebih banyak kebebasan, lebih banyak otonomi, distribusi kepercayaan global. Apa yang tidak ingin ada di sana?

Dengan demikian, semakin banyak insinyur di seluruh dunia mulai mengembangkan aplikasi terdesentralisasi. Dan ini adalah kekuatan yang tidak bisa diberhentikan hanya dengan mengatakan: "Ahh, blockchain hanyalah database terdistribusi yang diimplementasikan dengan buruk." Atau bagaimana skeptis suka mengatakan: "Tidak ada kegunaan nyata untuk blockchain." Jika Anda memikirkannya, maka 150 tahun yang lalu mereka mengatakan hal yang sama tentang listrik. Dan bahkan dalam beberapa hal mereka benar, karena apa yang dimungkinkan oleh listrik pada hari ini di abad ke-19 sama sekali tidak realistis dalam hal apa pun.

Ngomong-ngomong, siapa yang tahu logo seperti apa yang ada di layar? Ini Hyperledger. Ini adalah proyek yang sedang dikembangkan di bawah naungan The Linux Foundation, termasuk satu set teknologi blockchain. Ini benar-benar kekuatan komunitas open source kami.

Rekayasa Kekacauan

Jadi, sistem yang kami kembangkan menjadi lebih kompleks, lebih kacau, lebih adaptif. Netflix - pelopor sistem layanan mikro. Mereka adalah salah satu yang pertama memahami hal ini, mereka mengembangkan alat yang disebut Tentara Simian, yang paling terkenal adalah Chaos Monkey . Dia mendefinisikan apa yang kemudian dikenal sebagai "prinsip-prinsip rekayasa kekacauan . "

Ngomong-ngomong, dalam proses mengerjakan laporan, kami bahkan menerjemahkan teks ini ke dalam bahasa Rusia, jadi buka tautan , baca, komentar, tegur.

Secara singkat, prinsip-prinsip rekayasa kekacauan menunjukkan hal berikut. Sistem terdistribusi kompleks secara inheren tidak dapat diprediksi, dan secara inheren memiliki kesalahan di dalamnya. Kesalahan tidak dapat dihindari, yang berarti bahwa kita perlu menerima kesalahan ini dan bekerja dengan sistem ini dengan cara yang sama sekali berbeda.

Kita sendiri harus mencoba memperkenalkan kesalahan-kesalahan ini ke dalam sistem produksi kita untuk menguji sistem kita untuk kemampuan beradaptasi yang sangat ini, untuk kemampuan mengatur diri sendiri ini, untuk bertahan hidup.

Dan itu mengubah segalanya. Tidak hanya bagaimana kita menjalankan sistem dalam produksi, tetapi juga bagaimana kita mengembangkannya, bagaimana kita mengujinya. Tidak ada proses stabilisasi, pembekuan kode, sebaliknya, ada proses destabilisasi yang konstan. Kami mencoba untuk membunuh sistem dan melihat bahwa itu terus bertahan.

Protokol Integrasi Sistem Terdistribusi

Oleh karena itu, ini membutuhkan sistem kami untuk berubah. Agar mereka menjadi lebih stabil, mereka membutuhkan beberapa protokol interaksi baru di antara bagian-bagian mereka. Sehingga bagian-bagian ini dapat dinegosiasikan dan datang ke semacam organisasi mandiri. Dan ada segala macam alat baru, protokol baru, yang saya sebut "protokol untuk interaksi sistem terdistribusi."



Apa yang saya bicarakan? Pertama, proyek Opentracing . Beberapa upaya untuk membuat protokol umum untuk pelacakan terdistribusi, yang merupakan alat yang sangat diperlukan untuk debugging sistem terdistribusi kompleks.



Berikutnya adalah Agen Kebijakan Terbuka . Kami mengatakan bahwa kami tidak dapat memprediksi apa yang akan terjadi pada sistem, yaitu, kami perlu meningkatkan daya pengamatan, daya pengamatan. Opentracing adalah kumpulan alat yang memberikan kemampuan pengamatan terhadap sistem kami. Tetapi kita perlu dapat diamati untuk menentukan apakah sistem berperilaku seperti yang kita harapkan darinya atau tidak. Bagaimana kita menentukan perilaku yang diharapkan? Dengan mendefinisikan di dalamnya semacam kebijakan, semacam seperangkat aturan. Proyek Agen Kebijakan Terbuka mendefinisikan serangkaian aturan ini pada rentang yang luas: dari akses hingga alokasi sumber daya.



Seperti yang kami katakan, sistem kami semakin didorong oleh peristiwa. Serverless adalah contoh yang bagus untuk sistem yang digerakkan oleh event. Agar kita dapat mentransmisikan kejadian di antara sistem dan melacaknya, kita memerlukan beberapa bahasa umum, beberapa protokol umum tentang bagaimana kita berbicara tentang peristiwa, bagaimana kita mengirimkannya satu sama lain. Ini adalah proyek yang disebut Cloudevents .



Aliran perubahan terus-menerus yang mencuci sistem kami, yang terus-menerus mengganggu kestabilannya, adalah aliran artefak perangkat lunak yang berkelanjutan. Agar kita dapat mempertahankan aliran perubahan yang konstan ini, kita memerlukan beberapa protokol umum yang dengannya kita dapat berbicara tentang apa artefak perangkat lunak, bagaimana itu diverifikasi, apa verifikasi yang diteruskannya. Ini adalah proyek yang disebut Grafeas . Yaitu, protokol metadata artefak perangkat lunak yang umum.



Dan akhirnya, jika kita ingin sistem kita sepenuhnya independen, adaptif, mengatur diri sendiri, kita harus memberi mereka hak untuk identifikasi diri. Sebuah proyek bernama spiffe melakukan hal itu. Ini juga merupakan proyek yang disponsori oleh Cloud Native Computing Foundation.

Semua proyek ini masih muda, mereka semua membutuhkan cinta kita, ujian kita. Ini semua open source, pengujian kami, implementasi kami. Mereka menunjukkan kepada kita ke arah mana teknologi bergerak.

Tapi DevOps tidak pernah terutama tentang teknologi, terutama selalu tentang kolaborasi antara orang-orang. Dan, dengan demikian, jika kita ingin sistem yang kita kembangkan berubah, maka kita harus mengubah diri kita sendiri. Faktanya, kita sudah berubah, kita tidak punya pilihan khusus.



Ada sebuah buku yang bagus oleh penulis Inggris Rachel Botsman di mana dia menulis tentang evolusi kepercayaan sepanjang sejarah manusia. Dia mengatakan bahwa pada awalnya, dalam masyarakat primitif, kepercayaan adalah lokal, yaitu, kami hanya memercayai mereka yang kami kenal secara pribadi.

Kemudian ada periode yang sangat panjang - masa yang gelap, ketika kepercayaan terpusat, ketika kita mulai mempercayai orang-orang yang tidak kita kenal atas dasar bahwa kita milik lembaga publik atau lembaga negara yang sama.

Dan inilah yang kita lihat di dunia modern kita: kepercayaan semakin terdistribusi dan terdesentralisasi, dan didasarkan pada kebebasan arus informasi, pada ketersediaan informasi.

Jika Anda memikirkannya, aksesibilitas ini yang memungkinkan kepercayaan ini adalah apa yang kami laksanakan.Ini berarti bahwa baik cara kita bekerja maupun cara kita melakukannya harus berubah, karena organisasi TI hierarkis terpusat dari jenis lama berhenti bekerja. Mereka mulai mati.

Dasar-dasar Organisasi DevOps

Organisasi DevOps yang ideal di masa depan adalah desentralisasi, sistem adaptif yang terdiri dari tim otonom, yang masing-masing terdiri dari individu yang otonom. Tim-tim ini tersebar di seluruh dunia, mereka secara efektif bekerja sama satu sama lain menggunakan komunikasi asinkron, menggunakan protokol komunikasi yang sangat transparan. Sangat cantik bukan? Masa depan yang sangat indah.

Tentu saja, ini semua mustahil tanpa 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 di mana kita menjadi bagian, dan sistem yang kita bangun, semakin kacau, dan sulit bagi kita, orang-orang, untuk mengatasi gagasan ini, dan melepaskan ilusi kontrol. Kami mencoba untuk terus mengendalikan mereka, dan ini sering menyebabkan kelelahan. Saya mengatakan ini dari pengalaman saya sendiri, saya juga terbakar, juga cacat karena kegagalan produksi yang tidak terduga.



Kelelahan terjadi ketika kita mencoba mengendalikan sesuatu yang, pada dasarnya, tidak dapat dikendalikan. Ketika kita kelelahan, maka semuanya kehilangan artinya, karena kita kehilangan keinginan untuk melakukan sesuatu yang baru, kita mengambil posisi bertahan dan mulai mempertahankan apa yang ada.

Profesi teknik, seperti yang sering saya ingatkan pada diri saya sendiri, pada dasarnya adalah profesi kreatif. Jika kita kehilangan keinginan untuk menciptakan sesuatu, maka kita berubah menjadi abu, berubah menjadi abu. Orang-orang terbakar, seluruh organisasi terbakar.

Menurut pendapat saya, hanya menerima kekuatan kreatif kekacauan, hanya membangun kerja sama berdasarkan prinsip-prinsipnya yang membantu kita untuk tidak kehilangan kebaikan yang ada dalam profesi kita.

Apa yang saya inginkan untuk Anda: mencintai pekerjaan saya, mencintai apa yang kami lakukan. Dunia ini memakan informasi, kami mendapat kehormatan untuk memberinya makan. Jadi mari kita pelajari kekacauan, kita akan menjadi ahli chaos, kita akan membawa nilai, menciptakan sesuatu yang baru, baik, dan masalahnya, seperti yang telah kita ketahui, tidak terhindarkan, dan ketika mereka muncul, kita hanya akan mengatakan "Ops!", Dan masalahnya selesai.

Apa selain Chaos Monkey?

Padahal, semua alat ini, mereka masih sangat muda. Alat-alat yang dibangun Netflix untuk diri mereka sendiri. Bangun alat untuk diri sendiri. Baca prinsip-prinsip rekayasa kekacauan dan patuhi prinsip-prinsip ini, dan jangan mencoba mencari alat lain yang sudah dibangun orang lain.

Coba pahami bagaimana sistem Anda rusak dan mulailah memecahnya dan perhatikan bagaimana sistem itu tahan terhadap dampak. Ini yang pertama dan terutama. Dan Anda dapat mencari alat. Ada semua jenis proyek.

Saya tidak begitu mengerti saat ketika Anda mengatakan bahwa sistem tidak dapat disederhanakan dengan menyederhanakan komponennya, dan segera beralih ke layanan microser, yang hanya menyederhanakan sistem dengan menyederhanakan komponen sendiri dan menyulitkan interaksi. Ini pada dasarnya adalah dua bagian yang saling bertentangan.

Itu benar, layanan microser adalah topik yang sangat kontroversial secara umum. Bahkan, penyederhanaan bagian meningkatkan fleksibilitas. Apa yang diberikan oleh layanan microser? Mereka memberi kita fleksibilitas dan kecepatan, tetapi tentu saja mereka tidak memberi kita kesederhanaan dalam cara apa pun. Mereka meningkatkan kompleksitas.

Artinya, dalam filosofi DevOps, layanan mikro bukan merupakan berkah?

Setiap kebaikan memiliki sisi yang salah. Ada manfaatnya: meningkatkan fleksibilitas, memberi kita kemampuan untuk melakukan perubahan lebih cepat, tetapi meningkatkan kompleksitas dan, karenanya, kerapuhan seluruh sistem.

Namun, apa yang lebih ditekankan pada: penyederhanaan interaksi atau penyederhanaan bagian?

Penekanannya tidak diragukan lagi pada penyederhanaan interaksi, karena jika kita melihatnya dari sudut pandang bagaimana kami bekerja dengan Anda, maka, pertama-tama, kita perlu memperhatikan penyederhanaan interaksi, dan bukan untuk menyederhanakan pekerjaan kita masing-masing secara terpisah. Karena penyederhanaan pekerjaan berubah menjadi robot. Tetapi di McDonald's itu bekerja dengan baik ketika diresepkan untuk Anda: di sini Anda meletakkan burger, di sini Anda menuangkan saus di atasnya. Ini dalam karya kreatif kami tidak bekerja sama sekali.

Benarkah semua yang Anda katakan hidup di dunia tanpa persaingan, dan kekacauan di sana sangat baik, dan tidak ada kontradiksi dalam kekacauan ini, tidak ada yang mau makan, bunuh siapa pun? Bagaimana seharusnya kompetisi dan DevOps hidup?

Yah, itu tergantung pada kompetisi apa yang sedang kita bicarakan. Kompetisi di tempat kerja atau persaingan antar perusahaan?

Tentang persaingan layanan yang ada, karena layanan tidak sedikit perusahaan. Kami menciptakan tipe baru dari lingkungan informasi, dan lingkungan apa pun tidak dapat hidup tanpa persaingan. Di mana-mana ada kompetisi.

Netflix yang sama, kami mengambil mereka untuk panutan. Mengapa mereka datang dengan ini? Karena mereka harus kompetitif. Fleksibilitas dan kecepatan pergerakan ini, justru persyaratan yang sangat kompetitif ini, memperkenalkan keacakan ke dalam sistem kami. Artinya, kekacauan bukanlah apa yang secara sadar kita lakukan, karena kita menginginkannya, itu yang terjadi karena dunia membutuhkannya. Kami hanya harus beradaptasi. Dan kekacauan, itu hanya hasil dari kompetisi.

Apakah ini berarti kekacauan adalah kurangnya tujuan? Atau tujuan-tujuan yang tidak ingin kita lihat? Kami berada di rumah dan tidak mengerti tujuan orang lain. Persaingan, pada kenyataannya, ini disebabkan oleh kenyataan bahwa kita memiliki tujuan yang jelas, dan kita tahu ke mana kita akan datang pada setiap saat berikutnya. Dalam hal ini, dari sudut pandang saya, esensi dari DevOps.

Juga lihat pertanyaannya. Saya pikir kita semua memiliki satu tujuan: untuk bertahan hidup dan melakukannya dengan
senang hati. Dan tujuan kompetitif organisasi mana pun adalah sama. Kelangsungan hidup sering dalam persaingan, tidak ada yang bisa dilakukan.

Tahun ini, konferensi DevOpsDays Moscow akan diadakan pada 7 Desember di Technopolis. Hingga 11 November, kami menerima aplikasi untuk laporan. Email kami jika Anda ingin berbicara.

Pendaftaran untuk peserta terbuka, biaya tiketnya 7.000 rubel. Bergabunglah sekarang!