Serverivaba andmetöötlus

Allikas: Vikipeedia
Jump to navigation Jump to search

Serverivaba andmetöötlus (inglise keeles serverless computing) on pilveandmetöötluse (inglise keeles cloud computing) laiendusmudel, milles pilveteenuse pakkuja toimib serverina, jaotades dünaamiliselt masina ressursse. Serverivaba andmetöötluse puhul määratakse hind sõltuvalt vajalikest vahenditest, mida rakendus kasutab töö tegemiseks, tarbimisele erinevalt pilveandmetöötlusest, kus hinnakujundus põhineb eelnevalt ostetud ruumil.[1]

Serverivaba andmetöötluse nimetus tuleneb sellest, et serveri haldamise ja võimsuse planeerimise otsused on täielikult peidetud arendaja või operaatori eest. Serverivaba koodi saab kasutada koos traditsioonilistes stiilides kasutatavate koodidega, näiteks mikroteenustega.[2] Enamik, kuid mitte kõik, serveriversioonide pakkujaid esitavad arvutamisperioodi, mis on tuntud ka kui FaaS-platvormid (inglise keeles Function as a Service), mis täidavad rakenduste loogikat, kuid ei salvesta andmeid.

Ajalugu[muuda | muuda lähteteksti]

Esimene platvorm, mis pakkus serverivaba andmetöötlust, oli 2006. aastal Zimki, mis aga ei leidnud piisavalt tunnustust ega saanud äriliselt edukaks.[3] Google avaldas 2008. aastal Google App Engine, mis tutvustas mõõdetud arveldamist rakendustele, mis kasutasid kohandatud Pythoni raamistikku.[4] Microsoft andis 2010. aastal välja Microsoft Azure, mis pakub pilve- ja serverivaba andmetöötluse platvormi.[5] 2014. aastal Amazoni loodud AWS Lambda oli esimene pilveandmetöötluse müüja, pakkudes lisaks sellele ka abstraktset serverivaba andmetöötlust.[6] IBM on avaldas 2014. aastal OpenWhiski, mis on avatud lähtekoodiga serverivaba andmetöötluse platvorm.[7] OpenWhisk toetab mitmeid programmeerimiskeeli, nagu Node.js, ja pakub veel paljusid teisi programmeerimiskeeli, kasutades selleks Dockerit. Google Cloud Platform pakub Google Cloud funktsioone alates aastast 2016.[8] Oracle tutvustas 2017. aastal Fn Projekti – avatud lähtekoodiga serveriteta andmetöötluse raamistik, mis on pakutud Oracle Cloud Platformile ja on saadaval GitHubis vajadusel kasutamiseks teistel platvormidel.[9]

Eelised[muuda | muuda lähteteksti]

Serverivaba andmetöötlus võib osutuda kulutõhusamaks kui kindlaksmääratud arvu serverite rentimine või ostmine.[10][11] Kaob vajadus väljaminekuteks operatsioonisüsteemide paigaldamise, hoolduse ja muude üldkulutuste peale.[10] Seda võib kirjeldada ka kui ümberjaotuse põhimõttel toimivat (inglise keeles pay-as-you-go) digitaalarvutamist, kus tasu võetakse ainult sõltuvalt koodi käivitamiseks ja jooksutamiseks tuleneva aja-ruumi kulu eest (maksad siis, kui tarbid).[10]

Lisaks väiksematele kuludele tähendab serverivaba andmetöötluse arhitektuur, et arendaja ja operaatorid ei pea veetma aega süsteemide seadmistamiseks ja häälestamiseks. Pilveteenuse pakkuja vastutab nõudlusele vastava võimsuse suurenemise võimaldamise eest.[10] Lisaks sellele suudavad väikesed arendusrühmad käivitada koodi sõltumata infrastruktuurirühmadest ja tugitehnoloogiatest.

Puudused[muuda | muuda lähteteksti]

