Napa perusahaan kaya MegaFon mbutuhake Tarantool ing tagihane? Saka njaba misale jek sing vendor biasane teka, ndadekke sawetara jenis kothak gedhe, plug plug menyang soket - lan iku tagihan! Biyen ya ngono, nanging saiki wis kuna, lan dinosaurus kuwi wis punah utawa wis punah. Kaping pisanan, tagihan minangka sistem kanggo nerbitake invoice - mesin hitung utawa kalkulator. Ing telekomunikasi modern, iki sistem otomatisasi kanggo kabeh siklus urip interaksi karo pelanggan saka kesimpulan saka kontrak kanggo mandap, kalebu tagihan nyata-wektu, acceptance pembayaran lan akeh liyane. Tagihan ing perusahaan telekomunikasi kaya robot tempur - gedhe, kuat lan diisi gaman.
Apa hubungane Tarantool? Dheweke bakal ngomong babagan iki Oleg Ivlev и Andrey Knyazev. Oleg minangka arsitek utama perusahaan kasebut Kanthi pengalaman ekstensif ing perusahaan manca, Andrey minangka direktur sistem bisnis. Saka transkrip laporan ing sampeyan bakal ngerti sebabe R&D dibutuhake ing perusahaan, apa Tarantool, kepiye impasse skala vertikal lan globalisasi dadi prasyarat kanggo tampilan database iki ing perusahaan, babagan tantangan teknologi, transformasi arsitektur, lan kepiye technostack MegaFon padha karo Netflix. , Google lan Amazon.
Proyek "Tagihan Terpadu"
Proyek sing bakal dibahas diarani "Tagihan Terpadu". Ing kene Tarantool nuduhake kualitas sing paling apik.
Wutah produktivitas peralatan Hi-End ora selaras karo pertumbuhan basis pelanggan lan wutah ing jumlah layanan; wutah luwih akeh ing jumlah pelanggan lan layanan wis samesthine amarga M2M, IoT, lan fitur cabang dipimpin. menyang rusak ing wektu-kanggo-pasar. Perusahaan mutusake kanggo nggawe sistem bisnis terpadu kanthi arsitektur modular kelas donya sing unik, tinimbang 8 sistem tagihan sing beda saiki.
MegaFon minangka wolung perusahaan ing siji. Ing taun 2009, reorganisasi rampung: cabang ing saindhenging Rusia digabung dadi siji perusahaan, MegaFon OJSC (saiki PJSC). Mangkono, perusahaan duwe sistem tagihan 8 kanthi solusi "adat" dhewe, fitur cabang lan struktur organisasi sing beda, IT lan marketing.
Kabeh apik nganti kita kudu miwiti produk federal umum. Akeh kangelan wis muncul ing kene: sawetara duwe tarif dibunderaké, sawetara dibunderaké mudhun, lan sawetara adhedhasar rata-rata aritmetika. Ana ewonan wektu kuwi.
Senadyan kasunyatan sing ana mung siji versi sistem tagihan, siji supplier, setelan padha beda banget sing njupuk wektu dawa kanggo sijine bebarengan. Kita nyoba kanggo nyuda nomer, lan teka tengen masalah kapindho sing menowo kanggo akeh perusahaan.
Skala vertikal. Malah hardware paling keren ing wektu iku ora nyukupi kabutuhan. Karya kasebut nggunakake peralatan Hewlett-Packard saka garis Superdome Hi-End, nanging ora nyukupi kabutuhan loro cabang. Aku pengin skala horisontal tanpa biaya operasi gedhe lan investasi modal.
Pangarepan wutah ing jumlah pelanggan lan layanan. Konsultan wis suwe nggawa crita babagan IoT lan M2M menyang jagad telekomunikasi: bakal teka nalika saben telpon lan wesi duwe kertu SIM, lan saben kulkas bakal duwe loro. Dina iki jumlah pelanggan sing padha, nanging ing mangsa ngarep bakal luwih akeh.
Tantangan teknologi
Papat alasan iki dadi motivasi kanggo nggawe owah-owahan sing serius. Ana pilihan antarane nganyarke sistem lan ngrancang saka ngeruk. Kita mikir suwe, nggawe keputusan serius, main tender. Akibaté, kita mutusaké kanggo ngrancang saka awal, lan njupuk tantangan menarik - tantangan teknologi.
Skalabilitas
Yen sadurunge, ayo ngomong, ayo ngomong 8 tagihan kanggo 15 yuta pelanggan, lan saiki kudu bisa 100 yuta pelanggan lan liyane - beban kasebut minangka urutan gedhene sing luwih dhuwur.
Kita wis bisa dibandhingake karo pemain Internet gedhe kaya Mail.ru utawa Netflix.
Nanging gerakan luwih akeh kanggo nambah beban lan basis pelanggan wis nggawe tantangan serius kanggo kita.
Geografi negara kita sing jembar
Antarane Kaliningrad lan Vladivostok 7500 km lan 10 zona wektu. Kacepetan cahya iku winates lan ing jarak kuwi wektu tundha wis pinunjul. 150 ms ing saluran optik modern sing paling keren rada akeh kanggo tagihan wektu nyata, utamane amarga saiki ana ing telekomunikasi ing Rusia. Kajaba iku, sampeyan kudu nganyari ing siji dina bisnis, lan karo zona wektu beda iki masalah.
Kita ora mung nyedhiyakake layanan kanthi biaya langganan, kita duwe tarif kompleks, paket, lan macem-macem modifikasi. Kita kudu ora mung ngidini utawa nolak pelanggan kanggo ngomong, nanging menehi kuota tartamtu - count telpon lan tumindak ing wektu nyata supaya ora sok dong mirsani.
toleransi kesalahan
Iki minangka sisih liya saka sentralisasi.
Yen kita ngumpulake kabeh pelanggan ing siji sistem, acara darurat lan bencana bakal mbebayani kanggo bisnis. Mula, kita ngrancang sistem kasebut kanthi cara kanggo ngilangi dampak kacilakan ing kabeh basis pelanggan.
Iki maneh akibat saka penolakan kanggo skala vertikal. Nalika kita skala horisontal, kita nambah nomer server saka atusan kanggo ewu. Dheweke kudu dikelola lan bisa diganti, kanthi otomatis nggawe serep infrastruktur IT lan dibalekake menyang sistem sing disebarake.
Kita ngadhepi tantangan sing menarik. Kita ngrancang sistem kasebut, lan nalika iku kita nyoba golek praktik paling apik global kanggo mriksa kepiye tren kita, sepira kita ngetutake teknologi canggih.
Pengalaman donya
Kaget, kita durung nemokake referensi siji ing telekomunikasi global.
Eropah wis ambruk ing babagan jumlah pelanggan lan skala, Amerika Serikat wis ambruk ing babagan flatness tarif. Kita ndeleng sawetara perkara ing China, lan nemokake sawetara perkara ing India lan nyewa spesialis saka Vodafone India.
Kanggo nganalisa arsitektur, kita nglumpuk Dream Team dipimpin déning IBM-arsitek saka macem-macem lapangan. Wong-wong iki bisa ngevaluasi kanthi cekap apa sing kita lakoni lan nggawa kawruh tartamtu kanggo arsitektur kita.
Skala
A sawetara nomer kanggo ilustrasi.
We ngrancang sistem kanggo 80 yuta pelanggan kanthi cadangan milyar. Iki carane kita mbusak batesan ing mangsa ngarep. Iki ora amarga kita bakal njupuk alih China, nanging amarga serangan IoT lan M2M.
300 yuta dokumen diproses ing wektu nyata. Senajan kita duwe 80 yuta pelanggan, kita bisa karo loro klien potensial lan sing wis ninggalake kita yen kita perlu kanggo ngumpulake receivables. Mulane, volume nyata luwih gedhe.
2 milyar transaksi Imbangan ganti saben dina amarga pembayaran, biaya, telpon lan acara liyane. 200 TB data aktif ganti, owah-owahan rada alon 8 PB data, lan iki ora arsip, nanging data urip ing tagihan siji. Skala miturut pusat data - 5 ewu server ing 14 situs.
Teknologi tumpukan
Nalika kita ngrancang arsitektur lan miwiti ngrakit sistem, kita ngimpor teknologi paling menarik lan majeng. Asil kasebut minangka tumpukan teknologi sing akrab karo pemain lan perusahaan Internet sing nggawe sistem beban dhuwur.
Tumpukan kasebut padha karo tumpukan pemain utama liyane: Netflix, Twitter, Viber. Iku kasusun saka 6 komponen, nanging kita arep kanggo shorten lan nyawiji.
Fleksibilitas apik, nanging ing perusahaan gedhe ora ana cara tanpa manunggal.
Kita ora bakal ngganti Oracle sing padha karo Tarantool. Ing kasunyatan perusahaan gedhe, iki minangka utopia, utawa perang salib kanggo 5-10 taun kanthi asil sing ora jelas. Nanging Cassandra lan Couchbase bisa gampang diganti dening Tarantool, lan apa kita ngupayakake.
Kenapa Tarantool?
Ana 4 kritéria prasaja kok kita milih database iki.
Kacepetan. Kita nganakake tes beban ing sistem industri MegaFon. Tarantool menang amarga nuduhake kinerja sing paling apik.
Iki ora ateges sistem liyane ora nyukupi kabutuhan MegaFon. Solusi memori saiki kuat banget yen cadangan perusahaan luwih saka cukup. Nanging kita kasengsem ing dealing with pimpinan, lan ora karo wong sing mburi mburi, kalebu ing test kaku.
Tarantool nyakup kabutuhan perusahaan sanajan ing jangka panjang.
biaya TCO. Ndhukung Couchbase ing volume MegaFon biaya rejeki, nanging karo Tarantool kahanan luwih becik, lan padha ing fungsi.
Fitur apik liyane sing rada dipengaruhi pilihan kita yaiku Tarantool luwih apik karo memori tinimbang database liyane. Dheweke nuduhake efisiensi maksimum.
Linuwih. MegaFon nandur modal ing linuwih, mbokmenawa ora kaya liyane. Mulane, nalika kita ndeleng Tarantool, kita nyadari yen kita kudu nyukupi syarat kita.
Kita nandur modal wektu lan keuangan, lan bebarengan karo Mail.ru kita nggawe versi perusahaan, sing saiki digunakake ing sawetara perusahaan liyane.
Tarantool-enterprise rampung marem kita babagan keamanan, linuwih, lan logging.
Kemitraan
Sing paling penting kanggo aku yaiku kontak langsung karo pangembang. Iki persis apa wong lanang saka Tarantool tuku kula karo.
Yen sampeyan teka menyang pemain, utamané sing dianggo karo klien anchor, lan ngandika yen sampeyan kudu database kanggo bisa nindakake iki, iki lan iki, kang biasane njawab:
- Oke, lebokake syarat ing ngisor tumpukan kasebut - ing sawijining dina, mesthine kita bakal entuk.
Akeh wong duwe roadmap kanggo sabanjuré 2-3 taun, lan iku meh mokal kanggo nggabungake ana, nanging pangembang Tarantool captivate karo openness, lan ora mung karo MegaFon, lan ngganti sistem kanggo customer. Kelangan lan kita seneng banget.
Where kita digunakake Tarantool
Kita nggunakake Tarantool ing sawetara unsur. Sing pisanan ana ing pilot., sing digawe ing sistem direktori alamat. Ing sawijining wektu, aku pengin dadi sistem sing padha karo Yandex.Maps lan Google Maps, nanging ternyata rada beda.
Contone, katalog alamat ing antarmuka dodolan. Ing Oracle, nggoleki alamat sing dikarepake butuh 12-13 detik. - nomer ora nyaman. Nalika kita ngalih menyang Tarantool, ngganti Oracle karo database liyane ing console, lan nindakake search padha, kita njaluk speedup 200-melu! Kutha njedhul munggah sawise huruf katelu. Saiki kita adaptasi antarmuka supaya iki kedadeyan sawise sing pisanan. Nanging, kacepetan respon temen beda - saiki milliseconds tinimbang detik.
Aplikasi kaloro yaiku tema trendi sing diarani IT loro-kacepetan. Iki amarga konsultan saka saben pojok ujar manawa perusahaan kudu mlebu.
Ana lapisan infrastruktur, ing ndhuwur ana domain, contone, sistem tagihan kaya telekomunikasi, sistem perusahaan, laporan perusahaan. Iki minangka inti sing ora kena didemek. Sing, mesthi, iku bisa, nanging paranoidly njamin kualitas, amarga ndadekke dhuwit kanggo perusahaan.
Sabanjure ana lapisan microservices, sing mbedakake operator utawa pemain liyane. Layanan mikro bisa digawe kanthi cepet adhedhasar cache tartamtu, nggawa data saka macem-macem domain ing kana. kene lapangan kanggo eksperimen - yen ana sing ora bisa ditindakake, aku nutup layanan mikro lan mbukak liyane. Iki nyedhiyakake wektu sing luwih apik kanggo pasar lan nambah linuwih lan kacepetan perusahaan.
Microservices mbok menawa peran utama Tarantool ing MegaFon.
Where kita rencana nggunakake Tarantool
Yen kita mbandhingake proyek tagihan sing sukses karo program transformasi ing Deutsche Telekom, Svyazcom, Vodafone India, pancen dinamis lan kreatif. Ing proses ngleksanakake proyek iki, ora mung MegaFon lan strukture sing diowahi, nanging uga Tarantool-enterprise muncul ing Mail.ru, lan vendor Nexign (sadurunge Peter-Service) - BSS Box (solusi tagihan kotak).
Iki, ing pangertèn, proyek sajarah kanggo pasar Rusia. Iki bisa dibandhingake karo apa sing diterangake ing buku Frederick Brooks The Mythical Man-Month. Nalika iku, ing taun 60-an, IBM nyewa 360 wong kanggo ngembangake sistem operasi OS/5 anyar kanggo mainframe. Kita duwe kurang - 000, nanging kita ana ing rompi, lan njupuk menyang akun nggunakake open source lan pendekatan anyar, kita bisa luwih produktif.
Ing ngisor iki minangka domain tagihan utawa, luwih umum, sistem bisnis. Wong perusahaan ngerti CRM banget. Saben uwong kudu duwe sistem liyane: Open API, API Gateway.
Buka API
Ayo ndeleng nomer maneh lan kepiye Open API saiki bisa digunakake. Bebane yaiku 10 transaksi per detik. Awit kita rencana kanggo aktif ngembangaken lapisan microservices lan mbangun MegaFon API umum, kita ngarepake wutah luwih ing mangsa ing bagean iki. Mesthi bakal ana 100 transaksi.
Aku ora ngerti yen SSO iso dibandhingke karo Mail.ru-wong lanang koyone duwe 1 transaksi per detik. Kita kasengsem banget karo solusi kasebut lan kita rencana nggunakake pengalamane - contone, nggawe serep SSO fungsional nggunakake Tarantool. Saiki pangembang saka Mail.ru nindakake iki karo kita.
CRM
CRM padha karo 80 yuta pelanggan sing pengin kita tekan milyar, amarga wis ana 300 yuta dokumen sing kalebu sejarah telung taun. We are tenan looking nerusake kanggo layanan anyar lan kene titik wutah layanan disambungake. Iki minangka bal sing bakal tuwuh amarga bakal luwih akeh layanan. Dadi, kita butuh crita; kita ora pengin kesandhung babagan iki.
Tagihan dhewe babagan nerbitake invoice lan nggarap piutang pelanggan diowahi dadi domain sing kapisah. Kanggo nambah kinerja, pola arsitektur arsitektur domain sing diterapake.
Sistem iki dipérang dadi domain, mbukak disebarake lan toleransi fault wis mesthekake. Kajaba iku, kita nggarap arsitektur sing disebarake.
Kabeh liyane minangka solusi tingkat perusahaan. Ing panyimpenan telpon - 2 milyar saben dina, 60 milyar saben sasi. Kadhangkala sampeyan kudu ngetung ing sasi, lan luwih apik kanggo nindakake kanthi cepet. Pemantauan finansial - iki persis padha 300 yuta sing terus berkembang lan akeh: pelanggan asring mbukak antarane operator, nambah bagean iki.
Komponen telekomunikasi komunikasi seluler sing paling akeh yaiku tagihan online. Iki minangka sistem sing ngidini sampeyan nelpon utawa ora nelpon, nggawe keputusan kanthi nyata. Ing kene beban yaiku 30 transaksi per detik, nanging kanthi nganggep pertumbuhan transfer data, kita rencana 250 transaksi, lan mula kita kasengsem banget karo Tarantool.
Gambar sadurunge nuduhake domain ing ngendi kita bakal nggunakake Tarantool. CRM dhewe, mesthi, luwih jembar lan kita bakal nggunakake ing inti dhewe.
Angka TTX kira-kira 100 yuta pelanggan mbingungake aku minangka arsitek - kepiye yen 101 yuta? Apa sampeyan kudu mbaleni kabeh maneh? Kanggo nyegah kedadeyan kasebut, kita nggunakake cache, ing wektu sing padha nambah kasedhiyan.
Umumé, ana rong pendekatan kanggo nggunakake Tarantool. pisanan- mbangun kabeh cache ing tingkat microservice. Sa adoh aku ngerti, VimpelCom ngetutake dalan iki, nggawe cache klien.
Kita kurang gumantung ing vendor, kita ngganti inti BSS, supaya kita duwe file klien siji metu saka kothak. Nanging kita pengin nggedhekake. Mulane, kita njupuk pendekatan sing rada beda - nggawe caches nang sistem.
Kanthi cara iki ana kurang desynchronization - siji sistem tanggung jawab kanggo loro cache lan sumber master utama.
Cara kasebut cocog karo pendekatan Tarantool kanthi kerangka transaksional, nalika mung bagean sing ana hubungane karo nganyari, yaiku, owah-owahan data, dianyari. Kabeh liyane bisa disimpen ing papan liya. Ora ana tlaga data sing gedhe, cache global sing ora dikelola. Cache dirancang kanggo sistem, utawa kanggo produk, utawa kanggo klien, utawa kanggo nggawe urip luwih gampang kanggo pangopènan. Nalika pelanggan nelpon lan duka babagan kualitas layanan, sampeyan pengin nyedhiyakake layanan sing berkualitas.
RTO lan RPO
Ana rong istilah ing IT: OTR и RPO.
Tujuan wektu pemulihan yaiku wektu sing dibutuhake kanggo mulihake layanan sawise gagal. RTO = 0 tegese sanajan ana sing gagal, layanan kasebut tetep bisa digunakake.
Tujuan titik pemulihan - iki wektu Recovery data, carane akeh data kita bisa ilang liwat wektu tartamtu. RPO = 0 tegese kita ora kelangan data.
Tugas Tarantool
Ayo dadi nyoba kanggo ngatasi masalah kanggo Tarantool.
diwenehi: basket saka panjalukan sing everyone mangerténi, contone, ing Amazon utawa nang endi wae liya. Dipun supaya kréta blanja bisa digunakake 24 jam 7 dina seminggu, utawa 99,99% wektu. Pesenan sing teka kudu tetep, amarga kita ora bisa ngaktifake utawa mateni sambungan pelanggan kanthi acak - kabeh kudu konsisten. Langganan sadurunge mengaruhi sing sabanjure, mula data kasebut penting - ora ana sing ilang.
kaputusan. Sampeyan bisa nyoba ngatasi masalah kasebut lan takon marang pangembang database, nanging masalah kasebut ora bisa ditanggulangi kanthi matematis. Sampeyan bisa ngelingi teorema, hukum konservasi, fisika kuantum, nanging kok - ora bisa ditanggulangi ing tingkat DB.
Pendekatan arsitektur lawas sing apik dianggo ing kene - sampeyan kudu ngerti wilayah subyek kanthi apik lan, kanthi biaya, ngrampungake teka-teki iki.
Solusi kita: nggawe registri aplikasi sing disebarake kanggo Tarantool - kluster sing disebarake geo. Ing diagram kasebut, ana telung pusat pangolahan data sing beda - loro sadurunge Urals, siji ngluwihi Urals, lan kita nyebarake kabeh panjalukan menyang pusat kasebut.
Netflix, sing saiki dianggep minangka salah sawijining pimpinan ing IT, nganti 2012 mung duwe siji pusat data. Ing wengi Natal Katulik, 24 Desember, pusat data iki mudhun. Pangguna ing Kanada lan Amerika Serikat ditinggal tanpa film favorit, banget duka lan nulis babagan kasebut ing jaringan sosial. Netflix saiki duwe telung pusat data ing pesisir kulon-wétan lan siji ing Eropah kulon.
Kaping pisanan, kita mbangun solusi sing disebarake geo - toleransi kesalahan penting kanggo kita.
Dadi, kita duwe kluster, nanging babagan RPO = 0 lan RTO = 0? Solusi iku prasaja, gumantung ing subyek.
Apa sing penting ing aplikasi? Rong Bagean: Basket Throwing TO nggawe keputusan tuku, lan NULIS. Bagian DO ing telekomunikasi biasane diarani njupuk pesenan utawa rembugan pesenan. Ing telekomunikasi, iki bisa dadi luwih angel tinimbang ing toko online, amarga ana klien kudu dilayani, ditawakake 5 opsi, lan kabeh iki kedadeyan kanggo sawetara wektu, nanging kranjang wis diisi. Ing wektu iki, kegagalan bisa, nanging ora medeni amarga kedadeyan sacara interaktif ing pengawasan manungsa.
Yen pusat data Moskow tiba-tiba gagal, banjur kanthi otomatis ngalih menyang pusat data liyane, kita bakal terus kerja. Secara teoritis, siji produk bisa uga ilang ing kranjang, nanging sampeyan ndeleng iki, tambahake menyang kranjang maneh lan terus kerja. Ing kasus iki, RTO = 0.
Ing wektu sing padha, ana pilihan liya: nalika kita ngeklik "kirim", kita pengin data ora ilang. Saka wayahe, automation wiwit bisa - iki RPO = 0. Panggunaan loro pola beda ing siji cilik bisa mung klompok geo-mbagekke karo siji master switchable, ing kasus liyane sawetara jinis rekaman kuorum. Pola bisa beda-beda, nanging kita ngatasi masalah kasebut.
Salajengipun, gadhah registri aplikasi sing disebarake, kita uga bisa ngukur kabeh - duwe akeh dispatcher lan eksekutor sing ngakses pendaptaran iki.
Cassandra lan Tarantool bebarengan
Ana kasus liyane - "pameran saldo". Iki minangka kasus sing menarik babagan panggunaan gabungan Cassandra lan Tarantool.
Kita nggunakake Cassandra amarga 2 milyar telpon saben dina ora watesan, lan bakal ana liyane. Pemasar seneng menehi warna lalu lintas kanthi sumber; umpamane, luwih akeh rincian katon ing jaringan sosial. Kabeh mau nambahi crita.
Cassandra ngidini sampeyan nggawe skala horisontal kanggo ukuran apa wae.
Kita rumangsa kepenak karo Cassandra, nanging dheweke duwe masalah - dheweke ora pinter maca. Kabeh OK ing rekaman, 30 per detik ora masalah. masalah maca.
Mulane, topik karo cache muncul, lan ing wektu sing padha, kita ngrampungake masalah ing ngisor iki: ana kasus tradisional lawas nalika peralatan saka switch saka tagihan online teka menyang file sing dimuat menyang Cassandra. Kita berjuang karo masalah download file sing dipercaya, sanajan nggunakake saran saka transfer file manajer IBM - ana solusi sing ngatur transfer file kanthi efisien nggunakake protokol UDP, contone, tinimbang TCP. Iki apik, nanging isih sawetara menit, lan nganti kita ndownload kabeh, operator ing call center ora bisa njawab klien apa kedaden kanggo imbangan - kita kudu ngenteni.
Kanggo nyegah kedadeyan kasebut, kita kita nggunakake cadangan fungsi paralel. Nalika kita ngirim acara liwat Kafka kanggo Tarantool, ngetung agregat ing wektu nyata, contone, kanggo dina iki, kita nampa saldo kas, sing bisa nransfer saldo ing sembarang kacepetan, contone, 100 ewu transaksi per detik lan sing padha 2 detik.
Tujuane yaiku sawise nelpon, sajrone 2 detik, akun pribadhi sampeyan ora mung duwe imbangan sing diganti, nanging informasi babagan kenapa owah-owahan.
kesimpulan
Iki minangka conto nggunakake Tarantool. Kita seneng banget karo keterbukaan Mail.ru lan kekarepan kanggo nimbang macem-macem kasus.
Wis angel kanggo konsultan saka BCG utawa McKinsey, Accenture utawa IBM kanggo nggumunake apa wae sing anyar - akeh sing ditawakake, sing wis ditindakake, wis rampung, utawa rencana arep ditindakake. Aku mikir sing Tarantool bakal njupuk Panggonan tengen ing tumpukan teknologi kita lan bakal ngganti akeh teknologi ana. Kita ana ing fase aktif pangembangan proyek iki.
Laporan dening Oleg lan Andrey minangka salah sawijining sing paling apik ing Konferensi Tarantool taun kepungkur, lan tanggal 17 Juni Oleg Ivlev bakal ngomong ing kanthi laporan . Alexander Deulin uga bakal menehi presentasi saka MegaFon . Ayo ngerteni apa sing wis owah, apa rencana sing wis ditindakake. Gabung - konferensi gratis, sampeyan mung kudu nindakake ... Kabeh lan program konferensi wis kawangun: kasus anyar, pengalaman anyar ing nggunakake Tarantool, arsitektur, perusahaan, tutorial lan microservices.
Source: www.habr.com