Tanggal 25 April, kita ing Mail.ru Group nganakake konferensi babagan awan lan sekitar - . Sawetara sorotan:
- Utama - Solusi Cloud Mail.ru, #CloudMTS, SberCloud, Selectel, Pusat Data Rostelecom lan Yandex.Cloud ngomong babagan spesifik pasar maya lan layanane;
- Kolega saka Bitrix24 ngandhani carane dheweke ;
- Leroy Merlin, Otkritie, Burger King lan Schneider Electric kasedhiya menarik - apa tugas bisnis sing disetel kanggo IT lan teknologi apa, kalebu awan, sing dianggep paling njanjeni.
Sampeyan bisa nonton kabeh video saka mailto: konferensi CLOUD , lan ing kene sampeyan bisa maca kepiye diskusi babagan layanan mikro. Alexander Deulin, kepala pusat riset lan pangembangan sistem bisnis MegaFon, lan Sergey Sergeev, direktur teknologi informasi grup M.Video-Eldorado, nuduhake kasus sing sukses kanggo nyingkirake monolit. Kita uga ngrembug masalah sing ana gandhengane karo strategi IT, proses lan uga HR.
Panelis
- Sergey Sergeev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, kepala pusat riset lan pangembangan sistem bisnis MegaFon;
- Moderator - Dmitry Lazarenko, Kepala arah PaaS Solusi Cloud Mail.ru.
Sawise pidato Alexander Deulin dheweke gabung kanggo diskusi dening Sergey Sergeev saka M.Video-Eldorado lan moderator diskusi Dmitry Lazarenko, Mail.ru Cloud Solutions.
Ing ngisor iki kita wis nyiapake transkrip diskusi kanggo sampeyan, nanging sampeyan uga bisa nonton video kasebut:
Transisi menyang layanan mikro minangka respon kanggo kabutuhan pasar
Dmitriy:
Apa sampeyan duwe pengalaman sukses migrasi menyang layanan mikro? Lan umume: ngendi sampeyan ndeleng keuntungan bisnis paling gedhe saka nggunakake microservices utawa pindhah saka monoliths kanggo microservices?
Sergey:
Kita wis entuk sawetara cara ing transisi menyang layanan mikro lan wis nggunakake pendekatan iki luwih saka telung taun. Kabutuhan pisanan sing mbenerake kabutuhan layanan mikro yaiku integrasi tanpa wates saka macem-macem produk ngarep karo kantor mburi. Lan saben-saben kita dipeksa nindakake integrasi lan pangembangan tambahan, ngleksanakake aturan dhewe kanggo operasi iki utawa layanan kasebut.
Ing sawetara titik, kita nyadari yen kita kudu nyepetake operasi sistem lan output fungsi. Ing wayahe, konsep kayata layanan mikro lan pendekatan layanan mikro wis ana ing pasar, lan kita mutusake kanggo nyoba. Iki diwiwiti ing 2016. Banjur platform kasebut dilebokake lan 10 layanan pisanan ditindakake dening tim sing kapisah.
Salah sawijining layanan pisanan, sing paling akeh dimuat, yaiku layanan pitungan rega. Saben-saben sampeyan teka ing saluran apa wae, menyang grup perusahaan M.Video-Eldorado, dadi situs web utawa toko ritel, pilih produk ing kana, deleng rega ing situs web utawa ing "Basket", biaya kanthi otomatis diwilang dening siji layanan. Napa iki perlu: sadurunge iki, saben sistem duwe prinsip dhewe kanggo nggarap promosi - kanthi diskon lan liya-liyane. Kantor mburi kita nangani rega; fungsi diskon dileksanakake ing sistem liyane. Iki kudu dipusatake lan layanan sing unik lan bisa dipisahake digawe ing wangun proses bisnis sing bakal ngidini kita ngleksanakake iki. Semono uga kita miwiti.
Nilai saka asil pisanan banget gedhe. Kaping pisanan, kita bisa nggawe entitas sing bisa dipisahake sing ngidini kita bisa kerja kanthi kapisah lan kanthi cara sing dikumpulake. Kapindho, kita wis nyuda biaya kepemilikan babagan integrasi karo sistem liyane.
Sajrone telung taun kepungkur, kita wis nambah telung sistem garis ngarep. Iku angel kanggo njaga kanthi jumlah sumber daya sing padha karo perusahaan. Mulane, tugas muncul kanggo nggoleki toko anyar, nanggapi pasar babagan kacepetan, babagan biaya internal lan efisiensi.
Cara ngukur sukses migrasi menyang layanan mikro
Dmitriy:
Kepiye sukses migrasi menyang layanan mikro ditemtokake? Apa "sadurunge" ing saben perusahaan? Apa metrik sing sampeyan gunakake kanggo nemtokake sukses transisi, lan sapa sing nemtokake?
Sergey:
Kaping pisanan, lair ing IT minangka enabler - "mbukak kunci" kemampuan anyar. Kita kudu nindakake kabeh luwih cepet kanthi dhuwit sing padha, nanggapi tantangan pasar. Saiki sukses dituduhake ing jumlah layanan sing digunakake maneh dening sistem sing beda-beda, manunggalake proses ing antarane. Saiki, nanging ing wayahe iku minangka kesempatan kanggo nggawe platform lan konfirmasi hipotesis yen kita bisa nindakake iki, bakal menehi efek lan ngetung kasus bisnis.
Alexander:
Sukses minangka perasaan internal. Bisnis tansah pengin luwih akeh, lan ambane backlog kita minangka bukti sukses. Iku misale jek kanggo kula.
Sergey:
Ya, aku setuju. Ing telung taun, kita wis duwe luwih saka rong atus layanan lan backlog. Kebutuhan sumber daya ing tim mung tuwuh - 30% saben taun. Iki kedadeyan amarga wong rumangsa: luwih cepet, beda, ana teknologi sing beda, kabeh iki berkembang.
Microservices bakal teka, nanging inti bakal tetep
Dmitriy:
Iku kaya proses sing ora ana pungkasan ing ngendi sampeyan nandur modal ing pembangunan. Apa transisi menyang layanan mikro kanggo bisnis wis rampung utawa durung?
Sergey:
Gampang banget kanggo njawab. Apa sampeyan mikir: ngganti telpon minangka proses tanpa wates? Awake dhewe tuku telpon saben taun. Lan ing kene: anggere ana kabutuhan kacepetan, kanggo adaptasi menyang pasar, sawetara owah-owahan bakal dibutuhake. Iki ora ateges kita nglirwakake barang-barang standar.
Nanging kita ora bisa nutupi lan mbaleni kabeh bebarengan. Kita duwe warisan, layanan integrasi standar sing wis ana sadurunge: bus perusahaan lan liya-liyane. Nanging ana backlog, lan ana uga perlu. Jumlah aplikasi seluler lan fungsine tambah akeh. Ing wektu sing padha, ora ana sing ngomong yen sampeyan bakal diwenehi dhuwit 30%. Sing, tansah ana kabutuhan ing tangan siji, lan search kanggo efficiency ing sisih liyane.
Dmitriy:
Urip iku apik. (Ngguyu)
Alexander:
Umumé, ya. Kita ora duwe pendekatan revolusioner kanggo mbusak bagean inti saka lanskap. Karya sistematis ditindakake kanggo ngurai sistem supaya luwih konsisten karo arsitektur layanan mikro, kanggo nyuda pengaruh sistem ing saben liyane.
Nanging kita ngrancang supaya bagean inti, amarga ing lanskap operator mesthi ana sawetara platform sing kita tuku. Maneh, kita butuh keseimbangan sing sehat: kita ora kudu cepet-cepet nglereni inti. We nyeleh sistem sisih dening sisih, lan saiki dadi metu sing kita wis ing ndhuwur akeh bagean inti. Salajengipun, ngembangake fungsi kasebut, kita nggawe perwakilan sing dibutuhake kanggo kabeh saluran sing bisa digunakake karo layanan komunikasi.
Cara adol layanan mikro menyang bisnis
Dmitriy:
Aku uga kasengsem - kanggo wong-wong sing durung ngalih, nanging ngrancang: sepira gampang kanggo ngedol ide iki kanggo bisnis lan apa iku petualangan, proyek investasi? Utawa iku strategi sadar: saiki kita arep menyang microservices lan iku, ora ana sing bakal mungkasi kita. Kepiye carane kanggo sampeyan?
Sergey:
Kita ora ngedol pendekatan, nanging entuk manfaat bisnis. Ana masalah ing bisnis, lan kita nyoba kanggo ngatasi. Ing wayahe, diungkapake yen saluran sing beda-beda nggunakake prinsip sing beda kanggo ngitung rega - kanthi kapisah kanggo promosi, promosi, lan liya-liyane. Iku angel kanggo njaga, ana kesalahan, lan kita ngrungokake keluhan customer. Sing, kita padha ngedol solusi kanggo masalah, nanging kita teka karo kasunyatan sing kita perlu dhuwit kanggo nggawe platform. Lan dheweke nuduhake kasus bisnis kanthi nggunakake conto investasi tahap pertama: kepiye kita bakal terus mbalekake lan apa sing bakal ditindakake.
Dmitriy:
Apa sampeyan ngrekam wektu tahap pertama?
Sergey:
Iya tenanan. Kita nyedhiyakake 6 sasi kanggo nggawe inti minangka platform lan nyoba pilot. Sajrone wektu iki, kita nyoba nggawe platform kanggo skate pilot. Banjur hipotesis kasebut dikonfirmasi, lan amarga kerjane, tegese kita bisa nerusake. Dheweke wiwit niru lan nguatake tim kasebut - dheweke pindhah menyang divisi sing kapisah sing nindakake kaya ngono.
Sabanjure teka karya sistematis adhedhasar kabutuhan bisnis, kesempatan, kasedhiyan sumber daya lan kabeh sing saiki ing karya.
Dmitriy:
OK. Alexander, apa sampeyan ngomong?
Alexander:
Layanan mikro kita lair saka "umpluk segara" - amarga ngirit sumber daya, amarga sawetara sisa ing wangun kapasitas server lan redistribusi pasukan ing tim. Kaping pisanan, kita ora ngedol proyek iki kanggo bisnis. Iki minangka proyek sing kita riset lan dikembangake. Kita miwiti ing awal 2018 lan mung ngembangake arah iki kanthi semangat. Penjualan wis diwiwiti lan kita lagi proses.
Dmitriy:
Apa ana bisnis sing ngidini sampeyan nindakake kaya Google - ing dina gratis saben minggu? Apa sampeyan duwe arah kaya ngono?
Alexander:
Ing wektu sing padha karo riset, kita uga ngatasi masalah bisnis, saengga kabeh layanan mikro minangka solusi kanggo masalah bisnis. Mung ing wiwitan kita mbangun layanan mikro sing nutupi bagean cilik saka basis pelanggan, lan saiki kita ana ing meh kabeh produk unggulan.
Lan dampak materi wis jelas - kita wis bisa diitung, kacepetan peluncuran produk lan penghasilan sing ilang bisa dikira yen kita wis ngetutake dalan lawas. Iki sing kita mbangun kasus kasebut.
Microservices: hype utawa kabutuhan?
Dmitriy:
Angka iku angka. Lan revenue utawa dhuwit disimpen iku penting banget. Apa yen sampeyan ndeleng sisih liyane? Kayane microservices minangka tren, hype lan akeh perusahaan sing nyalahake? Sepira jelas sampeyan mbedakake apa sing sampeyan lakoni lan ora nerjemahake menyang layanan mikro? Yen warisan saiki, apa sampeyan isih duwe warisan ing 5 taun? Apa umur sistem informasi sing bisa digunakake ing M.Video-Eldorado lan MegaFon sajrone 5 taun? Apa bakal ana sistem informasi sepuluh taun, limalas taun utawa bakal dadi generasi anyar? Kepiye sampeyan ndeleng iki?
Sergey:
Kayane aku angel mikir adoh banget. Yen kita ndeleng maneh, sapa sing mbayangake manawa pasar teknologi bakal berkembang kanthi cara iki, kalebu sinau mesin lan identifikasi pangguna kanthi pasuryan? Nanging yen katon ing taun teka, misale jek kula sing sistem inti, perusahaan sistem ERP-kelas ing perusahaan - padha wis digunakake kanggo dangu.
Perusahaan kita umure 25 taun, kanthi ERP klasik banget ing lanskap sistem. Cetha yen kita njupuk sawetara potongan lan nyoba nglumpukake menyang layanan mikro, nanging inti bakal tetep. Iku hard kanggo kula saiki kanggo mbayangno sing kita bakal ngganti kabeh sistem inti ana lan cepet pindhah menyang liyane, sisih padhang saka sistem anyar.
Aku minangka panyengkuyung kasunyatan manawa kabeh sing luwih cedhak karo klien lan konsumen yaiku entuk manfaat lan nilai bisnis sing paling gedhe, ing ngendi adaptasi lan fokus ing kacepetan, owah-owahan, "nyoba, mbatalake, gunakake maneh, nindakake sing beda" dibutuhake "- ing kono lanskap bakal ganti. Lan produk kothak ora pas banget ing kono. Paling ora kita weruh. Solusi sing paling gampang lan paling gampang dibutuhake ing kana.
Kita ndeleng pangembangan iki:
- sistem informasi inti (biasane back office);
- lapisan tengah ing wangun microservices nyambung inti, agregat, nggawe cache, lan ing;
- sistem ngarep-line ngarahke ing konsumen;
- lapisan integrasi sing umume digabungake menyang pasar, sistem lan ekosistem liyane. Lapisan iki minangka entheng sabisa, prasaja, lan ngemot minimal logika bisnis.
Nanging ing wektu sing padha, aku dadi pendukung kanggo terus nggunakake prinsip lawas yen digunakake kanthi tepat.
Contone, sampeyan duwe sistem perusahaan klasik. Dumunung ing malang siji vendor lan kasusun saka rong modul sing bisa karo saben liyane. Ana uga antarmuka integrasi standar. Apa maneh lan nggawa layanan mikro ing kana?
Nanging nalika ana 5 modul ing kantor mburi, saka kang bêsik informasi diklumpukake menyang proses bisnis, kang banjur digunakake dening 8-10 sistem ngarep-line, entuk manfaat langsung katon. Sampeyan njupuk saka limang sistem back-office lan nggawe layanan, sing terisolasi, sing fokus ing proses bisnis. Nggawe layanan kanthi teknologi maju - supaya bisa nyimpen informasi lan tahan kesalahan, lan uga bisa digunakake karo dokumen utawa entitas bisnis. Lan sampeyan nggabungake miturut prinsip siji karo kabeh produk ngarep. Dheweke mbatalake produk garis ngarep - mung mateni integrasi. Sesuk sampeyan kudu nulis aplikasi seluler utawa nggawe situs web cilik lan mung sijine siji bagean ing fungsi - kabeh iku prasaja: sampeyan nglumpuk kaya konstruktor. Aku ndeleng luwih akeh pembangunan ing arah iki - paling ora ing negara kita.
Alexander:
Sergey ngrampungake pendekatan kita, matur nuwun. Aku mung bakal ngomong ing ngendi kita mesthi ora bakal pindhah - menyang bagean inti, menyang topik tagihan online. Yaiku, rating lan ngisi daya bakal tetep, nyatane, thresher "gedhe" sing bisa dipercaya ngilangi dhuwit. Lan sistem iki bakal terus disertifikasi dening panguwasa peraturan kita. Kabeh liyane sing katon menyang klien, mesthi, microservices.
Dmitriy:
Ing kene sertifikasi minangka salah sawijining crita. Mbokmenawa luwih akeh dhukungan. Yen sampeyan mbuwang sethithik kanggo dhukungan utawa sistem ora mbutuhake dhukungan lan modifikasi, luwih becik ora ndemek. A kompromi cukup.
Cara ngembangake layanan mikro sing dipercaya
Dmitriy:
nggih. Nanging aku isih kasengsem. Saiki sampeyan ngandhani crita sukses: kabeh apik, kita ngalih menyang microservices, mbela ide kanggo bisnis, lan kabeh bisa. Nanging aku wis krungu crita liyane.
Sawetara taun kepungkur, perusahaan Swiss sing wis nandur modal rong taun kanggo ngembangake platform layanan mikro anyar kanggo bank-bank pungkasane nutup proyek kasebut. Rampung ambruk. Akeh mayuta-yuta franc Swiss sing dibuwang, lan pungkasane tim kasebut bubar - ora bisa ditindakake.
Apa sampeyan duwe crita sing padha? Apa utawa ana kangelan? Contone, njaga microservices lan ngawasi uga sirah ing aktivitas operasional perusahaan. Sawise kabeh, jumlah komponen mundhak puluhan kaping. Kepiye sampeyan ndeleng, apa ana conto investasi sing ora sukses ing kene? Lan apa sampeyan bisa menehi saran marang wong supaya ora nemoni masalah kasebut?
Alexander:
Conto sing ora sukses kalebu bisnis sing ngganti prioritas lan mbatalake proyek. Nalika ing tahap kesiapan sing apik (nyatane, MVP wis siyap), bisnis kasebut ujar: "Kita duwe prioritas anyar, kita pindhah menyang proyek liyane, lan kita nutup proyek iki."
Kita ora duwe kegagalan global babagan layanan mikro. Kita turu kanthi tentrem, kita duwe shift tugas 24/7 sing nglayani kabeh BSS [sistem dhukungan bisnis].
Lan siji liyane - kita nyewa layanan mikro miturut aturan sing ditrapake kanggo produk kothak. Kunci sukses yaiku sampeyan kudu, pisanan, kanggo ngumpulake tim sing bakal nyiapake microservice kanthi lengkap kanggo produksi. Perkembangan kasebut, kanthi syarat, 40%. Liyane ana analytics, metodologi DevSecOps, integrasi sing bener lan arsitektur sing bener. Kita menehi perhatian khusus marang prinsip mbangun aplikasi sing aman. Perwakilan keamanan informasi melu ing saben proyek ing tahap perencanaan arsitektur lan sajrone proses implementasine. Dheweke uga ngatur sistem kanggo nganalisa kode kanggo kerentanan.
Contone, kita nggunakake layanan stateless - ana ing Kubernetes. Iki ngidini saben wong bisa turu kanthi tentrem amarga layanan skala otomatis lan mundhakaken otomatis, lan shift tugas njupuk kedadeyan.
Ing kabeh microservices kita, mung ana siji utawa loro kedadean sing wis tekan baris kita. Saiki ora ana masalah karo operasi. Kita, mesthi, ora duwe 200, nanging udakara 50 layanan mikro, nanging digunakake ing produk unggulan. Yen gagal, kita bakal dadi sing pertama ngerti babagan iki.
Microservices lan HR
Sergey:
Aku setuju karo kancaku babagan transfer menyang dhukungan - manawa karya kasebut kudu diatur kanthi bener. Nanging aku bakal pitutur marang kowe bab masalah sing, mesthi, ana.
Kaping pisanan, teknologi kasebut anyar. Iki minangka hype kanthi cara sing apik, lan nemokake spesialis sing bakal ngerti lan bisa nggawe iki minangka tantangan gedhe. Kompetisi kanggo sumber daya edan, mula para ahli entuk bobote emas.
Kapindho, kanthi nggawe lanskap tartamtu lan akeh layanan, masalah panggunaan maneh kudu terus dirampungake. Kaya sing dikarepake para pangembang: "Ayo nulis akeh perkara sing menarik ing kene saiki ..." Amarga iki, sistem kasebut tuwuh lan ilang efektifitas ing babagan dhuwit, biaya kepemilikan, lan liya-liyane. Yaiku, perlu kanggo nyakup panggunaan maneh ing arsitektur sistem, kalebu ing peta dalan kanggo ngenalake layanan lan mindhah warisan menyang arsitektur anyar.
Masalah liyane - sanajan iki apik kanthi cara dhewe - yaiku kompetisi internal. "Oh, wong modis anyar wis muncul ing kene, dheweke nganggo basa anyar." Wong, mesthi, beda. Ana sing wis biasa nulis ing Jawa, lan sing nulis lan nggunakake Docker lan Kubernetes. Iki wong temen beda, padha ngomong beda, nggunakake istilah beda lan kadhangkala ora ngerti saben liyane. Kemampuan utawa ora bisa kanggo nuduhake laku, nuduhake kawruh, ing pangertèn iki uga masalah.
Inggih, scaling sumber daya. “Gwaenchana, ayo! Lan saiki kita pengin luwih cepet, luwih. Apa, sampeyan ora bisa? Apa ora bisa ngirim kaping pindho ing setahun? Lan kenapa?" Rasa lara sing kaya ngono bisa uga standar kanggo akeh perkara, akeh pendekatan, lan sampeyan bisa ngrasakake.
Bab ngawasi. Kayane aku layanan utawa alat ngawasi industri wis sinau utawa bisa nggarap Docker lan Kubernetes ing mode non-standar sing beda. Dadi, contone, sampeyan ora duwe 500 mesin Java sing kabeh iki mlaku, yaiku, agregat. Nanging produk-produk iki isih kurang kadewasan; padha kudu ngliwati iki. Topik kasebut pancen anyar, bakal terus berkembang.
Dmitriy:
Ya, menarik banget. Lan iki ditrapake kanggo HR. Mungkin proses HR lan merek HR sampeyan wis owah sethithik sajrone 3 taun iki. Sampeyan wiwit ngrekrut wong liya kanthi kompetensi sing beda. Lan mbokmenawa ana loro Pros lan cons. Sadurungé, pamblokiran lan ilmu data minangka hype, lan spesialis ing babagan iki regane mayuta-yuta. Saiki biaya saya mudhun, pasar dadi jenuh, lan ana tren sing padha ing layanan mikro.
Sergey:
Ya, pancen.
Alexander:
HR takon pitakonan: "Endi unicorn pink ing antarane mburi lan frontend?" HR ora ngerti apa microservice. We marang wong-wong mau rahasia lan marang wong-wong mau sing backend nindakake kabeh, lan ora ana unicorn. Nanging HR saya ganti, sinau kanthi cepet lan rekrut wong sing duwe kawruh IT dhasar.
Evolusi microservices
Dmitriy:
Yen sampeyan ndeleng arsitektur target, layanan mikro katon kaya monster. Perjalanan sampeyan njupuk sawetara taun. Liyane duwe setahun, liyane telung taun. Apa sampeyan ndeleng kabeh masalah, arsitektur target, apa ana owah-owahan? Contone, ing kasus microservices, gateways lan meshes layanan saiki katon maneh. Apa sampeyan nggunakake ing wiwitan utawa sampeyan ngganti arsitektur dhewe? Apa sampeyan duwe tantangan kaya ngono?
Sergey:
Kita wis nulis maneh sawetara protokol komunikasi. Ing wiwitan ana siji protokol, saiki kita ngalih menyang liyane. Kita nambah safety lan linuwih. Kita miwiti karo teknologi perusahaan - Oracle, Web Logic. Saiki kita pindhah adoh saka produk perusahaan teknologi ing layanan mikro lan pindhah menyang teknologi open source utawa rampung mbukak. Kita ninggalake database lan pindhah menyang apa sing luwih efektif kanggo kita ing model iki. Kita ora butuh teknologi Oracle maneh.
Kita miwiti mung minangka layanan, tanpa mikir babagan apa sing dibutuhake cache, apa sing bakal ditindakake nalika ora ana sambungan karo microservice, nanging data dibutuhake, lan liya-liyane. Saiki kita ngembangake platform supaya arsitektur bisa diterangake. ora ing basa layanan, lan ing basa bisnis, njupuk logika bisnis kanggo tingkat sabanjuré nalika kita miwiti ngomong ing tembung. Saiki kita wis sinau nganggo huruf, lan tingkat sabanjure yaiku nalika layanan bakal diklumpukake dadi sawetara jinis agregat, nalika iki wis dadi tembung - contone, kertu produk kabeh. Iki dirakit saka microservices, nanging iku API dibangun ing ndhuwur iki.
Safety penting banget. Sanalika sampeyan miwiti bisa diakses lan sampeyan duwe layanan liwat kang sampeyan bisa njaluk akèh iku menarik, lan cepet banget, ing pamisah detik, banjur ana kepinginan kanggo njaluk iku ing cara sing ora paling aman. Kanggo nyingkiri iki, kita kudu ngganti pendekatan kanggo nguji lan ngawasi. Kita kudu ngganti tim, struktur manajemen pangiriman, CI / CD.
Iki minangka evolusi - kaya karo telpon, mung luwih cepet: pisanan ana telpon tombol push, banjur smartphone muncul. Dheweke nulis ulang lan ngrancang maneh produk kasebut amarga pasar duwe kabutuhan sing beda. Iki carane kita berkembang: kelas siji, kelas sepuluh, karya.
Secara iteratif, ana sing ditata saben taun saka sudut pandang teknologi, liyane saka sudut pandang backlog lan kabutuhan. Kita nyambungake siji bab liyane. Tim mbuwang 20% kanggo utang teknis lan dhukungan teknis kanggo tim, 80% kanggo entitas bisnis. Lan kita pindhah kanthi pangerten kenapa kita nindakake, kenapa kita nggawe dandan teknologi kasebut, apa sing bakal ditindakake. Koyo kui.
Dmitriy:
Kelangan. Apa sing ana ing MegaFon?
Alexander:
Tantangan utama nalika kita teka ing microservices ora tiba ing lam. Kantor arsitektur MegaFon langsung gabung karo kita, malah dadi inisiator lan pembalap - saiki kita duwe arsitektur sing kuwat banget. Tugase yaiku ngerti model target apa sing bakal ditindakake lan teknologi apa sing kudu dicoba. Kanthi arsitektur, kita nindakake pilot kasebut dhewe.
Pitakonan sabanjure yaiku: "Banjur kepiye ngeksploitasi kabeh iki?" Lan siji liyane: "Kepiye njamin interaksi transparan ing antarane layanan mikro?" Service bolong mbantu kita njawab pitakonan pungkasan. We pilot Istio lan disenengi asil. Saiki kita ana ing tahap nggulung menyang zona produktif. Kita duwe sikap positif marang kabeh tantangan - kasunyatan manawa kita kudu terus-terusan ngganti tumpukan, sinau sing anyar. Kita kasengsem ngembangake, ora ngeksploitasi solusi lawas.
Dmitriy:
Tembung emas! Tantangan kasebut njaga tim lan bisnis ing driji sikil lan nggawe masa depan. GDPR nggawe kepala pejabat perlindungan data, lan tantangan saiki nggawe kepala microservices lan pejabat arsitektur. Lan iku pleases.
We rembugan kathah. Sing utama yaiku desain layanan mikro sing apik lan arsitektur dhewe ngidini sampeyan ngindhari akeh kesalahan. Mesthine, proses kasebut minangka iteratif lan evolusi, nanging iku masa depan.
Thanks kanggo kabeh peserta, thanks kanggo Sergei lan Alexander!
Pitakonan saka pamirsa
Pitakonan saka pamirsa (1):
Sergey, kepiye manajemen IT diganti ing perusahaan sampeyan? Aku ngerti yen ana tumpukan gedhe saka sawetara sistem, carane ngatur iku proses cukup cetha lan logis. Kepiye carane sampeyan mbangun maneh manajemen komponen IT sawise akeh microservices digabungake ing wektu sing cendhak?
Sergey:
Aku setuju karo kolega sing arsitektur penting banget minangka pembalap saka owah-owahan. Kita miwiti kanthi nduwe divisi arsitektur. Arsitek bebarengan karo pamilik distribusi fungsi lan syarat carane bakal katon ing lanskap. Dadi dheweke uga dadi koordinator owah-owahan kasebut. Akibaté, ana owah-owahan tartamtu kanggo proses pangiriman tartamtu nalika kita nggawe platform CI / CD.
Nanging standar, prinsip dhasar pangembangan, analisis bisnis, tes lan pangembangan durung dibatalake. Kita mung nambah kacepetan. Sadurunge, siklus njupuk akeh banget, instalasi ing lingkungan test njupuk luwih akeh. Saiki bisnis ndeleng entuk manfaat lan ujar: "Napa kita ora bisa nindakake perkara sing padha ing papan liya?"
Kaya, kanthi cara sing apik, injeksi ing bentuk vaksin sing nuduhake: sampeyan bisa nindakake kanthi cara iki, nanging sampeyan bisa nindakake kanthi cara liya. Mesthi, ana masalah ing personel, ing kompetensi, ing kawruh, ing resistance.
Pitakonan saka pamirsa (2):
Kritikus arsitektur microservice ujar manawa tes lan pangembangan angel. Iki logis nalika kedadeyan dadi rumit. Tantangan apa sing diadhepi tim sampeyan lan kepiye carane sampeyan ngatasi? Pitakonan kanggo kabeh wong.
Alexander:
Ana kangelan nalika pindhah saka microservices kanggo platform, nanging padha bisa ditanggulangi.
Contone, kita nggawe produk sing kasusun saka 5-7 microservices. Kita kudu menehi tes integrasi ing kabeh tumpukan microservices kanggo menehi lampu ijo kanggo pindhah menyang cabang master. Tugas iki ora anyar kanggo kita: kita wis nindakake iki kanggo wektu sing suwe ing BSS, nalika vendor nyedhiyakake solusi sing wis dikirim.
Lan masalah kita mung ing tim cilik. Siji insinyur QA dibutuhake kanggo siji produk bersyarat. Dadi, kita ngirim produk saka 5-7 layanan mikro, sing 2-3 bisa dikembangake dening pihak katelu. Contone, kita duwe produk ing pangembangan sing vendor sistem tagihan kita, Mail.ru Group lan MegaFon R&D melu. Kita kudu nutupi iki kanthi tes sadurunge dikirim menyang produksi. Insinyur QA wis nggarap produk iki sajrone setengah wulan, lan tim liyane ora ana dhukungan.
Kerumitan iki mung disebabake dening skala. Kita ngerti manawa layanan mikro ora bisa ana ing vakum; ora ana isolasi mutlak. Nalika ngganti siji layanan, kita tansah nyoba kanggo njaga kontrak API. Yen ana owah-owahan ing hood, layanan ngarep tetep. Yen owah-owahan iku fatal, sawetara jinis transformasi arsitektur njupuk Panggonan lan kita pindhah menyang metamodel data temen beda, kang rampung kompatibel - mung banjur kita pirembagan bab specification API layanan v2 katon. Kita ndhukung versi pisanan lan kaloro bebarengan, lan sawise kabeh konsumen pindhah menyang versi kaloro, kita mung nutup sing pisanan.
Sergey:
Aku pengin nambah. Aku pancen setuju babagan komplikasi - kedadeyan. Lanskap dadi luwih rumit, lan biaya overhead mundhak, utamane kanggo tes. Carane menehi hasil karo iki: ngalih menyang testing otomatis. Ya, sampeyan kudu nandur modal tambahan kanggo nulis tes otomatis lan tes unit. Supaya pangembang ora bisa nindakake tanpa lulus tes, dheweke ora bisa ngganti kode kasebut. Supaya malah tombol push ora bisa tanpa autotest, unit test.
Penting kanggo njaga fungsi sadurungé, lan iki nduwur sirah tambahan. Yen sampeyan nulis ulang teknologi menyang protokol liyane, banjur tulis maneh nganti sampeyan nutup kabeh.
Kadhangkala kita ora nindakake tes end-to-end kanthi tujuan, amarga kita ora pengin mungkasi pembangunan, sanajan kita uga duwe siji-sijine. Lanskap iku gedhe banget, kompleks, ana akeh sistem. Kadhangkala mung rintisan - ya, sampeyan nyuda wates safety, luwih akeh risiko katon. Nanging ing wektu sing padha sampeyan ngeculake pasokan.
Alexander:
Ya, tes otomatis lan tes unit ngidini sampeyan nggawe layanan sing berkualitas. We are kanggo pipa sing ora bisa dilewati tanpa tes unit lan integrasi. Kita asring kudu nyeret emulator lan sistem komersial menyang zona test lan lingkungan pangembangan, amarga ora kabeh sistem bisa diselehake ing zona test. Kajaba iku, dheweke ora mung udan - kita ngasilake respon lengkap saka sistem kasebut. Iki minangka bagean serius kanggo nggarap layanan mikro, lan kita uga nandur modal. Tanpa iki, kekacauan bakal kedadeyan.
Pitakonan saka pamirsa (3):
Sa adoh aku ngerti, microservices wiwitane tuwuh saka tim sing kapisah lan saiki ana ing model iki. Apa sing pro lan cons?
Kita mung duwe crita sing padha: ana jinis pabrik microservice. Saiki kita wis konseptual tekan titik sing kita ndawakake pendekatan iki kanggo produksi dening lepen lan dening sistem. Ing tembung liyane, kita wis pindhah adoh saka pangembangan terpusat microservices, model microservice, lan dadi nyedhaki sistem.
Mulane, operasi kita uga menyang sistem, yaiku, kita desentralisasi topik iki. Apa pendekatan sampeyan lan apa crita target sampeyan?
Alexander:
Sampeyan ngilangi jeneng "pabrik layanan mikro" langsung saka tutuk - kita uga pengin skala. Kaping pisanan, saiki kita duwe tim siji. Kita pengin nyedhiyakake kabeh tim pangembangan sing MegaFon duwe kesempatan kanggo bisa kerja ing ekosistem umum. Kita ora pengin ngrampungake kabeh fungsi pangembangan sing saiki ana. Tugas lokal yaiku skala, tugas global yaiku mimpin pangembangan kabeh tim ing lapisan microservice.
Sergey:
Aku bakal ngandhani sampeyan dalan sing wis ditindakake. Kita pancene wiwit kerja minangka siji tim, nanging saiki kita ora piyambak. Aku minangka panyengkuyung ing ngisor iki: kudu ana sing duwe proses. Ana sing kudu ngerti, ngatur, ngontrol lan mbangun proses pangembangan microservice. Dheweke kudu duwe sumber daya lan melu manajemen sumber daya.
Sumber daya kasebut, sing ngerti teknologi, spesifik lan ngerti carane nggawe layanan mikro, bisa ditemokake ing tim produk. Kita duwe campuran ing ngendi wong saka platform microservice ana ing tim produk sing nggawe aplikasi seluler. Dheweke ana, nanging kerjane miturut proses departemen manajemen platform microservice karo manajer pangembangane. Ing divisi iki ana tim kapisah sing ngurusi teknologi. Yaiku, kita nyampurake sumber daya umum ing antarane awake dhewe lan dibagi, menehi menyang tim.
Ing wektu sing padha, proses kasebut tetep umum, dikontrol, diterusake miturut prinsip teknologi umum, kanthi tes unit lan liya-liyane - kabeh sing dibangun ing ndhuwur. Bisa uga ana kolom ing wangun sumber daya sing diklumpukake saka macem-macem departemen pendekatan produk.
Alexander:
Sergey, sampeyan sejatine pemilik proses kasebut, ta? Apa backlog tugas dibagi? Sapa sing tanggung jawab kanggo distribusi kasebut?
Sergey:
Deleng: iki campuran maneh. Ana backlog sing dibentuk adhedhasar dandan teknologi - iki minangka salah sawijining crita. Ana backlog, sing dirumusake saka proyek, lan ana backlog saka produk. Nanging urutan introduksi menyang saben produk layanan utawa nggawe layanan iki dikembangake dening spesialis produk. Dheweke ora ana ing direktorat IT; dheweke dicopot khusus. Nanging wong-wongku mesthi makarya miturut proses sing padha.
Pemilik backlog ing arah sing beda - backlog saka owah-owahan - bakal dadi wong sing beda. Sambungan layanan teknologi, prinsip pangaturan - kabeh iki bakal ana ing IT. Aku uga duwe platform lan sumber daya. Ing sisih ndhuwur yaiku babagan backlog lan owah-owahan fungsional, lan arsitektur ing pangertèn iki.
Contone, bisnis ujar: "Kita pengin fungsi iki, kita pengin nggawe produk anyar - remake a loan." Kita mangsuli: "Ya, kita bakal nggawe maneh." Arsitek ujar: "Ayo dipikirake: ing endi utang bakal nulis microservices lan kepiye carane?" Banjur dipecah dadi proyek, produk utawa tumpukan teknologi, dilebokake menyang tim lan dileksanakake. Apa sampeyan wis nggawe produk internal lan mutusake nggunakake layanan mikro ing produk iki? Kita ujar: "Saiki sistem warisan sing kita duwe, utawa sistem garis ngarep, kudu ngalih menyang layanan mikro iki." Arsitek ujar: "Dadi: ing backlog teknologi ing produk ngarep - transisi menyang layanan mikro. Tindak". Lan spesialis produk utawa pamilik bisnis ngerti kepiye kapasitas sing diwenehake, kapan bakal ditindakake lan kenapa.
Mungkasi diskusi, nanging ora kabeh
Konferensi mailto:CLOUD diatur .
Kita uga nindakake acara liyane - f.eks. @Kubernetes Meetup, ing ngendi kita tansah nggoleki pamicara sing apik:
- Tindakake @Kubernetes lan warta @Meetup liyane ing saluran Telegram kita
- Tertarik ngomong ing salah sawijining @Meetups? Ninggalake panjalukan kanggo
Source: www.habr.com