DevOops 2019 melalui mata pengembang

29-30 Oktober di St. Petersburg menjadi tuan rumah konferensi DevOops . Dalam artikel ini, saya akan membagikan kesan dan wawasan saya, serta catatan singkat tentang laporan yang saya dengar. Penafian kecil: karena saya seorang pengembang, beberapa pemikiran dan komentar mungkin bias di Dev daripada di Ops, tapi saya akan berusaha seobjektif mungkin.

DevOops adalah salah satu acara yang diselenggarakan oleh Grup JUG Ru . Dan harus saya akui, organisasi dan level laporan ada di level tersebut. Konferensi berlangsung dua hari, dalam tiga aliran. Selain itu, ada area diskusi untuk komunikasi dengan pembicara, lokakarya, serta pembicaraan kilat - presentasi yang lebih mudah dan lebih pendek, termasuk bagi mereka yang belum pernah tampil sebelumnya dan ingin mencoba sendiri sebagai pembicara.

Kanvas tematik DevOops 2019 - cloud asli. Sebagian besar laporan secara langsung atau tidak langsung dikhususkan untuk awan. Topik ini tidak baru untuk waktu yang lama, tetapi ada banyak kesulitan yang tidak terlihat yang muncul dalam proses menggunakan teknologi cloud. Dan banyak yang datang dengan sengaja untuk menemukan jawaban. Ini terutama terlihat pada sesi QA setelah presentasi. Para pembicara ditanyai pertanyaan-pertanyaan praktis yang sangat menggairahkan orang. Hampir setiap pertanyaan diikuti oleh komentar dari peserta lain “Kami memiliki masalah yang sama!” Dan diskusi yang hidup dimulai.

Hari pertama

Karakter, komunitas, dan budaya: Faktor penting untuk kemakmuran (Timothy Lister, The Atlantic Systems Guild Inc.)

Konferensi dibuka oleh Timothy Lister, yang kembali pada tahun 1987 (!) Menulis sebuah buku tentang praktik DevOps. Tim banyak berbicara tentang apa yang membedakan tim yang kuat dan sukses dengan suasana yang sehat dan menyenangkan dari tim yang biasa-biasa saja dan beracun. Saya terutama ingat pikiran itu:

"Perusahaan yang baik penuh dengan orang-orang yang mengatakan" Saya tidak tahu. "

Ini tentang keterbukaan dan kepercayaan dalam tim. Suasana keterbukaan sangat penting jika Anda memiliki tujuan yang ambisius. Untuk melakukan ini, semua orang di tim harus merasa nyaman dan bebas. Ini tidak berarti bahwa jika terjadi masalah, anggota tim segera meningkatkannya ke semua orang. Suasana keterbukaan adalah penting dan kemampuan kapan saja untuk beralih ke seseorang yang spesifik (terlepas dari posisi) atau ke seluruh tim dan dengan jelas menyatakan apa yang perlu diperbaiki atau diubah. Budaya seperti itu membentuk latar belakang yang tenang untuk bekerja, ketika semua orang tahu bahwa jika muncul pertanyaan mereka akan didengarkan.

Dalam pengalaman saya, untuk operasi yang produktif dan stabil, faktor ini sangat penting. Bagaimanapun, pertanyaan, gesekan dan perubahan arah akan selalu ada. Dan suasana keterbukaan adalah alat universal yang memungkinkan Anda untuk mengatasi tantangan pribadi dan tim.

Pikiran lain yang tampaknya benar bagi saya: tidak ada formula yang benar untuk membangun budaya di perusahaan.

“Tidak ada budaya yang bisa disebut ideal. Dan tidak ada satu budaya pun yang bisa disebut kegagalan total. ”

Tren terkini: semakin banyak konferensi mencakup laporan tentang manajemen, komunikasi, pembangunan tim, dan budaya. Tidak terkecuali DevOops. Saya percaya bahwa ini adalah tren positif, karena faktor-faktor ini memiliki dampak yang lebih besar pada hasil akhir daripada kesulitan teknologi.

"Pemimpin tidak mengelola tim, tetapi menumbuhkannya."

Lakukan dalam kode (bukan YAML)! Membuka kekuatan Kotlin DSL untuk Kubernetes (Victor Gamow, Confluent, dan Fedor Korotkov, Cirrus Labs)

Laporan semi-pemakaman, tetapi sepenuhnya mengungkapkan rasa sakit menulis file YAML yang tak ada habisnya, dukungan mereka dan (oh, horor!) Debug jika terjadi kesalahan atau kesalahan ketik. Ini bahkan menyebabkan munculnya item baris Insinyur YAML tertentu.

