Konferensi DUMP | grep 'backend \ | devops'

Minggu lalu saya pergi ke konferensi DUMP IT (https://dump-ekb.ru/) di Yekaterinburg dan saya ingin berbicara tentang apa yang dibahas di bagian Backend dan Devops dan apakah konferensi TI regional layak mendapat perhatian.


Nikolay Sverchkov dari Evil Martians tentang Serverless

Apa yang ada di sana?

Secara total, konferensi memiliki 8 bagian: Backend, Frontend, Mobile, Testing dan QA, Devops, Desain, Sains dan Manajemen.

Omong-omong terbesar, omong-omong, adalah Sains dan Manajemen)) Masing-masing ~ 350 orang. Backend dan Frontend tidak jauh lebih sedikit. Devops Hall adalah yang terkecil tetapi paling aktif.

Saya mendengarkan laporan di bagian Devops dan Backend dan berbicara sedikit dengan para pembicara. Saya ingin berbicara tentang topik yang dibahas dan memberikan tinjauan umum mengenai bagian-bagian ini di konferensi.

Perwakilan dari SKB-Kontur, DataArt, Evil Martians, studio web Yekaterinburg Flag, Miro (Miro (RealTimeBoard)) berbicara di bagian Devops dan Backend. Topik yang terkait dengan CI / CD, bekerja dengan layanan antrian, masuk, topik Tanpa Server dan bekerja dengan PostgreSQL in Go sudah tercakup dengan baik.

Ada juga laporan dari Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, tetapi saya tidak punya waktu untuk mengunjungi mereka secara fisik (rekaman video dan slide laporan belum tersedia, mereka berjanji akan diposting di dump-ekb.ru dalam waktu 2 minggu).

Bagian devops

Yang mengejutkan - bagian itu diadakan di aula terkecil, sekitar 50 kursi. Orang-orang bahkan berdiri di lorong :) Saya akan memberi tahu Anda tentang laporan yang berhasil saya dengarkan.

Berat elastis dalam petabyte

Bagian ini dimulai dengan laporan oleh Vladimir Lil (SKB-Kontur) tentang Elasticsearch di Kontur. Mereka memiliki Elastis yang cukup besar dan memuat (~ 800 TB data, ~ 1,3 petabyte, dengan mempertimbangkan redundansi akun). Elasticsearch untuk semua layanan sirkuit adalah tunggal, terdiri dari 2 cluster (dari 7 dan 9 server), dan sangat penting sehingga ada insinyur Elasticsearch khusus di sirkuit (pada kenyataannya, Vladimir sendiri).

Vladimir juga membagikan pemikirannya tentang manfaat dari Elasticsearch dan masalah yang dia bawa.

Manfaat:

• Semua log di satu tempat, akses mudah ke sana
• Penyimpanan log selama setahun dan analisisnya yang mudah
• Kecepatan tinggi dengan log
• Visualisasi data keren “out of the box”

Masalahnya:

• broker pesan - harus ada (Kafka memainkan peran Kontur)
• Fitur bekerja dengan Elasticsearch Kurator (secara berkala dibuat beban tinggi dari tugas-tugas reguler di Kurator)
• tidak ada otorisasi bawaan (hanya untuk uang terpisah, cukup besar, atau sebagai plug-in open source dengan berbagai tingkat kesiapan untuk produksi)

Tentang Open Distro for Elasticsearch, ulasannya hanya positif :) Masalah otorisasi yang sama diselesaikan di sana.

Fitur Pengembangan Tanpa Server

Laporan lebih lanjut dari Ruslan Serkin dari DataArt tentang Serverless.

Ruslan berbicara tentang apa pengembangan dengan pendekatan Serverless secara umum, dan apa saja fitur-fiturnya.

Serverless adalah pendekatan pengembangan di mana pengembang tidak ada hubungannya dengan infrastruktur. Contohnya adalah AWS Lambda Serverless, Kubeless.io (Serverless di dalam Kubernetes), Google Cloud Functions.

