Habr-konferenssi ei ole debyyttitarina. Aiemmin järjestimme melko suuria Toaster-tilaisuuksia 300-400 hengelle, mutta nyt päätimme, että pienet temaattiset tapaamiset olisivat merkityksellisiä, joiden suunnan voit asettaa esimerkiksi kommenteissa. Ensimmäinen tämän muodon konferenssi pidettiin heinäkuussa, ja se oli omistettu taustakehitykselle. Osallistujat kuuntelivat Valtion palveluportaalissa raportteja taustajärjestelmästä ML:ään siirtymisen ominaisuuksista ja Quadrupel-palvelun suunnittelusta sekä osallistuivat myös Serverlessille omistettuun pyöreän pöydän keskusteluun. Niille, jotka eivät päässeet osallistumaan tapahtumaan henkilökohtaisesti, kerromme tässä postauksessa mielenkiintoisimmat asiat.
Taustakehityksestä koneoppimiseen
Mitä tietosuunnittelijat tekevät ML:ssä? Miten taustakehittäjän ja ML-insinöörin tehtävät ovat samanlaisia ja erilaisia? Mitä polkua sinun on valittava vaihtaaksesi ensimmäinen ammattisi toiseksi? Tämän kertoi Alexander Parinov, joka aloitti koneoppimisen 10 vuoden taustatyön jälkeen.
Aleksanteri Parinov
Nykyään Alexander työskentelee tietokonenäköjärjestelmien arkkitehtina X5 Retail Groupissa ja osallistuu avoimen lähdekoodin projekteihin, jotka liittyvät tietokonenäköön ja syväoppimiseen (github.com/creafz). Hänen taitonsa vahvistaa hänen osallistuminen koneoppimiskilpailujen suosituimman alustan, Kaggle Masterin (kaggle.com/creafz) maailmanlistan sadan parhaan joukkoon.
Miksi siirtyä koneoppimiseen?
Puolitoista vuotta sitten Jeff Dean, Googlen syvään oppimiseen perustuvan tekoälytutkimusprojektin Google Brainin johtaja, kuvaili, kuinka puoli miljoonaa koodiriviä Google Translatessa korvattiin Tensor Flow -hermoverkolla, joka koostuu vain 500 rivistä. Verkon koulutuksen jälkeen tiedon laatu parani ja infrastruktuuri yksinkertaistui. Näyttää siltä, että tämä on valoisa tulevaisuutemme: meidän ei enää tarvitse kirjoittaa koodia, riittää, että valmistamme hermosoluja ja täytämme ne tiedoilla. Mutta käytännössä kaikki on paljon monimutkaisempaa.
ML-infrastruktuuri Googlessa
Neuroverkot ovat vain pieni osa infrastruktuuria (pieni musta neliö yllä olevassa kuvassa). Tietojen vastaanottamiseen, käsittelyyn, tallentamiseen, laadun tarkistamiseen jne. tarvitaan monia muita apujärjestelmiä. Tarvitsemme infrastruktuurin koulutukseen, koneoppimiskoodin käyttöönottoon tuotannossa ja tämän koodin testaamiseen. Kaikki nämä tehtävät ovat täsmälleen samanlaisia kuin taustakehittäjät.
Koneoppimisprosessi
Mitä eroa on ML:n ja taustajärjestelmän välillä?
Klassisessa ohjelmoinnissa kirjoitamme koodia ja tämä sanelee ohjelman käyttäytymisen. ML:ssä meillä on pieni mallikoodi ja paljon dataa, jota heitämme malliin. ML-tiedot ovat erittäin tärkeitä: sama malli, joka on koulutettu eri tietoihin, voi näyttää täysin erilaisia tuloksia. Ongelmana on, että tiedot ovat lähes aina hajallaan ja tallennettu eri järjestelmiin (relaatiotietokannat, NoSQL-tietokannat, lokit, tiedostot).
Tietojen versiointi
ML vaatii paitsi koodin versioimista, kuten klassisessa kehityksessä, myös datan: on ymmärrettävä selvästi, mihin malliin on opetettu. Voit tehdä tämän käyttämällä suosittua Data Science -versionhallintakirjastoa (dvc.org).
Tietojen merkintä
Seuraava tehtävä on tietojen merkitseminen. Merkitse esimerkiksi kaikki kuvan kohteet tai sano mihin luokkaan se kuuluu. Tämän tekevät erikoispalvelut, kuten Yandex.Toloka, jonka työtä yksinkertaistaa huomattavasti API:n läsnäolo. Vaikeuksia syntyy ”inhimillisestä tekijästä”: voit parantaa tiedon laatua ja vähentää virheet minimiin antamalla saman tehtävän useille esiintyjille.
Visualisointi Tensor Boardissa
Kokeiden kirjaaminen on välttämätöntä tulosten vertaamiseksi ja parhaan mallin valitsemiseksi joidenkin mittareiden perusteella. Visualisointiin on olemassa suuri joukko työkaluja - esimerkiksi Tensor Board. Mutta ei ole olemassa ihanteellisia tapoja tallentaa kokeita. Pienet yritykset tyytyvät usein Excel-taulukkoon, kun taas suuret käyttävät erityisiä alustoja tulosten tallentamiseen tietokantaan.
Koneoppimisen alustoja on monia, mutta mikään niistä ei kata 70 % tarpeista
Ensimmäinen ongelma, joka on kohdattava, kun koulutettu malli otetaan tuotantoon, liittyy datatieteilijöiden suosikkityökaluun - Jupyter Notebookiin. Siinä ei ole modulaarisuutta, eli tulos on sellainen koodin "jalkaliina", jota ei ole jaettu loogisiin osiin - moduuleihin. Kaikki on sekaisin: luokat, funktiot, kokoonpanot jne. Tätä koodia on vaikea versioida ja testata.
Kuinka käsitellä tätä? Voit erota itsestäsi, kuten Netflix, ja luoda oman alustan, jonka avulla voit käynnistää nämä kannettavat tietokoneet suoraan tuotantoon, siirtää tietoja niihin syötteenä ja saada tuloksia. Voit pakottaa mallia tuotantoon vievät kehittäjät kirjoittamaan koodin uudelleen normaalisti, jakamaan sen moduuleiksi. Mutta tällä lähestymistavalla on helppo tehdä virhe, eikä malli toimi tarkoitetulla tavalla. Siksi ihanteellinen vaihtoehto on kieltää Jupyter Notebookin käyttö mallikoodina. Tietenkin jos datatutkijat suostuvat tähän.
Malli mustana laatikkona
Helpoin tapa saada malli tuotantoon on käyttää sitä mustana laatikkona. Sinulla on jonkinlainen malliluokka, sinulle annettiin mallin painot (opetetun verkon neuronien parametrit), ja jos alustat tämän luokan (kutsut ennustusmenetelmäksi, syötät sen kuvan), saat tietyn ennuste tulosteena. Mitä sisällä tapahtuu, ei ole väliä.
Erillinen palvelinprosessi mallin kanssa
Voit myös nostaa tietyn erillisen prosessin ja lähettää sen RPC-jonon kautta (kuvien tai muun lähdedatan kanssa. Lähdössä saamme ennusteita.
Esimerkki mallin käyttämisestä Flaskissa:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Tämän lähestymistavan ongelmana on suorituskyvyn rajoitus. Oletetaan, että meillä on datatieteilijöiden kirjoittama Phyton-koodi, joka on hidasta, ja haluamme puristaa maksimaalisen suorituskyvyn. Voit tehdä tämän käyttämällä työkaluja, jotka muuntavat koodin alkuperäiseksi tai muuntaa sen toiseksi tuotantoa varten räätälöityksi viitekehykseksi. Tällaisia työkaluja on jokaiselle kehykselle, mutta ihanteellisia ei ole; sinun on lisättävä ne itse.
ML:n infrastruktuuri on sama kuin tavallisessa taustajärjestelmässä. On olemassa Docker ja Kubernetes, vain Dockerille sinun on asennettava ajonaika NVIDIAsta, mikä sallii kontin sisällä olevien prosessien pääsyn isäntäkoneen näytönohjainkortteihin. Kubernetes tarvitsee laajennuksen, jotta se voi hallita palvelimia näytönohjaimella.
Toisin kuin klassisessa ohjelmointissa, ML:n tapauksessa infrastruktuurissa on monia erilaisia liikkuvia elementtejä, jotka on tarkistettava ja testattava - esimerkiksi tietojenkäsittelykoodi, mallin koulutusputkisto ja tuotanto (katso kaavio yllä). On tärkeää testata eri putkien osia yhdistävää koodia: osia on monia ja ongelmia syntyy hyvin usein moduulien rajoilla.
Miten AutoML toimii
AutoML-palvelut lupaavat valita tarpeisiisi optimaalisen mallin ja kouluttaa sen. Mutta sinun on ymmärrettävä: tiedot ovat erittäin tärkeitä ML: ssä, tulos riippuu sen valmistelusta. Merkinnät tekevät ihmiset, mikä on täynnä virheitä. Ilman tiukkaa valvontaa tulos voi olla roskaa, eikä prosessia ole vielä mahdollista automatisoida, vaan tarvitaan asiantuntijoiden - datatieteilijöiden - todentaminen. Tässä AutoML hajoaa. Mutta se voi olla hyödyllistä valittaessa arkkitehtuuria - kun olet jo valmistellut tiedot ja haluat suorittaa sarjan kokeita löytääksesi parhaan mallin.
Kuinka päästä koneoppimiseen
Helpoin tapa päästä ML:ään on kehittää Pythonilla, jota käytetään kaikissa syväoppimiskehyksissä (ja tavallisissa kehyksissä). Tämä kieli on käytännössä pakollinen tällä toiminta-alalla. C++:aa käytetään joissakin tietokonenäkötehtävissä, esimerkiksi itseohjautuvien autojen ohjausjärjestelmissä. JavaScript ja Shell - visualisointiin ja sellaisiin outoihin asioihin kuin neuronin ajamiseen selaimessa. Javaa ja Scalaa käytetään Big Datan kanssa työskentelyyn ja koneoppimiseen. Matemaattista tilastoa opiskelevat ihmiset rakastavat R:tä ja Juliaa.
Kätevin tapa hankkia käytännön kokemusta on aluksi Kaggle: osallistuminen johonkin alustan kilpailuista antaa yli vuoden opiskelua teoriaa. Tällä alustalla voit ottaa jonkun muun lähettämän ja kommentoiman koodin ja yrittää parantaa sitä, optimoida sen omiin tarkoituksiin. Bonus - Kaggle-arvosi vaikuttaa palkkaasi.
Toinen vaihtoehto on liittyä ML-tiimiin taustakehittäjäksi. On monia koneoppimisen startup-yrityksiä, joissa voit hankkia kokemusta auttamalla kollegoitasi ratkaisemaan heidän ongelmiaan. Lopuksi voit liittyä johonkin datatieteilijäyhteisöistä - Open Data Science (ods.ai) ja muihin.
Puhuja julkaisi aiheesta lisätietoja linkissä
"Quadrupel" - "Valtion palvelut" -portaalin kohdennettujen ilmoitusten palvelu
Evgeny Smirnov
Seuraavana puhujana oli sähköisen hallinnon infrastruktuurin kehittämisosaston johtaja Jevgeny Smirnov, joka puhui Quadruplesta. Tämä on kohdistettu ilmoituspalvelu Gosuslugi-portaalille (gosuslugi.ru), joka on Runetin suosituin valtion resurssi. Päivittäinen yleisö on 2,6 miljoonaa, yhteensä sivustolla on 90 miljoonaa rekisteröitynyttä käyttäjää, joista 60 miljoonaa on vahvistettu. Portaalin API:n kuormitus on 30 tuhatta RPS.
Valtion palveluiden taustalla käytetyt tekniikat
“Quadrupel” on kohdennettu ilmoituspalvelu, jonka avulla käyttäjä saa palvelutarjouksen hänelle parhaiten sopivalla hetkellä asettamalla erityiset ilmoitussäännöt. Keskeiset vaatimukset palvelua kehitettäessä olivat joustavat asetukset ja riittävä postitusaika.
Miten Quadrupel toimii?
Yllä oleva kaavio näyttää yhden Quadrupelin toimintasäännöistä esimerkkinä tilanteesta, jossa ajokortti on vaihdettava. Ensin palvelu etsii käyttäjiä, joiden viimeinen voimassaolopäivä vanhenee kuukauden kuluttua. Heille näytetään banneri, jossa on tarjous saada asianmukainen palvelu, ja viesti lähetetään sähköpostitse. Niiden käyttäjien osalta, joiden määräaika on jo umpeutunut, banneri ja sähköposti muuttuvat. Onnistuneen oikeuksien vaihdon jälkeen käyttäjä saa muita ilmoituksia - ehdotuksella identiteetin tietojen päivittämisestä.
Teknisestä näkökulmasta nämä ovat muhkeita skriptejä, joissa koodi kirjoitetaan. Syöte on dataa, tulos on tosi/epätosi, täsmäytys/ei täsmännyt. Sääntöjä on yhteensä yli 50 – käyttäjän syntymäajan määrittämisestä (nykyinen päivämäärä on sama kuin käyttäjän syntymäaika) monimutkaisiin tilanteisiin. Joka päivä nämä säännöt tunnistavat noin miljoona ottelua – ihmisiä, joille on ilmoitettava.
Quadrupel-ilmoituskanavat
Quadrupelin konepellin alla on tietokanta, johon käyttäjätiedot tallennetaan, ja kolme sovellusta:
- Työntekijä tarkoitettu tietojen päivittämiseen.
- Rest API poimii ja toimittaa itse bannerit portaaliin ja mobiilisovellukseen.
- Scheduler käynnistää työn bannerien tai joukkopostitusten uudelleenlaskentaa varten.
Tietojen päivittämistä varten taustaohjelma on tapahtumapohjainen. Kaksi käyttöliittymää - lepo tai JMS. Tapahtumia on paljon; ennen tallennusta ja käsittelyä ne kootaan yhteen, jotta ei tehdä tarpeettomia pyyntöjä. Itse tietokanta, taulukko, johon tiedot tallennetaan, näyttää avainarvovarastolta - käyttäjän avain ja itse arvo: liput, jotka osoittavat asiaankuuluvien asiakirjojen olemassaolon tai puuttumisen, niiden voimassaoloajan, aggregoidut tilastot palveluiden järjestyksestä tämä käyttäjä ja niin edelleen.
Tietojen tallentamisen jälkeen JMS:ssä asetetaan tehtävä, jotta bannerit lasketaan välittömästi uudelleen - tämä on heti näytettävä verkossa. Järjestelmä käynnistyy yöllä: JMS:ään heitetään tehtäviä käyttäjän väliajoin, jonka mukaan säännöt on laskettava uudelleen. Uudelleenlaskentaan osallistuvat prosessorit poimivat tämän. Seuraavaksi käsittelytulokset siirtyvät seuraavaan jonoon, joka joko tallentaa bannerit tietokantaan tai lähettää käyttäjäilmoitustehtävät palveluun. Prosessi kestää 5-7 tuntia, se on helposti skaalautuva, koska voit aina joko lisätä käsittelijöitä tai nostaa esiintymiä uusilla käsittelijöillä.
Palvelu toimii varsin hyvin. Tietojen määrä kuitenkin kasvaa, kun käyttäjiä on enemmän. Tämä johtaa tietokannan kuormituksen lisääntymiseen - vaikka otetaan huomioon se tosiasia, että Rest API tarkastelee kopiota. Toinen kohta on JMS, joka, kuten kävi ilmi, ei ole kovin sopiva korkean muistinkulutuksensa vuoksi. On olemassa suuri riski, että jonon ylivuoto aiheuttaa JMS:n kaatumisen ja käsittelyn pysähtymisen. Tämän jälkeen on mahdotonta nostaa JMS:ää ilman lokien tyhjentämistä.
Ongelmat on tarkoitus ratkaista shardingilla, mikä mahdollistaa tietokannan kuormituksen tasapainottamisen. Suunnitelmissa on myös muuttaa tietojen tallennusjärjestelmää ja muuttaa JMS:ksi Kafka - vikasietoisempi ratkaisu, joka ratkaisee muistiongelmia.
Backend-as-a-Service vs. Palvelimeton
Vasemmalta oikealle: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend palveluna vai palvelimeton ratkaisu? Tämän kiireellisen kysymyksen pyöreän pöydän keskusteluun osallistuivat:
- Ara Israelyan, CTO CTO ja Scorocoden perustaja.
- Nikolay Markov, Aligned Research Groupin vanhempi tietoinsinööri.
- Andrey Tomilenko, RUVDS-kehitysosaston johtaja.
Keskustelua johti vanhempi kehittäjä Alexander Borgart. Esittelemme keskustelut, joihin myös kuulijat osallistuivat, lyhennettynä.
— Mikä on palvelinton käsityksesi mukaan?
Andrew: Tämä on laskentamalli - Lambda-funktio, jonka täytyy käsitellä tietoja niin, että tulos riippuu vain tiedoista. Termi tuli joko Googlelta tai Amazonilta ja sen AWS Lambda -palvelulta. Palveluntarjoajan on helpompi käsitellä tällaista toimintoa varaamalla sille kapasiteettivarasto. Eri käyttäjät voidaan kirjata itsenäisesti samoilla palvelimilla.
Nicholas: Yksinkertaisesti sanottuna siirrämme osan IT-infrastruktuuristamme ja liiketoimintalogiikastamme pilveen, ulkoistamiseen.
ara: Kehittäjien puolelta - hyvä yritys säästää resursseja, markkinoijien puolelta - ansaita enemmän rahaa.
— Onko palvelinton sama asia kuin mikropalvelut?
Nicholas: Ei, Serverless on enemmän arkkitehtuuriorganisaatio. Mikropalvelu on jonkin logiikan atomiyksikkö. Palvelimeton on lähestymistapa, ei "erillinen kokonaisuus".
ara: Palvelimeton toiminto voidaan pakata mikropalveluun, mutta tämä ei ole enää palvelintonta, se lakkaa olemasta Lambda-toiminto. Palvelimettomassa toiminnossa toiminto alkaa toimia vasta kun sitä pyydetään.
Andrew: Ne eroavat elämänsä aikana. Käynnistimme Lambda-toiminnon ja unohdimme sen. Se toimi muutaman sekunnin, ja seuraava asiakas voi käsitellä pyyntönsä toisella fyysisellä koneella.
– Kumpi on parempi?
ara: Vaakasuunnassa skaalattaessa lambda-toiminnot toimivat täsmälleen samalla tavalla kuin mikropalvelut.
Nicholas: Riippumatta siitä, kuinka monta kopioita asetat, niitä tulee olemaan yhtä monta; Serverlessillä ei ole skaalausongelmia. Tein replikasarjan Kubernetesissa, käynnistin 20 esiintymää "jossain" ja 20 nimetöntä linkkiä palautettiin sinulle. Eteenpäin!
— Onko mahdollista kirjoittaa backend Serverlessiin?
Andrew: Teoriassa, mutta siinä ei ole järkeä. Lambda-toiminnot perustuvat yhteen tietovarastoon - meidän on varmistettava takuu. Esimerkiksi, jos käyttäjä on suorittanut tietyn tapahtuman, hänen pitäisi seuraavan yhteydenoton yhteydessä nähdä: tapahtuma on suoritettu, varat on hyvitetty. Kaikki lambda-toiminnot estyvät tässä puhelussa. Itse asiassa joukko palvelimettomia toimintoja muuttuu yhdeksi palveluksi, jossa on yksi pullonkaulayhteyspiste tietokantaan.
— Missä tilanteissa on järkevää käyttää palvelimetonta arkkitehtuuria?
Andrew: Tehtävät, jotka eivät vaadi jaettua tallennustilaa - sama louhinta, lohkoketju. Missä sinun täytyy tehdä paljon laskemista. Jos sinulla on paljon laskentatehoa, voit määrittää funktion kuten "laske tiiviste johonkin tuonne..." Mutta voit ratkaista ongelman tietojen tallennuksen kanssa ottamalla esimerkiksi Amazonin Lambda-funktiot ja niiden hajautetun tallennustilan. . Ja käy ilmi, että kirjoitat säännöllistä palvelua. Lambda-toiminnot pääsevät tallennustilaan ja tarjoavat käyttäjälle jonkinlaisen vastauksen.
Nicholas: Serverless-tilassa toimivien säiliöiden resurssit ovat erittäin rajalliset. Muistia on vähän ja kaikkea muuta. Mutta jos koko infrastruktuurisi on otettu käyttöön kokonaan jossain pilvessä - Google, Amazon - ja sinulla on pysyvä sopimus heidän kanssaan, kaikelle tälle on budjetti, niin joihinkin tehtäviin voit käyttää palvelimettomia säiliöitä. On välttämätöntä olla tämän infrastruktuurin sisällä, koska kaikki on räätälöity käytettäväksi tietyssä ympäristössä. Eli jos olet valmis sitomaan kaiken pilviinfrastruktuuriin, voit kokeilla. Etuna on, että sinun ei tarvitse hallita tätä infrastruktuuria.
ara: Se, että Serverless ei vaadi sinua hallitsemaan Kubernetesia, Dockeria, asentamaan Kafkaa ja niin edelleen, on itsepetosta. Sama Amazon ja Google asentavat tämän. Toinen asia on, että sinulla on SLA. Voit yhtä hyvin ulkoistaa kaiken sen sijaan, että koodaat sen itse.
Andrew: Palvelimeton itsessään on edullinen, mutta joudut maksamaan paljon muista Amazon-palveluista - esimerkiksi tietokannasta. Ihmiset ovat jo haastaneet heidät oikeuteen, koska he veloittivat järjettömiä summia API-portista.
ara: Jos puhumme rahasta, sinun on otettava huomioon tämä seikka: sinun on käännettävä koko yrityksen kehitysmetodologia 180 astetta, jotta voit siirtää kaiken koodin Serverlessille. Tämä vie paljon aikaa ja rahaa.
- Onko Amazonin ja Googlen maksullisille Serverlessille arvokkaita vaihtoehtoja?
Nicholas: Kubernetesissa käynnistät jonkinlaisen työn, se juoksee ja kuolee - tämä on arkkitehtonisesti melko palvelimetonta. Jos haluat luoda todella mielenkiintoista liiketoimintalogiikkaa jonojen ja tietokantojen avulla, sinun on mietittävä sitä hieman enemmän. Tämä kaikki voidaan ratkaista poistumatta Kubernetesista. En viitsi lykätä lisätoteutusta.
— Kuinka tärkeää on seurata, mitä Serverlessissä tapahtuu?
ara: Riippuu järjestelmäarkkitehtuurista ja liiketoimintavaatimuksista. Pohjimmiltaan palveluntarjoajan on toimitettava raportit, jotka auttavat devops-tiimiä ymmärtämään mahdolliset ongelmat.
Nicholas: Amazonilla on CloudWatch, jossa kaikki lokit striimataan, mukaan lukien Lambdan lokit. Integroi lokin edelleenlähetys ja käytä erillistä työkalua katseluun, hälytykseen ja niin edelleen. Voit pakata agentteja aloittamiisi astioihin.
- Tehdään yhteenveto.
Andrew: Lambda-toimintojen ajatteleminen on hyödyllistä. Jos luot palvelun itse - ei mikropalvelun, vaan sellaisen, joka kirjoittaa pyynnön, käyttää tietokantaa ja lähettää vastauksen - Lambda-toiminto ratkaisee useita ongelmia: monisäikeisyyden, skaalautuvuuden ja niin edelleen. Jos logiikkasi on rakennettu tällä tavalla, voit tulevaisuudessa siirtää nämä lambdat mikropalveluihin tai käyttää kolmannen osapuolen palveluita, kuten Amazon. Tekniikka on hyödyllinen, idea on mielenkiintoinen. Kuinka perusteltua se on liiketoiminnalle, on edelleen avoin kysymys.
Nikolay: Palvelimetonta on parempi käyttää operatiivisiin tehtäviin kuin jonkin liikelogiikan laskemiseen. Ajattelen sitä aina tapahtumankäsittelynä. Jos sinulla on se Amazonissa, jos olet Kubernetesissa, kyllä. Muuten joudut tekemään paljon vaivaa saadaksesi Serverlessin toimimaan itse. On tarpeen tarkastella tiettyä liiketoimintatapausta. Esimerkiksi yksi tehtävistäni nyt on: kun tiedostot ilmestyvät levylle tietyssä muodossa, minun on ladattava ne Kafkaan. Voin käyttää WatchDogia tai lambdaa. Loogisesta näkökulmasta molemmat vaihtoehdot ovat sopivia, mutta toteutuksen kannalta Serverless on monimutkaisempi ja pidän parempana yksinkertaisempaa tapaa, ilman Lambdaa.
ara: Serverless on mielenkiintoinen, käyttökelpoinen ja teknisesti erittäin kaunis idea. Ennemmin tai myöhemmin tekniikka saavuttaa pisteen, jossa mikä tahansa toiminto käynnistyy alle 100 millisekunnissa. Silloin ei periaatteessa ole kysymys siitä, onko odotusaika kriittistä käyttäjälle. Samaan aikaan Serverlessin soveltuvuus, kuten kollegat ovat jo sanoneet, riippuu täysin liiketoimintaongelmasta.
Kiitämme sponsoreitamme, jotka auttoivat meitä paljon:
- IT-konferenssitila «» konferenssisivustolle.
- IT-tapahtumien kalenteri ja julkaisu"» tietoa tuesta ja uutisista.
- «"lahjoille.
- yhteisluomiseen.
- "Sähköisen viestinnän yhdistys" osallistumista ja kokemusta varten.
- Pääsponsori - kaikille!
Lähde: will.com