Bagaimana semuanya dimulai? Sekali waktu ada skrip. Lalu ada lebih banyak dari mereka. Dan lagi. Ada kebutuhan untuk menyatukan, menyederhanakan dan skala solusi. Jadi di dunia DevOps, format YAML muncul dan menjadi standar dalam banyak alat.

Penulis laporan berpikir dan berkata: "sesuatu di konservatori salah."

• Tidak jelas cara menguji file YAML.
• Mudah membuat kesalahan. Selain itu, beberapa kesalahan hampir mustahil untuk ditangkap dan sangat menyakitkan untuk diperbaiki. Misalnya, Anda dapat dengan mudah menentukan versi ketergantungan sebagai angka, bukan string. Dan kemudian cari tahu sejak lama mengapa versi yang salah digunakan, yang ditunjukkan dalam konfigurasi. Dan ini semua tentang tipe casting dan pembulatan.
• Jika kesalahan adalah sintaksis, maka itu akan dideteksi dengan cukup cepat, dalam CI. Tetapi ini tidak akurat.

Sorotan dari laporan ini adalah mengunggah konfigurasi yang tidak valid ke Kubernetes, yang ia balas dengan tenang: Terlalu banyak kesalahan .

Victor dan Fedor menawarkan untuk menulis konfigurasi pada DSL Kotlin, yang membantu mengatasi semua masalah ini. Ya, solusinya menarik dan nyaman, tetapi tidak universal dan hanya berfungsi untuk k8s. Selain itu, dalam hal memperbarui API, Anda juga harus memperbarui perpustakaan.

Pipelines & pods: DevOps dengan Kubernetes (Burr Sutter, Red Hat)

Sebuah laporan ringan tentang konsep umum dan komponen utama Kubernetes, serta alat-alat Ops lainnya dan praktik-praktik Ops. Untuk pemula dalam subjek - apa yang dibutuhkan. Ini akan sangat cocok dengan program konferensi untuk pengembang, tetapi aneh untuk mendengarkan laporan tingkat ini di konferensi khusus tentang DevOps. Meskipun demikian, ulasannya ternyata bagus, sederhana dan jelas.

Tetapi untuk membentuk JSON dari kode Java menggunakan StringBuilder entah bagaimana terlalu banyak. Bahkan mempertimbangkan bahwa ini adalah proyek demo.

Pola dan antipattern dari pembaruan berkelanjutan dalam praktik DevOps (Baruch Sadogursky, JFrog)

Dalam laporan Baruch, sulit untuk memilih satu ide atau arah apa pun. Sebaliknya, itu adalah kumpulan pengalaman pribadi, kisah hidup, contoh-contoh "bagaimana berbuat baik dan seberapa buruk", dongeng, hi-hack lain dan "fakapchikov".

Terutama dari laporan ini saya ingat cerita ketika, karena kesalahan dalam proses penyebaran, Grup Capital Knight kehilangan $ 440.000.000 dalam 45 menit dan bangkrut.

Pada akhirnya, Baruch bercerita tentang bug dalam perangkat lunak Airbus A350. Karena bug ini, maskapai terpaksa me-restart pesawat setiap 149 jam, dan untuk ini harus ditanam di darat. Dan jika seseorang lupa melakukan ini, pesawat akan membeku. Bug yang tidak menyenangkan. Masalahnya sederhana - terjadi overflow dalam kode. Perbaiki juga sederhana. Tapi seandainya mereka masih lupa untuk memulai kembali pesawat, itu berangkat dengan penerbangan Los Angeles → London dan 3 jam sebelum pendaratan, para pilot menyadari bahwa dalam satu jam pesawat akan membeku. "Houston, kita punya masalah." "Sekarang kita perbaiki!" Para operator menjawab, mengumpulkan programmer AirBus, memperbaikinya, semuanya berfungsi. Apa yang harus dilakukan selanjutnya? Menyebarkan versi baru di pesawat melalui udara? Atau tidak mengambil risiko? Baruch bertekad: "Menyebarkan. Itu tidak akan lebih buruk. "

Hari kedua

CDK dan infrastruktur sebagai kode (Sergey Kurson, AWS)

Sergey berbicara tentang AWS CDK (Cloud Development Kit). Ini adalah sekumpulan pustaka yang memungkinkan Anda untuk mengelola infrastruktur kode Anda. Keputusan ini kontroversial, karena manajemen infrastruktur dengan gaya imperatif adalah semacam kemunduran. Semua alat otomasi modern memungkinkan Anda untuk menggambarkan infrastruktur dengan gaya deklaratif (yaitu keadaan yang seharusnya dihasilkan). Namun, ada keuntungan dari pendekatan ini. Misalnya, proses pengujian infrastruktur yang digunakan sangat disederhanakan, dan proses penempatan dan memutuskan apa dan bagaimana menggunakan menjadi jauh lebih fleksibel. Selain itu, ada peluang besar untuk manajemen infrastruktur yang dinamis dan sangat fleksibel berdasarkan peristiwa, atribut, atau metrik.

