Pada 25 April, kami di Mail.ru Group mengadakan persidangan tentang awan dan sekitar - . Beberapa sorotan:
- Yang utama β Penyelesaian Awan Mail.ru, #CloudMTS, SberCloud, Selectel, Pusat Data Rostelecom dan Yandex.Cloud bercakap tentang spesifik pasaran awan kami dan perkhidmatan mereka;
- Rakan sekerja dari Bitrix24 memberitahu bagaimana mereka ;
- Leroy Merlin, Otkritie, Burger King dan Schneider Electric menyediakan yang menarik β apakah tugas yang ditetapkan oleh perniagaan mereka untuk IT dan teknologi apa, termasuk teknologi awan, yang mereka lihat sebagai yang paling menjanjikan.
Anda boleh menonton semua video dari persidangan mailto:CLOUD , dan di sini anda boleh membaca bagaimana perbincangan tentang perkhidmatan mikro berjalan. Alexander Deulin, ketua pusat penyelidikan dan pembangunan sistem perniagaan MegaFon, dan Sergey Sergeev, pengarah teknologi maklumat kumpulan M.Video-Eldorado, berkongsi kes kejayaan mereka untuk menyingkirkan monolit. Kami juga membincangkan isu berkaitan strategi IT, proses dan juga HR.
Ahli panel
- Sergey Sergeev, CIO Kumpulan "M.Video-Eldorado";
- Alexander Deulin, ketua pusat penyelidikan dan pembangunan sistem perniagaan MegaFon;
- Moderator β Dmitry Lazarenko, Ketua arah PaaS Penyelesaian Awan Mail.ru.
Selepas ucapan Alexander Deulin beliau disertai untuk perbincangan oleh Sergey Sergeev dari M.Video-Eldorado dan moderator perbincangan Dmitry Lazarenko, Mail.ru Cloud Solutions.
Di bawah kami telah menyediakan transkrip perbincangan untuk anda, tetapi anda juga boleh menonton video:
Peralihan kepada perkhidmatan mikro adalah tindak balas kepada keperluan pasaran
Dmitriy:
Adakah anda mempunyai pengalaman yang berjaya berhijrah ke perkhidmatan mikro? Dan secara umum: di manakah anda melihat manfaat perniagaan terbesar daripada menggunakan perkhidmatan mikro atau beralih daripada monolit kepada perkhidmatan mikro?
Sergey:
Kami telah melalui beberapa cara dalam peralihan kepada perkhidmatan mikro dan telah menggunakan pendekatan ini selama lebih daripada tiga tahun. Keperluan pertama yang mewajarkan keperluan untuk perkhidmatan mikro ialah penyepaduan yang tidak berkesudahan pelbagai produk bahagian hadapan dengan pejabat belakang. Dan setiap kali kami terpaksa melakukan penyepaduan dan pembangunan tambahan, melaksanakan peraturan kami sendiri untuk operasi perkhidmatan ini atau itu.
Pada satu ketika, kami menyedari bahawa kami perlu mempercepatkan operasi sistem kami dan output kefungsian. Pada masa itu, konsep seperti perkhidmatan mikro dan pendekatan perkhidmatan mikro telah wujud di pasaran, dan kami memutuskan untuk mencubanya. Ini bermula pada 2016. Kemudian platform itu diletakkan dan 10 perkhidmatan pertama dilaksanakan oleh pasukan yang berasingan.
Salah satu perkhidmatan pertama, yang paling banyak dimuatkan, ialah perkhidmatan pengiraan harga. Setiap kali anda datang ke mana-mana saluran, ke kumpulan syarikat M.Video-Eldorado, sama ada laman web atau kedai runcit, pilih produk di sana, lihat harga di laman web atau dalam "Bakul", kosnya secara automatik dikira oleh satu perkhidmatan. Mengapa ini perlu: ββsebelum ini, setiap sistem mempunyai prinsip sendiri untuk bekerja dengan promosi - dengan diskaun dan sebagainya. Pejabat belakang kami mengendalikan harga; fungsi diskaun dilaksanakan dalam sistem lain. Ini perlu dipusatkan dan perkhidmatan unik yang boleh dipisahkan dibuat dalam bentuk proses perniagaan yang membolehkan kami melaksanakannya. Begitulah cara kami bermula.
Nilai keputusan pertama adalah sangat hebat. Pertama, kami dapat mencipta entiti boleh diasingkan yang membolehkan kami bekerja secara berasingan dan secara agregat. Kedua, kami telah mengurangkan kos pemilikan dari segi penyepaduan dengan lebih banyak sistem.
Sepanjang tiga tahun yang lalu, kami telah menambah tiga sistem barisan hadapan. Sukar untuk mengekalkannya dengan jumlah sumber yang sama yang mampu dimiliki oleh syarikat. Oleh itu, tugas timbul untuk mencari cawangan baru, bertindak balas kepada pasaran dari segi kelajuan, dari segi kos dalaman dan kecekapan.
Bagaimana untuk mengukur kejayaan berhijrah ke perkhidmatan mikro
Dmitriy:
Bagaimanakah kejayaan dalam berhijrah ke perkhidmatan mikro ditentukan? Apakah "sebelum ini" dalam setiap syarikat? Apakah metrik yang anda gunakan untuk menentukan kejayaan peralihan, dan siapa sebenarnya yang menentukannya?
Sergey:
Pertama sekali, ia dilahirkan dalam IT sebagai pemboleh - "membuka kunci" keupayaan baharu. Kami mempunyai keperluan untuk melakukan segala-galanya dengan lebih pantas untuk wang yang agak sama, bertindak balas kepada cabaran pasaran. Kini kejayaan dinyatakan dalam bilangan perkhidmatan yang digunakan semula oleh sistem yang berbeza, penyatuan proses antara mereka sendiri. Sekarang ia, tetapi pada masa itu ia adalah peluang untuk mencipta platform dan mengesahkan hipotesis bahawa kita boleh melakukan ini, ia akan memberi kesan dan mengira kes perniagaan.
Alexander:
Kejayaan adalah perasaan dalaman. Perniagaan sentiasa mahu lebih, dan kedalaman tunggakan kami adalah bukti kejayaan. Nampaknya begitu kepada saya.
Sergey:
Ya, saya setuju. Dalam tiga tahun, kami sudah mempunyai lebih daripada dua ratus perkhidmatan dan tunggakan. Keperluan untuk sumber dalam pasukan hanya berkembang - sebanyak 30% setiap tahun. Ini berlaku kerana orang merasakan: ia lebih pantas, ia berbeza, terdapat teknologi yang berbeza, semua ini sedang berkembang.
Perkhidmatan mikro akan datang, tetapi teras akan kekal
Dmitriy:
Ia seperti proses yang tidak berkesudahan di mana anda melabur dalam pembangunan. Adakah peralihan kepada perkhidmatan mikro untuk perniagaan sudah tamat atau belum?
Sergey:
Ia sangat mudah untuk menjawab. Apakah pendapat anda: menggantikan telefon adalah proses yang tidak berkesudahan? Kami sendiri membeli telefon setiap tahun. Dan inilah: selagi terdapat keperluan untuk kelajuan, untuk penyesuaian kepada pasaran, beberapa perubahan akan diperlukan. Ini tidak bermakna kita meninggalkan perkara biasa.
Tetapi kita tidak boleh menutup dan membuat semula semuanya sekaligus. Kami mempunyai warisan, perkhidmatan penyepaduan standard yang wujud sebelum ini: bas perusahaan dan sebagainya. Tetapi ada tunggakan, dan ada juga keperluan. Bilangan aplikasi mudah alih dan fungsinya semakin meningkat. Pada masa yang sama, tiada siapa yang mengatakan bahawa anda akan diberi 30% lebih wang. Iaitu, sentiasa ada keperluan di satu pihak, dan pencarian kecekapan di pihak yang lain.
Dmitriy:
Hidup dalam keadaan baik. (Ketawa)
Alexander:
Secara umum, ya. Kami tidak mempunyai pendekatan revolusioner untuk mengalih keluar bahagian teras daripada landskap. Kerja sistematik sedang dijalankan untuk menguraikan sistem supaya ia lebih konsisten dengan seni bina perkhidmatan mikro, untuk mengurangkan pengaruh sistem antara satu sama lain.
Tetapi kami merancang untuk mengekalkan bahagian teras, kerana dalam landskap pengendali akan sentiasa ada beberapa platform yang kami beli. Sekali lagi, kita memerlukan keseimbangan yang sihat: kita tidak seharusnya tergesa-gesa memotong inti. Kami meletakkan sistem bersebelahan, dan kini ternyata kami sudah berada di atas banyak bahagian teras. Selanjutnya, membangunkan fungsi, kami mencipta perwakilan yang diperlukan untuk semua saluran yang berfungsi dengan perkhidmatan komunikasi kami.
Bagaimana untuk menjual perkhidmatan mikro kepada perniagaan
Dmitriy:
Saya juga berminat - bagi mereka yang belum bertukar, tetapi merancang untuk: betapa mudahnya untuk menjual idea ini kepada perniagaan dan adakah ia satu pengembaraan, projek pelaburan? Atau adakah itu strategi yang sedar: kini kami akan pergi ke perkhidmatan mikro dan itu sahaja, tiada apa yang akan menghalang kami. Bagaimana keadaan anda?
Sergey:
Kami tidak menjual pendekatan, tetapi manfaat perniagaan. Terdapat masalah dalam perniagaan, dan kami cuba menyelesaikannya. Pada masa itu, ia dinyatakan dalam fakta bahawa saluran yang berbeza menggunakan prinsip yang berbeza untuk mengira harga - secara berasingan untuk promosi, untuk promosi, dan sebagainya. Sukar untuk dikekalkan, ralat berlaku dan kami mendengar aduan pelanggan. Maksudnya, kami menjual penyelesaian kepada masalah, tetapi kami datang dengan hakikat bahawa kami memerlukan wang untuk mencipta platform. Dan mereka menunjukkan kes perniagaan menggunakan contoh peringkat pertama pelaburan: bagaimana kami akan terus mendapatkan semula dan perkara ini akan membolehkan kami lakukan.
Dmitriy:
Adakah anda entah bagaimana merekodkan masa peringkat pertama?
Sergey:
Ya pasti. Kami memperuntukkan 6 bulan untuk mencipta teras sebagai platform dan menguji perintis. Pada masa ini, kami cuba mencipta platform untuk meluncur juruterbang. Kemudian hipotesis telah disahkan, dan kerana ia berfungsi, ini bermakna kita boleh meneruskan. Mereka mula meniru dan menguatkan pasukan - mereka memindahkannya ke bahagian berasingan yang melakukan perkara itu.
Seterusnya datang kerja sistematik berdasarkan keperluan perniagaan, peluang, ketersediaan sumber dan segala-galanya yang sedang dalam usaha.
Dmitriy:
OKEY. Alexander, apa yang anda katakan?
Alexander:
Perkhidmatan mikro kami lahir daripada "buih laut" - disebabkan oleh penjimatan sumber, disebabkan oleh beberapa baki dalam bentuk kapasiti pelayan dan pengagihan semula kuasa dalam pasukan. Pada mulanya, kami tidak menjual projek ini kepada perniagaan. Ini adalah projek di mana kami berdua meneliti dan membangunkan dengan sewajarnya. Kami bermula pada awal 2018 dan hanya membangunkan arah ini dengan penuh semangat. Jualan baru sahaja bermula dan kami dalam proses.
Dmitriy:
Adakah perniagaan membenarkan anda melakukan perkara seperti Google - pada satu hari percuma seminggu? Adakah anda mempunyai hala tuju sedemikian?
Alexander:
Pada masa yang sama dengan penyelidikan, kami juga menangani masalah perniagaan, jadi semua perkhidmatan mikro kami adalah penyelesaian kepada masalah perniagaan. Hanya pada mulanya kami membina perkhidmatan mikro yang merangkumi sebahagian kecil pangkalan pelanggan, dan kini kami hadir dalam hampir semua produk perdana.
Dan kesan materialnya sudah jelas - kita sudah boleh dikira, kelajuan pelancaran produk dan kehilangan hasil boleh dianggarkan jika kita telah mengikut laluan lama. Inilah yang kami sedang membina kes itu.
Perkhidmatan mikro: gembar-gembur atau keperluan?
Dmitriy:
Nombor adalah nombor. Dan hasil atau wang yang disimpan adalah sangat penting. Bagaimana jika anda melihat sisi lain? Nampaknya perkhidmatan mikro adalah trend, gembar-gembur dan banyak syarikat menyalahgunakannya? Sejauh manakah anda membezakan antara perkara yang anda lakukan dan tidak menterjemah kepada perkhidmatan mikro? Jika legasi sekarang, adakah anda masih mempunyai legasi dalam masa 5 tahun? Berapakah umur sistem maklumat yang berfungsi di M.Video-Eldorado dan MegaFon dalam masa 5 tahun? Adakah terdapat sistem maklumat sepuluh tahun, lima belas tahun atau adakah ia akan menjadi generasi baharu? Bagaimana anda melihat ini?
Sergey:
Nampaknya saya sukar untuk berfikir jauh. Jika kita melihat kembali, siapa yang membayangkan bahawa pasaran teknologi akan berkembang dengan cara ini, termasuk pembelajaran mesin dan pengenalan pengguna melalui muka? Tetapi jika anda melihat pada tahun-tahun akan datang, nampaknya saya sistem teras, sistem kelas ERP perusahaan dalam syarikat - mereka telah bekerja untuk masa yang agak lama.
Syarikat kami secara kolektif berusia 25 tahun, dengan ERP klasik yang sangat mendalam dalam landskap sistem. Adalah jelas bahawa kami mengambil beberapa bahagian dari sana dan cuba mengagregatkannya ke dalam perkhidmatan mikro, tetapi terasnya akan kekal. Sukar bagi saya sekarang untuk membayangkan bahawa kami akan menggantikan semua sistem teras di sana dan dengan cepat beralih ke bahagian lain yang cerah dalam sistem baharu.
Saya menyokong hakikat bahawa segala-galanya yang lebih dekat dengan pelanggan dan pengguna adalah di mana manfaat dan nilai perniagaan yang terbesar adalah, di mana kebolehsesuaian dan tumpuan pada kelajuan, pada perubahan, pada "cuba, batalkan, guna semula, lakukan sesuatu yang berbeza" adalah diperlukan "βdi situlah landskap akan berubah. Dan produk berkotak tidak sesuai di sana dengan baik. Sekurang-kurangnya kita tidak melihatnya. Penyelesaian yang paling mudah dan paling mudah diperlukan di sana.
Kami melihat perkembangan ini:
- sistem maklumat teras (kebanyakan pejabat belakang);
- lapisan tengah dalam bentuk perkhidmatan mikro menyambungkan teras, agregat, mencipta cache, dan sebagainya;
- sistem barisan hadapan ditujukan kepada pengguna;
- lapisan integrasi yang secara amnya disepadukan ke dalam pasaran, sistem lain dan ekosistem. Lapisan ini seringan mungkin, ringkas dan mengandungi minimum logik perniagaan.
Tetapi pada masa yang sama, saya adalah penyokong untuk terus menggunakan prinsip lama jika ia digunakan dengan sewajarnya.
Katakan anda mempunyai sistem perusahaan klasik. Ia terletak dalam landskap satu vendor dan terdiri daripada dua modul yang berfungsi antara satu sama lain. Terdapat juga antara muka integrasi standard. Mengapa buat semula dan bawa perkhidmatan mikro ke sana?
Tetapi apabila terdapat 5 modul di pejabat belakang, dari mana cebisan maklumat dikumpul ke dalam proses perniagaan, yang kemudiannya digunakan oleh 8-10 sistem barisan hadapan, faedahnya dapat dilihat dengan serta-merta. Anda mengambil daripada lima sistem pejabat belakang dan mencipta perkhidmatan, yang terpencil, yang tertumpu pada proses perniagaan. Jadikan perkhidmatan itu berteknologi maju - supaya ia menyimpan maklumat dan bertolak ansur dengan kesalahan, dan juga berfungsi dengan dokumen atau entiti perniagaan. Dan anda menyepadukannya mengikut satu prinsip dengan semua produk barisan hadapan. Mereka membatalkan produk barisan hadapan - mereka hanya mematikan penyepaduan. Esok anda perlu menulis aplikasi mudah alih atau membuat laman web kecil dan meletakkan hanya satu bahagian ke dalam fungsi - semuanya mudah: anda memasangnya seperti pembina. Saya melihat lebih banyak pembangunan ke arah ini - sekurang-kurangnya di negara kita.
Alexander:
Sergey menerangkan sepenuhnya pendekatan kami, terima kasih. Saya hanya akan menyatakan ke mana kita pasti tidak akan pergi - ke bahagian teras, kepada topik pengebilan dalam talian. Iaitu, penarafan dan pengecasan akan kekal, sebenarnya, pengirik "besar" yang boleh menghapuskan wang dengan pasti. Dan sistem ini akan terus diperakui oleh pihak berkuasa kawal selia kami. Segala-galanya yang melihat ke arah pelanggan, sudah tentu, adalah perkhidmatan mikro.
Dmitriy:
Di sini pensijilan adalah satu cerita. Mungkin lebih banyak sokongan. Jika anda membelanjakan sedikit untuk sokongan atau sistem tidak memerlukan sokongan dan pengubahsuaian, adalah lebih baik untuk tidak menyentuhnya. Satu kompromi yang munasabah.
Bagaimana untuk membangunkan perkhidmatan mikro yang boleh dipercayai
Dmitriy:
baiklah. Tetapi saya masih berminat. Kini anda menceritakan kisah kejayaan: semuanya baik-baik saja, kami bertukar kepada perkhidmatan mikro, mempertahankan idea kepada perniagaan dan semuanya berjaya. Tetapi saya pernah mendengar cerita lain.
Beberapa tahun lalu, sebuah syarikat Switzerland yang telah melabur dua tahun dalam membangunkan platform perkhidmatan mikro baharu untuk bank akhirnya menutup projek itu. Rebah sepenuhnya. Berjuta-juta franc Swiss telah dibelanjakan, dan akhirnya pasukan itu tersebar - ia tidak berjaya.
Adakah anda mempunyai cerita yang serupa? Adakah atau terdapat sebarang kesulitan? Sebagai contoh, mengekalkan perkhidmatan mikro dan pemantauan juga merupakan satu masalah dalam aktiviti operasi syarikat. Lagipun, bilangan komponen meningkat berpuluh kali ganda. Bagaimana anda melihatnya, adakah terdapat contoh pelaburan yang tidak berjaya di sini? Dan apa yang boleh anda nasihatkan orang supaya mereka tidak menghadapi masalah sedemikian?
Alexander:
Contoh yang tidak berjaya termasuk perniagaan yang mengubah keutamaan dan membatalkan projek. Apabila pada tahap kesediaan yang baik (sebenarnya, MVP sudah bersedia), perniagaan itu berkata: "Kami mempunyai keutamaan baharu, kami beralih kepada projek lain, dan kami akan menutup projek ini."
Kami tidak mengalami sebarang kegagalan global dengan perkhidmatan mikro. Kami tidur dengan tenang, kami mempunyai syif bertugas 24/7 yang memberi perkhidmatan kepada keseluruhan BSS [sistem sokongan perniagaan].
Dan satu perkara lagi - kami menyewakan perkhidmatan mikro mengikut peraturan yang digunakan untuk produk berkotak. Kunci kejayaan ialah anda perlu, pertama sekali, untuk mengumpulkan pasukan yang akan menyediakan sepenuhnya perkhidmatan mikro untuk pengeluaran. Pembangunan itu sendiri adalah, bersyarat, 40%. Selebihnya ialah analitik, metodologi DevSecOps, integrasi yang betul dan seni bina yang betul. Kami memberi perhatian khusus kepada prinsip membina aplikasi selamat. Wakil keselamatan maklumat mengambil bahagian dalam setiap projek pada peringkat perancangan seni bina dan semasa proses pelaksanaan. Mereka juga menguruskan sistem untuk menganalisis kod untuk kelemahan.
Katakan kami menggunakan perkhidmatan tanpa kewarganegaraan kami - kami ada di Kubernetes. Ini membolehkan semua orang tidur dengan tenang disebabkan penskalaan automatik dan peningkatan automatik perkhidmatan, dan anjakan tugas mengambil kira insiden.
Dalam keseluruhan kewujudan perkhidmatan mikro kami, hanya terdapat satu atau dua insiden yang telah sampai ke talian kami. Sekarang tiada masalah dengan operasi. Kami, sudah tentu, tidak mempunyai 200, tetapi kira-kira 50 perkhidmatan mikro, tetapi ia digunakan dalam produk utama. Jika mereka gagal, kami akan menjadi orang pertama yang mengetahuinya.
Perkhidmatan mikro dan HR
Sergey:
Saya bersetuju dengan rakan sekerja saya tentang pemindahan ke sokongan - bahawa kerja itu perlu disusun dengan betul. Tetapi saya akan memberitahu anda tentang masalah yang, sudah tentu, wujud.
Pertama, teknologi ini baru. Ini adalah gembar-gembur dengan cara yang baik, dan mencari pakar yang akan memahami dan boleh mencipta ini adalah satu cabaran besar. Persaingan untuk mendapatkan sumber adalah gila, jadi pakar bernilai berat mereka dalam emas.
Kedua, dengan penciptaan landskap tertentu dan bilangan perkhidmatan yang semakin meningkat, masalah penggunaan semula mesti sentiasa diselesaikan. Seperti yang pemaju suka lakukan: "Mari kita tulis banyak perkara menarik di sini sekarang ..." Disebabkan ini, sistem berkembang dan kehilangan keberkesanannya dari segi wang, kos pemilikan, dan sebagainya. Iaitu, adalah perlu untuk memasukkan penggunaan semula dalam seni bina sistem, memasukkannya dalam peta jalan untuk memperkenalkan perkhidmatan dan memindahkan warisan kepada seni bina baharu.
Masalah lain - walaupun ini bagus dengan caranya sendiri - ialah persaingan dalaman. "Oh, lelaki baru yang bergaya telah muncul di sini, mereka bercakap bahasa baharu." Orang, tentu saja, berbeza. Terdapat mereka yang biasa menulis dalam Java, dan mereka yang menulis dan menggunakan Docker dan Kubernetes. Ini adalah orang yang sama sekali berbeza, mereka bercakap secara berbeza, menggunakan istilah yang berbeza dan kadang-kadang tidak memahami antara satu sama lain. Keupayaan atau ketidakupayaan untuk berkongsi amalan, perkongsian ilmu, dalam pengertian ini juga menjadi masalah.
Nah, skala sumber. βHebat, mari pergi! Dan sekarang kami mahu lebih cepat, lebih banyak lagi. Apa, anda tidak boleh? Tidakkah mungkin untuk menghantar dua kali lebih banyak dalam setahun? Dan mengapa?" Kesakitan yang semakin meningkat itu mungkin standard untuk banyak perkara, banyak pendekatan, dan anda boleh merasakannya.
Berkenaan pemantauan. Nampaknya pada saya perkhidmatan atau alat pemantauan industri sudah belajar atau dapat bekerja dengan Docker dan Kubernetes dalam mod bukan standard yang berbeza. Supaya, sebagai contoh, anda tidak mempunyai 500 mesin Java di mana semua ini berjalan, iaitu, ia agregat. Tetapi produk ini masih kurang matang; mereka perlu melalui ini. Topik itu benar-benar baru, ia akan terus berkembang.
Dmitriy:
Ya, sangat menarik. Dan ini terpakai kepada HR. Mungkin proses HR dan jenama HR anda telah berubah sedikit sepanjang 3 tahun ini. Anda mula merekrut orang lain dengan kecekapan yang berbeza. Dan mungkin ada kebaikan dan keburukan. Sebelum ini, blockchain dan sains data adalah gembar-gembur, dan pakar di dalamnya bernilai berjuta-juta. Kini kos jatuh, pasaran menjadi tepu, dan terdapat trend yang sama dalam perkhidmatan mikro.
Sergey:
Ya, sama sekali.
Alexander:
HR bertanya soalan: "Di manakah unicorn merah jambu anda di antara bahagian belakang dan bahagian hadapan?" HR tidak faham apa itu perkhidmatan mikro. Kami memberitahu mereka rahsia itu dan memberitahu mereka bahawa bahagian belakang melakukan segala-galanya, dan tidak ada unicorn. Tetapi HR sedang berubah, belajar dengan cepat dan merekrut orang yang mempunyai pengetahuan asas IT.
Evolusi perkhidmatan mikro
Dmitriy:
Jika anda melihat seni bina sasaran, perkhidmatan mikro kelihatan seperti raksasa. Perjalanan anda mengambil masa beberapa tahun. Yang lain ada setahun, yang lain tiga tahun. Adakah anda meramalkan semua masalah, seni bina sasaran, adakah apa-apa perubahan? Contohnya, dalam kes perkhidmatan mikro, get laluan dan jaringan perkhidmatan kini muncul semula. Adakah anda menggunakannya pada mulanya atau adakah anda menukar seni bina itu sendiri? Adakah anda mempunyai cabaran sedemikian?
Sergey:
Kami telah pun menulis semula beberapa protokol komunikasi. Pada mulanya terdapat satu protokol, kini kami bertukar kepada yang lain. Kami meningkatkan keselamatan dan kebolehpercayaan. Kami bermula dengan teknologi perusahaan - Oracle, Web Logic. Kini kami beralih daripada produk perusahaan teknologi dalam perkhidmatan mikro dan beralih kepada teknologi sumber terbuka atau terbuka sepenuhnya. Kami meninggalkan pangkalan data dan beralih kepada perkara yang lebih berkesan untuk kami dalam model ini. Kami tidak lagi memerlukan teknologi Oracle.
Kami bermula hanya sebagai perkhidmatan, tanpa memikirkan betapa kami memerlukan cache, apa yang akan kami lakukan apabila tiada sambungan dengan perkhidmatan mikro, tetapi data diperlukan, dan lain-lain. Sekarang kami sedang membangunkan platform supaya seni bina dapat diterangkan bukan dalam bahasa perkhidmatan, dan dalam bahasa perniagaan, bawa logik perniagaan ke peringkat seterusnya apabila kita mula bercakap dalam perkataan. Kini kami telah belajar bercakap dalam surat, dan peringkat seterusnya ialah apabila perkhidmatan akan dikumpulkan ke dalam beberapa jenis agregat, apabila ini sudah menjadi perkataan - sebagai contoh, keseluruhan kad produk. Ia dipasang daripada perkhidmatan mikro, tetapi ia adalah API yang dibina di atas ini.
Keselamatan adalah sangat penting. Sebaik sahaja anda mula boleh diakses dan anda mempunyai perkhidmatan yang melaluinya anda boleh mendapatkan banyak perkara menarik, dan dengan cepat, dalam sekelip mata, maka ada keinginan untuk mendapatkannya dengan cara yang tidak paling selamat. Untuk menjauhi perkara ini, kami terpaksa menukar pendekatan kepada ujian dan pemantauan. Kami terpaksa menukar pasukan, struktur pengurusan penghantaran, CI/CD.
Ini adalah evolusi - seperti dengan telefon, hanya lebih pantas: mula-mula terdapat telefon tekan butang, kemudian telefon pintar muncul. Mereka menulis semula dan mereka bentuk semula produk kerana pasaran mempunyai keperluan yang berbeza. Beginilah cara kami berkembang: gred pertama, gred kesepuluh, kerja.
Secara berulang, sesuatu dibentangkan setiap tahun dari segi teknologi, dan sesuatu yang lain dari segi tunggakan dan keperluan. Kami menghubungkan satu perkara dengan yang lain. Pasukan membelanjakan 20% untuk hutang teknikal dan sokongan teknikal untuk pasukan, 80% untuk entiti perniagaan. Dan kami bergerak dengan pemahaman tentang mengapa kami melakukannya, mengapa kami membuat penambahbaikan teknologi ini, apa yang akan dibawa olehnya. Macam itu.
Dmitriy:
Sejuk. Apa yang ada dalam MegaFon?
Alexander:
Cabaran utama apabila kami datang ke perkhidmatan mikro adalah untuk tidak jatuh ke dalam huru-hara. Pejabat seni bina MegaFon segera menyertai kami, malah menjadi pemula dan pemandu - kini kami mempunyai seni bina yang sangat kuat. Tugasnya adalah untuk memahami model sasaran yang akan kami tuju dan teknologi apa yang perlu dipandu. Dengan seni bina, kami mengendalikan juruterbang ini sendiri.
Soalan seterusnya ialah: "Lalu bagaimana untuk mengeksploitasi semua ini?" Dan satu lagi: "Bagaimana untuk memastikan interaksi telus antara perkhidmatan mikro?" Jaringan perkhidmatan membantu kami menjawab soalan terakhir. Kami menguji Istio dan menyukai hasilnya. Sekarang kita berada di peringkat melancarkan ke zon produktif. Kami mempunyai sikap positif terhadap semua cabaran - hakikat bahawa kami perlu sentiasa mengubah susunan, mempelajari sesuatu yang baharu. Kami berminat untuk membangunkan, bukan mengeksploitasi penyelesaian lama.
Dmitriy:
Perkataan emas! Cabaran sebegini memastikan pasukan dan perniagaan sentiasa bersedia dan mencipta masa depan. GDPR mencipta ketua pegawai perlindungan data, dan cabaran semasa mewujudkan ketua pegawai mikro dan seni bina. Dan ia berkenan.
Banyak yang kami bincangkan. Perkara utama ialah reka bentuk perkhidmatan mikro yang baik dan seni bina itu sendiri membolehkan anda mengelakkan banyak kesilapan. Sudah tentu, proses itu berulang dan evolusi, tetapi ia adalah masa depan.
Terima kasih kepada semua peserta, terima kasih kepada Sergei dan Alexander!
Soalan daripada penonton
Soalan daripada penonton (1):
Sergey, bagaimana pengurusan IT berubah dalam syarikat anda? Saya faham bahawa apabila terdapat timbunan besar beberapa sistem, cara ia diuruskan adalah proses yang agak jelas dan logik. Bagaimanakah anda membina semula pengurusan komponen IT selepas sejumlah besar perkhidmatan mikro disepadukan dalam masa yang singkat?
Sergey:
Saya bersetuju dengan rakan sekerja saya bahawa seni bina adalah sangat penting sebagai pemacu perubahan. Kami bermula dengan mempunyai bahagian seni bina. Arkitek pada masa yang sama adalah pemilik pengedaran fungsi dan keperluan untuk bagaimana ia akan muncul dalam landskap. Jadi mereka juga bertindak sebagai penyelaras perubahan ini. Akibatnya, terdapat perubahan khusus pada proses penghantaran tertentu apabila kami mencipta platform CI/CD.
Tetapi standard, prinsip asas pembangunan, analisis perniagaan, ujian dan pembangunan tidak dibatalkan. Kami hanya menambah kelajuan. Sebelum ini, kitaran mengambil banyak masa, pemasangan pada persekitaran ujian mengambil lebih banyak masa. Kini perniagaan melihat faedahnya dan berkata: "Mengapa kami tidak boleh melakukan perkara yang sama di tempat lain?"
Ia seperti, dengan cara yang baik, suntikan dalam bentuk vaksin yang menunjukkan: anda boleh melakukannya dengan cara ini, tetapi anda boleh melakukannya dengan cara lain. Sudah tentu, terdapat masalah dalam kakitangan, dalam kecekapan, dalam pengetahuan, dalam rintangan.
Soalan daripada penonton (2):
Pengkritik seni bina perkhidmatan mikro mengatakan bahawa ujian dan pembangunan adalah sukar. Ini adalah logik apabila keadaan menjadi rumit. Apakah cabaran yang dihadapi oleh pasukan anda dan bagaimana anda mengatasinya? Soalan untuk semua orang.
Alexander:
Terdapat kesukaran apabila berpindah dari perkhidmatan mikro ke platform, tetapi ia boleh diselesaikan.
Sebagai contoh, kami membuat produk yang terdiri daripada 5-7 perkhidmatan mikro. Kami perlu menyediakan ujian penyepaduan merentas keseluruhan timbunan perkhidmatan mikro untuk memberi lampu hijau untuk berpindah ke cawangan induk. Tugas ini bukan perkara baru bagi kami: kami telah melakukan ini untuk masa yang lama di BSS, apabila vendor membekalkan kami penyelesaian yang telah dihantar.
Dan masalah kami hanya dalam pasukan kecil. Seorang jurutera QA diperlukan untuk satu produk bersyarat. Oleh itu, kami menghantar produk 5-7 perkhidmatan mikro, yang mana 2-3 boleh dibangunkan oleh pihak ketiga. Sebagai contoh, kami mempunyai produk dalam pembangunan yang mana vendor sistem pengebilan kami, Kumpulan Mail.ru dan R&D MegaFon mengambil bahagian. Kami perlu menutup perkara ini dengan ujian sebelum menghantarnya ke pengeluaran. Jurutera QA telah mengusahakan produk ini selama sebulan setengah, dan seluruh pasukan ditinggalkan tanpa sokongannya.
Kerumitan ini hanya disebabkan oleh penskalaan. Kami faham bahawa perkhidmatan mikro tidak boleh wujud dalam vakum; pengasingan mutlak tidak wujud. Apabila menukar satu perkhidmatan, kami sentiasa cuba mengekalkan kontrak API. Jika sesuatu berubah di bawah hud, perkhidmatan hadapan kekal. Jika perubahan itu membawa maut, beberapa jenis transformasi seni bina berlaku dan kami beralih ke metamodel data yang sama sekali berbeza, yang tidak serasi sepenuhnya - barulah kita bercakap tentang spesifikasi API perkhidmatan v2 yang muncul. Kami menyokong versi pertama dan kedua secara serentak, dan selepas semua pengguna beralih kepada versi kedua, kami hanya menutup versi pertama.
Sergey:
saya nak tambah. Saya benar-benar bersetuju tentang komplikasi - ia berlaku. Landskap menjadi lebih kompleks, dan kos overhed meningkat, terutamanya untuk ujian. Cara menangani perkara ini: beralih kepada ujian automatik. Ya, anda perlu melabur tambahan dalam autotest bertulis dan ujian unit. Supaya pembangun tidak boleh komited tanpa lulus ujian, mereka tidak boleh menukar kod. Supaya butang tekan pun tidak berfungsi tanpa autotest, ujian unit.
Adalah penting untuk mengekalkan fungsi sebelumnya, dan ini adalah overhed tambahan. Jika anda menulis semula teknologi kepada protokol lain, maka anda menulis semula sehingga anda menutup semuanya sepenuhnya.
Kami kadang-kadang tidak melakukan ujian hujung ke hujung dengan sengaja, kerana kami tidak mahu menghentikan pembangunan, walaupun kami juga mempunyai satu demi satu perkara. Landskapnya sangat besar, kompleks, terdapat banyak sistem. Kadangkala ia hanya stub - ya, anda menurunkan margin keselamatan, lebih banyak risiko muncul. Tetapi pada masa yang sama anda melepaskan bekalan.
Alexander:
Ya, ujian auto dan ujian unit membolehkan anda mencipta perkhidmatan berkualiti tinggi. Kami adalah untuk saluran paip yang tidak boleh diluluskan tanpa ujian unit dan integrasi. Kami selalunya perlu menyeret emulator dan sistem komersial ke dalam zon ujian dan persekitaran pembangunan, kerana tidak semua sistem boleh diletakkan dalam zon ujian. Selain itu, ia bukan sahaja basah - kami menjana respons sepenuhnya daripada sistem. Ini adalah bahagian serius dalam bekerja dengan perkhidmatan mikro, dan kami juga melabur di dalamnya. Tanpa ini, huru-hara akan berlaku.
Soalan daripada penonton (3):
Setakat yang saya faham, perkhidmatan mikro pada mulanya berkembang daripada pasukan yang berasingan dan kini wujud dalam model ini. Apakah kebaikan dan keburukannya?
Kami hanya mempunyai cerita yang sama: sejenis kilang perkhidmatan mikro timbul. Sekarang kami secara konsep telah sampai ke tahap yang kami meluaskan pendekatan ini kepada pengeluaran melalui aliran dan sistem. Dalam erti kata lain, kami semakin menjauhi pembangunan berpusat perkhidmatan mikro, model perkhidmatan mikro dan semakin hampir dengan sistem.
Oleh itu, operasi kami juga pergi ke sistem, iaitu, kami mendesentralisasi topik ini. Apakah pendekatan anda dan apakah cerita sasaran anda?
Alexander:
Anda telah membuang nama "kilang perkhidmatan mikro" terus daripada mulut anda - kami juga mahu meningkatkan. Pertama, kami benar-benar mempunyai satu pasukan sekarang. Kami mahu memberikan semua pasukan pembangunan yang MegaFon mempunyai peluang untuk bekerja dalam ekosistem yang sama. Kami tidak mahu mengambil alih sepenuhnya semua fungsi pembangunan yang kami ada sekarang. Tugas tempatan adalah untuk skala, tugas global adalah untuk memimpin pembangunan kepada semua pasukan dalam lapisan perkhidmatan mikro.
Sergey:
Saya akan memberitahu anda jalan yang telah kita lalui. Kami benar-benar mula bekerja sebagai satu pasukan, tetapi kini kami tidak bersendirian. Saya penyokong yang berikut: mesti ada pemilik proses. Seseorang perlu memahami, mengurus, mengawal dan membina proses pembangunan perkhidmatan mikro. Dia mesti memiliki sumber dan melibatkan diri dalam pengurusan sumber.
Sumber ini, yang mengetahui teknologi, spesifik dan memahami cara membina perkhidmatan mikro, boleh didapati dalam pasukan produk. Kami mempunyai campuran di mana orang daripada platform perkhidmatan mikro berada dalam pasukan produk yang membuat aplikasi mudah alih. Mereka berada di sana, tetapi mereka bekerja mengikut proses jabatan pengurusan platform perkhidmatan mikro dengan pengurus pembangunan mereka. Dalam bahagian ini terdapat pasukan berasingan yang berurusan dengan teknologi. Iaitu, kami mencampurkan kumpulan sumber yang sama di kalangan kami dan membahagikannya, memberikannya kepada pasukan.
Pada masa yang sama, proses itu tetap umum, terkawal, ia berjalan mengikut prinsip teknologi umum, dengan ujian unit dan sebagainya - segala-galanya yang dibina di atas. Mungkin terdapat lajur dalam bentuk sumber yang dikumpul daripada pelbagai jabatan pendekatan produk.
Alexander:
Sergey, anda sebenarnya pemilik proses itu, bukan? Adakah tunggakan tugas dikongsi? Siapa yang bertanggungjawab untuk pengedarannya?
Sergey:
Lihat: ini campuran lagi. Terdapat tunggakan yang dibentuk berdasarkan peningkatan teknologi - ini adalah satu cerita. Terdapat tunggakan, yang dirumus daripada projek, dan terdapat tunggakan daripada produk. Tetapi urutan pengenalan ke dalam setiap produk perkhidmatan atau penciptaan perkhidmatan ini dibangunkan oleh pakar produk. Dia tidak berada dalam direktorat IT; dia telah dikeluarkan khas daripadanya. Tetapi orang saya pasti bekerja mengikut proses yang sama.
Pemilik tunggakan dalam arah yang berbeza - tunggakan perubahan - akan menjadi orang yang berbeza. Sambungan perkhidmatan teknologi, prinsip penganjuran mereka - semua ini akan berada dalam IT. Saya memiliki platform dan sumber juga. Di bahagian atas ialah perkara yang berkaitan dengan tunggakan dan perubahan fungsi, dan seni bina dalam pengertian ini.
Katakan perniagaan berkata: "Kami mahu fungsi ini, kami mahu mencipta produk baharu - membuat semula pinjaman." Kami menjawab: "Ya, kami akan melakukannya semula." Arkitek berkata: "Mari kita fikirkan: di mana dalam pinjaman kita akan menulis perkhidmatan mikro dan bagaimana kita akan melakukannya?" Kemudian kami memecahkannya kepada projek, produk atau timbunan teknologi, memasukkannya ke dalam pasukan dan melaksanakannya. Adakah anda telah mencipta produk secara dalaman dan memutuskan untuk menggunakan perkhidmatan mikro dalam produk ini? Kami berkata: "Kini sistem warisan yang kami ada, atau sistem barisan hadapan, mesti beralih kepada perkhidmatan mikro ini." Para arkitek berkata: "Jadi: dalam tunggakan teknologi di dalam produk barisan hadapan - peralihan kepada perkhidmatan mikro. Pergi". Dan pakar produk atau pemilik perniagaan memahami berapa banyak kapasiti yang diperuntukkan, bila ia akan dilakukan dan sebabnya.
Tamat perbincangan, tetapi bukan semua
Persidangan mailto:CLOUD telah dianjurkan .
Kami juga melakukan acara lain - cth. Pertemuan @Kubernetes, di mana kami sentiasa mencari pembesar suara yang hebat:
- Ikuti @Kubernetes dan berita @Meetup lain di saluran Telegram kami
- Berminat untuk bercakap di salah satu @Meetups? Tinggalkan permintaan untuk
Sumber: www.habr.com