V , rääkisin Veliam'i loomise eelloo ja selle SaaS-süsteemi levitamise lahenduse kohta. Selles artiklis räägin, mida tuli teha, et toode saaks kohalikust avalikuks. Kuidas me levitamist alustasime ja milliste probleemidega silmitsi seisisime.
Planeerimine
Praegune serveripool kasutajatele oli Linux. Peaaegu igas organisatsioonis on Windowsi serverid, mida ei saa öelda Linuxi kohta. Veliam'i peamine tugevus on kaugühendused serverite ja võrgu varadega NAT-i taga. Kuid see funktsionaalsus sõltus rangelt sellest, et marsruuteriks peab olema kindlasti MikroTik. Ja see ei rahuldaks ilmselt paljusid. Alguses mõtlesin, et lisada tugi kõige levinumate tootjate marsruutereid. Kuid mõistsin, et see on lõputu võidujooks toetatavate ettevõtete loendi laiendamiseks. Veelgi enam, isegi need, mis juba on toetatud, võivad mudelist mudelisse omada erinevat käskude komplekti NAT-reeglite muutmiseks. Ainus väljapääs olukorrast näis olevat VPN.
Kuna otsustasime toodet levitada, kuid mitte avatud lähtekoodiga, ei saanud me kaasata oma koostisse erinevaid GPL-tüüpi avatud litsentsidega raamatukogu. See on üldse eraldi teema, pärast toote müügile suunamise otsust tuli meil läbi vaadata pool raamatukogudest, kuna need olid GPL. Kui me seda endale kirjutasime, oli see normaalne. Kuid levitamiseks ei sobi. Esimene VPN, mis pähe tuleb, on OpenVPN. Kuid see on GPL. Veel oli võimalus kasutada Jaapani SoftEther VPNi. Selle litsents lubas selle oma toote koostisse lisada. Pärast mitme päevase katsetamise tegemist, et integreerida see nii, et kasutajal ei oleks vaja seda seadistada ega SoftEther VPNi kohta midagi teada — valmis prototüüp. Kõik oli nii nagu pidi. Kuid mingil põhjusel häiris meid siiski see skeem ja lõpuks otsustasime sellest loobuda. Loomulikult loobusime sellest pärast seda, kui olime leidnud teise variandi. Lõpuks tegime kõik tavaliste TCP-ühenduste peale. Osa ühendustest töötab koordineerija kaudu, osa otse tehnoloogia NAT Hole Punching (NHP) kaudu, mida rakendati ka Free Pascalis. Pean ütlema, et NHP-st ei olnud ma varem isegi kuulnud. Ja ei tulnud pähe, et võiks kahe NAT-i taga asuva võrku seadme vahepeal otse ühendada. Uurisin teemat, sain aru, kuidas see töötab ja hakkasin kirjutama. Mida kavandatud, see teostati: kasutaja saab RDP, SSH või Winbox kaudu NAT-i taga olevale seadmele ühendada ühe klõpsuga ilma paroole ja VPN-i seadistamist sisestamata. Pealegi toimub suurem osa neist ühendustest meie koordineerijast mööda, mis tõukab pinget ja teeninduse maksumust.
Serveri Linuxilt Windowsile ülemineku protsess
Üleminek Windowsile tõi esile mitmed probleemid. Esiteks, Windowsi sisseehitatud wmic ei võimalda teha WQL päringuid, samas kui meie süsteem tugines juba neile. Ja oli veel midagi, aga nüüd ei meenugi, miks sellest kasutamisest lõpuks loobusid. Võimalik, et erinevused Windowsi versioonide vahel. Teiseks probleemiks oli mitme tahkuse töötlus. Otsides sobiva litsentsiga kõrge kvaliteediga kolmanda osapoole utiliiti, avasin taas IDE Lazaruse ning kirjutasin vajaliku utiliidi. Sisendiks on vajalik objektide nimekiri ja täpsed päringud, mida teha, ja vastuseks saan vajalikud andmed. Ja kõik see toimub mitme tahkuse režiimis. Suurepärane.
Pärast pthreads'i seadistamist PHP Windows'is arvasin, et kõik töötab kenasti, aga ei sajnud. Pärast natukest tõrgetes veedetud aega sain aru, et pthreads töötab justkui, kuid meie süsteemis mitte. Selgeks sai, et Windows'is on pthreads'iga töötamisel mingi eripära. Ja nii oligi. Lugesin dokumentatsiooni, kus oli kirjas, et Windows'is on nihete arv piiratud ja, kui ma õigesti mäletan, mitteavalikult. See osutus probleemiks. Kui hakkasin vähendama nihete arvu, millega rakendus töötas, siis tegi see tööd väga aeglaselt. Avasin uuesti IDE ja lisasin sama utiliidi mitme otsingu funktsiooni. Ja lisaks ka portsikaane skaneerimine. Pärast seda kadus vajadus PHP vahel pthreads'i järele ja seda enam ei kasutata. Edasi lisati sellele utiliidile veel mitu funktsiooni ja see töötab siiani. Pärast seda koostati Windows'i installer, mis sisaldas Apache't, PHP-d, MariaDB-d, ise PHP rakendust ja komplekti utiliite süsteemiga suhtlemiseks, kirjutatud Free Pascalis. Mis puutub installerisse, siis arvasin, et lahendan selle kiiresti, kuna see on ülilevinud ja kõrvaline asi igasugusele tarkvarale. Küll ma ei osanud otsida, või siis oli veel midagi muud. Aga ma leidsin pidevalt tooteid, mis olid kas liiga jäigad või kallid ja ka jäigad. Ja siiski leidsin tasuta installeri, kus sai arvesse võtta kõiki soovitud funktsioone. See on InnoSetup. Kirjutan siia, kuna pidin natuke otsima, äkki säästan kellelgi aega.
Plugina loobumine oma klientide kasuks
Olen varem kirjutanud, et kliendi osaks oli brauser koos "pluginaga". Oli aegu, mil Chrome uuendus ja kujundus muutus veidi kohmakaks, siis uuendus Windows ja custom uri skeem kadus. Tõeliselt ei soovinud selliseid üllatusi toote avalikus versioonis. Eriti kuna custom uri kadusid pärast igat Windowsi uuendust. Microsoft lihtsalt kustutas kõik mitte tema harud vajalikus osas. Lisaks ei luba Google Chrome enam mäletada, kas avada rakendust custom uri kaudu või mitte, ja küsib seda igal objekti klõpsamisel. Üldiselt oli vajalik normaalne suhtlemine kohaliku süsteemiga, mida brauser ei paku. Kõige lihtsam lahendus tundub olevat teha oma brauser, nagu paljud nüüd teevad Electroni kaudu. Kuid paljud asjad olid kirjutatud Free Pascalis, sealhulgas serveriosa, seega otsustasime ka kliendi teha samas keeles ja mitte luua erinevat zooparki. Nii kirjutati klient Chromiumiga pardal. Pärast seda hakkas see koguma erinevaid lisandusi.
Väljalase
Lõpuks valisime süsteemile nime. Me pidevalt kaalume erinevaid variante, samas kui muundamise protsess käis kohalikust versioonist SaaS-iks. Kuna me algselt planeerisime siseneda mitte ainult koduturule, oli peamiseks kriteeriumiks nime valimisel vaba või mitte liiga kallis domeen zone '.com'. Mõned funktsioonid/moduulid ei olnud veel kohalikust versioonist Veliamisse kantud, kuid otsustasime, et käivitame praegu olemasoleva funktsionaalsusega ja jääme hilisemaid täiendusi juba värskenduste kaudu. Esialgses versioonis ei olnud HelpDeski, Veliam Connectorit, ei saanud muuta teatamisjärelvõtu piiranguid ja palju muud. Ostsime Code Sign Certificate'i, allkirjastasime kliendipoolse ja serveripoolse osa. Koostasime tootele veebilehe, alustasime tarkvara, kaubamärgi jne registreerimise protseduure. Olenemata kõigest olime valmis alustama. Kergelt õhku täis tunne tehtust ja teadmisest, et ehk kasutab keegi sinu toodet, kuigi selles osas ei olnud meil kahtlusi. Ja siis stopp. Partner ütles, et turule ei saa siseneda ilma teavitusteta sõnumirakendustesse. Ilma paljude muude asjadeta võib, aga mitte selleta. Pärast lühikesi vaidlusi, lisasime Telegrami integreerimise, mis sobis meile. Kõigist praegustest sõnumirakendustest on see ainus, mis annab tasuta juurdepääsu oma API-le ja ilma keerulisi kooskõlastamisprotseduure. WhatsApp küsib samasuguste teenuste kasutamise eest raha, kõik kirjad paludes juurdepääsu ilma vahendajateta jäeti tähelepanuta. Noh, Viber... Ma ei tea, kes seda praegu kasutab, kuna rämps ja reklaam on seal üle uue piiri. Detsembri lõpus, pärast mitmeid siseseid katsetusi ja katsetusi sõprade seas, avasime registreerimise kõigile ja panime tarkvara allalaadimiseks välja.
Käivitamine
Juba algusest peale mõistsime, et vajame väikest kasutajate voogu süsteemis, et nad saaksid toodet reaalses režiimis testida ja mingit esimest tagasisidet anda. Mitmed ostetud postitused VK-s tõid vilja. Esimesed registreerimised hakkasid tulema.
Siinkohal tuleb öelda, et turule sisenemine on väga keeruline, kui sinu ettevõttel pole tuntud nime ning samal ajal pakud agendivaba jälgimise funktsioneerimist, kuhu tuleb sisestada kontod oma serverite ja tööjaamade jaoks. Palju inimesi sellest pelgab. Meie mõistsime juba algusest peale, et sellega võivad tekkida probleemid ning olime valmis nii tehniliselt kui moraalselt. Kõik kaugühendused, vaatamata sellele, et RDP ja SSH krüpteeritakse juba vaikimisi, krüpteeritakse lisaks meie tarkvara abil AES-standardi järgi. Kõik andmed kohalikest serveritest edastatakse pilve üle HTTPSi. Kontod hoitakse krüpteeritud kujul. Krüpteerimisvõtmed kõigi süsteemide jaoks on kõigi klientide jaoks individuaalsed. Kaugühenduste puhul kasutatakse üldse seansivõtmeid.
Kõik, mida me selles olukorras teha saame, et inimesi rahustada, on olla võimalikult avatud, töötada turvalisuse nimel ja mitte väsida vastamast inimestele nende muresid tekitavatele küsimustele.
Paljude jaoks kaaluvad tarkvara mugavus ja funktsionaalsus üles hirmu ning nad registreeruvad. Mõned isikud on VK-s avaldatud postitustes kirjutanud, et seda tarkvara ei saa kasutada, kuna see kogub nende paroole ja on üldiselt tundmatu ettevõte. Tuleb öelda, et selline arvamus ei olnud ainus. Paljud lihtsalt ei mõista, et kui nad installivad oma serverisse mõnda teist patentitud tarkvara, mis töötab teenusena, on sel samuti süsteemis täiendavad õigused ja neile ei ole vajalikud kontod, et teha midagi seadusevastast (muidugi on võimalik muuta, millise kasutaja alt teenus töötab, kuid sama on ka siin, sisestada võib iga kasutajakonto). Tegelikult on inimeste mured arusaadavad. Tarkvara installimine serverisse on tavaline asi, kuid konto sisestamine on juba veidi hirmutav ja intiimne, kuna headel pooltel inimestel on üks parool kõikidele teenustele ning eraldi konto isegi katsetamiseks loomisele ei viitsita. Kuid praegusel hetkel on tohutult palju teenuseid, millele inimesed usaldavad oma kontode andmed ja mitte ainult. Meie eesmärk on saada üheks neist.
Palju kommentaare oli selliseid, et me oleme kuskilt selle varastanud. See üllatas meid veidi. Noh, ühe inimese arvamus, kuid selliseid kommentaare oli erinevates väljaannetes erinevatelt inimestelt. Alguses ei teadnud me, kuidas sellele reageerida. Kas peaks kurvastama, et mõnede arvates ei suuda Venemaal keegi midagi ise teha, vaid saavad ainult varastada, või rõõmustama, et arvavad, et sellist asja on võimalik ainult varastada.
Praegu oleme lõpetanud EV Code Sign Certificate'i saamise protseduuri. Selle saamiseks tuleb läbida mitmeid kontrollimisi ja esitada hulk dokumente ettevõtte kohta, millest osa peab olema tõestatud advokaadi poolt. EV Code Sign sertifikaadi saamine pandeemia tingimustes on täielikult eraldi artikli teema. Protsess kestis kuu aega. Ja see oli kuu, mitte ootamine, vaid pidevad lisadokumentide nõudmised. Võib-olla pandeemial siin ei ole osa ja kõigil kulges protsess nii kaua? Jagage oma kogemusi.
Mõned ütlevad, et ei hakka teenust kasutama, kuna puudub FSTEK sertifikaat. Peame selgitama, et me ei saa seda saada ja ei plaani, kuna selle sertifikaadi saamiseks peab krüpteerimine vastama GOST nõuetele, kuid plaanime tarkvara levitamist mitte ainult Venemaal ja kasutame AES-i.
Need kommentaarid süvendasid teatud ebakindlust, et kas on võimalik edendada toodet, mille jaoks tuleb luua kontosid, olles samal ajal mitte tuntud. Isegi arvestades, et teadsime, et leidub neid, kes on selle suhtes väga negatiivselt meelestatud. Pärast seda, kui registreerumiste arv ületas tuhat, lõpetasime sellega muretsemise. Eriti pärast seda, kui negatiivsete arvustuste kõrval, mille andsid need, kes produktsiooni isegi katsetanud ei olnud, hakkasid ilmnema ka väga positiivsed tagasisided. Tuleb öelda, et need positiivsed tagasisided on kõige suurem motivatsioon toote arendamiseks.
Kaugjuhtimise funktsionaalsuse lisamine töötajatele
Üks sagedasemaid kliendiküsimusi on: "Kuidas saada Vane ligipääs oma arvutile kodust?" Seadsime VPN-i Mikrotikule ja lõime kasutajatele kontod. Kuid see on tõeline probleem. Kasutajad ei suuda instruktsioone lugeda ja järgida, et VPN-i ühendust luua. Erinevad Windowsi versioonid. Ühes süsteemis kõik toimib hästi, teises on vajalikud teised protokollid. Ja üldiselt on see alati seotud VPN-serverina toimiva võrku seadme seadistamisega, millele ei ole kõigil töötajatel ligipääsu ja see oli ebamugav.
Kuid meil on juba kaugühendused serverite ja võrgu seadmetega. Miks mitte kasutada olemasolevat transporti ja luua eraldi väike utiliit, mille saaks lihtsalt kasutajale anda ühendamiseks? Soovitud oli vaid see, et kasutaja ei peaks seal midagi keerulist sisestama. Lihtsalt üks nupp 'ühenda'. Kuid kuidas see utiliit mõistab, kuhu ühenduda, kui seal on ainult üks nupp? Oli idee online rakenduse koostamisest meie serverites. Süsteemiadministraator vajutab nuppu 'laadi alla otsetee', ja meie pilve saadetakse käsk individuaalse binaari koostamiseks, kuhu on sisse kirjutatud ühendamise teave soovitud serveri/ arvuti RDP kaudu. Üldiselt oleks seda saanud teha. Kuid see on aeganõudev, administraator oleks pidanud esmalt ootama, kuni binaar koostatakse, ja seejärel allalaadimist. Loomulikult oleks võinud lihtsalt lisada teise faili konfiguratsiooniga, kuid see oleks juba kaks faili, ja kasutajale on lihtsuse nimel vajalik ainult üks. Üks fail, üks nupp ja mingeid installijaid. Veidi Google'i avarustes ringi vaadates, jõudsin järeldusele, et kui kompilatsiooni lõppu lisada mingisugust teavet, siis see ei riku (noh, peaaegu). Seal saab lisada isegi 'Sõda ja rahu' ja see töötab nagu enne. See oleks patt sellest mitte kasutada. Nüüd saab lihtsalt kohapeal klientide sees rakendust välja pakkuda, muide, selle nimi on Veliam Connector, ja lihtsalt kirjutada sinna lõppu vajalik udendamiseks teave. Ja ise rakendus teab, mida sellega teha. Miks ma enne sulgudes kirjutasin 'noh, peaaegu'? Sest selle mugavuse eest tuleb maksta sellega, et rakendus kaotab oma digiallkirja. Kuid me peame selle etapi juures väikest hinda sellise mugavuse eest mõistlikuks.
Kolmandate osapoolte moodulite litsentsid
Olen juba varem maininud, et pärast selle otsuse tegemist, et toode peaks olema avalikult kergesti kättesaadav ja mitte ainult isiklikuks kasutuseks, tuli mul kõvasti vaeva näha ja otsida asendusi mõnedele moodulitele, mis ei lubanud meid oma toote koostisse lisada. Ent pärast väljalaskmist avastasime juhuslikult üsna ebameeldiva asja. Veliam Serveri koostisosadena, mis oli kliendi pool, oli andmebaas MariaDB. Ja see on litsentsiga GPL. GPL litsents eeldab, et tarkvara peab olema avatud lähtekoodiga, ja kui meie toote koosseisus on MariaDB, millel on see litsents, peab ka meie toode olema selle litsentsi all. Kuid õnneks on selle litsentsi eesmärk avatud lähtekood, mitte kohtusse kaevata neid, kes on kogemata eksinud. Kui õiguste omanikul on pretensioon, peab ta kirjutama rikkumistest teavitama ja rikkumise heastamiseks on aega 30 päeva. Me avastasime oma vea ise ja kirju ei saanud, seega asusime kohe vaatama, kuidas probleemi lahendada. Lahendus osutus ilmselgeks — üleminek SQLite-le. Sellel andmebaasil ei ole litsentseerimise osas mingeid piiranguid. Enamik kaasaegseid brausereid kasutab SQLite-d, samuti palju teisi programme. Olen internetis kohanud teavet, et SQLite loetakse maailma kõige levinumaks andmebaasiks, just tänu brauseritele, kuid tõendeid selle kohta ei otsinud, nii et see on ebatäpne informatsioon. Alustasin uurimist, milliseid tagajärgi võib SQLite-le üleminek kaasa tuua.
See muutub korralikuks väljakutseks, kui klientidel on paigaldatud mitu sada MariaDB serverit koos andmetega. Mõned MariaDB funktsioonid ei ole SQLite's saadaval. Näiteks koodis kasutati päringuid nagu
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
See konstruktsioon mitte ainult ei vali andmeid tabelist, vaid blokeerib ka vastavad read. Kindlasti pidin ümber kirjutama ka mitmeid teisi konstruktsioone. Kuid lisaks sellele, et pidin ümber kirjutama palju päringuid, tuli mul välja mõelda mehhanism, mis klientide Veliam Serveri uuendamisel kõik andmed uude andmebaasi portib ja vana kustutab. Samuti ei töötanud SQLite'is tehingud, mis oli tõeline probleem. Kuid pärast internetis uurimist leidsin ma probleemideta, et SQLite'is on võimalik tehingud sisse lülitada, edastades ühenduse loomisel lihtsa käsu
PRAGMA journal_mode=WAL;Lõpuks on ülesanne täidetud ja nüüd töötab klientide serveri osa SQLite'il. Me ei ole süsteemi töö osas märganud mingeid muutusi.
Uus HelpDesk
Sisemisest versioonist SaaS versiooniks oli vajalik HelpDeski süsteemi migreerimine, kuid teatud muudatustega. Esimene soov oli integreerida kliendi domeen, et tagada kasutajate sujuv autentimine süsteemis. Praegu peab kasutaja, et siseneda HelpDeski ja esitada süsteemis oma taotlus, lihtsalt klõpsama töölaual oleval otseteel ja avama veebibrauseri. Kasutaja ei sisesta mingeid kasutajatunnuseid. Apache SSPI moodul, mis on osa Veliam Serverist, autoriseerib kasutaja automaatselt domeeni kasutajakontoga. Kui kasutaja asub väljaspool ettevõtte võrku ja soovib süsteemis taotlust esitada, vajutab ta nuppu ning talle saadetakse e-posti teel link, mille kaudu saab ta süsteemi HelpDesk ilma paroole sisestamata. Kui kasutaja domeenis deaktiveeritakse või kustutatakse, siis lakkab ka tema HelpDeski konto töötamast. Nii ei pea süsteemi administraator enam jälgima kasutajakontosid ei domeenis ega HelpDeskis. Kui töötaja on lahkunud, piisab domeeni kasutajakonto deaktiveerimisest ning kõik — ta ei saa enam süsteemi siseneda, ei ettevõtte võrgust ega lingi kaudu. Selle integreerimise toimimiseks peab süsteemi administraator looma ühe GPO, mis ja .
Teiseks, mida peame HelpDesk süsteemide jaoks äärmiselt vajalikuks, vähemalt meie jaoks, on ühendamine taotlejaga otse ülesandest ühe klikiga. Veelgi enam, ühendused peavad toimuma isegi siis, kui süsteemi administraator on teises võrgus. See on hädavajalik väliselt, aga ka sisemiste süsteemi administraatorite jaoks on see sageli väga vajalik. Juba on olemas mitu toodet, mis lahendavad kaugühenduse ülesande suurepäraselt. Oleme otsustanud luua neile integratsioonid. Praegu oleme teinud integratsiooni VNC jaoks ja tulevikus plaanime lisada Radmini ja TeamVieweri. Kasutades meie võrgutransporti kaugühendusteks infrastruktuuri, oleme taganud, et VNC ühendub kaugjaamadeni NAT-i kaudu. Sama kehtib ka Radmini kohta. Praegu, et kasutajaga ühenduda, tuleb lihtsalt ülesandes vajutada nuppu "ühenduda taotlejaga". Avaneb VNC klient ja see ühendub taotlejaga, sõltumata sellest, kas olete samas võrgus või kodus slippersitega. Eelnevalt peab süsteemi administraator GPO vahenditega seadistama kõigile tööjaamadele VNC Serveri.
Praegu kolime ise uuele HelpDeskile ja kasutame domeeni ja VNC integreerimist. See on meie jaoks väga mugav. Nüüd ei pea me maksma TeamVieweri eest, mida oleme kasutanud rohkem kui kolm aastat meie tugiteenuse tööks.
Mida plaanime edaspidi teha
Toote väljalaskmisel ei planeerinud me mingeid tasulisi pakette, vaid piirasime tasuta paketi 50 jälgitava objektiga. Arvasime, et viiskümmend võrguseadet ja serverit peaks kõigile piisama. Siis aga hakkasid tulema päringud limiidi suurendamiseks. Ükski sõna ei suuda edasi anda meie üllatust — kas tõesti on meie tarkvara huvi äratanud kompanii, kellel on nii palju servereid? Me laiendasime tasuta limiiti nende jaoks, kes niisuguseid päringuid esitasid. Mõnede puhul küsisime, miks nad nii palju vajavad, kas neil on tõesti nii palju servereid ja võrguvarustust. Selgus, et süsteemi hakkasid kasutama süsteemiadministraatorid, nagu me polnud plaaninud. Kõik oli lihtsalt — meie tarkvaraga hakati jälgima mitte ainult servereid, vaid ka tööjaamu. Sealt ka palju päringuid limiitide suurendamiseks. Praeguseks oleme tutvustanud tasulisi pakette ning limiite on võimalik nüüd iseseisvalt suurendada.
Serverid töötavad peaaegu alati kas SAN-idega või RAID-kogude kohalike ketastega. Me valmistame tooteid nende jaoks. SMART-i jälgimine ei pakkunud selle ülesande jaoks suurt huvi. Kuid arvestades, et inimesed kohandasid tarkvara tööjaamade jälgimiseks, on ilmunud nõudlus SMART-i jälgimise teostamiseks. Varsti viime selle ellu.
Veliam Connectori tulekuga pole enam vaja VPN-serverit ettevõtte võrgus seadistada, RDGW-d luua või lihtsalt portide suunamist vajalikesse masinatesse RDP-ühenduse loomiseks. Paljud kasutavad meie süsteemi selleks, et luua kaugühendusi. Veliam Connector on saadaval ainult Windowsile, kuid mõned ettevõtte kasutajad ühenduvad kodustes MacOS-i sülearvutites oma tööjaamade või ettevõtte tööterminalide juurde. Tulemuseks on see, et süsteemiadministraator peab mitme kasutaja tõttu siiski tegelema portide suunamise või VPN-i seadistamisega. Seetõttu viime praegu lõpule Veliam Connectori MacOS-i versiooni arendamist. Ka Apple'i seadmete kasutajad saavad minna korporatiivsete infrastruktuuride juurde ühe hiireklõpsuga.
Mulle meeldib, et kui süsteemil on palju kasutajaid, ei pea tundma muret, mida inimestele vaja on ja mis oleks mugavam. Nad ise kirjutavad oma soovid, nii et lähitulevikuks on arendamise plaane väga palju.
Samas plaanime praegu süsteemi tõlkida inglise keelde ja levitada seda välismaal. Me ei tea veel, kuidas toodet väljaspool meie riiki levitada, otsime variante. Võib-olla kirjutame sellest hiljem eraldi artikli. Võib-olla oskab keegi, kes seda artiklit luges, anda õige suunaga nõu või teab ja oskab seda teha ning pakub oma teenuseid. Oleme aitamise eest tänulikud.
Allikas: habr.com