Vähese kasutusega serverivaba kood võib kannatada suurema vastuse hilinemisega (inglise keeles response latency) kui kood, mis töötab järjest spetsiaalses serveris, virtuaalses masinas või konteineris. Seda seetõttu, et erinevalt autoskaleerimisest (inglise keeles autoscaling) vähendab serverivaba andmetöötluse teenusepakkuja tavaliselt vähekasutatud koodi valmidust käivituda serveris või lülitab selle täielikult välja. See tähendab, et kui käivitusaeg (näiteks Java Runtime) on märkimisväärselt pikk, luuakse see täiendava latentsusajaga.[12]

Tõhususe või ülemäärase ressursikasutuse probleemide diagnoosimine serverivaba koodi puhul võib olla keerulisem kui tavapärase serveri koodi korral. Kõiki funktsioone saab küll ajastada, kuid puudub võimalus süvitsi probleemi siseneda. Selleks saab kasutada silurit või APM-tööriistu.[2]

Serverivaba koodi peetakse mõnikord ekslikult turvalisemaks kui traditsioonilisi arhitektuure. Kui pilveteenuse pakkuja hoolitseb OS-i haavatavuste eest, siis kogu rünnaku pind on oluliselt suurem, kuna võrreldes tavapäraste arhitektuuridega on palju rohkem komponente, millest igaüks on serverivaba rakenduse sisendpunkt. Turvaliste lahenduste kasutamine muutub ebaoluliseks, kuna kliendid ei saa lõpp-punktil (inglise keeles endpoint) või võrgu tasemel, nagu IDS/IPS, midagi kontrollida ega nendele installeerida.[13]

Vaata ka[muuda | muuda lähteteksti]

Viited[muuda | muuda lähteteksti]

  1. Miller, Ron (24 november 2015). "AWS Lambda Makes Serverless Applications A Reality". TechCrunch. Kasutatud 02.12.2018.
  2. 2,0 2,1 MSV, Janakiram (16 juuli 2015). "PaaS Vendors, Watch Out! Amazon Is All Set To Disrupt the Market". Kasutatud 02.12.2018.
  3. Williams, Christopher (25 september 2007). "Fotango to smother Zimki on Christmas Eve". c. Kasutatud 02.12.2018
  4. "Python Runtime Environment | App Engine standard environment for Python | Google Cloud Platform". Viimati muudetud 28.10.2018. Google Cloud Platform. Kasutatud 02.12.2018.
  5. Miller, Ron (31 märts 2016). "Microsoft answers AWS Lambda's event-triggered serverless apps with Azure Functions". TechCrunch. Kasutatud 02.12.2018.
  6. Miller, Ron (13 november 2014). "Amazon Launches Lambda, An Event-Driven Compute Service". TechCrunch. Kasutatud 02.12.2018.
  7. Zimmerman, Mike (23 veebruar 2016). "IBM Unveils Fast, Open Alternative to Event-Driven Programming". Kasutatud 02.12.2018.
  8. Novet, Jordan (9 veebruar 2016). "Google has quietly launched its answer to AWS Lambda". VentureBeat. Kasutatud 02.12.2018.
  9. Shaun Smith (2 oktoober 2017). "Announcing Fn–An Open Source Serverless Functions Platform". Kasutatud 02.12.2018.
  10. 10,0 10,1 10,2 10,3 Jamieson, Frazer (4 september 2017). "Losing the server? Everybody is talking about serverless architecture". Kasutatud 02.12.2018.
  11. Ryan, Fintan (29 veebruar 2016). "Swift, OpenWhisk and APIs – Reflections on IBM InterConnect". Kasutatud 02.12.2018.
  12. Rohit Akiwatkar (15 mai 2017). "The Drawbacks of Serverless Architecture". Kasutatud 02.12.2018.
  13. PURESEC (2018). The Ten Most Critical Security Risks in Serverless Architectures