Pada 25 April, kami di Mail.ru Group mengadakan konferensi tentang cloud dan sekitar -
mailto: CLOUD . Beberapa hal penting:
- Penyedia utama Rusia berkumpul pada satu tahap - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center dan Yandex.Cloud berbicara tentang kekhasan pasar cloud kami dan layanan mereka;
- Kolega dari Bitrix24 memberi tahu bagaimana mereka melakukan multiclaud ;
- Leroy Merlin, Otkrytie, Burger King dan Schneider Electric memberikan pandangan yang menarik pada bagian dari konsumen cloud - tugas apa yang ditetapkan bisnis mereka untuk IT dan teknologi mana, termasuk cloud, yang mereka pandang sebagai yang paling menjanjikan.
Semua video dari mailto: konferensi CLOUD dapat dilihat di
sini , tetapi di sini Anda dapat membaca bagaimana diskusi tentang layanan microser. Alexander Deulin, kepala pusat penelitian dan pengembangan sistem bisnis MegaFon, dan Sergey Sergeyev, direktur teknologi informasi kelompok M.Video-Eldorado, berbagi kasus sukses mereka dalam menyingkirkan monolit. Mereka juga membahas masalah terkait strategi TI, proses, dan bahkan SDM.
Panelis
- Sergey Sergeev , Direktur Teknologi Informasi , M.Video-Eldorado Group ;
- Alexander Deulin , kepala pusat penelitian dan pengembangan sistem bisnis MegaFon ;
- Moderator - Dmitry Lazarenko , kepala Solusi Cloud Mail.ru PaaS-direction.
Setelah pidato oleh Alexander Deulin
“Bagaimana MegaFon Memperluas Bisnisnya Melalui Platform Layanan Mikro”, Sergey Sergeev dari M.Video-Eldorado bergabung untuk berdiskusi dan menjadi moderator diskusi Dmitry Lazarenko, Mail.ru Cloud Solutions.
Di bawah ini kami siapkan untuk Anda transkrip diskusi, tetapi Anda juga dapat menonton video:
Beralih ke layanan microser - respons terhadap kebutuhan pasar
Dmitry:Pernahkah Anda memiliki pengalaman sukses beralih ke layanan microser? Dan secara umum: di mana Anda melihat manfaat terbesar dalam bisnis dari penggunaan layanan microser atau transisi dari monolit ke layanan microser?
Sergey:Kami telah menempuh beberapa cara untuk transisi ke layanan-layanan mikro dan telah menggunakan pendekatan ini selama lebih dari tiga tahun. Kebutuhan pertama yang membenarkan kebutuhan akan layanan-layanan mikro adalah integrasi tanpa akhir dari berbagai produk lini depan dengan kantor belakang. Dan setiap kali kami harus melakukan integrasi tambahan, pengembangan, penerapan aturan kami untuk pengoperasian layanan.
Pada titik tertentu, kami menyadari bahwa kami perlu mempercepat fungsi sistem dan output kami. Pada saat itu, konsep seperti layanan mikro, pendekatan layanan mikro sudah ada di pasar, dan kami memutuskan untuk mencobanya. Itu dimulai pada 2016. Kemudian platform diletakkan dan 10 layanan pertama diimplementasikan, oleh tim yang terpisah.
Salah satu layanan pertama, yang paling banyak memuat, adalah layanan perhitungan harga. Setiap kali Anda datang ke saluran apa pun, ke grup perusahaan M.Video-Eldorado, apakah itu situs web atau toko ritel, ambil barang di sana, lihat harga di situs web atau di "Keranjang", satu layanan secara otomatis menghitung harga. Mengapa ini diperlukan: sebelum itu, masing-masing sistem memiliki prinsipnya sendiri bekerja dengan promo - diskon dan sebagainya. Kantor belakang terlibat dalam penetapan harga, fungsi diskon diimplementasikan dalam sistem lain. Sangatlah penting untuk memusatkan dan menciptakan layanan yang unik dan dapat dilepas dalam bentuk proses bisnis yang memungkinkan kami untuk mengimplementasikannya. Begitulah cara kami memulai.
Nilai hasil pertama sangat besar. Pertama, kami dapat membuat entitas yang dapat dilepas yang memungkinkan kami untuk bekerja secara terpisah, teragregasi. Kedua, kami telah mengurangi biaya kepemilikan dalam hal integrasi dengan sejumlah besar sistem.
Selama tiga tahun terakhir, kami telah menambahkan tiga sistem garis depan. Sulit untuk mempertahankannya dalam jumlah sumber daya yang sama dengan yang bisa didapatkan perusahaan. Oleh karena itu, tugas muncul untuk mencari pintu keluar baru, merespons pasar dalam hal kecepatan, dalam hal biaya internal dan efisiensi.
Bagaimana mengevaluasi keberhasilan transisi ke layanan-layanan mikro
Dmitry:Bagaimana keberhasilan dalam beralih ke layanan mikro ditentukan? Apa "sebelum" di setiap perusahaan? Metrik apa yang Anda gunakan untuk menentukan keberhasilan transisi, siapa yang sebenarnya menentukannya?
Sergey:Pertama-tama, ia lahir di dalam IT sebagai enabler - "membuka" fitur baru. Kami harus melakukan segalanya dengan lebih cepat untuk uang yang relatif sama, menanggapi tantangan pasar. Sekarang, kesuksesan dinyatakan dalam jumlah layanan yang digunakan kembali oleh sistem yang berbeda, penyatuan proses di antara mereka sendiri. Sekarang sudah benar, dan pada saat itu merupakan kesempatan untuk membuat platform dan mengkonfirmasi hipotesis bahwa kita dapat melakukan ini, ini akan memberikan efek dan perhitungan kasus bisnis.
Alexander:Sukses lebih merupakan sensasi batin. Bisnis selalu menginginkan lebih, dan kedalaman jaminan kami adalah konfirmasi kesuksesan. Saya kira begitu.
Sergey:Ya saya setuju. Selama tiga tahun kami telah memiliki lebih dari dua ratus layanan dan jaminan. Permintaan sumber daya dalam tim hanya tumbuh - setiap tahun sebesar 30%. Ini karena orang merasa: lebih cepat, berbeda, teknologi lain, semua ini berkembang.
Layanan Microsoft akan datang, tetapi inti akan tetap
Dmitry:Ini seperti proses tanpa akhir di mana Anda berinvestasi dalam pengembangan. Apakah transisi ke layanan mikro untuk bisnis itu sendiri sudah berakhir atau belum?
Sergey:Sangat mudah dijawab. Bagaimana menurut Anda: mengganti telepon adalah proses tanpa akhir? Kami sendiri membeli telepon setiap tahun. Dan ini dia: sementara ada kebutuhan untuk kecepatan, dalam beradaptasi dengan pasar, beberapa perubahan akan diperlukan. Ini tidak berarti bahwa kami menolak hal-hal standar.
Tapi kita tidak bisa langsung merangkul dan mengulang semuanya. Kami memiliki warisan, layanan integrasi standar yang ada sebelum ini: bus perusahaan dan sebagainya. Tapi ada jaminan, dan ada kebutuhan juga. Jumlah aplikasi seluler dan fungsinya meningkat. Pada saat yang sama, tidak ada yang mengatakan bahwa mereka akan memberi Anda 30% lebih banyak uang. Artinya, selalu ada kebutuhan di satu sisi, dan di sisi lain, pencarian efisiensi.
Dmitry:Hidup dalam kondisi yang baik.
(Tertawa)Alexander:Secara umum, ya. Kami tidak memiliki pendekatan revolusioner untuk menghilangkan bagian inti dari lanskap. Pekerjaan sistematis sedang berlangsung untuk menguraikan sistem sehingga mereka lebih konsisten dengan arsitektur layanan mikro, untuk mengurangi pengaruh sistem pada satu sama lain.
Tetapi kami berencana untuk mempertahankan bagian intinya, karena dalam lanskap operator akan selalu ada beberapa platform yang kami beli. Sekali lagi, Anda membutuhkan keseimbangan yang sehat: kita tidak harus terburu-buru ke inti "pemotongan". Kami menempatkan sistem berdampingan, dan sekarang, ternyata sudah melewati banyak bagian inti. Selanjutnya, mengembangkan fungsionalitas, kami membuat representasi yang diperlukan untuk semua saluran yang bekerja dengan layanan komunikasi kami.
Cara menjual layanan microser ke bisnis
Dmitry:Saya masih tertarik - untuk mereka yang belum beralih, tetapi akan: betapa mudahnya menjual ide ini ke bisnis dan apakah itu pertaruhan, proyek investasi? Atau itu adalah strategi yang disengaja: sekarang kita pergi ke layanan microser dan itu semua, tidak ada yang akan menghentikan kita. Bagaimana denganmu?
Sergey:Kami tidak menjual pendekatan, tetapi keuntungan bisnis. Ada masalah dalam bisnis, dan kami mencoba menghapusnya. Pada saat itu, dinyatakan dalam kenyataan bahwa pada saluran yang berbeda, prinsip penetapan harga yang berbeda digunakan - secara terpisah untuk promosi, untuk saham, dan sebagainya. Sulit untuk mempertahankan, timbul kesalahan, kami mendengarkan keluhan pelanggan. Artinya, kami menjual penghapusan masalah, tetapi datang dengan fakta bahwa kami membutuhkan uang untuk membuat platform. Dan mereka menunjukkan kasus bisnis pada contoh investasi tahap pertama: bagaimana kita akan terus membayar untuk itu dan apa yang akan kita lakukan.
Dmitry:Apakah Anda entah bagaimana memperbaiki waktu tahap pertama?
Sergey:Ya tentu saja Kami membutuhkan waktu 6 bulan untuk membuat inti sebagai platform dan uji coba. Selama waktu ini, kami mencoba membuat sebuah platform di mana si pilot berseluncur. Mereka semakin mengkonfirmasi hipotesis tersebut, dan karena itu berhasil, maka kita dapat melanjutkan. Mereka mulai meniru dan memperkuat tim - mereka membawanya ke unit terpisah, yang hanya terlibat dalam hal ini.
Berikutnya adalah kerja sistematis mulai dari kebutuhan bisnis, peluang, ketersediaan sumber daya dan semua yang sekarang dalam pekerjaan.
Dmitry:Baiklah Alexander, apa yang kamu katakan?
Alexander:Layanan microser kami lahir dari "busa laut" - karena penghematan sumber daya, karena beberapa residu dalam bentuk kapasitas server dan redistribusi kekuatan dalam tim. Awalnya, kami tidak menjual proyek ini ke bisnis. Itu adalah proyek tempat kami berdua meneliti dan mengembangkannya. Kami mulai pada awal 2018 dan dengan antusias mengembangkan arah ini. Penjualan baru saja dimulai, dan kami sedang dalam proses.
Dmitry:Tetapi kebetulan bahwa suatu bisnis memungkinkan Anda untuk melakukan hal-hal seperti itu pada prinsip Google - dalam satu hari bebas seminggu? Apakah Anda memiliki arah seperti itu?
Alexander:Pada saat yang sama dengan penelitian, kami terlibat dalam tugas bisnis, karena semua layanan microsoft kami adalah solusi untuk masalah bisnis. Hanya pada awalnya kami membangun layanan microser yang mencakup sebagian kecil basis pelanggan, dan sekarang kami berada di hampir semua produk unggulan.
Dan dampak material sudah jelas - kita sudah bisa dihitung, kita bisa memperkirakan kecepatan output produk dan kehilangan pendapatan jika kita ingin pergi dengan cara lama. Di sinilah kami sedang membangun kasing.
Layanan Mikro: hype atau kebutuhan?
Dmitry:Angka adalah angka. Dan pendapatan atau uang yang dihemat sangat penting. Dan jika Anda melihat ke sisi lain? Tampaknya microservices adalah tren, hype dan banyak perusahaan menyalahgunakannya? Seberapa jelas Anda membedakan antara apa yang Anda terjemahkan dan yang tidak terjemahkan ke dalam layanan mikro? Jika warisan sekarang, apakah Anda masih memiliki warisan dalam 5 tahun? Berapa umur sistem informasi yang bekerja di M. Video-Eldorado dan MegaFon dalam 5 tahun? Apakah akan ada sistem informasi sepuluh tahun, lima belas tahun atau akankah itu generasi baru? Bagaimana Anda melihatnya?
Sergey:Menurut saya, sangat jauh itu sulit dilakukan. Jika Anda melihat ke belakang, siapa yang menyarankan bahwa ini akan mengembangkan pasar untuk teknologi dan pembelajaran mesin yang sama, identifikasi pengguna secara langsung? Tetapi jika Anda melihat di tahun-tahun mendatang, bagi saya tampaknya sistem inti, sistem perusahaan dari kelas ERP di perusahaan - mereka telah bekerja untuk waktu yang lama.
Perusahaan kami telah bersama selama 25 tahun, di dalamnya ERP klasik terletak sangat dalam di lanskap sistem. Jelas bahwa kita mengambil beberapa bagian dari sana dan mencoba untuk mengumpulkannya menjadi layanan-layanan mikro, tetapi inti akan tetap ada. Sulit bagi saya sekarang untuk membayangkan bahwa kita akan mengganti semua sistem inti di sana dan dengan cepat beralih ke sisi lain, sistem yang lebih cerah.
Saya adalah pendukung bahwa segala sesuatu yang lebih dekat dengan klien dan konsumen, di mana ada manfaat dan nilai bisnis terbesar, di mana Anda memerlukan kemampuan beradaptasi dan fokus pada kecepatan, pada perubahan, pada “coba, batalkan, gunakan kembali, lakukan sesuatu yang lain "- di sana lanskap akan berubah. Dan produk kotak tidak dibangun dengan sangat baik di sana. Setidaknya kita tidak melihat ini. Ini membutuhkan solusi yang paling ringan dan sederhana.
Kami melihat perkembangan seperti itu:
- sistem informasi inti (kebanyakan back office);
- lapisan tengah dalam bentuk microservices menghubungkan inti, agregat, membuat cache dan sebagainya;
- sistem garis depan ditujukan untuk konsumen;
- lapisan integrasi, yang umumnya diintegrasikan ke dalam pasar, sistem dan ekosistem lainnya. Lapisan ini seringan mungkin, sederhana, dengan logika bisnis minimum di dalamnya.
Tetapi pada saat yang sama saya adalah pendukung untuk terus menggunakan prinsip-prinsip lama, jika mereka terbiasa dengan tempat itu.
Katakanlah Anda memiliki sistem perusahaan klasik. Terletak di lanskap satu vendor, terdiri dari dua modul yang bekerja satu sama lain. Ada juga antarmuka integrasi standar. Mengapa mengulanginya dan membawa layanan mikro di sana?
Tetapi ketika ada 5 modul di back office, dari mana informasi dikumpulkan ke dalam proses bisnis, yang kemudian digunakan oleh 8-10 sistem front-end, manfaatnya langsung terlihat. Anda mengambil dari lima sistem back-office, membuat layanan, apalagi, terisolasi, yang berfokus pada proses bisnis. Anda membuat teknologi layanan - sehingga cache informasi dan toleran terhadap kesalahan, dan juga bekerja dengan dokumen atau entitas bisnis. Dan mengintegrasikannya pada satu prinsip dengan semua produk lini depan. Mereka membatalkan produk lini depan - mereka hanya mematikan integrasi. Besok Anda perlu menulis aplikasi seluler atau membuat situs kecil dan hanya satu bagian untuk mendarat di fungsional - sederhana: Anda menyatukannya sebagai konstruktor. Saya melihat perkembangan ke arah ini lebih - setidaknya di negara kita.
Alexander:Sergey sepenuhnya menggambarkan pendekatan kami, terima kasih. Saya hanya akan mengatakan di mana kita pasti tidak akan pergi - ke bagian inti, ke topik pengisian online. Artinya, peringkat dan penagihan akan tetap, pada kenyataannya, perontok "pengirik" yang andal akan menghapus uang. Dan sistem ini akan terus disertifikasi oleh otoritas regulasi kami. Segala sesuatu yang terlihat ke arah pelanggan, tentu saja, adalah layanan microser.
Dmitry:Di sini sertifikasi hanyalah satu cerita. Mungkin lebih banyak dukungan. Jika Anda menghabiskan sedikit untuk dukungan atau sistem tidak memerlukan dukungan dan peningkatan, lebih baik untuk tidak menyentuhnya. Kompromi yang masuk akal.
Bagaimana mengembangkan layanan microser yang andal
Dmitry:Bagus Tapi saya masih tertarik. Sekarang Anda menceritakan kisah sukses: semuanya baik-baik saja, kami beralih ke layanan mikro, membela ide di depan bisnis, dan semuanya berhasil. Tetapi saya mendengar cerita lain.
Beberapa tahun yang lalu, sebuah perusahaan Swiss, yang berinvestasi dua tahun dalam pengembangan platform layanan-mikro baru untuk bank, akhirnya menutup proyek ini. Benar-benar terlipat. Berjuta-juta franc Swiss dihabiskan, tetapi pada akhirnya mereka membubarkan tim - tidak.
Apakah Anda punya cerita serupa? Adakah atau ada kesulitan? Sebagai contoh, pemeliharaan layanan mikro, pemantauan yang sama juga merupakan sakit kepala dalam operasi perusahaan. Lagi pula, jumlah komponen bertambah puluhan kali. Bagaimana Anda melihat ini, apakah ada contoh investasi yang gagal di sini? Dan apa yang bisa disarankan orang agar mereka tidak mengalami masalah yang sama?
Alexander:Contoh yang tidak berhasil adalah bahwa bisnis mengubah prioritas dan membatalkan proyek. Ketika pada tahap kesiapan yang baik (MVP sebenarnya siap), bisnis mengatakan: "Kami memiliki prioritas baru, kami akan pergi ke proyek lain, dan kami akan menutup yang ini."
Kami tidak memiliki file global dengan layanan microser. Kami tidur nyenyak, kami memiliki shift tugas 24/7 yang melayani seluruh BSS [sistem dukungan bisnis].
Namun - kami menyewa layanan microser sesuai dengan aturan yang digunakan produk kotak disewa. Kunci keberhasilan adalah bahwa, pertama, Anda perlu membentuk tim yang akan sepenuhnya menyiapkan layanan mikro untuk produksi. Pembangunan itu sendiri, secara kondisional, 40%. Sisanya adalah analytics, metodologi DevSecOps, integrasi yang tepat, dan arsitektur yang tepat. Kami memberikan perhatian khusus pada prinsip-prinsip membangun aplikasi yang aman. Dalam setiap proyek, perwakilan keamanan informasi berpartisipasi dalam tahap perencanaan arsitektur dan dalam proses implementasi. Mereka juga mengelola sistem analisis kode untuk kerentanan.
Misalkan kita menggunakan layanan stateless - kita memilikinya di Kubernetes. Hal ini memungkinkan setiap orang untuk tidur nyenyak karena layanan penskalaan dan peningkatan otomatis, dan pergantian tugas mengambil insiden.
Selama keberadaan microservices kami, hanya ada satu atau dua insiden yang mencapai garis kami. Sekarang tidak ada masalah operasional. Tentu saja, kami belum memiliki 200, tetapi sekitar 50 layanan mikro, tetapi mereka digunakan dalam produk-produk unggulan. Jika mereka gagal, kita akan menjadi orang pertama yang mengetahuinya.
Layanan Mikro dan SDM
Sergey:Saya setuju dengan kolega saya tentang transfer dalam dukungan - bahwa Anda perlu mengatur pekerjaan dengan benar. Tapi saya akan katakan tentang masalah, yang, tentu saja, adalah.
Pertama, teknologinya baru. Ini adalah hype dengan cara yang baik, dan menemukan spesialis yang akan memahami dan mampu menciptakan ini adalah tantangan besar. Persaingan untuk sumber daya gila, masing-masing, para ahli layak bobotnya dalam emas.
Kedua, saat membuat lanskap tertentu dan semakin banyak layanan, masalah penggunaan kembali harus terus diselesaikan. Seperti yang suka dilakukan pengembang: "Mari kita menulis banyak hal menarik di sini ..." Karena ini, sistem tumbuh dan kehilangan efektivitasnya dalam hal uang, biaya kepemilikan, dan sebagainya. Artinya, Anda perlu meletakkan kembali dalam arsitektur sistem, termasuk dalam peta jalan pengenalan layanan dan transfer warisan ke arsitektur baru.
Masalah lain - walaupun ini bagus dengan caranya sendiri - adalah kompetisi internal. "Oh, para perancang busana baru muncul di sini, mereka berbicara bahasa baru." Orang, tentu saja, berbeda. Ada orang-orang yang terbiasa menulis di Jawa, dan mereka yang menulis dan menggunakan Docker dan Kubernetes. Mereka adalah orang yang sama sekali berbeda, mereka berbicara secara berbeda, menggunakan istilah yang berbeda dan terkadang tidak saling memahami. Kemampuan atau ketidakmampuan untuk berbagi praktik, berbagi pengetahuan, dalam hal ini juga merupakan masalah.
Yah, meningkatkan sumber daya. "Bagus, ayo pergi! Dan sekarang kami ingin lebih cepat, lebih. Tidak bisa Anda Apakah tidak mungkin mengirim dua kali lipat dalam setahun? Kenapa? " Masalah pertumbuhan seperti itu adalah standar, mungkin untuk banyak hal, banyak pendekatan, dan mereka dirasakan.
Tentang pemantauan. Sepertinya saya bahwa layanan atau alat pemantauan industri sudah belajar atau dapat bekerja dengan Docker dan Kubernetes dalam mode non-standar yang berbeda. Sehingga Anda, misalnya, tidak memiliki 500 mesin Java di mana semua ini berjalan, yaitu, agregat. Tetapi produk ini masih kurang matang, mereka harus melalui ini. Topiknya benar-benar baru, masih akan dikembangkan.
Dmitry:Ya, sangat menarik. Dan ini berlaku untuk SDM. Mungkin proses SDM dan merek SDM Anda telah sedikit berubah selama 3 tahun ini. Anda mulai merekrut orang lain dengan kompetensi yang berbeda. Dan mungkin ada pro dan kontra. Sebelumnya, blockchain dan ilmu data berteknologi tinggi, dan spesialis di dalamnya hanya bernilai jutaan. Sekarang harga jatuh, pasar jenuh, dan ada kecenderungan serupa di layanan-layanan mikro.
Sergey:Ya tentu saja.
Alexander:HR mengajukan pertanyaan: "Di mana unicorn pink Anda antara backend dan frontend?" SDM tidak mengerti apa itu microservice. Kami mengungkapkan rahasia kepada mereka dan mengatakan bahwa backend ini melakukan segalanya, dan tidak ada unicorn. Tetapi SDM berubah, dengan cepat belajar dan merekrut orang-orang yang memiliki pengetahuan dasar IT.
Evolusi layanan mikro
Dmitry:Jika Anda melihat arsitektur target, maka layanan microser terlihat seperti monster. Perjalanan Anda memakan waktu beberapa tahun. Yang lain punya satu tahun, yang lain punya tiga tahun. Anda meramalkan semua masalah, arsitektur target, apakah ada perubahan? Misalnya, dalam hal layanan microser, gateway, jerat layanan sekarang muncul lagi. Apakah Anda menggunakannya di awal atau apakah Anda mengubah arsitektur itu sendiri? Apakah Anda memiliki tantangan seperti itu?
Sergey:Kami telah menulis ulang beberapa protokol interaksi. Awalnya, satu protokol, sekarang beralih ke yang lain. Kami meningkatkan keamanan dan keandalan. Kami mulai dengan teknologi perusahaan - Oracle, Web Logic. Sekarang kita beralih dari produk-produk perusahaan teknologi dalam layanan-layanan microser dan pindah ke open source atau ke teknologi-teknologi yang sepenuhnya terbuka. Kami meninggalkan basis data, beralih ke apa yang lebih efisien bagi kami dalam model ini. Kami tidak lagi membutuhkan teknologi Oracle.
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
Mailto: CLOUD conference diselenggarakan oleh Mail.ru Cloud Solutions .Kami juga melakukan acara lain - misalnya, @Kubernetes Meetup , tempat kami selalu mencari pembicara keren:- Ikuti berita tentang @Kubernetes dan @Meetup lainnya di saluran Telegram kami t.me/k8s_mail
- Ingin berbicara di salah satu @Meetup? Tinggalkan permintaan di mcs.mail.ru/speak