Waarom heeft een bedrijf als MegaFon Tarantool nodig voor de facturering? Van buitenaf lijkt het erop dat de verkoper meestal komt, een soort grote doos meeneemt, de stekker in het stopcontact steekt - en dat is de facturering! Dit was ooit het geval, maar nu is het archaïsch, en dergelijke dinosauriërs zijn al uitgestorven of zijn aan het uitsterven. In eerste instantie is facturering een systeem voor het uitreiken van facturen: een telmachine of rekenmachine. In moderne telecommunicatie is dit wel het geval automatiseringssysteem voor de gehele levenscyclus van interactie met een abonnee, vanaf het sluiten van een contract tot de beëindiging, inclusief realtime facturering, betalingsacceptatie en nog veel meer. Facturering bij telecombedrijven is als een gevechtsrobot: groot, krachtig en boordevol wapens.
Wat heeft Tarantool ermee te maken? Ze zullen erover praten Oleg Ivlev и Andrey Knjazev. Oleg is de hoofdarchitect van het bedrijf Andrey heeft uitgebreide ervaring met het werken bij buitenlandse bedrijven en is directeur bedrijfssystemen. Vanaf het transcript van hun rapport je leert waarom R&D nodig is in bedrijven, wat Tarantool is, hoe de impasse van verticale schaalvergroting en globalisering de voorwaarden werden voor de verschijning van deze database in het bedrijf, over technologische uitdagingen, architecturale transformatie en hoe de technostack van MegaFon vergelijkbaar is met Netflix , Google en Amazon.
Project ‘Unified Billing’
Het project in kwestie heet “Unified Billing”. Het was hier dat Tarantool zijn beste kwaliteiten toonde.
De groei van de productiviteit van Hi-End-apparatuur hield geen gelijke tred met de groei van het abonneebestand en de groei van het aantal diensten; een verdere groei van het aantal abonnees en diensten werd verwacht vanwege M2M, IoT en branchekenmerken. tot een verslechtering van de time-to-market. Het bedrijf besloot een uniform bedrijfssysteem te creëren met een unieke modulaire architectuur van wereldklasse, in plaats van de huidige acht verschillende factureringssystemen.
MegaFon is acht bedrijven in één. In 2009 werd de reorganisatie voltooid: vestigingen in heel Rusland fuseerden tot één bedrijf, MegaFon OJSC (nu PJSC). Zo beschikt het bedrijf over 8 facturatiesystemen met hun eigen “op maat” oplossingen, filiaalfuncties en verschillende organisatiestructuren, IT en marketing.
Alles was in orde totdat we één gemeenschappelijk federaal product moesten lanceren. Hier deden zich veel moeilijkheden voor: voor sommigen worden de tarieven naar boven afgerond, voor anderen naar beneden afgerond, en voor anderen - gebaseerd op het rekenkundig gemiddelde. Er zijn duizenden van zulke momenten.
Ondanks het feit dat er maar één versie van het facturatiesysteem was, één leverancier, liepen de instellingen zo uiteen dat het in elkaar zetten lang duurde. We probeerden hun aantal terug te dringen en kwamen een tweede probleem tegen dat bij veel bedrijven bekend is.
Verticale schaling. Zelfs de coolste hardware van die tijd voldeed niet aan de behoeften. We gebruikten Hewlett-Packard-apparatuur uit de Superdome Hi-End-lijn, maar deze voldeed niet aan de behoeften van zelfs maar twee vestigingen. Ik wilde horizontale schaalvergroting zonder grote exploitatiekosten en kapitaalinvesteringen.
Verwachting van groei van het aantal abonnees en diensten. Consultants brengen al lang verhalen over IoT en M2M naar de telecomwereld: er zal een tijd komen dat elke telefoon en strijkijzer een simkaart zal hebben, en twee in de koelkast. Vandaag hebben we één aantal abonnees, maar in de nabije toekomst zullen dat er nog veel meer worden.
Technologische uitdagingen
Deze vier redenen motiveerden ons om serieuze veranderingen door te voeren. Er was een keuze tussen het upgraden van het systeem of het helemaal opnieuw ontwerpen. We hebben lang nagedacht, serieuze beslissingen genomen, aanbestedingen gespeeld. Als gevolg hiervan besloten we vanaf het allereerste begin te ontwerpen en gingen we interessante uitdagingen aan: technologische uitdagingen.
Schaalbaarheid
Als het eerder was, laten we zeggen, laten we zeggen 8 facturen voor 15 miljoen abonnees, en nu zou het moeten werken 100 miljoen abonnees en meer - de belasting is een orde van grootte hoger.
We zijn qua schaal vergelijkbaar geworden met grote internetspelers als Mail.ru of Netflix.
Maar de verdere beweging om het bezoekersaantal en het abonneebestand te vergroten heeft ons voor serieuze uitdagingen gesteld.
Geografie van ons uitgestrekte land
Tussen Kaliningrad en Vladivostok 7500 km en 10 tijdzones. De snelheid van het licht is eindig en op zulke afstanden zijn de vertragingen al aanzienlijk. 150 ms op de coolste moderne optische kanalen is te veel voor realtime facturering, vooral omdat dit nu het geval is in de telecomsector in Rusland. Bovendien moet je binnen één werkdag updaten, en met verschillende tijdzones is dit een probleem.
We leveren niet alleen diensten tegen abonnementsgeld, we hebben complexe tarieven, pakketten en verschillende modifiers. We moeten de abonnee niet alleen toestaan of weigeren om te praten, maar hem ook een bepaald quotum geven: oproepen en acties in realtime berekenen, zodat hij het niet merkt.
fout tolerantie
Dit is de andere kant van centralisatie.
Als we alle abonnees in één systeem verzamelen, zijn eventuele noodsituaties en rampen rampzalig voor het bedrijfsleven. Daarom ontwerpen we het systeem zo dat de impact van ongevallen op het gehele abonneebestand wordt geëlimineerd.
Dit is opnieuw een gevolg van de weigering om verticaal te schalen. Toen we horizontaal schaalden, verhoogden we het aantal servers van honderden naar duizenden. Ze moeten beheerd en uitwisselbaar zijn, automatisch een back-up maken van de IT-infrastructuur en het gedistribueerde systeem herstellen.
We stonden voor zulke interessante uitdagingen. We hebben het systeem ontworpen en op dat moment probeerden we mondiale best practices te vinden om te controleren in hoeverre we in de mode zijn, in hoeverre we geavanceerde technologieën volgen.
Wereld ervaring
Verrassend genoeg vonden we geen enkele referentie in de mondiale telecomsector.
Europa is weggevallen wat betreft het aantal abonnees en de omvang, de VS wat betreft de vlakheid van de tarieven. We hebben er een aantal in China bekeken, een aantal in India gevonden en specialisten van Vodafone India ingehuurd.
Om de architectuur te analyseren, hebben we een Dream Team samengesteld onder leiding van IBM - architecten uit verschillende vakgebieden. Deze mensen konden adequaat inschatten waar we mee bezig waren en bepaalde kennis inbrengen in onze architectuur.
Schaal
Een paar cijfers ter illustratie.
Wij ontwerpen het systeem voor 80 miljoen abonnees met een reserve van één miljard. Zo nemen we toekomstige drempels weg. Dit is niet omdat we China gaan overnemen, maar vanwege de aanval van IoT en M2M.
300 miljoen documenten verwerkt in realtime. Hoewel we 80 miljoen abonnees hebben, werken we samen met zowel potentiële klanten als degenen die ons hebben verlaten als we vorderingen moeten innen. Daarom zijn de werkelijke volumes merkbaar groter.
2 miljard transacties Het saldo verandert dagelijks: dit zijn betalingen, kosten, oproepen en andere gebeurtenissen. 200 TB aan gegevens is actief aan het veranderen, verander iets langzamer 8 PB aan gegevens, en dit is geen archief, maar live gegevens in één enkele facturering. Schaal per datacenter - 5 servers op 14 sites.
Technologie stapel
Toen we de architectuur planden en het systeem begonnen te assembleren, importeerden we de meest interessante en geavanceerde technologieën. Het resultaat is een technologiestapel die bekend is bij elke internetspeler en bedrijven die systemen met hoge belasting maken.
De stapel is vergelijkbaar met de stapels van andere grote spelers: Netflix, Twitter, Viber. Het bestaat uit 6 componenten, maar we willen het inkorten en verenigen.
Flexibiliteit is goed, maar in een grote onderneming kan er geen sprake zijn van eenwording.
We gaan niet hetzelfde Oracle veranderen in Tarantool. In de realiteit van grote bedrijven is dit een utopie, of een kruistocht van vijf tot tien jaar met een onduidelijke uitkomst. Maar Cassandra en Couchbase kunnen eenvoudig worden vervangen door Tarantool, en dat is waar we naar streven.
Waarom Tarantool?
Er zijn vier eenvoudige criteria waarom we voor deze database hebben gekozen.
snelheid. We hebben belastingtests uitgevoerd op industriële MegaFon-systemen. Tarantool won - het toonde de beste prestaties.
Dit wil niet zeggen dat andere systemen niet aan de behoeften van MegaFon voldoen. De huidige geheugenoplossingen zijn zo productief dat de reserves van het bedrijf ruim voldoende zijn. Maar we zijn geïnteresseerd in de omgang met een leider, en niet met iemand die achterop raakt, ook niet in de belastingtest.
Tarantool dekt zelfs op de lange termijn de behoeften van het bedrijf.
TCO-kosten. Ondersteuning voor Couchbase op MegaFon-volumes kost astronomische hoeveelheden geld, maar met Tarantool is de situatie veel aangenamer en zijn ze qua functionaliteit vergelijkbaar.
Een andere leuke feature die onze keuze enigszins heeft beïnvloed, is dat Tarantool beter met geheugen werkt dan andere databases. Hij toont maximale efficiëntie.
Betrouwbaarheid. MegaFon investeert waarschijnlijk meer dan wie dan ook in betrouwbaarheid. Dus toen we naar Tarantool keken, beseften we dat we het aan onze eisen moesten laten voldoen.
We hebben onze tijd en geld geïnvesteerd en samen met Mail.ru een enterprise-versie gemaakt, die nu in verschillende andere bedrijven wordt gebruikt.
Tarantool-enterprise heeft ons volledig tevreden gesteld op het gebied van veiligheid, betrouwbaarheid en loggen.
vennootschap
Het belangrijkste voor mij is direct contact met de ontwikkelaar. Dit is precies waarmee de jongens van Tarantool hebben omgekocht.
Als je bij een speler komt, vooral iemand die met een ankerclient werkt, en zegt dat je de database nodig hebt om dit, dit en dit te kunnen doen, antwoordt hij meestal:
- Oké, leg de vereisten onderaan de stapel. Op een dag zullen we ze waarschijnlijk bereiken.
Velen hebben een routekaart voor de komende 2-3 jaar, en het is bijna onmogelijk om daar te integreren, maar Tarantool-ontwikkelaars boeien met hun openheid, en niet alleen van MegaFon, en passen hun systeem aan de klant aan. Het is cool en we vinden het erg leuk.
Waar we Tarantool gebruikten
We gebruiken Tarantool in verschillende elementen. De eerste zit in de pilot, die we hebben gemaakt op het adreslijstsysteem. Ooit wilde ik dat het een systeem zou zijn dat vergelijkbaar was met Yandex.Maps en Google Maps, maar het pakte een beetje anders uit.
Bijvoorbeeld de adrescatalogus in de verkoopinterface. Op Oracle duurt het zoeken naar het gewenste adres 12-13 seconden. - ongemakkelijke cijfers. Wanneer we overschakelen naar Tarantool, Oracle vervangen door een andere database in de console en dezelfde zoekopdracht uitvoeren, krijgen we een snelheidswinst van 200x! De stad verschijnt na de derde letter. Nu passen we de interface aan zodat dit na de eerste gebeurt. De reactiesnelheid is echter compleet anders: milliseconden in plaats van seconden.
De tweede applicatie is een trendy thema genaamd IT met twee snelheden. Dit komt omdat consultants uit alle hoeken zeggen dat bedrijven daarheen moeten gaan.
Er is een infrastructuurlaag, daarboven bevinden zich domeinen, bijvoorbeeld een factureringssysteem zoals een telecombedrijf, bedrijfssystemen, bedrijfsrapportage. Dit is de kern die niet aangeraakt hoeft te worden. Dat is natuurlijk mogelijk, maar paranoïde om de kwaliteit te garanderen, omdat het geld oplevert voor het bedrijf.
Vervolgens komt de laag van microservices – wat de operator of een andere speler onderscheidt. Op basis van bepaalde caches kunnen snel microservices worden gemaakt, waardoor gegevens uit verschillende domeinen daar terechtkomen. Hier veld voor experimenten — als iets niet lukte, sloot ik de ene microservice en opende een andere. Dit zorgt voor een werkelijk langere time-to-market en verhoogt de betrouwbaarheid en snelheid van het bedrijf.
Microservices zijn misschien wel de hoofdrol van Tarantool bij MegaFon.
Waar we Tarantool willen gebruiken
Als we ons succesvolle facturatieproject vergelijken met de transformatieprogramma's bij Deutsche Telekom, Svyazcom en Vodafone India, is het verrassend dynamisch en creatief. Tijdens het implementatieproces van dit project werden niet alleen MegaFon en zijn structuur getransformeerd, maar verscheen ook de Tarantool-onderneming op Mail.ru, en onze leverancier Nexign (voorheen Peter-Service) - BSS Box (een oplossing voor facturering in dozen).
Dit is in zekere zin een historisch project voor de Russische markt. Het is te vergelijken met wat beschreven wordt in het boek “The Mythical Man-Month” van Frederick Brooks. Vervolgens huurde IBM in de jaren zestig 60 mensen in om het nieuwe OS/360-besturingssysteem voor mainframes te ontwikkelen. We hebben er minder - 5, maar die van ons zijn in vesten, en rekening houdend met het gebruik van open source en nieuwe benaderingen werken we productiever.
Hieronder staan de domeinen van facturering of, breder gesproken, bedrijfssystemen. Mensen uit het bedrijfsleven kennen CRM heel goed. Iedereen zou al andere systemen moeten hebben: Open API, API Gateway.
Open API
Laten we nog eens naar de cijfers kijken en hoe de Open API momenteel werkt. Zijn lading is 10 transacties per seconde. Omdat we van plan zijn de microserviceslaag actief te ontwikkelen en de openbare API van MegaFon te bouwen, verwachten we in de toekomst een grotere groei op dit onderdeel. Er zullen zeker 100 transacties plaatsvinden.
Ik weet niet of we het kunnen vergelijken met Mail.ru op het gebied van SSO: de jongens lijken 1 transacties per seconde te hebben. Hun oplossing is voor ons buitengewoon interessant en we zijn van plan hun ervaring over te nemen, bijvoorbeeld door een functionele SSO-back-up te maken met Tarantool. Nu doen de ontwikkelaars van Mail.ru dit voor ons.
CRM
CRM is dezelfde 80 miljoen abonnees die we willen verhogen tot een miljard, omdat er al 300 miljoen documenten zijn met een geschiedenis van drie jaar. We kijken erg uit naar nieuwe diensten en hier groeipunt zijn verbonden diensten. Dit is een bal die zal groeien, omdat er steeds meer diensten zullen zijn. Daarom hebben we een verhaal nodig; we willen hier niet over struikelen.
Zelf factureren in termen van het uitreiken van facturen, werken met debiteuren van klanten omgevormd tot een apart domein. Om de prestaties te verbeteren, toegepaste domeinarchitectuur architectonisch patroon.
Het systeem is opgedeeld in domeinen, de belasting is verdeeld en fouttolerantie is gewaarborgd. Daarnaast hebben we gewerkt met gedistribueerde architectuur.
Al het andere zijn oplossingen op ondernemingsniveau. In de oproepopslag - 2 miljard per dag, 60 miljard per maand. Soms moet je ze binnen een maand tellen, en het gaat snel beter. Financiële monitoring - dit zijn precies dezelfde 300 miljoen die voortdurend groeien en groeien: abonnees lopen vaak tussen operators, waardoor dit deel toeneemt.
De meest telecomcomponent van mobiele communicatie is online tariefstelling. Dit zijn de systemen waarmee u wel of niet kunt bellen en in realtime beslissingen kunt nemen. Hier is de belasting 30 transacties per seconde, maar rekening houdend met de groei in gegevensoverdracht plannen we 250 transacties, en daarom zijn we erg geïnteresseerd in Tarantool.
De vorige afbeelding zijn de domeinen waar we Tarantool gaan gebruiken. CRM zelf is uiteraard breder en we gaan het in de kern zelf inzetten.
Ons geschatte TTX-cijfer van 100 miljoen abonnees brengt mij als architect in verwarring - wat als 101 miljoen? Moet je alles opnieuw doen? Om dit te voorkomen, gebruiken we caches en vergroten we tegelijkertijd de toegankelijkheid.
Over het algemeen zijn er twee benaderingen voor het gebruik van Tarantool. Eerst - bouw alle caches op microserviceniveau. Voor zover ik het begrijp, volgt VimpelCom dit pad en creëert een cache van klanten.
We zijn minder afhankelijk van leveranciers, we veranderen de BSS-kern, dus we hebben kant-en-klaar één klantenbestand. Maar wij willen het uitbreiden. Daarom hanteren wij een iets andere aanpak: maak caches binnen systemen.
Op deze manier is er minder synchronisatie: één systeem is verantwoordelijk voor zowel de cache als de hoofdmasterbron.
De methode sluit goed aan bij de Tarantool-aanpak met een transactioneel skelet, waarbij alleen delen die betrekking hebben op updates, dat wil zeggen gegevenswijzigingen, worden bijgewerkt. Al het andere kan ergens anders worden opgeslagen. Er is geen enorm datameer, onbeheerde wereldwijde cache. Caches zijn ontworpen voor het systeem, of voor producten, of voor klanten, of om het leven gemakkelijker te maken voor onderhoud. Wanneer een abonnee belt en zich zorgen maakt over de kwaliteit van uw service, wilt u hoogwaardige service bieden.
RTO en RPO
Er zijn twee termen in de IT: RTO и RPO.
Hersteltijddoelstelling is de tijd die nodig is om de service te herstellen na een storing. RTO = 0 betekent dat zelfs als er iets mislukt, de service blijft werken.
Herstelpuntdoelstelling - dit is de gegevenshersteltijd, hoeveel gegevens we gedurende een bepaalde periode kunnen verliezen. RPO = 0 betekent dat we geen gegevens verliezen.
Tarantool-taak
Laten we proberen een probleem voor Tarantool op te lossen.
Gegeven: een mandje met applicaties die iedereen begrijpt, bijvoorbeeld bij Amazon of ergens anders. Nodig zodat het winkelwagentje 24 uur, 7 dagen per week, oftewel 99,99% van de tijd, werkt. De bestellingen die naar ons toekomen, moeten in orde blijven, omdat we de verbinding van de abonnee niet willekeurig kunnen in- of uitschakelen - alles moet strikt consistent zijn. Het vorige abonnement heeft invloed op het volgende, dus de gegevens zijn belangrijk: er mag niets verloren gaan.
beslissing. Je kunt proberen het rechtstreeks op te lossen en het aan de databaseontwikkelaars te vragen, maar het probleem kan niet wiskundig worden opgelost. Je kunt je stellingen, behoudswetten en kwantumfysica herinneren, maar waarom: dat kan niet op DB-niveau worden opgelost.
De goede oude architectonische benadering werkt hier: je moet het vakgebied goed kennen en gebruiken om deze puzzel op te lossen.
Onze oplossing: het creëren van een gedistribueerd register van applicaties op Tarantool - een geografisch gedistribueerd cluster. In het diagram zijn dit drie verschillende gegevensverwerkingscentra: twee vóór de Oeral, één buiten de Oeral, en we verdelen alle verzoeken onder deze centra.
Netflix, dat nu wordt beschouwd als een van de leiders op het gebied van IT, had tot 2012 slechts één datacenter. Aan de vooravond van katholieke Kerstmis, 24 december, ging dit datacenter uit de lucht. Gebruikers in Canada en de VS bleven zonder hun favoriete films achter, waren erg overstuur en schreven erover op sociale netwerken. Netflix heeft nu drie datacenters aan de westoostkust en één in West-Europa.
We bouwen in eerste instantie een geogedistribueerde oplossing; fouttolerantie is belangrijk voor ons.
We hebben dus een cluster, maar hoe zit het met RPO = 0 en RTO = 0? De oplossing is eenvoudig, afhankelijk van het onderwerp.
Wat is belangrijk bij toepassingen? Twee delen: mandenwerpen NAAR het nemen van een aankoopbeslissing, en NA. Het DO-gedeelte in telecom wordt meestal genoemd bestelling vastleggen of onderhandeling over bestellingen. In telecom kan dit veel moeilijker zijn dan in een online winkel, omdat daar de klant bediend moet worden, 5 opties aangeboden moet worden, en dit gebeurt allemaal een tijdje, maar het winkelmandje is gevuld. Op dit moment is een mislukking mogelijk, maar niet eng, omdat het interactief gebeurt onder menselijk toezicht.
Als het datacenter in Moskou plotseling uitvalt, blijven we door automatisch over te schakelen naar een ander datacenter. Theoretisch kan het gebeuren dat één product verloren gaat in de winkelwagen, maar als je het ziet, voeg je het opnieuw toe aan de winkelwagen en ga je verder met werken. In dit geval RTO = 0.
Tegelijkertijd is er nog een tweede optie: wanneer we op “verzenden” klikken, willen we dat de gegevens niet verloren gaan. Vanaf dit moment begint de automatisering te werken - dit is RPO = 0. Met behulp van deze twee verschillende patronen kan het in het ene geval eenvoudigweg een geografisch gedistribueerd cluster zijn met één schakelbare master, in het andere geval een soort quorumrecord. Patronen kunnen variëren, maar wij lossen het probleem op.
Bovendien kunnen we, omdat we een gedistribueerd register van applicaties hebben, alles ook schalen: er zijn veel coördinatoren en uitvoerders die toegang hebben tot dit register.
Cassandra en Tarantool samen
Er is nog een geval - "showcase van evenwichten". Hier is een interessant geval van het gezamenlijke gebruik van Cassandra en Tarantool.
We gebruiken Cassandra omdat 2 miljard oproepen per dag niet de limiet is, en er zullen er meer zijn. Marketeers kleuren het verkeer graag in op bron; er verschijnen bijvoorbeeld steeds meer details op sociale netwerken. Het draagt allemaal bij aan het verhaal.
Met Cassandra kunt u horizontaal naar elk formaat schalen.
We voelen ons op ons gemak bij Cassandra, maar ze heeft één probleem: ze kan niet goed lezen. Op de opname is alles in orde, 30 per seconde is geen probleem - leesprobleem.
Daarom verscheen er een onderwerp met een cache en tegelijkertijd hebben we het volgende probleem opgelost: er is een oud traditioneel geval waarin apparatuur van een overstap van online facturering in de bestanden komt die we in Cassandra laden. We worstelden met het probleem van het betrouwbaar downloaden van deze bestanden, zelfs met behulp van het advies van de IBM-manager bestandsoverdracht. Er zijn oplossingen die de bestandsoverdracht efficiënt beheren, bijvoorbeeld met behulp van het UDP-protocol in plaats van TCP. Dit is goed, maar het duurt nog een paar minuten, en we hebben nog niet alles geladen. De telefoniste in het callcenter kan de klant niet antwoorden wat er met zijn saldo is gebeurd - we moeten wachten.
Om dit te voorkomen hebben wij we gebruiken parallelle functionele reserve. Wanneer we een gebeurtenis via Kafka naar Tarantool sturen en de aggregaten in realtime herberekenen, bijvoorbeeld voor vandaag, krijgen we kassaldi, waarmee u saldi op elke snelheid kunt overboeken, bijvoorbeeld 100 transacties per seconde en diezelfde 2 seconden.
Het doel is dat na het bellen binnen 2 seconden in je persoonlijke account niet alleen het gewijzigde saldo staat, maar ook informatie over waarom dit is gewijzigd.
Conclusie
Dit waren voorbeelden van het gebruik van Tarantool. We waren erg tevreden over de openheid van Mail.ru en hun bereidheid om verschillende zaken te overwegen.
Het is al moeilijk voor consultants van BCG of McKinsey, Accenture of IBM om ons met iets nieuws te verrassen; veel van wat zij bieden, doen we al, hebben we gedaan of zijn we van plan te gaan doen. Ik denk dat Tarantool zijn rechtmatige plaats in onze technologiestapel zal innemen en veel bestaande technologieën zal vervangen. We bevinden ons in de actieve fase van de ontwikkeling van dit project.
Het rapport van Oleg en Andrey is een van de beste op de Tarantool-conferentie van vorig jaar, en op 17 juni zal Oleg Ivlev spreken op met een rapport . Ook Alexander Deulin zal een presentatie geven vanuit MegaFon . Laten we eens kijken wat er is veranderd, welke plannen zijn geïmplementeerd. Doe mee: de conferentie is gratis, u hoeft alleen maar deel te nemen ... Alle en het conferentieprogramma is gevormd: nieuwe cases, nieuwe ervaringen met het gebruik van Tarantool, architectuur, onderneming, tutorials en microservices.
Bron: www.habr.com