Miks vajab selline ettevõte nagu MegaFon arveldamisel Tarantooli? Väljast paistab, et müüja tavaliselt tuleb, toob mingi suure karbi, pistab pistiku pistikupessa - ja ongi arveldamine! Kunagi oli see nii, kuid nüüd on see arhailine ja sellised dinosaurused on juba välja surnud või väljasuremas. Esialgu on arveldamine arvete väljastamise süsteem – loendusmasin või kalkulaator. Kaasaegses telekommunikatsioonis on see nii automatiseerimissüsteem kogu abonendiga suhtlemise elutsükli jaoks alates lepingu sõlmimisest kuni lõpetamiseni, sealhulgas reaalajas arveldamine, maksete vastuvõtmine ja palju muud. Arveldamine telekomiettevõtetes on nagu lahingurobot – suur, võimas ja relvadega koormatud.
Mis on Tarantoolil sellega pistmist? Nad räägivad sellest Oleg Ivlev и Andrei Knjazev. Oleg on ettevõtte peaarhitekt pikaajaliste välisettevõtetes töötamise kogemusega Andrey on ärisüsteemide direktor. Nende raporti ärakirjast saate teada, miks on ettevõtetes vaja teadus- ja arendustegevust, mis on Tarantool, kuidas vertikaalse skaleerimise ja globaliseerumise ummik sai selle andmebaasi ettevõttesse ilmumise eelduseks, saate teada tehnoloogilistest väljakutsetest, arhitektuurimuutustest ja kuidas MegaFoni tehnostack sarnaneb Netflixiga. , Google ja Amazon.
Projekt "Ühtne arveldamine"
Kõnealune projekt kannab nime "Unified Billing". Just siin näitas Tarantool oma parimaid omadusi.
Hi-End seadmete tootlikkuse kasv ei pidanud sammu abonendibaasi kasvu ja teenuste arvu kasvuga, M2M, IoT ja harufunktsioonide tõttu oodati abonentide ja teenuste arvu edasist kasvu. turule jõudmise aja lühenemiseni. Ettevõte otsustas luua unikaalse maailmatasemel moodularhitektuuriga ühtse ärisüsteemi praeguse 8 erineva arveldussüsteemi asemel.
MegaFon on kaheksa ettevõtet ühes. 2009. aastal viidi reorganiseerimine lõpule: filiaalid kogu Venemaal ühendati üheks ettevõtteks MegaFon OJSC (nüüd PJSC). Seega on ettevõttel 8 arveldussüsteemi, millel on oma “kohandatud” lahendused, filiaali funktsioonid ja erinevad organisatsioonilised struktuurid, IT ja turundus.
Kõik oli korras, kuni pidime turule tooma ühe ühise föderaalse toote. Siin on tekkinud palju raskusi: mõne jaoks ümardatakse tariifid ülespoole, teiste jaoks allapoole ja teiste jaoks - aritmeetilise keskmise alusel. Selliseid hetki on tuhandeid.
Vaatamata sellele, et arveldussüsteemist oli ainult üks versioon, üks tarnija, läksid seaded nii palju lahku, et nende kokkupanek võttis kaua aega. Püüdsime nende arvu vähendada ja puutusime kokku teise probleemiga, mis on paljudele ettevõtetele tuttav.
Vertikaalne skaleerimine. Isegi kõige lahedam riistvara tol ajal ei vastanud vajadustele. Kasutasime Superdome Hi-End liini Hewlett-Packardi seadmeid, kuid see ei vastanud isegi kahe haru vajadustele. Tahtsin horisontaalset skaleerimist ilma suurte tegevuskulude ja kapitaliinvesteeringuteta.
Abonentide ja teenuste arvu kasvu ootus. Konsultandid on juba ammu toonud telekomimaailma lugusid asjade Internetist ja M2M-ist: tuleb aeg, mil igas telefonis ja triikrauas on SIM-kaart, külmikus kaks. Täna on meil üks arv tellijaid, kuid lähitulevikus on neid palju rohkem.
Tehnoloogilised väljakutsed
Need neli põhjust ajendasid meid tegema tõsiseid muudatusi. Valida oli süsteemi uuendamise või nullist kujundamise vahel. Mõtlesime kaua, tegime tõsiseid otsuseid, mängisime pakkumisi. Selle tulemusena otsustasime algusest peale disainida ja võtsime vastu huvitavad väljakutsed – tehnoloogilised väljakutsed.
Skaalautuvus
Kui see oli varem, siis ütleme, ütleme 8 arvet 15 miljonile tellijale, ja nüüd oleks see pidanud toimima 100 miljonit tellijat ja rohkem - koormus on suurusjärgu võrra suurem.
Oleme muutunud mastaabilt võrreldavaks suurte Interneti-mängijatega, nagu Mail.ru või Netflix.
Kuid edasine liikumine koormuse ja abonentide arvu suurendamiseks on seadnud meile tõsiseid väljakutseid.
Meie suure riigi geograafia
Kaliningradi ja Vladivostoki vahel 7500 km ja 10 ajavööndit. Valguse kiirus on piiratud ja sellistel vahemaadel on viivitused juba märkimisväärsed. 150 ms kõige lahedamatel kaasaegsetel optilistel kanalitel on reaalajas arveldamiseks liiga palju, eriti kuna see on praegu Venemaal telekomis. Lisaks peate värskendama ühe tööpäeva jooksul ja erinevate ajavööndite puhul on see probleem.
Me ei paku teenuseid ainult liitumistasu eest, meil on keerulised tariifid, paketid ja erinevad modifikaatorid. Peame mitte ainult lubama või keelama abonendil rääkida, vaid andma talle teatud kvoodi - arvutama kõned ja toimingud reaalajas, et ta ei märkaks.
veataluvus
See on tsentraliseerimise teine pool.
Kui kogume kõik abonendid ühte süsteemi, on kõik hädaolukorrad ja katastroofid ärile hukatuslikud. Seetõttu kujundame süsteemi selliselt, et õnnetuste mõju kogu abonentide baasile oleks välistatud.
See on jällegi vertikaalsest skaleerimisest keeldumise tagajärg. Kui me skaleerisime horisontaalselt, suurendasime serverite arvu sadadelt tuhandeteni. Neid tuleb hallata ja vahetada, IT-taristut tuleb automaatselt varundada ja hajutatud süsteemi taastada.
Me seisime silmitsi selliste huvitavate väljakutsetega. Kujundasime süsteemi ja sel hetkel püüdsime leida ülemaailmseid parimaid tavasid, et kontrollida, kui palju me oleme trendis, kui palju järgime arenenud tehnoloogiaid.
Maailma kogemus
Üllataval kombel ei leidnud me ülemaailmsest telekommunikatsioonist ühtegi viidet.
Euroopa on langenud ära abonentide arvu ja ulatuse poolest, USA - oma tariifide tasasuse poolest. Vaatasime mõnda Hiinast ja leidsime mõned Indiast ning palkasime Vodafone India spetsialistid.
Arhitektuuri analüüsimiseks panime kokku Dream Teami, mida juhib IBM – erinevate valdkondade arhitektid. Need inimesed said adekvaatselt hinnata meie tegemist ja tuua meie arhitektuuri teatud teadmisi.
Skaala
Illustreerimiseks paar numbrit.
Disainime süsteemi selleks 80 miljonit abonenti ühe miljardi suuruse reserviga. Nii eemaldame tulevased künnised. Seda mitte sellepärast, et me hakkame Hiinat üle võtma, vaid asjade Interneti ja M2M-i pealetungist.
300 miljonit dokumenti töödeldakse reaalajas. Kuigi meil on 80 miljonit tellijat, töötame nii potentsiaalsete klientidega kui ka meie hulgast lahkunutega, kui meil on vaja nõudeid sisse nõuda. Seetõttu on tegelikud mahud märgatavalt suuremad.
2 miljardit tehingut Saldo muutub iga päev – need on maksed, tasud, kõned ja muud sündmused. 200 TB andmeid muutub aktiivselt, muuda veidi aeglasemalt 8 PB andmeid, ja see ei ole arhiiv, vaid reaalajas andmed ühes arvelduses. Skaala andmekeskuse järgi – 5 tuhat serverit 14 saidil.
Tehnoloogia virn
Arhitektuuri kavandades ja süsteemi kokku panema hakates importisime kõige huvitavamad ja arenenumad tehnoloogiad. Tulemuseks on tehnoloogiapakk, mis on tuttav kõigile Interneti-mängijatele ja suure koormusega süsteeme tootvatele ettevõtetele.
Pinn on sarnane teiste suuremate mängijate virnadega: Netflix, Twitter, Viber. See koosneb 6 komponendist, kuid me tahame seda lühendada ja ühtlustada.
Paindlikkus on hea, kuid suurkorporatsioonis ei saa ilma ühinemiseta kuidagi.
Me ei kavatse muuta sama Oracle'i Tarantooliks. Suurettevõtete tegelikkuses on see utoopia ehk ebaselge tulemusega 5-10-aastane ristisõda. Kuid Cassandra ja Couchbase'i saab hõlpsasti Tarantooliga asendada ja see on see, mille poole me püüdleme.
Miks Tarantool?
Selle andmebaasi valimiseks on neli lihtsat kriteeriumi.
Kiirus. Tegime MegaFoni tööstussüsteemide koormusteste. Tarantool võitis – näitas parimat esitust.
See ei tähenda, et teised süsteemid ei vasta MegaFoni vajadustele. Praegused mälulahendused on nii produktiivsed, et ettevõtte varudest on enam kui küll. Aga meid huvitab suhtlemine juhiga, mitte mahajääjaga, sealhulgas koormustestis.
Tarantool katab ettevõtte vajadused ka pikemas perspektiivis.
TCO maksumus. Couchbase'i toetamine MegaFoni mahtudel maksab astronoomilisi rahasummasid, kuid Tarantooliga on olukord palju meeldivam ja need on funktsionaalsuselt sarnased.
Teine tore omadus, mis meie valikut veidi mõjutas, on see, et Tarantool töötab mäluga paremini kui teised andmebaasid. Ta näitab maksimaalne efektiivsus.
Usaldusväärsus. MegaFon investeerib töökindlusse ilmselt rohkem kui keegi teine. Nii et kui vaatasime Tarantooli, mõistsime, et peame selle oma nõuetele vastama.
Investeerisime oma aega ja raha ning koos Mail.ru-ga lõime ettevõtte versiooni, mis on nüüd kasutusel mitmes teises ettevõttes.
Tarantool-ettevõte rahuldas meid täielikult turvalisuse, töökindluse ja metsaraie osas.
Partnerlus
Minu jaoks on kõige tähtsam otsekontakt arendajaga. Just sellega Tarantooli kutid altkäemaksu andsid.
Kui tulete mängija, eriti sellise, kes töötab ankurkliendiga, juurde ja ütlete, et teil on vaja andmebaasi, et saaksite seda, seda ja seda teha, vastab ta tavaliselt:
- Olgu, pane nõuded selle hunniku alumisse ossa – ühel päeval jõuame ilmselt nendeni.
Paljudel on teekaart järgmiseks 2-3 aastaks ja sinna integreerumine on peaaegu võimatu, kuid Tarantooli arendajad köidavad oma avatusega ja mitte ainult MegaFoni poolt ning kohandavad oma süsteemi kliendi järgi. See on lahe ja meile väga meeldib.
Kus kasutasime Tarantooli
Tarantooli kasutame mitmes elemendis. Esimene on piloodis, mille tegime aadressikataloogisüsteemis. Omal ajal tahtsin, et see oleks Yandex.Mapsi ja Google Mapsiga sarnane süsteem, kuid see osutus veidi teistsuguseks.
Näiteks aadressikataloog müügiliideses. Oracle'is võtab soovitud aadressi otsimine aega 12–13 sekundit. - ebamugavad numbrid. Kui läheme Tarantoolile, asendame Oracle'i konsoolis mõne teise andmebaasiga ja sooritame sama otsingu, saame 200-kordse kiirenduse! Linn hüppab välja pärast kolmandat tähte. Nüüd kohandame liidest nii, et see juhtuks pärast esimest. Reageerimiskiirus on aga täiesti erinev – sekundite asemel millisekundid.
Teine rakendus on trendikas teema, mida nimetatakse kahekiiruseliseks IT-ks. Seda seetõttu, et iga nurga konsultandid ütlevad, et korporatsioonid peaksid sinna minema.
On infrastruktuurikiht, selle kohal on domeenid, näiteks arveldussüsteem nagu telekommunikatsioon, ettevõtte süsteemid, ettevõtte aruandlus. See on tuum, mida pole vaja puudutada. See on muidugi võimalik, kuid paranoiliselt kvaliteedi tagamine, sest see toob korporatsioonile raha.
Edasi tuleb mikroteenuste kiht – mis operaatorit või teist mängijat eristab. Mikroteenuseid saab kiiresti luua kindlate vahemälude põhjal, tuues sinna andmeid erinevatest domeenidest. Siin katsete väli — kui midagi ei õnnestunud, sulgesin ühe mikroteenuse ja avasin teise. See pikendab tõeliselt turule jõudmise aega ning suurendab ettevõtte usaldusväärsust ja kiirust.
Mikroteenused on võib-olla Tarantooli peamine roll MegaFonis.
Kus plaanime Tarantooli kasutada
Kui võrrelda meie edukat arveldusprojekti Deutsche Telekomi, Svyazcomi, Vodafone India ümberkujundamisprogrammidega, on see üllatavalt dünaamiline ja loominguline. Selle projekti elluviimise käigus muudeti mitte ainult MegaFon ja selle struktuur, vaid saidil Mail.ru ilmus ka Tarantool-ettevõte ja meie müüja Nexign (endine Peter-Service) - BSS Box (karbis arvelduslahendus).
See on Venemaa turu jaoks teatud mõttes ajalooline projekt. Seda võib võrrelda Frederick Brooksi raamatus “The Mythical Man-Month” kirjeldatuga. Seejärel palkas IBM 60ndatel 360 inimest, et välja töötada uus suurarvutite operatsioonisüsteem OS/5. Meil on vähem - 000, aga meie omad on vestides ning avatud lähtekoodi kasutamist ja uusi lähenemisi arvestades töötame produktiivsemalt.
Allpool on välja toodud arvelduse või laiemalt ärisüsteemide valdkonnad. Ettevõtte inimesed tunnevad CRM-i väga hästi. Kõigil peaks juba olema teised süsteemid: Open API, API Gateway.
Avatud API
Vaatame uuesti numbreid ja seda, kuidas Open API praegu töötab. Selle koormus on 10 000 tehingut sekundis. Kuna plaanime aktiivselt arendada mikroteenuste kihti ja ehitada MegaFon avalikku API-d, siis ootame selles osas tulevikus suuremat kasvu. Kindlasti tuleb 100 000 tehingut.
Ma ei tea, kas saame SSO-s võrrelda Mail.ru-ga - kuttidel näib olevat 1 000 0000 tehingut sekundis. Nende lahendus on meie jaoks äärmiselt huvitav ja plaanime nende kogemusi üle võtta – näiteks Tarantooli abil funktsionaalse SSO varukoopia tegemise. Nüüd teevad seda meie eest Mail.ru arendajad.
CRM
CRM on seesama 80 miljonit tellijat, mida tahame kasvatada miljardini, sest kolmeaastase ajalooga dokumente on juba 300 miljonit. Ootame väga uusi teenuseid ja siin kasvupunkt on ühendatud teenused. See on pall, mis kasvab, sest teenuseid tuleb järjest rohkem. Seetõttu vajame lugu; me ei taha selle otsa komistada.
Ise arveldamine arvete väljastamise osas, töö klientide arvetega muudetakse eraldi domeeniks. Toimivuse parandamiseks rakendusdomeeni arhitektuuri arhitektuurimuster.
Süsteem on jagatud domeenideks, koormus jaotatakse ja tõrketaluvus on tagatud. Lisaks töötasime hajutatud arhitektuuriga.
Kõik muu on ettevõtte tasemel lahendused. Kõnede salvestusruumis - 2 miljardit päevas, 60 miljardit kuus. Mõnikord peate neid lugema kuu jooksul ja see on parem kiiresti. Finantsjärelevalve - see on täpselt sama 300 miljonit, mis pidevalt kasvab ja kasvab: abonendid jooksevad sageli operaatorite vahel, suurendades seda osa.
Mobiilside kõige telekomikomponent on Internetis arveldamine. Need on süsteemid, mis võimaldavad teil helistada või mitte helistada, teha otsuseid reaalajas. Siin on koormus 30 000 tehingut sekundis, kuid arvestades andmeedastuse kasvu, plaanime 250 000 tehingut, ja seetõttu oleme Tarantoolist väga huvitatud.
Eelmisel pildil on domeenid, kus me Tarantooli kasutama hakkame. CRM ise on muidugi laiem ja me hakkame seda tuumas endas kasutama.
Meie hinnanguline TTX-i arv 100 miljonit tellijat ajab mind arhitektina segadusse – mis siis, kui 101 miljonit? Kas peate kõik uuesti tegema? Selle vältimiseks kasutame vahemälu, suurendades samal ajal juurdepääsetavust.
Üldiselt on Tarantooli kasutamisel kaks lähenemisviisi. Esiteks - ehitada kõik vahemälud mikroteenuste tasemel. Minu arusaamist mööda käib VimpelCom seda teed, luues klientide vahemälu.
Oleme vähem sõltuvad müüjatest, muudame BSS-i tuuma, nii et meil on karbist väljas üks kliendifail. Kuid me tahame seda laiendada. Seetõttu kasutame veidi teistsugust lähenemist - teha vahemälu süsteemide sees.
Nii on sünkroonimist vähem – üks süsteem vastutab nii vahemälu kui ka peamise põhiallika eest.
Meetod sobib hästi Tarantooli lähenemisviisiga tehingute skeletiga, kui värskendatakse ainult värskendustega, st andmete muudatustega seotud osi. Kõik muu saab hoiustada kuskil mujal. Puudub tohutu andmejärv, haldamata globaalne vahemälu. Vahemälud on mõeldud süsteemi, toodete või klientide jaoks või elu hõlbustamiseks hoolduse jaoks. Kui abonent helistab ja on teie teenuse kvaliteedi pärast ärritunud, soovite pakkuda kvaliteetset teenust.
RTO ja RPO
IT-s on kaks terminit - OTR и RPO.
Taastumisaja eesmärk on aeg, mis kulub teenuse taastamiseks pärast riket. RTO = 0 tähendab, et isegi kui midagi ebaõnnestub, töötab teenus edasi.
Taastumispunkti eesmärk - see on andmete taastamise aeg, kui palju andmeid võime teatud aja jooksul kaotada. RPO = 0 tähendab, et me ei kaota andmeid.
Tarantooli ülesanne
Proovime lahendada Tarantooli probleemi.
Antud: rakenduste korv, millest igaüks aru saab, näiteks Amazonis või mujal. nõutav nii, et ostukorvi töötab 24 tundi 7 päeva nädalas ehk 99,99% ajast. Meile saabuvad tellimused peavad olema korras, sest me ei saa abonendi ühendust juhuslikult sisse või välja lülitada - kõik peab olema rangelt kooskõlas. Eelmine tellimus mõjutab järgmist, seega on andmed olulised – midagi ei tohiks kaduma minna.
otsus. Võite proovida seda otsekohe lahendada ja küsida andmebaasi arendajatelt, kuid probleemi ei saa matemaatiliselt lahendada. Teoreeme, jäävusseadusi, kvantfüüsikat võib meeles pidada, aga miks – seda ei saa DB tasemel lahendada.
Siin töötab vana hea arhitektuurne lähenemine – tuleb ainevaldkonda hästi tunda ja seda mõistatuse lahendamisel kasutada.
Meie lahendus: rakenduste hajutatud registri loomine Tarantoolis - geograafiliselt hajutatud klastris. Diagrammil on need kolm erinevat andmetöötluskeskust – kaks enne Uurali, üks Uuralitest kaugemal ja me jagame kõik päringud nende keskuste vahel laiali.
Netflixil, mida praegu peetakse üheks IT-valdkonna liidriks, oli kuni 2012. aastani vaid üks andmekeskus. Katoliiklike jõulude eelõhtul, 24. detsembril, läks see andmekeskus alla. Kanada ja USA kasutajad jäid oma lemmikfilmidest ilma, olid väga ärritunud ja kirjutasid sellest sotsiaalvõrgustikes. Netflixil on nüüd kolm andmekeskust lääne-idarannikul ja üks Lääne-Euroopas.
Ehitame esialgu geograafiliselt hajutatud lahendust – meile on oluline veataluvus.
Nii et meil on klaster, aga kuidas on RPO = 0 ja RTO = 0? Lahendus on olenevalt teemast lihtne.
Mis on rakendustes oluline? Kaks osa: korviviskamine TO ostuotsuse tegemine ja Pärast. Tavaliselt nimetatakse telekomi DO-osa tellimuse hõivamine või tellimuse läbirääkimine. Telekomis võib see olla palju keerulisem kui veebipoes, sest seal tuleb klienti teenindada, pakkuda 5 varianti ja see kõik toimub mõnda aega, aga korv saab täis. Praegusel hetkel on ebaõnnestumine võimalik, kuid see pole hirmutav, sest see toimub interaktiivselt inimese järelevalve all.
Kui Moskva andmekeskus äkki ebaõnnestub, siis automaatselt teisele andmekeskusele üle minnes jätkame tööd. Teoreetiliselt võib üks toode ostukorvi kaduda, aga näed seda, lisad uuesti ostukorvi ja jätkad tööd. Sel juhul RTO = 0.
Samal hetkel on ka teine võimalus: kui vajutasime “esita”, tahame, et andmed ei läheks kaduma. Sellest hetkest hakkab tööle automatiseerimine - see on RPO = 0. Kasutades neid kahte erinevat mustrit, võib ühel juhul olla tegemist lihtsalt geograafiliselt hajutatud klastriga, millel on üks lülitatav master, teisel juhul mingi kvoorumi kirje. Mustrid võivad erineda, kuid me lahendame probleemi.
Lisaks, kuna meil on hajutatud rakenduste register, saame seda kõike ka skaleerida – meil on palju dispetšereid ja täitjaid, kes pääsevad sellele registrile juurde.
Cassandra ja Tarantool koos
On veel üks juhtum - "saldode vitriin". Siin on huvitav juhtum Cassandra ja Tarantooli ühisest kasutamisest.
Kasutame Cassandrat, sest 2 miljardit kõnet päevas ei ole piir ja neid tuleb veelgi. Turundajatele meeldib liiklust allika järgi värvida, näiteks sotsiaalvõrgustikes ilmub üha rohkem üksikasju. See kõik lisab loole.
Cassandra võimaldab teil skaleerida horisontaalselt mis tahes suurusele.
Tunneme end Cassandraga mugavalt, kuid tal on üks probleem – ta ei oska lugeda. Salvestusel on kõik korras, 30 000 sekundis pole probleem - lugemise probleem.
Seetõttu ilmus vahemäluga teema ja samal ajal lahendasime järgmise probleemi: on vana traditsiooniline juhtum, kui võrguarveldusest lülitumisel tulevad seadmed failidesse, mille laadime Cassandrasse. Võitlesime nende failide usaldusväärse allalaadimise probleemiga, kasutades isegi IBMi halduri failiedastuse nõuandeid – on lahendusi, mis haldavad failiedastust tõhusalt, kasutades näiteks UDP-protokolli, mitte TCP-d. See on hea, kuid see on veel minuteid ja me pole seda kõike veel laadinud, kõnekeskuse operaator ei saa kliendile vastata, mis tema saldoga juhtus - peame ootama.
Et seda ei juhtuks, me kasutame paralleelset funktsionaalset reservi. Kui saadame sündmuse Kafka kaudu Tarantoolile, arvutades reaalajas koondtulemusi näiteks tänaseks, saame sularaha jäägid, mis suudab saldosid üle kanda mis tahes kiirusega, näiteks 100 tuhat tehingut sekundis ja sama 2 sekundit.
Eesmärk on, et pärast helistamist oleks teie isiklikul kontol 2 sekundi jooksul mitte ainult muutunud saldo, vaid ka teave selle muutumise põhjuste kohta.
Järeldus
Need olid näited Tarantooli kasutamisest. Meile meeldis väga Mail.ru avatus ja valmisolek erinevaid juhtumeid kaaluda.
BCG või McKinsey, Accenture'i või IBMi konsultantidel on juba raske meid millegi uuega üllatada – suurt osa nende pakutavast me juba teeme, oleme teinud või kavatseme teha. Arvan, et Tarantool võtab meie tehnoloogiavirnas oma õige koha ja asendab paljusid olemasolevaid tehnoloogiaid. Oleme selle projekti arendamise aktiivses faasis.
Olegi ja Andrey ettekanne on Tarantooli konverentsil eelmisel aastal üks paremaid ning 17. juunil esineb Oleg Ivlev. aruandega . MegaFonist teeb ettekande ka Alexander Deulin . Uurime, mis on muutunud, millised plaanid on ellu viidud. Liitu – konverents on tasuta, pead vaid tegema . Kõik ja konverentsi programm on kujunenud: uued juhtumid, uus kogemus Tarantooli kasutamisel, arhitektuur, ettevõtlus, õpetused ja mikroteenused.
Allikas: www.habr.com