Aplikasi Serverless yang ideal hanyalah fitur yang mengirimkan permintaan ke penyedia Serverless melalui API Gateway khusus. Layanan mikro yang ideal, sementara dalam AWS Lambda yang sama sejumlah besar bahasa pemrograman modern didukung. Biaya untuk mendukung dan menggunakan infrastruktur menjadi nol dalam hal penyedia cloud, mendukung aplikasi kecil juga akan sangat murah (AWS Lambda - $ 0,2 / 1 juta permintaan sederhana).

Skalabilitas sistem semacam itu hampir sempurna - penyedia cloud menangani ini sendiri, Kubeless secara otomatis diskalakan di dalam kluster Kubernetes.

Ada kerugiannya:

• mengembangkan aplikasi besar semakin sulit
• ada kesulitan dengan membuat profil aplikasi (hanya log yang tersedia untuk Anda, tetapi tidak membuat profil dalam arti biasa)
• tidak ada versi

Terus terang, saya mendengar tentang Serverless beberapa tahun yang lalu, tetapi selama ini tidak jelas bagi saya bagaimana menggunakannya dengan benar. Setelah laporan Ruslan, pemahaman muncul, dan setelah laporan Nikolai Sverchkov (Evil Martians) dari bagian Backend, ia bergabung. Tidak heran saya pergi ke konferensi :)

CI untuk orang miskin, atau layak menulis CI Anda sendiri untuk studio web

Mikhail Radionov, kepala studio web Flag dari Yekaterinburg, berbicara tentang CI / CD yang ditulis sendiri.

Studionya beralih dari "CI / CD manual" (masuk ke server melalui SSH, melakukan git pull, ulangi 100 kali sehari) ke Jenkins dan ke alat yang ditulis sendiri yang memungkinkan Anda untuk mengontrol kode dan menjalankan rilis yang disebut Pullkins.

Mengapa Jenkins tidak bekerja? Itu tidak memberikan fleksibilitas yang cukup secara default dan terlalu rumit untuk kustomisasi.

"Bendera" sedang dikembangkan di Laravel (kerangka PHP). Ketika mengembangkan server CI / CD, Michael dan rekan-rekannya menggunakan mekanisme Laravel built-in yang disebut Telescope dan Utusan. Hasilnya adalah server php (perhatikan) yang memproses permintaan webhook yang masuk, dapat merakit frontend, backend, menyebarkan ke server yang berbeda dan melaporkan ke Slack.

Lebih lanjut, untuk kemampuan melakukan penyebaran biru / hijau, untuk memiliki pengaturan seragam di lingkungan dev-stage-prod, mereka beralih ke Docker. Nilai tambahnya tetap sama, kemungkinan untuk menyeragamkan lingkungan dan penyebaran yang mulus ditambahkan, dan kebutuhan untuk mempelajari Docker agar bekerja dengan benar telah ditambahkan.

Proyek ini ada di Github

Bagaimana kami mengurangi jumlah kemunduran rilis server hingga 99%

Laporan terbaru di bagian Devops adalah dari Victor Eremchenko, insinyur devops di Miro.com (sebelumnya RealTimeBoard).

RealTimeBoard, produk inti dari tim Miro, didasarkan pada aplikasi Java monolitik. Mengumpulkan, menguji, dan menyebarkannya tanpa downtime adalah tugas yang sulit. Pada saat yang sama, penting untuk menggunakan versi kode sedemikian rupa sehingga tidak harus diputar kembali (monolit berat).

Dalam perjalanan untuk membangun sebuah sistem yang memungkinkan ini, Miro pergi jauh, termasuk bekerja pada arsitektur, alat yang digunakan (Atlassian Bamboo, Ansible, dll), dan bekerja pada tim pembangunan (mereka sekarang memiliki perintah Devops khusus + banyak perintah Scrum terpisah dari pengembang profil yang berbeda).

