Wawancara dengan Alexander Titov, salah satu anggota komite program
pada konferensi HighLoad ++ Juni kami, bagian terpisah yang akan dikhususkan untuk DevOps.
Di bawah potongan tentang arah mana "angin" DevOps berhembus, dan apa sebenarnya aspek dari konsep ini akan dibahas di forum.
Alexander cukup akrab dengan komunitas kami, ia adalah penyelenggara DevOps Moscow dan konferensi DevOpsDays Moscow, ia telah berbicara di acara kami selama beberapa tahun dan membantu dalam pembentukan program mereka. Dia saat ini adalah Managing Partner di Express 42, yang menumbuhkan DevOps di perusahaan teknologi. Sebelumnya, dari 2010 hingga 2012, Alexander melewati jalur pengambilalihan yang menarik bersama Qik, dari mengoperasikan startup yang tumbuh cepat hingga beroperasi di perusahaan besar internasional Microsoft. Sebelum itu, pada 2009-2010, ia adalah direktur teknis hosting awan pertama di Rusia, Skalaxi.- Mari kita mulai dari jauh: apakah budaya DevOps berkembang? Perubahan apa yang telah diamati di bidang ini dalam beberapa tahun terakhir? Dan seperti apa DevOps di Rusia?Tentu saja, di dunia di mana teknologi saling berubah setiap tiga tahun, semuanya terus berubah dan sangat banyak. Awalnya, masalah dasar adalah produksi dan pengoperasian perangkat lunak itu sendiri di era digital. Tentang masalah ini, gerakan DevOps telah berkumpul. Sekarang, masalah dasar telah dibagi menjadi banyak subkategori - manajemen infrastruktur, pemantauan, integrasi berkelanjutan, pengiriman berkelanjutan, bekerja dengan orang-orang (khususnya, masalah kelelahan orang yang terlibat dalam eksploitasi dan pengembangan), beberapa hal teknologi (misalnya, penampilan Kubernetes, seperti standar de facto untuk seluruh platform infrastruktur di perusahaan). Yaitu, dalam banyak hal, hal-hal spesifik muncul: kami melewati tahap memahami apa yang perlu dilakukan secara berbeda dari sebelumnya, mencoba banyak pendekatan baru dan sampai pada pembentukan beberapa proses terstandarisasi untuk memecahkan masalah umum (tipikal). Tetapi pada saat yang sama, alat dan proses di banyak perusahaan di seluruh dunia masih tetap berkualitas buruk atau sangat tidak diformalkan.
Dalam konteks Rusia, masalah tambahan adalah kita tidak mengerti mengapa semua ini diperlukan. Ini membingungkan banyak orang. Kami memiliki pengembangan, pengujian, dan operasi secara terpisah, dan kemudian beberapa Kubernet datang untuk menyelesaikan beberapa masalah, tetapi mereka mencoba mengimplementasikannya tanpa mengubah proses, pendekatan, dan kompetensi orang. Semuanya rusak. Dan mengapa teknologi baru ini tidak jelas.
- Dan apa alasan transformasi radikal seperti itu?Seperti yang sudah saya sebutkan, kami mulai memecahkan masalah lain. Awalnya, TI klasik memecahkan masalah mengotomatisasi proses bisnis dalam suatu perusahaan. Seluruh infrastruktur disesuaikan dengan ini - database, bus, dll. Sejak tahun 2000, setelah krisis dot-com, TI telah beralih untuk menciptakan produk-produk digital yang secara besar-besaran dapat menyediakan layanan yang disesuaikan, memberikan beberapa nilai. Jika sebelumnya perusahaan memproduksi model mobil tertentu, sekarang telah beralih ke penyesuaian untuk setiap klien. Ini adalah solusi untuk masalah lain, yang memerlukan pendekatan dan teknologi yang berbeda secara fundamental - proses produksi perangkat lunak yang berbeda. Di sini tidak mungkin lagi melakukan pengembangan, pengujian, dan operasi secara berurutan. Sekarang proses ini dimulai secara bersamaan.
Ngomong-ngomong, meskipun demikian, ada kesalahpahaman bahwa DevOps adalah tentang operasi. Administrator sistem klasik yang melakukan pekerjaan operasional diubah namanya menjadi insinyur DevOps, mendiskreditkan istilah tersebut pada prinsipnya. Padahal, konsepnya jauh lebih luas. Ini adalah seperangkat praktik terpisah, kerangka kerja terpisah yang memungkinkan Anda untuk memecahkan masalah khusus dalam kondisi tertentu dan dengan orang-orang dari kompetensi tertentu - tidak lebih, tidak kurang. Hanya sedikit orang yang mengerti mengapa ini perlu. Dan ini adalah salah satu masalah yang kami coba selesaikan melalui konferensi.
-
Laporan apa yang direncanakan untuk fokus pada bagian dalam Siberian HighLoad?Jika sebelumnya ada terutama laporan operasional, maka tahun ini kami ingin menambahkan lebih banyak informasi tentang koneksi dengan pengembangan, misalnya, tentang proses pengiriman berkelanjutan, integrasi berkelanjutan, pengujian. Contoh keren adalah laporan oleh Maxim Lapshin pada RIT ++ (sebagai bagian dari pegas RootConf 2018) tentang cara menggunakan DevOps dalam pengembangan kotak. Perusahaan seperti itu pada dasarnya tidak memiliki eksploitasi - itu membuat sebuah kotak yang dijualnya kepada pelanggan. Pada saat yang sama, ia memiliki DevOps di dalamnya. Pendekatan ini mematahkan polanya, tetapi pada saat yang sama membantu menghilangkan prasangka mitos yang menyebutkan bahwa DevOps hanya tentang operasi. Ini adalah fokus dasar pertama kami.
Fokus kedua adalah teknologi baru. Sekarang fashionable untuk berbicara tentang Kubernetes, Prometheus dan lainnya. Dan kami mencari orang yang bisa merasakan teknologi ini dalam praktiknya. Artinya, tidak hanya dikonfigurasi dan dibuat berfungsi, tetapi juga termasuk ini dalam proses pengembangan mereka. Secara umum, kami mencoba untuk mempertimbangkan semua teknologi di bawah prisma tentang bagaimana mereka termasuk dalam proses produksi perangkat lunak - masalah apa yang mereka pecahkan, tujuan apa yang mereka tetapkan, dll. Jika Anda tidak membicarakan hal ini, orang-orang mulai bekerja dengan teknologi sebagai kultus kargo: "Ayo pakai Kubernet dan kita bisa membuat Google." Itu tidak akan berhasil seperti itu.
- Konsep integrasi berkelanjutan sudah diterima dengan baik oleh pasar. Selain alat khusus, apakah ada yang perlu dibicarakan?Tentu saja Konsep dasar yang dapat dikatakan penting adalah bahwa dalam konteks DevOps, produk tidak diuji kualitasnya dalam proses integrasi berkelanjutan. Artinya, tidak masalah seberapa matang produk itu secara fungsional. Penting untuk memeriksa seberapa baik dimulai dan apakah siap untuk diintegrasikan dengan komponen lain.
Ini adalah perubahan besar, karena ada integrasi berkelanjutan dalam pengembangan, operasi dan pengujian yang konsisten. Tetapi di sana, pada level ini, kualitas produk diperiksa sesuai dengan kebutuhan pengguna, dan dalam kerangka kerja DevOps, kualitas fungsional diperiksa. Tahap inilah yang memungkinkan integrasi tercepat dari layanan individual dalam kerangka infrastruktur layanan-mikro (dan DevOps secara keseluruhan tidak ada tanpa arsitektur layanan-mikro).
- Alat apa yang menjadi fokus tahun ini?Pertama-tama, Kubernet sudah disebutkan. Itu muncul beberapa waktu lalu, tetapi baru saja mencapai tahap ketika itu dapat digunakan. Sekarang ini dapat digunakan oleh perusahaan mana pun yang mengembangkan layanan digital yang diperbarui, misalnya, menyediakan layanan melalui situs web atau aplikasi seluler.
Sering disebut sebagai Prometheus - sistem pemantauan, GitLab - sebagai sistem integrasi berkelanjutan. Dan juga seluruh tumpukan HashiCorp - Vault, Terraform (keduanya dikembangkan oleh HashiCorp). Yah, tentu saja, Docker - sebagai format pengiriman.
- Apakah ada perubahan terbaru dalam kerangka konsep "semuanya sebagai kode"?Praktik "semuanya sebagai kode" itu sendiri jelas berguna. Ini adalah salah satu prinsip dasar yang menjadi dasar proses DevOps. Kubernetes hanya meneruskan ideologi ini.
Di DevOps, cerita utamanya adalah "infrastruktur sebagai kode". Dan ini bukan hanya sebuah konsep, tetapi juga sebuah proses di mana semua komponen disajikan dalam bentuk kode yang memungkinkan masing-masing "potongan" infrastruktur untuk saling berinteraksi. Tidak ada perubahan drastis di sini, tetapi, sebagai praktik, sekarang berkembang di dalam Kubernetes. Misalnya, alat manajemen ketergantungan seperti Helm dikembangkan, alat untuk membuat modul terpisah, deskripsi infrastruktur, misalnya operator (dan tampaknya ada kerangka kerja untuk menulis pernyataan di Kubernetes), dll. Dengan kata lain, ada perkembangan instrumen yang sehat dan penetrasi praktik di dalamnya.
- Apakah praktik "semuanya sebagai kode" terpisah dari instrumen yang layak dibicarakan?Kami belum sepenuhnya membentuk program, jadi saya tidak bisa mengatakan apakah kami akan mengangkat topik semacam itu secara khusus di HighLoad ++. Tapi ini dengan sendirinya dimungkinkan.
Ada banyak pendekatan untuk mengatur infrastruktur, mengelola ketergantungan dalam kode infrastruktur, dan mengujinya. Tentu saja, kita akan berbicara tentang konsep untuk bekerja dengan praktik - misalnya, kode infrastruktur harus dibagi menjadi beberapa modul. Tampaknya bagi saya bahwa penyempurnaan, terpisah dari praktik, topik-topik seperti itu tidak cocok dengan baik. Tapi, mungkin, kami akan memilih laporan di mana semua pendekatan yang mungkin akan dikumpulkan dalam kerangka deskripsi sistem tunggal. Namun, itu jauh lebih berharga ketika orang mengatakan dan menunjukkan bagaimana konsep-konsep teoretis ini diwujudkan dalam kenyataan. Tentang teori yang mendasari praktik, Anda kemudian dapat berbicara dengan orang yang sama di sela-sela.
- Ada pendapat yang mengatakan bahwa popularitas arsitektur berbasis acara semakin meningkat dari waktu ke waktu. Apakah Anda setuju dengan pernyataan ini?Infrastruktur yang digerakkan oleh acara selalu menjadi bagian dari pendekatan obrolan - dengan acara, kami membuat keputusan dalam obrolan tentang apa yang harus terjadi pada sepotong infrastruktur. Kisah ini sangat penting bagi perusahaan besar, tetapi bagi penonton lainnya masih belum cukup matang. Untuk membuat keputusan tentang apa yang harus terjadi (apa yang harus kita lakukan), perlu untuk mengembangkan beberapa kerangka kerja untuk aturan dalam tim tentang bagaimana kita membuat keputusan ini, sehingga setiap orang melakukannya kurang lebih sama - lihat dari satu sisi. Dan dengan ini, semuanya rumit. Format untuk mengembangkan kerangka kerja seperti itu adalah apa yang dibicarakan semua orang sekarang: bagaimana hal itu dapat diotomatisasi, dibawa ke alat, bagaimana hal itu perlu dilakukan di tingkat pembentukan tim dan bagaimana berkoordinasi dengan tim yang berbeda.
- Apakah ini tercermin dalam laporan konferensi?Tidak, HighLoad ++ lebih tentang sistem dan alat yang sangat dimuat, jadi di sini kita dapat berbicara tentang alat, tetapi bukan tentang mengembangkan kerangka kerja seperti itu. Tetapi pada musim gugur kita akan mengadakan konferensi RootConf terpisah, yang akan diadakan pada 1-2 Oktober. Sampai 2011, ia dikhususkan untuk masalah operasional (yaitu, hanya satu komponen dari seluruh proses "pengembangan-pengujian-operasi"). Pada 2015, kami bereinkarnasi dalam konteks seluruh DevOps - jadi kami secara bertahap memperluas topik. Di RootConf kami membahas bagaimana memastikan interaksi pengembang dan teknisi pemeliharaan, kami berbicara tentang proses dan teknologi baru, tentang platform infrastruktur dan manajemen infrastruktur, yang dalam paradigma DevOps tidak hanya terlibat dalam operasi, tetapi juga dalam pengembangan (mereka hanya melakukan tugas yang berbeda).
- Apakah ada teknologi yang menarik untuk meningkatkan ketahanan proyek dalam beberapa tahun terakhir? Apakah mereka akan dibahas di konferensi?Hari ini kami menemukan paradoks yang terkait dengan fakta bahwa "toleransi kesalahan" tidak berarti "keandalan". Toleransi kesalahan sekarang digantikan oleh keandalan.
Toleransi kesalahan adalah konsep dari paradigma sistem monolitik, di mana masalah keandalan diselesaikan melalui duplikasi, peningkatan sumber daya, dll. Sekarang pendekatan seperti itu tidak lagi berhasil. Keandalan didasarkan pada pendekatan yang berbeda secara mendasar - ini menyiratkan "anti-kerapuhan" sistem. Artinya, sistem menjadi "lunak": jika kita bertindak, itu berubah, bukan runtuh. Dengan kata lain, jika Anda akan membangun semacam layanan baru, Anda harus menyediakan untuk varian perilakunya di mana jika pengguna atau lingkungan di mana ia bekerja mencoba untuk menghancurkannya, maka layanan hanya mengubah propertinya, sementara layanan masih disediakan , beberapa hasil diberikan.
Penanda tren yang baik adalah munculnya rekayasa keandalan situs sebagai praktik dan spesialis individu - insinyur keandalan situs (SRE) sebagai pengganti kompetensi masa lalu dari administrator sistem. Sebagai ilustrasi dari proses ini, saya akan menyebutkan bahwa Google merilis praktik implementasi DevOps dalam bentuk buku tentang rekayasa keandalan situs dan secara aktif mempromosikan ide ini kepada massa.
Kami juga akan membicarakan ini di RootConf. Sekarang topik ini sedang populer di Barat, dan kami (oleh komunitas DevOps Moscow) mencoba untuk secara bertahap membawanya kepada kami.