Pada tanggal 25 April, kami di Mail.ru Group mengadakan konferensi tentang awan dan sekitar - . Beberapa hal penting:
- Yang utama — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center, dan Yandex.Cloud berbicara tentang spesifikasi pasar cloud kami dan layanannya;
- Rekan-rekan dari Bitrix24 menceritakan caranya ;
- Leroy Merlin, Otkritie, Burger King dan Schneider Electric memberikan hal menarik — tugas apa yang ditetapkan bisnis mereka untuk TI dan teknologi apa, termasuk teknologi cloud, yang mereka anggap paling menjanjikan.
Anda dapat menonton semua video dari konferensi mailto:CLOUD , dan di sini Anda dapat membaca bagaimana diskusi tentang layanan mikro berlangsung. Alexander Deulin, kepala pusat penelitian dan pengembangan sistem bisnis MegaFon, dan Sergey Sergeev, direktur teknologi informasi grup M.Video-Eldorado, berbagi kasus sukses mereka dalam menghilangkan monolit. Kami juga membahas isu-isu terkait strategi TI, proses dan bahkan SDM.
Panelis
- ергей ергеев, Grup CIO "M.Video-Eldorado";
- Alexander Deulin, kepala pusat penelitian dan pengembangan sistem bisnis MegaFon;
- Moderator — Dmitry Lazarenko, Kepala arahan PaaS Solusi Cloud Mail.ru.
Setelah pidato Alexander Deulin dia bergabung dalam diskusi dengan Sergey Sergeev dari M.Video-Eldorado dan moderator diskusi Dmitry Lazarenko, Mail.ru Cloud Solutions.
Di bawah ini kami telah menyiapkan transkrip diskusinya untuk Anda, namun Anda juga dapat menonton videonya:
Transisi ke layanan mikro merupakan respons terhadap kebutuhan pasar
Dimitri:
Apakah Anda memiliki pengalaman sukses dalam bermigrasi ke layanan mikro? Dan secara umum: di manakah Anda melihat manfaat bisnis terbesar dari penggunaan layanan mikro atau peralihan dari monolit ke layanan mikro?
Sergey:
Kami telah mencapai tahap transisi ke layanan mikro dan telah menggunakan pendekatan ini selama lebih dari tiga tahun. Kebutuhan pertama yang membenarkan kebutuhan akan layanan mikro adalah integrasi tanpa akhir dari berbagai produk front-end dengan back office. Dan setiap kali kami terpaksa melakukan integrasi dan pengembangan tambahan, menerapkan aturan kami sendiri untuk pengoperasian layanan ini atau itu.
Pada titik tertentu, kami menyadari bahwa kami perlu mempercepat pengoperasian sistem kami dan keluaran fungsionalitasnya. Saat itu, konsep seperti layanan mikro dan pendekatan layanan mikro sudah ada di pasaran, dan kami memutuskan untuk mencobanya. Ini dimulai pada tahun 2016. Kemudian platform diletakkan dan 10 layanan pertama dilaksanakan oleh tim terpisah.
Salah satu layanan pertama yang paling banyak memuatnya adalah layanan perhitungan harga. Setiap kali Anda mengunjungi saluran mana pun, ke grup perusahaan M.Video-Eldorado, baik itu situs web atau toko ritel, pilih produk di sana, lihat harga di situs web atau di “Keranjang”, biayanya otomatis dihitung oleh satu layanan. Mengapa ini perlu: sebelumnya, setiap sistem memiliki prinsipnya sendiri dalam bekerja dengan promosi - dengan diskon dan sebagainya. Kantor belakang kami menangani penetapan harga; fungsi diskon diterapkan di sistem lain. Hal ini perlu dipusatkan dan layanan unik dan terpisah harus dibuat dalam bentuk proses bisnis yang memungkinkan kita menerapkan hal ini. Begitulah cara kami memulai.
Nilai hasil pertama sangat besar. Pertama, kami dapat membuat entitas yang dapat dipisahkan yang memungkinkan kami bekerja secara terpisah dan agregat. Kedua, kami telah mengurangi biaya kepemilikan dalam hal integrasi dengan lebih banyak sistem.
Selama tiga tahun terakhir, kami telah menambahkan tiga sistem garis depan. Sulit untuk mempertahankannya dengan jumlah sumber daya yang sama dengan kemampuan perusahaan. Oleh karena itu, muncul tugas untuk mencari gerai baru, merespons pasar dalam hal kecepatan, biaya internal, dan efisiensi.
Cara mengukur keberhasilan migrasi ke layanan mikro
Dimitri:
Bagaimana keberhasilan migrasi ke layanan mikro ditentukan? Apa yang dimaksud dengan “sebelum” di setiap perusahaan? Metrik apa yang Anda gunakan untuk menentukan keberhasilan transisi, dan siapa sebenarnya yang menentukannya?
Sergey:
Pertama-tama, teknologi ini lahir di dalam TI sebagai sebuah penggerak (enabler) – “membuka” kemampuan-kemampuan baru. Kami mempunyai kebutuhan untuk melakukan segalanya lebih cepat dengan biaya yang relatif sama, untuk merespons tantangan pasar. Sekarang kesuksesan dinyatakan dalam jumlah layanan yang digunakan kembali oleh sistem yang berbeda, penyatuan proses satu sama lain. Sekarang, tapi pada saat itu adalah kesempatan untuk membuat platform dan mengkonfirmasi hipotesis bahwa kita bisa melakukan ini, itu akan memberikan efek dan menghitung kasus bisnis.
Alexander:
Sukses lebih merupakan perasaan internal. Bisnis selalu menginginkan lebih, dan banyaknya simpanan kami adalah bukti kesuksesan. Tampaknya demikian bagi saya.
Sergey:
Ya saya setuju. Dalam tiga tahun, kami sudah memiliki lebih dari dua ratus layanan dan jaminan simpanan. Kebutuhan sumber daya dalam tim terus meningkat - sebesar 30% setiap tahunnya. Hal ini terjadi karena masyarakat merasa: lebih cepat, berbeda, teknologi berbeda, semua ini berkembang.
Layanan mikro akan hadir, namun intinya akan tetap ada
Dimitri:
Ini seperti proses tanpa akhir di mana Anda berinvestasi dalam pembangunan. Apakah transisi ke layanan mikro untuk bisnis sudah berakhir atau belum?
Sergey:
Sangat mudah untuk menjawabnya. Bagaimana menurut Anda: mengganti ponsel adalah proses yang tidak ada habisnya? Kami sendiri membeli telepon setiap tahun. Dan ini dia: selama ada kebutuhan akan kecepatan dan adaptasi terhadap pasar, maka diperlukan beberapa perubahan. Ini tidak berarti bahwa kita meninggalkan hal-hal standar.
Namun kita tidak bisa mencakup dan mengulang semuanya sekaligus. Kami memiliki layanan integrasi standar lama yang sudah ada sebelumnya: bus perusahaan dan sebagainya. Tapi ada simpanan, dan ada juga kebutuhan. Jumlah aplikasi seluler dan fungsinya terus bertambah. Pada saat yang sama, tidak ada yang mengatakan bahwa Anda akan diberi uang 30% lebih banyak. Artinya, selalu ada kebutuhan di satu sisi, dan pencarian efisiensi di sisi lain.
Dimitri:
Hidup dalam kondisi yang baik. (Tertawa)
Alexander:
Secara umum, ya. Kami tidak memiliki pendekatan revolusioner untuk menghilangkan bagian inti dari lanskap. Pekerjaan sistematis sedang dilakukan untuk menguraikan sistem agar lebih konsisten dengan arsitektur layanan mikro, untuk mengurangi pengaruh sistem satu sama lain.
Namun kami berencana untuk mempertahankan bagian inti, karena dalam lanskap operator akan selalu ada beberapa platform yang kami beli. Sekali lagi, kita memerlukan keseimbangan yang sehat: kita tidak boleh terburu-buru memotong bagian inti. Kami menempatkan sistem secara berdampingan, dan sekarang ternyata kami sudah menguasai banyak bagian inti. Selanjutnya, dengan mengembangkan fungsionalitasnya, kami membuat representasi yang diperlukan untuk semua saluran yang bekerja dengan layanan komunikasi kami.
Cara menjual layanan mikro ke bisnis
Dimitri:
Saya juga tertarik - bagi mereka yang belum beralih, namun berencana untuk: seberapa mudah menjual ide ini ke bisnis dan apakah ini sebuah petualangan, proyek investasi? Atau apakah ini merupakan strategi sadar: sekarang kita akan beralih ke layanan mikro dan hanya itu, tidak ada yang dapat menghentikan kita. Bagaimana kabarmu?
Sergey:
Kami tidak menjual pendekatan, namun keuntungan bisnis. Ada masalah dalam bisnis, dan kami mencoba menyelesaikannya. Pada saat itu, hal ini terungkap dalam kenyataan bahwa saluran yang berbeda menggunakan prinsip yang berbeda dalam menghitung harga - secara terpisah untuk promosi, untuk promosi, dan sebagainya. Perawatannya sulit, terjadi kesalahan, dan kami mendengarkan keluhan pelanggan. Artinya, kami menjual solusi untuk suatu masalah, tetapi kami datang dengan fakta bahwa kami membutuhkan uang untuk membuat platform. Dan mereka menunjukkan kasus bisnis dengan menggunakan contoh investasi tahap pertama: bagaimana kami akan terus mengembalikannya dan apa yang dapat kami lakukan.
Dimitri:
Apakah Anda mencatat waktu tahap pertama?
Sergey:
Ya tentu. Kami mengalokasikan waktu 6 bulan untuk membuat inti sebagai platform dan menguji uji cobanya. Selama waktu ini, kami mencoba membuat platform untuk meluncur sebagai pilot. Kemudian hipotesisnya terkonfirmasi, dan karena berhasil, berarti kita dapat melanjutkan. Mereka mulai meniru dan memperkuat tim - mereka memindahkannya ke divisi terpisah yang melakukan hal itu.
Berikutnya adalah pekerjaan yang sistematis berdasarkan kebutuhan bisnis, peluang, ketersediaan sumber daya dan segala sesuatu yang sedang dikerjakan.
Dimitri:
OKE. Alexander, bagaimana menurutmu?
Alexander:
Layanan mikro kami lahir dari “busa laut” - karena penghematan sumber daya, karena beberapa sisa dalam bentuk kapasitas server dan redistribusi kekuatan dalam tim. Awalnya, kami tidak menjual proyek ini ke bisnis. Ini adalah proyek tempat kami meneliti dan mengembangkannya. Kami memulainya pada awal tahun 2018 dan mengembangkan arah ini dengan antusias. Penjualan baru saja dimulai dan kami sedang dalam proses.
Dimitri:
Apakah suatu bisnis mengizinkan Anda melakukan hal-hal seperti Google - pada satu hari luang dalam seminggu? Apakah Anda mempunyai arah seperti itu?
Alexander:
Bersamaan dengan penelitian, kami juga menangani masalah bisnis, sehingga semua layanan mikro kami adalah solusi untuk masalah bisnis. Baru pada awalnya kami membangun layanan mikro yang mencakup sebagian kecil basis pelanggan, dan kini kami hadir di hampir semua produk andalan.
Dan dampak materialnya sudah jelas - kita sudah bisa menghitungnya, kecepatan peluncuran produk dan hilangnya pendapatan bisa diperkirakan jika kita mengikuti jalur lama. Inilah yang sedang kami kembangkan dalam kasus ini.
Layanan mikro: sensasi atau kebutuhan?
Dimitri:
Angka adalah angka. Dan pendapatan atau uang yang dihemat sangatlah penting. Bagaimana jika Anda melihat sisi lain? Tampaknya layanan mikro sedang menjadi tren, hype, dan banyak perusahaan yang menyalahgunakannya? Seberapa jelas Anda membedakan antara apa yang Anda lakukan dan apa yang tidak Anda terjemahkan ke 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 yang berusia sepuluh tahun, lima belas tahun, ataukah akan ada generasi baru? Bagaimana Anda melihat ini?
Sergey:
Tampaknya bagi saya sulit untuk berpikir terlalu jauh. Jika kita melihat ke belakang, siapa yang membayangkan pasar teknologi akan berkembang seperti ini, termasuk pembelajaran mesin dan identifikasi pengguna melalui wajah? Tetapi jika Anda melihat tahun-tahun mendatang, menurut saya sistem inti, sistem kelas ERP perusahaan di perusahaan - mereka telah bekerja cukup lama.
Perusahaan kami secara kolektif berusia 25 tahun, dengan ERP klasik yang sangat mendalami lanskap sistem. Jelas bahwa kami mengambil beberapa bagian dari sana dan mencoba menggabungkannya ke dalam layanan-layanan mikro, tetapi intinya akan tetap ada. Sekarang sulit bagi saya untuk membayangkan bahwa kita akan mengganti semua sistem inti yang ada dan segera beralih ke sisi lain yang lebih baik dari sistem baru.
Saya mendukung fakta bahwa segala sesuatu yang lebih dekat dengan klien dan konsumen adalah tempat di mana manfaat dan nilai bisnis terbesar berada, di mana kemampuan beradaptasi dan fokus pada kecepatan, pada perubahan, pada “coba, batalkan, gunakan kembali, lakukan sesuatu yang berbeda” adalah dibutuhkan “—di situlah lanskap akan berubah. Dan produk dalam kotak tidak muat di sana. Setidaknya kita tidak melihatnya. Solusi termudah dan paling sederhana diperlukan di sana.
Kami melihat perkembangan ini:
- sistem informasi inti (kebanyakan back office);
- lapisan tengah berupa layanan mikro menghubungkan inti, agregat, membuat cache, dan sebagainya;
- sistem garis depan ditujukan untuk konsumen;
- lapisan integrasi yang umumnya terintegrasi ke dalam pasar, sistem dan ekosistem lain. Lapisan ini seringan mungkin, sederhana, dan mengandung logika bisnis minimal.
Namun pada saat yang sama, saya mendukung untuk terus menggunakan prinsip-prinsip lama jika digunakan dengan tepat.
Katakanlah Anda memiliki sistem perusahaan klasik. Itu terletak di lanskap satu vendor dan terdiri dari dua modul yang bekerja satu sama lain. Ada juga antarmuka integrasi standar. Mengapa mengulanginya dan menghadirkan layanan mikro ke sana?
Namun ketika ada 5 modul di back office, yang darinya potongan informasi dikumpulkan ke dalam proses bisnis, yang kemudian digunakan oleh 8-10 sistem lini depan, manfaatnya langsung terlihat. Anda mengambil lima sistem back-office dan menciptakan sebuah layanan, yang terisolasi, yang berfokus pada proses bisnis. Jadikan layanan berteknologi maju - sehingga menyimpan informasi dan toleran terhadap kesalahan, dan juga berfungsi dengan dokumen atau badan usaha. Dan Anda mengintegrasikannya berdasarkan prinsip yang sama dengan semua produk lini depan. Mereka membatalkan produk lini depan - mereka mematikan integrasinya. Besok Anda perlu menulis aplikasi seluler atau membuat situs web kecil dan hanya memasukkan satu bagian ke dalam fungsionalitas - semuanya sederhana: Anda merakitnya seperti konstruktor. Saya melihat lebih banyak perkembangan ke arah ini – setidaknya di negara kita.
Alexander:
Sergey menjelaskan secara lengkap pendekatan kami, terima kasih. Saya hanya akan mengatakan ke mana kami pasti tidak akan pergi - ke bagian inti, ke topik penagihan online. Artinya, pemeringkatan dan penagihan akan tetap menjadi alat perontok “besar” yang dapat diandalkan untuk menghapus uang. Dan sistem ini akan terus disertifikasi oleh otoritas pengatur kami. Segala hal lain yang mengarah pada klien, tentu saja, adalah layanan mikro.
Dimitri:
Di sini sertifikasi adalah satu cerita. Mungkin lebih banyak dukungan. Jika Anda menghabiskan sedikit uang untuk dukungan atau sistem tidak memerlukan dukungan dan modifikasi, lebih baik tidak menyentuhnya. Kompromi yang masuk akal.
Bagaimana mengembangkan layanan mikro yang andal
Dimitri:
Bagus. Tapi saya masih tertarik. Sekarang Anda menceritakan kisah sukses: semuanya baik-baik saja, kami beralih ke layanan mikro, mempertahankan ide bisnis, dan semuanya berhasil. Tapi saya pernah mendengar cerita lain.
Beberapa tahun yang lalu, sebuah perusahaan Swiss yang telah berinvestasi selama dua tahun dalam mengembangkan platform layanan mikro baru untuk bank akhirnya menutup proyek tersebut. Benar-benar runtuh. Jutaan franc Swiss dihabiskan, dan pada akhirnya tim dibubarkan - tidak berhasil.
Apakah Anda punya cerita serupa? Apakah ada kesulitan? Misalnya, mempertahankan layanan mikro dan pemantauan juga menjadi masalah dalam aktivitas operasional perusahaan. Bagaimanapun, jumlah komponen meningkat puluhan kali lipat. Bagaimana Anda melihatnya, apakah ada contoh investasi yang gagal di sini? Dan nasihat apa yang bisa Anda berikan kepada orang-orang agar mereka tidak menghadapi masalah seperti itu?
Alexander:
Contoh yang tidak berhasil mencakup perubahan prioritas bisnis dan pembatalan proyek. Ketika berada pada tahap kesiapan yang baik (pada kenyataannya, MVP sudah siap), pihak bisnis berkata: “Kami memiliki prioritas baru, kami beralih ke proyek lain, dan kami akan menutup proyek ini.”
Kami tidak mengalami kegagalan global apa pun dengan layanan mikro. Kami tidur nyenyak, kami memiliki shift tugas 24/7 yang melayani seluruh BSS [sistem pendukung bisnis].
Dan satu hal lagi - kami menyewakan layanan mikro sesuai aturan yang berlaku untuk produk kotak. Kunci suksesnya adalah pertama-tama Anda perlu membentuk tim yang akan sepenuhnya mempersiapkan layanan mikro untuk produksi. Perkembangannya sendiri, dengan syarat, 40%. Selebihnya adalah analitik, metodologi DevSecOps, integrasi yang tepat, dan arsitektur yang tepat. Kami memberikan perhatian khusus pada prinsip-prinsip membangun aplikasi yang aman. Perwakilan keamanan informasi berpartisipasi dalam setiap proyek baik pada tahap perencanaan arsitektur maupun selama proses implementasi. Mereka juga mengelola sistem untuk menganalisis kode untuk mengetahui kerentanannya.
Katakanlah kita menerapkan layanan tanpa kewarganegaraan - kita memilikinya di Kubernetes. Hal ini memungkinkan semua orang untuk tidur nyenyak karena penskalaan otomatis dan peningkatan layanan otomatis, dan pergantian tugas menangani insiden.
Sepanjang keberadaan layanan mikro kami, hanya ada satu atau dua insiden yang sampai ke jalur kami. Sekarang tidak ada masalah dengan pengoperasian. Kami, tentu saja, bukan 200, tetapi sekitar 50 layanan mikro, tetapi layanan tersebut digunakan dalam produk andalan. Jika mereka gagal, kamilah orang pertama yang mengetahuinya.
Layanan mikro dan SDM
Sergey:
Saya setuju dengan rekan saya tentang transfer ke dukungan - bahwa pekerjaan perlu diatur dengan benar. Namun saya akan bercerita tentang permasalahan yang tentu saja ada.
Pertama, teknologinya baru. Ini adalah sebuah hype dalam arti yang baik, dan menemukan seorang spesialis yang akan memahami dan dapat menciptakan hal ini adalah sebuah tantangan besar. Persaingan untuk mendapatkan sumber daya sangatlah gila, jadi para ahli sangat berharga.
Kedua, dengan terciptanya lanskap tertentu dan meningkatnya jumlah jasa, masalah penggunaan kembali harus terus diselesaikan. Seperti yang sering dilakukan oleh pengembang: “Mari kita tulis banyak hal menarik di sini sekarang…” Karena itu, sistem tumbuh dan kehilangan efektivitasnya dalam hal uang, biaya kepemilikan, dan sebagainya. Artinya, penggunaan kembali perlu dimasukkan dalam arsitektur sistem, dimasukkan dalam peta jalan untuk memperkenalkan layanan dan mentransfer warisan ke arsitektur baru.
Masalah lainnya – meskipun hal ini bagus dengan caranya sendiri – adalah persaingan internal. “Oh, orang-orang modis baru telah muncul di sini, mereka berbicara dalam bahasa baru.” Tentu saja, orangnya berbeda. Ada yang terbiasa menulis di Java, ada pula yang menulis dan menggunakan Docker dan Kubernetes. Mereka adalah orang-orang yang sangat berbeda, mereka berbicara dengan cara yang berbeda, menggunakan istilah yang berbeda dan terkadang tidak memahami satu sama lain. Kemampuan atau ketidakmampuan untuk berbagi praktik, berbagi pengetahuan, dalam pengertian ini juga menjadi masalah.
Ya, meningkatkan sumber daya. “Bagus, ayo pergi! Dan sekarang kami ingin lebih cepat, lebih banyak. Apa, kamu tidak bisa? Apakah tidak mungkin mengirimkan dua kali lebih banyak dalam setahun? Dan mengapa?" Rasa sakit yang tumbuh seperti itu mungkin merupakan standar dalam banyak hal, banyak pendekatan, dan Anda dapat merasakannya.
Mengenai pemantauan. Bagi saya, layanan atau alat pemantauan industri sudah belajar atau mampu bekerja dengan Docker dan Kubernetes dalam mode non-standar yang berbeda. Sehingga, misalnya, Anda tidak mendapatkan 500 mesin Java yang menjalankan semua ini, yaitu agregat. Namun produk-produk ini masih belum matang, mereka harus melalui ini. Topiknya benar-benar baru, akan terus berkembang.
Dimitri:
Ya, sangat menarik. Dan ini berlaku untuk HR. Mungkin proses HR dan brand HR Anda telah sedikit berubah selama 3 tahun ini. Anda mulai merekrut orang lain dengan kompetensi berbeda. Dan mungkin ada pro dan kontra. Sebelumnya, blockchain dan ilmu data sedang populer, dan spesialis di dalamnya bernilai jutaan. Kini biayanya turun, pasar menjadi jenuh, dan ada tren serupa dalam layanan mikro.
Sergey:
Ya, tentu saja.
Alexander:
HR menanyakan pertanyaan: “Di mana unicorn merah muda Anda antara backend dan frontend?” HR tidak memahami apa itu layanan mikro. Kami memberi tahu mereka rahasianya dan memberi tahu mereka bahwa backend melakukan segalanya, dan tidak ada unicorn. Namun SDM berubah, belajar dengan cepat dan merekrut orang-orang yang memiliki pengetahuan dasar TI.
Evolusi layanan mikro
Dimitri:
Jika Anda melihat arsitektur targetnya, layanan mikro terlihat seperti monster. Perjalanan Anda memakan waktu beberapa tahun. Yang lain punya waktu satu tahun, yang lain tiga tahun. Apakah Anda memperkirakan semua masalah, arsitektur target, apakah ada yang berubah? Misalnya, dalam kasus layanan mikro, gateway dan jerat layanan kini muncul kembali. Apakah Anda menggunakannya pada awalnya atau Anda mengubah arsitekturnya sendiri? Apakah Anda mempunyai tantangan seperti itu?
Sergey:
Kami telah menulis ulang beberapa protokol komunikasi. Awalnya hanya ada satu protokol, sekarang kami beralih ke protokol lain. Kami meningkatkan keamanan dan keandalan. Kami memulai dengan teknologi perusahaan - Oracle, Web Logic. Sekarang kita beralih dari produk perusahaan teknologi ke layanan mikro dan beralih ke teknologi open source atau teknologi yang sepenuhnya terbuka. Kami meninggalkan database dan beralih ke database yang lebih efektif bagi kami dalam model ini. Kita tidak lagi membutuhkan teknologi Oracle.
Kami memulai hanya sebagai sebuah layanan, tanpa memikirkan seberapa besar kami membutuhkan cache, apa yang akan kami lakukan ketika tidak ada koneksi dengan layanan mikro, tetapi data diperlukan, dll. Sekarang kami sedang mengembangkan platform sehingga arsitekturnya dapat dijelaskan bukan dalam bahasa layanan, dan dalam bahasa bisnis, bawa logika bisnis ke tingkat berikutnya ketika kita mulai berbicara dengan kata-kata. Sekarang kita telah belajar berbicara dalam huruf, dan tingkat berikutnya adalah ketika layanan akan dikumpulkan menjadi beberapa jenis agregat, ketika ini sudah menjadi sebuah kata - misalnya, seluruh kartu produk. Ini dirakit dari layanan mikro, tetapi merupakan API yang dibangun di atasnya.
Keamanan sangat penting. Segera setelah Anda mulai dapat diakses dan Anda memiliki layanan di mana Anda bisa mendapatkan banyak hal menarik, dan dengan sangat cepat, dalam sepersekian detik, maka ada keinginan untuk mendapatkannya dengan cara yang bukan cara yang paling aman. Untuk menghindari hal ini, kami harus mengubah pendekatan terhadap pengujian dan pemantauan. Kami harus mengubah tim, struktur manajemen pengiriman, CI/CD.
Ini adalah sebuah evolusi - seperti halnya telepon, hanya saja jauh lebih cepat: pertama ada telepon tombol, kemudian telepon pintar muncul. Mereka menulis ulang dan mendesain ulang produk karena pasar memiliki kebutuhan yang berbeda. Beginilah cara kami berkembang: kelas satu, kelas sepuluh, bekerja.
Secara berulang, ada sesuatu yang ditetapkan per tahun dari sudut pandang teknologi, sesuatu yang lain dari sudut pandang simpanan dan kebutuhan. Kami menghubungkan satu hal dengan hal lainnya. Tim membelanjakan 20% untuk utang teknis dan dukungan teknis untuk tim, 80% untuk entitas bisnis. Dan kami bergerak dengan pemahaman tentang alasan kami melakukan hal ini, alasan kami melakukan perbaikan teknologi ini, dan apa dampaknya. Seperti itu.
Dimitri:
Dingin. Apa yang ada di MegaFon?
Alexander:
Tantangan utama saat kami menggunakan layanan mikro adalah agar tidak terjerumus ke dalam kekacauan. Kantor arsitektur MegaFon segera bergabung dengan kami, bahkan menjadi penggagas dan penggerak - sekarang kami memiliki arsitektur yang sangat kuat. Tugasnya adalah memahami model target apa yang akan kita tuju dan teknologi apa yang perlu diujicobakan. Dengan arsitektur, kami melakukan uji coba ini sendiri.
Pertanyaan selanjutnya adalah: “Lalu bagaimana memanfaatkan semua ini?” Dan satu lagi: “Bagaimana memastikan interaksi transparan antar layanan mikro?” Jaring layanan membantu kami menjawab pertanyaan terakhir. Kami menguji coba Istio dan menyukai hasilnya. Saat ini kami sedang dalam tahap peluncuran ke zona produktif. Kami memiliki sikap positif terhadap semua tantangan - fakta bahwa kami perlu terus-menerus mengubah susunan, mempelajari sesuatu yang baru. Kami tertarik untuk mengembangkan, bukan mengeksploitasi solusi lama.
Dimitri:
Kata-kata emas! Tantangan-tantangan seperti ini membuat tim dan bisnis tetap waspada dan menciptakan masa depan. GDPR membentuk kepala petugas perlindungan data, dan tantangan saat ini menciptakan kepala petugas layanan mikro dan arsitektur. Dan itu menyenangkan.
Kami berdiskusi banyak hal. Hal utama adalah desain layanan mikro yang baik dan arsitektur itu sendiri memungkinkan Anda menghindari banyak kesalahan. Tentu saja, prosesnya berulang dan evolusioner, namun ini adalah masa depan.
Terima kasih kepada semua peserta, terima kasih kepada Sergei dan Alexander!
Pertanyaan dari penonton
Pertanyaan dari penonton (1):
Sergey, bagaimana perubahan manajemen TI di perusahaan Anda? Saya memahami bahwa ketika ada tumpukan besar dari beberapa sistem, cara mengelolanya adalah proses yang cukup jelas dan logis. Bagaimana Anda membangun kembali pengelolaan komponen TI setelah sejumlah besar layanan mikro terintegrasi dalam waktu singkat?
Sergey:
Saya sependapat dengan rekan saya bahwa arsitektur sangat penting sebagai penggerak perubahan. Kami memulai dengan memiliki divisi arsitektur. Arsitek sekaligus pemilik distribusi fungsionalitas dan persyaratan bagaimana fungsi tersebut akan muncul di lanskap. Jadi mereka juga berperan sebagai koordinator perubahan tersebut. Akibatnya, ada perubahan spesifik pada proses pengiriman tertentu saat kami membuat platform CI/CD.
Namun standar, prinsip dasar pengembangan, analisis bisnis, pengujian dan pengembangan belum dibatalkan. Kami baru saja menambahkan kecepatan. Sebelumnya, siklusnya memakan waktu sangat lama, instalasi pada lingkungan pengujian membutuhkan waktu lebih lama. Kini dunia bisnis melihat manfaatnya dan berkata: “Mengapa kita tidak bisa melakukan hal yang sama di tempat lain?”
Ini seperti, dalam arti yang baik, suntikan dalam bentuk vaksin yang menunjukkan: Anda bisa melakukannya dengan cara ini, tetapi Anda bisa melakukannya dengan cara lain. Tentu saja, ada masalah dalam personel, kompetensi, pengetahuan, dan perlawanan.
Pertanyaan dari penonton (2):
Kritik terhadap arsitektur layanan mikro mengatakan bahwa pengujian dan pengembangan itu sulit. Ini logis ketika segala sesuatunya menjadi rumit. Tantangan apa yang dihadapi tim Anda dan bagaimana Anda mengatasinya? Pertanyaan untuk semua orang.
Alexander:
Terdapat kesulitan saat berpindah dari layanan mikro ke platform, namun hal tersebut dapat diatasi.
Misalnya kita membuat produk yang terdiri dari 5-7 layanan mikro. Kita perlu menyediakan pengujian integrasi di seluruh tumpukan layanan mikro untuk memberikan lampu hijau untuk berpindah ke cabang master. Tugas ini bukanlah hal baru bagi kami: kami telah melakukan hal ini sejak lama di BSS, ketika vendor menyediakan solusi yang sudah dikirimkan kepada kami.
Dan masalah kami hanya ada di tim kecil. Satu insinyur QA diperlukan untuk satu produk bersyarat. Jadi, kami mengirimkan produk yang terdiri dari 5-7 layanan mikro, 2-3 di antaranya dapat dikembangkan oleh pihak ketiga. Misalnya, kami memiliki produk yang pengembangannya melibatkan vendor sistem penagihan kami, Mail.ru Group, dan MegaFon R&D. Kita perlu menutupinya dengan pengujian sebelum mengirimkannya ke produksi. Insinyur QA telah mengerjakan produk ini selama satu setengah bulan, dan anggota tim lainnya dibiarkan tanpa dukungannya.
Kompleksitas ini hanya disebabkan oleh penskalaan. Kami memahami bahwa layanan mikro tidak bisa ada dalam ruang hampa; isolasi mutlak tidak ada. Saat mengubah satu layanan, kami selalu berusaha mempertahankan kontrak API. Jika ada perubahan di bawah kap, servis depan tetap ada. Jika perubahannya fatal, semacam transformasi arsitektur terjadi dan kita beralih ke metamodel data yang sama sekali berbeda, yang sama sekali tidak kompatibel - baru kemudian kita berbicara tentang spesifikasi API layanan v2 yang muncul. Kami mendukung versi pertama dan kedua secara bersamaan, dan setelah semua konsumen beralih ke versi kedua, kami cukup menutup versi pertama.
Sergey:
Saya ingin menambahkan. Saya sangat setuju tentang komplikasi - komplikasi itu terjadi. Lanskapnya menjadi lebih kompleks, dan biaya overhead meningkat, terutama untuk pengujian. Cara mengatasinya: beralih ke pengujian otomatis. Ya, Anda harus berinvestasi tambahan dalam menulis tes otomatis dan tes unit. Sehingga pengembang tidak dapat melakukan tanpa lulus pengujian, mereka tidak dapat mengubah kodenya. Sehingga tombol tekan pun tidak berfungsi tanpa autotest, unit test.
Penting untuk mempertahankan fungsionalitas sebelumnya, dan ini merupakan biaya tambahan. Jika Anda menulis ulang suatu teknologi ke protokol lain, maka Anda menulis ulang sampai Anda menutup semuanya sepenuhnya.
Kami terkadang tidak melakukan pengujian end-to-end dengan sengaja, karena kami tidak ingin menghentikan pengembangan, meskipun kami juga memiliki banyak hal. Bentang alamnya sangat luas, kompleks, dan terdapat banyak sistem. Kadang-kadang itu hanya sebuah rintisan - ya, Anda menurunkan margin keamanan, lebih banyak risiko yang muncul. Tetapi pada saat yang sama Anda melepaskan persediaannya.
Alexander:
Ya, pengujian otomatis dan pengujian unit memungkinkan Anda membuat layanan berkualitas tinggi. Kami mendukung jalur pipa yang tidak dapat dilewati tanpa pengujian unit dan integrasi. Kita sering kali harus menyeret emulator dan sistem komersial ke dalam zona pengujian dan lingkungan pengembangan, karena tidak semua sistem dapat ditempatkan di zona pengujian. Selain itu, mereka tidak hanya menjadi basah - kami menghasilkan respons penuh dari sistem. Ini adalah bagian serius dalam bekerja dengan layanan mikro, dan kami juga berinvestasi di dalamnya. Tanpa hal ini, kekacauan akan terjadi.
Pertanyaan dari penonton (3):
Sejauh yang saya pahami, layanan mikro awalnya tumbuh dari tim terpisah dan sekarang ada dalam model ini. Apa kelebihan dan kekurangannya?
Kami hanya punya cerita serupa: semacam pabrik layanan mikro muncul. Sekarang kami secara konseptual telah mencapai titik di mana kami memperluas pendekatan ini pada produksi di seluruh aliran dan sistem. Dengan kata lain, kita beralih dari pengembangan layanan mikro yang terpusat, model layanan mikro, dan semakin dekat dengan sistem.
Oleh karena itu, operasi kami juga masuk ke sistem, yaitu kami mendesentralisasikan topik ini. Apa pendekatan Anda dan apa target cerita Anda?
Alexander:
Anda langsung menghilangkan nama “pabrik layanan mikro” - kami juga ingin meningkatkan skalanya. Pertama, kami benar-benar memiliki satu tim sekarang. Kami ingin memberikan kesempatan kepada semua tim pengembangan yang dimiliki MegaFon untuk bekerja dalam ekosistem yang sama. Kami tidak ingin sepenuhnya mengambil alih seluruh fungsi pengembangan yang kami miliki sekarang. Tugas lokalnya adalah melakukan penskalaan, tugas globalnya adalah memimpin pengembangan ke semua tim di lapisan layanan mikro.
Sergey:
Aku akan memberitahumu jalan yang telah kita ambil. Kami sebenarnya mulai bekerja sebagai satu tim, namun kini kami tidak sendirian. Saya pendukung hal berikut: harus ada pemilik proses. Seseorang perlu memahami, mengelola, mengendalikan, dan membangun proses pengembangan layanan mikro. Dia harus memiliki sumber daya dan terlibat dalam pengelolaan sumber daya.
Sumber daya ini, yang mengetahui teknologi, secara spesifik, dan memahami cara membangun layanan mikro, dapat ditempatkan di tim produk. Kami memiliki gabungan orang-orang dari platform layanan mikro yang berada di tim produk yang membuat aplikasi seluler. Mereka ada di sana, tetapi mereka bekerja sesuai dengan proses departemen manajemen platform layanan mikro dengan manajer pengembangannya. Dalam divisi ini terdapat tim tersendiri yang menangani bidang teknologi. Artinya, kita menggabungkan kumpulan sumber daya bersama di antara kita sendiri dan membaginya, lalu membaginya ke dalam tim.
Pada saat yang sama, prosesnya tetap bersifat umum, terkendali, berlangsung sesuai dengan prinsip-prinsip teknologi umum, dengan pengujian unit, dan seterusnya - segala sesuatu yang dibangun di atasnya. Mungkin ada kolom dalam bentuk sumber daya yang dikumpulkan dari berbagai departemen pendekatan produk.
Alexander:
Sergey, Anda sebenarnya adalah pemilik prosesnya, bukan? Apakah simpanan tugas dibagikan? Siapa yang bertanggung jawab atas distribusinya?
Sergey:
Lihat: ini campurannya lagi. Ada simpanan yang terbentuk berdasarkan kemajuan teknologi - ini adalah satu cerita. Ada backlog yang dirumuskan dari proyek, dan ada backlog dari produk. Namun urutan pengenalan ke dalam setiap produk jasa atau pembuatan layanan ini dikembangkan oleh spesialis produk. Dia tidak berada di direktorat IT, dia dikeluarkan secara khusus dari direktorat itu. Tapi orang-orang saya pasti bekerja menurut proses yang sama.
Pemilik simpanan di arah yang berbeda - simpanan perubahan - akan menjadi orang yang berbeda. Koneksi layanan teknologi, prinsip pengorganisasiannya - semua ini ada di TI. Saya juga pemilik platform dan sumber dayanya. Yang paling penting adalah masalah simpanan dan perubahan fungsional, serta arsitektur dalam pengertian ini.
Katakanlah sebuah bisnis berkata: “Kami menginginkan fungsi ini, kami ingin menciptakan produk baru - membuat ulang pinjaman.” Kami menjawab: “Ya, kami akan mengulanginya.” Arsitek berkata: “Mari kita pikirkan: di bagian mana kita akan menulis layanan mikro dan bagaimana kita akan melakukannya?” Kemudian kami memecahnya menjadi proyek, produk, atau kumpulan teknologi, memasukkannya ke dalam tim, dan menerapkannya. Sudahkah Anda membuat produk secara internal dan memutuskan untuk menggunakan layanan mikro pada produk ini? Kami berkata: “Sekarang sistem lama yang kami miliki, atau sistem lini depan, harus beralih ke layanan mikro ini.” Arsiteknya mengatakan: “Jadi: dalam simpanan teknologi di dalam produk garis depan - transisi ke layanan mikro. Pergi". Dan spesialis produk atau pemilik bisnis memahami berapa banyak kapasitas yang dialokasikan, kapan hal itu akan dilakukan dan mengapa.
Akhir dari diskusi, tapi tidak semua
Konferensi mailto:CLOUD diselenggarakan .
Kami juga mengadakan acara lain - mis. @Pertemuan Kubernetes, tempat kami selalu mencari pembicara hebat:
- Ikuti @Kubernetes dan berita @Meetup lainnya di saluran Telegram kami
- Tertarik untuk berbicara di salah satu @Meetups? Tinggalkan permintaan untuk
Sumber: www.habr.com