Jalan itu ternyata sulit dan sulit, dan Victor berbagi keputusannya, rasa sakit yang terakumulasi dan optimisme yang tidak berakhir di sana.


Memenangkan buku untuk pertanyaan

Bagian backend

Saya punya 2 laporan - dari Nikolai Sverchkov (Evil Martians), juga tentang Serverless, dan dari Grigory Koshelev (perusahaan Kontur) pada telemetri.

Tanpa server untuk manusia biasa

Jika Ruslan Sirkin berbicara tentang apa itu Serverless, Nikolai menunjukkan aplikasi sederhana menggunakan Serverless, dan berbicara tentang perincian yang memengaruhi biaya dan kecepatan aplikasi di AWS Lambda.

Detail menarik: item minimum yang dibayar adalah 128 Mb memori dan 100 ms CPU, harganya $ 0,000000208. Selain itu, 1 juta permintaan seperti itu per bulan adalah gratis.

Beberapa fungsi Nikolai sering melebihi batas 100 ms (aplikasi utama ditulis dalam Ruby), jadi menulis ulang di Go memberi penghematan yang luar biasa.

Vostok Hercules - buat telemetri menjadi luar biasa lagi!

Laporan terbaru dari bagian Backend dari Grigory Koshelev (perusahaan Kontur) tentang telemetri. Telemetri adalah log, metrik, jejak aplikasi.

Contour menggunakan alat tertulisnya sendiri yang diposting di Github untuk ini. Alat laporan, Hercules, github.com/vostok/hercules , digunakan untuk mengirimkan data telemetri.

Sebuah laporan oleh Vladimir Lila di bagian Devops melihat penyimpanan dan pemrosesan log di Elasticsearch, tetapi masih ada tugas untuk mengirimkan log dari ribuan perangkat dan aplikasi, dan alat-alat seperti Vostok Hercules menyelesaikannya.

Sirkuit berjalan seperti yang diketahui banyak orang - dari RabbitMQ ke Apache Kafka, tetapi tidak begitu sederhana)) Mereka harus menambahkan Zookeeper, Cassandra dan Graphite ke dalam skema. Saya tidak akan sepenuhnya mengungkapkan informasi tentang laporan ini (bukan profil saya), jika tertarik, Anda dapat menunggu slide dan video di situs web konferensi.

Bagaimana dibandingkan dengan konferensi lain?

Saya tidak dapat membandingkannya dengan konferensi di Moskow dan St. Petersburg, saya dapat membandingkannya dengan acara-acara lain di Ural dan dengan festival 404 di Samara.

DUMP diadakan di 8 bagian, ini adalah catatan untuk konferensi Ural. Bagian yang sangat besar dari Sains dan Manajemen, ini juga tidak biasa. Penonton di Yekaterinburg cukup terstruktur - kota ini memiliki departemen pengembangan besar Yandex, Kontur, Tinkoff, ini meninggalkan jejak pada laporan.

Hal lain yang menarik adalah bahwa banyak perusahaan segera memiliki 3-4 pembicara di konferensi (ini adalah kasus dengan Kontur, Evil Martians, Tinkoff). Banyak dari mereka adalah sponsor, tetapi laporannya cukup setara dengan yang lain, ini bukan laporan periklanan.

Pergi atau tidak pergi? Jika Anda tinggal di atau dekat Ural, Anda memiliki peluang dan topik menarik - ya, tentu saja. Jika Anda berpikir tentang perjalanan panjang, saya akan melihat topik laporan dan laporan video dari tahun-tahun sebelumnya www.youtube.com/user/videoitpeople/videos dan membuat keputusan.
Kelebihan lain dari konferensi di daerah, sebagai suatu peraturan, adalah mudah untuk berkomunikasi dengan pembicara setelah laporan, ada lebih sedikit pelamar untuk komunikasi tersebut.



Terima kasih kepada Dump dan Yekaterinburg! )