Mengapa kita membutuhkan saringan layanan? (Anton Weiss, Perangkat Lunak Otomato)

Mungkin salah satu laporan terbaik dan terdalam dari konferensi ini. Dengan "saringan layanan", seorang pembicara berarti sebuah mesh Layanan - lapisan terpisah dari infrastruktur cloud yang mengontrol komunikasi layanan di antara mereka sendiri. Pola jala Layanan mendelegasikan banyak tugas dari tingkat layanan (mis., Dari pengembang aplikasi) ke level saringan layanan itu sendiri (pada DevOps):

• manajemen keamanan;
• pemantauan lalu lintas;
• manajemen lalu lintas.

Meskipun Service mesh sebagai teknologi telah ada selama beberapa tahun, penulis membuat laporan mendalam tentang hal itu dan menganalisis sejarah asalnya, bagaimana ia berkembang dan bagaimana ia akan berkembang di tahun-tahun mendatang.

Laporan ini sangat berguna bagi pengembang, karena tugas yang diselesaikan Service mesh sekarang sering diselesaikan di tingkat layanan. Dan ini membutuhkan waktu ekstra dari pengembang dan membuatnya sulit untuk berkonsentrasi dalam memecahkan masalah bisnis.

Mempercepat permintaan Internet dan tidur nyenyak (Sergey Fedorov, Netflix)

Sergey bekerja di Netflix untuk memastikan bahwa layanan bekerja untuk pengguna akhir secepat mungkin. Semua permintaan di dalamnya dibagi menjadi dua kelompok besar:

• permintaan cloud (dinamika);
• Kueri CDN (statis).

Dalam banyak kasus, perlu secara bersamaan membuat permintaan untuk bagian infrastruktur yang dinamis dan statis. Tetapi skema seperti itu memiliki overhead: Anda perlu membangun setidaknya dua koneksi, melakukan TLS Handshake dua kali, dll.

Ada gagasan bahwa jika Anda membuat permintaan hanya ke infrastruktur statis, instal proxy pintar di atasnya dan percayakan dengan membuat permintaan dinamis ke cloud atas namanya, ini akan mempercepat permintaan klien. Tim Netflix telah menerapkan skema semacam itu, melakukan pengujian pada pengguna nyata. Namun, menjadi jelas bahwa itu tidak selalu berhasil dan tidak untuk semua orang, beberapa permintaan mulai diproses lebih buruk.

Karena itu, tim memutuskan untuk pergi ke arah lain. Mereka datang dengan skema yang memungkinkan setiap klien untuk secara individual memutuskan bagaimana lebih menguntungkan untuk melakukan permintaan dinamis: langsung dari klien atau percayakan proksi permintaan ini ke bagian statis dari infrastruktur.

Ini adalah contoh yang baik dari tidak harus mundur dari tantangan teknis. Anda harus berani dan memilih opsi kompromi jika itu membuat produk lebih baik, dan kehidupan pengguna lebih mudah.

Mengapa industri TI mengalami masa kelam, bagaimana DevOps disalahkan, dan mengapa Capital dapat membantu (Roman Shaposhnik, ZEDEDA Inc.)

Laporan paling "visioner" dari konferensi ini. Di dalamnya, Roman berbicara banyak tentang bagaimana teknologi (dan modal) saling berhubungan (dan tidak terpisahkan). Saya pikir tesis ini sangat penting bagi para insinyur dan memahami bahwa teknologi diciptakan untuk memecahkan masalah spesifik orang dan bisnis. Dengan pemikiran seperti itu, menjadi lebih mudah untuk memprioritaskan tugas dan memahami apa yang penting dan apa yang tidak. Roman juga berbicara tentang mengapa kebijakan tertutup dan perusahaan, yang semakin meningkatkan pengaruhnya, dapat menyebabkan krisis global di industri TI. Serta secara keseluruhan tentang sejarah dan filosofi bidang teknologi informasi.

DevOops adalah tentang pengembangan

Beberapa pembicara bertanya kepada hadirin siapa yang terlibat dalam operasi dan infrastruktur, dan siapa yang sedang berkembang. Hasilnya mengejutkan saya: distribusinya sekitar 50 hingga 50. Sangat menyenangkan bahwa semakin banyak pengembang ingin memahami apa yang terjadi pada kode mereka setelah menulis, bagaimana aplikasi dikerahkan dan berkomunikasi satu sama lain. Dengan pemahaman ini, ketika menulis kode, Anda segera berpikir tentang bagaimana itu akan bekerja dalam kondisi hidup dan di mana Anda dapat meletakkan sedotan.