Jani Similä
Azure Functions –
Serveritön arkkitehtuuri
Metropolia Ammattikorkeakoulu Insinööri (AMK)
Tietotekniikka Insinöörityö 3.12.2018
Otsikko Sivumäärä Aika
Jani Similä
Azure Functions – Serveritön arkkitehtuuri 28 sivua
03.12.2018
Tutkinto Insinööri (AMK)
Tutkinto-ohjelma Tietotekniikka Ammatillinen pääaine Sovellustekniikka Ohjaajat
Osaamisaluepäällikkö Janne Salonen
Insinöörityön tarkoitus oli tutustua ja toteuttaa pilvipalvelu käyttäen modernia serveritöntä arkkitehtuuria. Palvelun kriteereinä oli serverittömyys sekä pienet kustannukset. Etenkin kustannusrajoituksella oli selkeä vaikutus teknologiavalintoihin palvelua kehittäessä. Pilvi- palvelualustaksi valikoitui Microsoft Azure ja sen Azure Functions niminen Fuction as a Ser- vice palvelu, joka tarjosi helppokäyttöiset ja tunnetut työkalut sovelluksen kehittämiseen.
Työn alussa tutustuttiin pilvipalveluihin ja niiden historiaan yleisellä tasolla ja siihen, kuinka kehitys on johtanut serverittömän arkkitehtuurin syntymiseen. Serveritön arkkitehtuuri vaati hieman perinteisestä palveluarkkitehtuurista poikkeavaa suunnittelua ja näiden erikoisuuk- sien tutkiminen muodosti myös huomattavan osan työstä.
Tutkimuksessa perehdyttiin myös pintapuolisesti Azure Functions palvelun eri tyyppisiin funktioihin, pilvitallennusratkaisuihin ja autentikointimahdollisuuksiin serverittömässä arkki- tehtuurissa.
Varsinaisena projektina työssä oli pilvessä toimiva SaaS tyyppinen sovellus, joka tarjosi web käyttöliittymän ostoslistojen hallintaan useiden käyttäjien kesken. Työn palvelurajapinta to- teutettiin C# kielellä serverittömillä funktioilla ja käyttöliittymä puolestaan Angular 7- kirjastoa hyödyntävä web sovellus, joka palveltiin niin ikään serverittömästi Azure Blob Storagesta.
Budjettirajoituksista johtuen joitakin sovelluksen toiminnallisuuksia jouduttiin karsimaan, mutta työn tuloksena syntynyt sovellus osoittaa miten helposti ja nopeasti pilvipalveluita voi nykypäivänä toteuttaa serveritöntä arkkitehtuuria hyödyntäen.
Avainsanat serveritön, Azure, FaaS, pilvipalvelu
Title
Number of Pages Date
Azure Functions – Serveritön arkkitehtuuri 28 pages
03 December 2018
Degree Bachelor of Engineering
Degree Programme Information Technology Professional Major Software Engineering Instructors
Janne Salonen Supervisor
The goal of the thesis was to familiarize and to implement a cloud service using modern serverless architecture. The criteria for the service was to be entirely serverless and to run with minimal costs. The cost requirement ended up limiting some of the technology
choices for the implementation. Out of cloud services available Microsoft Azure and its Az- ure Functions service was selected as the platform for the project.
During the project a general knowledge of history and current situation of cloud services and how their development into serverless architecture occurred was acquired. Another focus point in the study was the serverless architecture and its special requirements for software development. The research also investigated Azure Functions service and explored its dif- ferent types of functions, authentication methods and cloud storage integration options avail- able for it.
The actual outcome of the project was a SaaS style cloud application that offered a wen user interface to manage shopping lists between multiple users. The service API was devel- oped using C# programming language with serverless functions and the user interface was implemented with Angular-7 framework. True to the nature of serverless computing the user interface was served as a single page application from Azure Blob Storage.
Even though the budget limitations forced to leave out some designed features for the ser- vice, it was still astonishing how easy and fast it was to create passable cloud application using modern serverless tools.
Keywords Serverless, Azure, FaaS, cloud, application
Sisällys
Lyhenteet
1 Johdanto 1
2 Pilvipalvelut 2
2.1 Pilvipalveluiden historia 3
2.2 Pilvipalveluiden palvelumallit 5
2.2.1 Infrastruktuuripalvelu 6
2.2.2 Alustapalvelu 7
2.2.3 Sovelluspalvelu 7
2.2.4 Funktiopalvelu 8
2.3 Pilvipalveluiden hankintamallit 9
2.4 Funktiopalvelun kehitys 10
2.4.1 Funktioilla on maksimi suoritusaika 11
2.4.2 Funktioiden välinen kommunikointi 11
2.4.3 Funktio on tilaton (Stateless) 11
2.4.4 Resurssien varaaminen 11
2.4.5 FaaS palveluiden vertailu 12
3 Azure Functions 13
3.1 Laukaisimet 13
3.1.1 Web-laukaisin 14
3.1.2 Ajastin 14
3.1.3 Sanomajono 15
3.2 Pysyvän tiedon tallennus 15
3.2.1 Blob Storage 15
3.2.2 Cosmo DB 16
3.2.3 Table Storage 16
3.3 Logiikan jakaminen funktioiden kesken 16
3.4 Autentikointi 17
4 Remindrs-sovellus 18
4.2 Remindrs-API kehitystyö 20
4.2.1 Tietokantamallin suunnittelu 21
4.2.2 Remindrs-API sovelluksen huoltofunktiot 22
4.3 Remindrs-SPA toteutus 23
4.4 Web sovelluksen jakelu serverittömässä ympäristössä 24
5 Pohdintaa 26
Lähteet 27
NIST National Institute of Standards and Technology, Yhdysvaltain stand- ardointi- ja teknologiavirasto
ARPANET Tietokannan hallintajärjestelmä. Ohjelmisto, jonka avulla hallinnoidaan tie- tokantoja.
IaaS Infrastructure as a Service, eli infrastruktuuripalveluksi kutsuttu pilvipalve- lun muoto.
PaaS Platform as a Service, eli alustapalveluksi kutsuttu pilvipalvelun muoto.
FaaS Functions as a Service, eli funktiopalveluksi kutsuttu pilvipalvelun muoto.
SaaS Software as a Service, eli sovelluspalveluksi, kutsuttu pilvipalvelun muoto.
1 Johdanto
Opinnäytetyön tarkoitus oli tutustua pilvipalveluihin ja etenkin moderniin serverittömään tapaan toteuttaa mikropalveluita. Omasta mielenkiinnosta ja tarpeesta tutkimuksen pää- aiheeksi valikoitui Microsoftin Azure Functions palvelu, joka mahdollisti nimenomaan mikropalvelun kaltaisten sovellusten nopean kehityksen ja automaattisen skaalautumi- sen.
Aluksi työssä tutustuttiin pilvipalveluiden historiaan ja nykytilaan erinäisine jakelu ja pal- velumalleineen. Pilvipalveuiden saralla verrattaen uusi palvelumalli, funktiopalvelut (FaaS), sai osakseen tarkempaa syventymistä sen ominaisesta serverittömyydestä joh- tuen. FaaS sovellusten todettiinkin vaativan hieman erilaista ajattelua perinteisellä Web palvelimella ajettavaan palveluun verraten.
Seuraavaksi työssä perehdyttiin Azure Functions palvelun työkaluihin ja funktioiden ra- kennuskomponentteihin. Lisäksi luotiin pikainen katsaus Azuren tarjoamiin serverittömiin tallennusmalleihin ja joista työn projektiosaa varten valikoitiin kustannustehokkaimmat Remindrs sovelluksen toteuttamista varten.
Työn viimeisessä osassa toteutettiin Remindrs sovellus, jonka suunnittelun periaatteina oli serverittömyys ja minimaaliset kulut. Sovellus toteutti molemmat tavoitteensa, vaikka joistakin suunnitelluista ominaisuuksista jouduttiinkin luopumaan aikataulu ja kustannus syistä. Helpon laajennettavuutensa puolesta uskonkin, että jatkan sovelluksen kehittä- mistä omaan käyttööni.
2 Pilvipalvelut
Terminä pilvipalvelu on tällä vuosikymmenellä ollut ylikäytetty ja yhdistetty monenlaisiin palveluihin. The National Institute of Standards and Technology, myöhemmin NIST, määrittelee pilvipalvelun seuraavasti. Pilvipalvelu on kokoelma tietojenkäsittely resurs- seja, jotka ovat helposti kaikkialta saatavilla ja joista voi varata asiakkaan käyttöön ja vapauttaa joko täysin ilman tai hyvin vähäisellä hallinnoinnilla palveluntarjoajan toimesta.
Tietojenkäsittely resursseja ovat esimerkiksi verkot, palvelimet, tallennusmediat, sovel- lukset sekä palvelut. NIST myös määrittelee viisi pääpiirrettä, jotka ovat olennaisia pilvi- palveluille [3.].
• Käyttäjän on voitava varata resursseja itsenäisesti ja resurssien varaami- sen tulee olla automaattista eikä vaatia henkilötyötä palveluntarjoajan puo- lelta.
• Resurssien tulee olla saatavilla verkon yli ja käyttää standardi verkkopro- tokollia ja siten mahdollistaa kaikenlaisten asiakasohjelmien yhdistämisen varattuun resurssiin.
• Palvelun resurssit ovat yhdistettynä (pooled) siten että niihin tehtyjä resurs- sivarauksia, fyysisiä ja virtuaalisia, voidaan ottaa käyttöön ja vapauttaa dy- naamisesti. Yhdistettyjen resurssien tulee olla riippumattomia fyysisestä si- jainnistaan eikä käyttäjällä tarvitse olla palvelinkeskuksen valintaa tarkem- paa kontrollia sijainnista.
• Resurssien tulee olla elastisia ja pystyä helposti tai jopa automaattisesti skaalautumaan käyttäjän tarpeen mukaan.
• Palvelussa tulee olla mekanismit käytön mittaamiseen ja raportointiin siten, että sekä palvelu tarjoaja, että käyttäjä voivat helposti muodostaa kuvan resurssien käytöstä ja siten myös laskutuksen pohjasta.
Viestintävirasto puolestaan määrittelee pilvipalvelut seuraavasti:
Pilvipalveluilla tarkoitetaan palvelumallia, jossa helposti säädettäviä usean käyttä- jän kesken jaettuja tietoteknisiä resursseja tarjotaan tietoverkkojen yli. Yhteyden- saanti pilvipalveluun on tehty mutkattomaksi. Palvelun toiminnallisuuksia voidaan kytkeä käyttöön ja pois käytöstä sekä yhdistää toisiin palveluihin nopeasti ja hel- posti käyttäjän tarpeen mukaan. Pilvipalvelun käytön ja kuormituksen seuranta on tehty helpoksi ja läpinäkyväksi. Tämä yhdessä helpon resurssien hallinnan kanssa mahdollistaa toiminnan ja kulujen optimoinnin. [2.]
Viestintäviraston määritelmä käyttää lähteenään samaa NIST dokumenttia kuin läh- teessä [3.].
Kuva 1. Pilvipalvelut tarjoavat tietojenkäsittelykapasiteettia julkisten rajapintojen kautta.
Pilvipalvelut syntyivät ratkaisemaan yritysten tietojenkäsittely infrastruktuuriin liittyviä on- gelmia. Oman laitteiston ostaminen, kokoaminen, kytkeminen ja niiden hallintaan liitty- vän henkilöstön ylläpito ovat asioita, joita modernin yrityksen ei välttämättä tarvitse poh- tia. Suomalaisista yrityksistä keskimäärin 57% käyttää pilvipalveluita jossain määrin, yleensä yrityksen henkilöstön kasvaessa myös pilvipalvelujen hyödyntäminen lisääntyy [1.].
2.1 Pilvipalveluiden historia
Pilvipalveluiden historia on kytköksissä sekä virtualisointiin että internetin historiaan. Var- haisin maininta konsepti pilvipalveluista löytyy 1961 vuodelta, jolloin John McCarthy ideoi tietojenkäsittelystä, joka olisi julkisesti samaan tapaan saatavilla kuin vesi ja sähkö [4].
Toinen hyvin keskeinen henkilö oli Joseph Carl Robnett Licklider jonka uraauurtavasta visiosta, maailmasta jossa jokainen ihminen olisi yhteydessä toisiinsa, ohjelmiin ja da- taan riippumatta fyysisestä sijainnista, pohjalta myöhemmin kehitettiin vuonna 1969 Ad- vanced Research Projects Agency Network eli ARPANET, joka toimi nykyisen Internetin edelläkävijänä [5.].
Seuraavat suuret murrokset tapahtuivat 1970-luvulla ja nämä olivat tietokoneiden virtu- aaliympäristöt sekä Internetin synty. IBM julkaisi 1972 IBM VM/370 ensimmäisen virtu- aalikone käyttöjärjestelmänsä. Tämä tarkoitti sitä, että yhdellä keskustietokoneen resurs- sit voitiin jakaa useampaan pienempään virtuaaliseen tietokoneeseen ja jakaa resurs- seja näin tehokkaammin usealle käyttäjälle samanaikaisesti. Samaan aikaan ARPANET jatkoi laajenemistaan uusien verkkojen liittyessä siihen ja lopulta näistä yhteen kytke- tyistä verkoista muodostui Internet.
Myöhemmin 1990-luvulle tultaessa World Wide Web eli WWW yleistyi räjähdysmäisesti, tästä seurasi, että internet alkoi olla helposti saatavilla niin kuluttajille kuin pienyrityksil- lekin. Vuonna 1996 termi ”Cloud Computing” eli pilvilaskenta esiintyy ensimmäistä kertaa Compaq Computer yrityksen liiketoiminta suunnitelmassa [6.]. Lopulta vuonna 1998 jul- kaistiin Salesforce.com-asiakkuudenhallintajärjestelmä. Salesforce.com oli ainutlaatui- nen alallaan, tähän asti asiakkuudenhallintajärjestelmät olivat olleet kalliita erikoissovel- luksia, joiden lisensointi ja ylläpito oli kallista ja raskasta. Salesforce.com mullisti mark- kinaa tuomalla sovelluksensa suoraan käyttäjän selaimeen rikkaana web-sovelluksena, joka oli helposti saatavilla missä päin maailmaa tahansa.
Kuva 2. Varhainen Salesforce.com näkymä
2000-luvun alussa nykyiset suuret pilvitoimijat alkoivat herätä pilvipalveluiden mahdolli- suuksiin ja Amazon julkaisi oman Amazon Web Services eli AWS palvelunsa, josta tuli
tiennäyttäjä muille pilvipalveluihin suuntaaville yrityksille. Muutaman vuoden sisällä Google seurasi omalla Google App Engine-palvelullaan ja myöhemmin Microsoft tuli markkinoille Microsoft Azure palvelullaan. Nykyisin AWS on edelleen markkinajohtaja kentällä, mutta Azure kehitys on ollut nopeaa ja hinnoittelu aggressiivista Microsoftin pyrkiessä kasvattamaan osuuttaan pilvipalveluissa.
Nykypäivänä pilvipalvelut yleistyvät entisestään ja alan uudet suuntaukset kuten serve- ritön tietojenkäsittely tuovat John McCarthyn visiota aina vain lähemmäs todellisuutta.
2.2 Pilvipalveluiden palvelumallit
Pilvipalvelut jaetaan yleisesti kolmeen luokkaan, infrastruktuuripalvelut (IaaS), alustapal- velut (PaaS) ja sovelluspalvelut (SaaS). Todellisuudessa luokkia on enemmänkin, mutta kolme edellä mainittua ovat vakiintuneet pilvipalvelujen yleisiksi luokituksiksi. Tässä työssä perehdymme tarkemmin verrattaen uuteen palvelutasoon, funktiopalveluun (FaaS), joka on parin viimevuoden aikana nostanut suosiotaan. Edellä mainitut palvelu- tasot kuvaavat sitä kuinka paljon kontrollia käyttäjällä on palvelun alustasta.
Kuva 3. Pilvipalveluiden palvelumallit listattuna
Ylläolevassa (Kuva 3.) kuvassa esitettään eri palvelumallien vastuunjakoa, asiakas vas- taa korostetuista osista ja palveluntarjoaja valkoisista.
2.2.1 Infrastruktuuripalvelu
Infrastructure as a Service eli (IaaS) on pilvipalveluiden malleista alimmalla tasolla, alin taso tarkoittaa, että se tarjoaa tilaajalle suurimman vapauden, tilaaja saa asentaa käyttöjärjestelmän ja konfiguroida alustaa vapaasti tahtonsa mukaan, mutta se tuo myös suurimman vastuun. Tilaajan tulee itse pitää alustan päivitykset ja tietoturva ajan tasalla.
Kuva 4. IaaS palvelussa asiakkaalla on enemmän vastuuta ja vapautta
Tilaajan näkökulmasta hänellä on käytössään perinteisiä tietotekniikan infrastruktuurin osia, palvelimia, tietokantoja, verkkolaitteita, joita hän voi hallinnoida vapaasti, mutta jotka perinteisestä infrastruktuurista poiketen eivät ole fyysisiä laitteita vaan palvelukes- kuksen resurssi altaasta varattuja virtuaalisia laitteita (3). Perinteisestä laitteesta eroten virtuaalisia voidaan skaalata tilaajan tarpeen mukaan, käytännössä laitteen muistin tai prosessorien lukumäärän lisääminen vaatii vain konfiguraatiomuutoksen ja palvelimen uudelleenkäynnistyksen.
Palveluntarjoajan puolella IaaS tarkoittaa yleensä virtualisointipalvelinta, jolla ajetaan niin kutsuttua HyperVisor sovellusta, joka jakaa fyysisen palvelimen resursseja pienem- piin virtuaalipalvelimiin. Näitä virtuaalipalvelimia sitten vuokrataan tilaajien käyttöön.
Useamman virtuaalisen palvelimen välille voidaan rakentaa virtuaalisia tietoverkkoja, joi- den kautta nämä kommunikoivat keskenään. IaaS palveluntarjoajat myös usein tarjoa- vat virtuaalipalvelimiensa rinnalla valmiita järjestelmäkuva-kirjastoja, joilla voidaan nope- asti alustaa palvelin haluttua tarkoitusta varten [7].
2.2.2 Alustapalvelu
Platform as a Service (PaaS) sijoittuu palveluhierarkiassa keskitasolle. Se tarjoaa tilaa- jalle valmiin ympäristön sovelluksen ajamiseen. PaaS ympäristö yleensä pitää sisällään työkalut, palvelut ja sovelluskirjastot tilaajan tilaamalle ohjelmointikielelle.
Kuva 5. Palvelussa käyttöjärjestelmä ja sovellusalusta ovat palveluntarjoajan vastuulla
Tilaajan näkökulmasta hän voi kehittää sovellustaan ja asentaa sen PaaS alustaan ja konfiguroida sovelluskirjastojen ajoympäristöä. Toisin kuin IaaS palveluissa, hänellä ei ole suoraa pääsyä palvelimiin tai verkkoihin, joiden varassa PaaS alustaa ajetaan. PaaS alusta myös tarjoaa sovellukselle automaattista elastisuutta, se osaa automaattisesti käynnistää sovelluksesta uusia instansseja.
Palveluntarjoaja PaaS palveluissa vastaa siitä, että alustan käyttöjärjestelmä, tietokan- nat ja sovelluskirjastot pysyvät ajan tasalla ja tietoturvallisina, ja että alustalla on tar- peeksi resursseja kasvattaa tilaajan sovelluksen resursseja tarpeen tullen. Jotkut PaaS alustat, kuten Azure tarjoaa myös lisätyökaluja kuten AppInsights jotka keräävät tilaajan sovelluksesta seuranta tietoja ja tarjoavat sen pohjalta liiketoiminta-analytiikkaa sekä te- hokkaan tavan sovelluksen seuraamiseen.
2.2.3 Sovelluspalvelu
Software as a Service (SaaS) sijaitsee pilvipalveluhierarkian korkeimmalla tasolla. SaaS palvelulla tarkoitetaan sovellusta, jota ajetaan pilvialustalla ja johon voidaan yhdistää in- ternetin välityksellä asiakasohjelmia tai web-käyttöliittymä [3.]. Parhaiten tunnettuja esi- merkkejä SaaS palveluista ovat esimerkiksi Gmail, Office 365 ja Salesforce.com.
Kuva 6. SaaS palvelussa palveluntarjoaja vastaa koko sovelluksen toiminnasta
Tilaajan näkökulmasta SaaS-palvelu on esimerkiksi web-sovellus, jota käytetään pelkäs- tään selaimen välityksellä. Sovellus ei vaadi erillistä asiakasohjelmaa eikä sen siten vaadi erikseen päivittämistä. SaaS sovelluksen tilaajan ei tarvitse tietää mitään käyttö- järjestelmistä, verkoista, ohjelmointikielistä tai päivityksistä vaan hän voi keskittyä tuot- tavan työn tekemiseen. SaaS sovelluksen käyttäjän on kuitenkin hyvä huomata, että kaikki käyttäjän arvokas tieto on tallennettuna palveluntarjoajan formaatissa tämän jär- jestelmässä ja sovelluksen vaihto toiselle palveluntarjoajalle voi osoittautua hankalaksi.
Palveluntarjoajan vastaa kaikesta SaaS sovelluksessa. Alusta, sovellus, sovelluksen saatavuus, tiedontallennus, tilaajien tiedon turvaaminen sekä käyttäjien asiakastuesta.
SaaS sovellusta usein markkinoidaan helpompana vaihtoehtona perinteisille asiakasso- velluksille koska ne selain pohjaisuutensa ansiosta ovat yleensä täysin käyttöjärjestel- märiippumattomia.
2.2.4 Funktiopalvelu
Functions as a Service (FaaS) sijoittuu pilvipalveluhierarkiassa PaaS ja SaaS palvelui- den väliin. Verrattaen uutena palvelumallina FaaS ei ole vielä vakiinnuttanut asemaansa muiden palvelumallien rinnalla, mutta se on nopeasti kasvattanut suosiotaan.
Kuva 7. FaaS palvelussa asiakkas vastaa vain sovelluslogiikasta ja konfiguroinnista
Perehdymme tarkemmin FaaS palveluihin myöhemmässä (2.4 Funktiopalvelun kehitys) kappaleessa.
2.3 Pilvipalveluiden hankintamallit
Pilvipalveluiden hankintamallit jaetaan neljään pääryhmään yksityinen, yhteisö, julkinen ja hybridipalvelut. Pääasiallinen jaottelu pohjautuu siihen, kuka palvelua hallinnoi ja ke- nen hallussa palvelun data on.
Kuva 8. Pilvipalveluiden hankintamallin havainnollistaja
Julkisen pilvipalvelun infrastruktuuri on avoinna kaikille, sen omistus on täysin palvelun- tarjoajan käsissä ja kynnys asiakkuuteen on pieni. Kuka tahansa voi varata pilven re- sursseja, esimerkiksi web-palvelimen, omaan käyttöönsä ja käyttää sitä kuten haluaa.
Julkisen pilven palvelut ovat saatavilla julkisen internet yhteyden välityksellä. Vaikka jul- kinen malli onkin helposti lähestyttävä, on ymmärrettävää, etteivät kaikki organisaatiot halua resurssiensa olevan saatavilla julkisen internetin yli tietoturva syistä, tätä ongel- maa kohtaamaan syntyi yksityinen pilvi.
Yksityinen pilvi on tietyn yrityksen tai organisaation tarpeeseen luotu pilvipalvelu. Sen omistus voi olla joko organisaatiolla itsellään tai kolmannella osapuolella, tässä tapauk- sessa se voi sijaita organisaation omissa tiloissa tai jaetussa suuremmassa datakeskuk- sessa. Yhteydet yksityiseen pilveen hoidetaan salatusti eivätkä ne ole saatavilla julkisen
internetin välityksellä. Tämä ratkaisu soveltuu erityisesti organisaatioille, joille tiedon yk- sityisyys on korkeassa arvossa.
Yhteisöpilven resurssit ovat varattuja tietyille organisaatio ryhmille, jotka jakavat samoja tehtäväkriittisiä ja lainsäädännöllisiä tavoitteita pilvipalveluille. Sen hallinto voi olla joko jonkun ryhmän jäsen organisaation, tai kolmannen osapuolen hallussa. Yhteisöpilven voi myös nähdä yksityisenä pilvenä, jonka resurssit on vain jaettu yhden organisaation si- jaan organisaatioryhmän kesken.
Hybridi pilvi ei sinänsä ole oma hankintamallinsa, vaan se voi olla yhdistelmä kaikkia kahta tai useampaa edellä mainitusta mallista. Erilliset pilvet yhdistetään salatulla yhtey- dellä, joka mahdollistaa datan ja sovellusten jakamisen eri pilvi instanssien kesken. Or- ganisaatio voisi esimerkiksi ajaa omaa yksityistä pilvipalveluaan ja yhdistää tämän julki- seen voidakseen vaihtaa palvelun alustaa nopeasti, jos kriittinen järjestelmävirhe kaataa oman järjestelmän.
2.4 Funktiopalvelun kehitys
Pohjimmiltaan FaaS tarkoittaa sitä, että taustapalvelun koodia voidaan ajaa serveristä tai palvelu sovelluksesta riippumatta. Funktiot eivät ole riippuvaisia yhdestä ohjelmointi- kielestä tai sovelluskehyksestä vaan FaaS alustat yleensä tukevat useampia suosittuja kieliä. Sovelluskehittäjän näkökulmasta paljon lähdekoodia, jolla ei ole tekemistä itse lii- ketoimintalogiikan kannalta voidaan jättää pois ja tämä mahdollistaa nopeamman proto- tyyppien toteutuksen ja tuotantoon viennin.
Sovelluksen tuotantoon vienti myös virtaviivaistuu siten, että kehittäjän koodi vain lada- taan funktiopalveluun, ja kaikki resurssien varaus, virtuaaliympäristön pystyttäminen ja prosessin ohjaus hoidetaan funktiopalvelun toimesta. Sovelluspalvelut tarjoavat monen- laisia laukaisimia, kuten tiedoston saapuminen, tietokanta tietueen päivitys tai http- pyyntö, joihin funktion voi asettaa vastaamaan. Funktiopalvelu myös hoitaa funktion ver- tikaalisen skaalautumisen täysin automaattisesti, funktioita voidaan ajaa täysin rinnak- kain ja palvelu skaalaa uusia instansseja tarpeen mukaan, tästä seuraa myös asioita, joita funktion suunnittelussa on tarpeen ottaa huomioon.
2.4.1 Funktioilla on maksimi suoritusaika
Funktiot eivät suoraan sovellu pitkäkestoisten prosessien suorittamiseen, kaikilla funk- tiopalveluilla on funktiolle maksimikesto, jota ei voi ylittää. Tämä johtuu siitä, että pitkä- kestoiset funktiot voivat aiheuttaa odottamattomia aikakatkaisu virheitä. Jos esimerkiksi http-laukaisimen suorittama funktio vie liian kauan aikaa, harkitse suorituksen siirtämistä tausta funktioon jonokäsittelyn kautta.
2.4.2 Funktioiden välinen kommunikointi
Funktioiden tulisi välttää suoria kutsuja muihin funktioihin, koska funktioista maksetaan käytön mukaan, kun ensimmäinen funktio kutsuu toista, ja odottaa vastausta, kulkee lasku molemmista erikseen. Jos funktion täytyy lähettää tietoa toiselle, on suositeltavaa käyttää viestijonoja jota toinen funktio käsittelee erikseen. Jos tarvetta monimutkaiselle monivaiheiselle käsittelylle on, suurin osa funktiopalveluista tarjoaa niin kutsuttuja ”or- kestrointi” työkaluja erikseen.
2.4.3 Funktio on tilaton (Stateless)
Tilaton funktio voi suorittaa yksinkertaisen ja kertaluontoisen tehtävän, se erimerkiksi ot- taa vastaan viestin ja tallentaa sen kantaan. Funktio ei itsessään sisällä mitään tietoa.
(Syrjä, 2016) Jos sovelluksen täytyy hallita tilaa jotenkin, se tulee suorittaa funktion ul- kopuolella.
2.4.4 Resurssien varaaminen
Resursseja kuten tietokanta yhteyksiä tai verkkopistokkeita varatessa on syytä ottaa huomioon, että jos jokainen kutsu varaa uudet resurssit alla oleva järjestelmä voi nope- asti tukehtua, jos liikennettä on paljon. Funktiot mahdollistavat resurssien jakamisen sa- man instanssin sisällä, ja tätä tulee ehdottomasti hyödyntää.
2.4.5 FaaS palveluiden vertailu
FaaS palvelut saivat alkunsa 2014 loppupuolella kun Amazon julkaisi AWS Lambdan.
Tämän jälkeen markkinoille ovat liittyneet Google, Microsoft ja IMB. Tarkkoja tietoja käyt- täjämääristä on vaikea saada mutta yleinen konsensus näyttää olevan, että suurin osa markkinoita jakautuu Amazonin, Microsoftin ja Googlen kesken edellä mainitussa järjes- tyksessä. AWS Lambdan kilpailijat ovat sijoittaneet teknologiaan paljon ja ovat saavut- taneet enimmäkseen tilan, jossa samankaltaiset toiminnallisuudet löytyvät kaikilta kilpai- levilta alustoilta. Suurimmat erot löytyvät lähinnä tuetuissa ohjelmointikielissä ja funktioi- den ympärille rakennettuihin palveluihin.
Taulukko 1. Funktio palvelujen ominaisuuksien vertailu
AWS Lambda Google Cloud Functions
Azure Functions
Julkaisu vuosi 11-2014 07-2016 03-2016
Funktion maksimi suoritusaika
900 sekuntia 540 sekuntia 300 sekuntia (voi asettaa 600)
Ympäristömuuttujat kyllä kyllä(beta) kyllä
Web työkalut funktioi- den luontiin
kyllä ei kyllä
Orkestrointi Step Functions ei Durable Functions
Tuetut kielet:
Node.js x x x
Python x x x
Java x x
Go x
C# x x
F# x
Kuten yllä nähdään, funktio palveluiden suurimmat erot ovat lähinnä ohjelmointikielten tuessa. Microsoft on kehittänyt Azure Functionsia vahvasti saavuttaakseen AWS
Lambdan toiminnallisuudet. Työkalut kehittyvät edelleen ja niissä voi olla mittaviakin eroja vuoden sisällä toisistaan. (Taulukko 1.)
3 Azure Functions
Azure Fuctions on Microsoftin tarjous funktiopalvelu markkinoille. Sen 1.0 versio julkais- tiin marraskuussa 2016, sen .Net kehysversion tuki oli 4.7. Se sisälsi tuen C#, F# ja JavaScriptin lisäksi. Syyskuussa 2018 julkaistu versio 2.0 toi mukanaan uuden kehys- version .Net Core 2.1 joka nopeuttaa funktioiden suorituskykyä ja mahdollistaa kehittä- misen myös Linux ja Mac alustoilla.
Azure Functions tarjoaa kattavat web-työkalut, jotka mahdollistavat kevyiden funktioiden kehittämisen, konfiguroinnin ja testaamisen suoraan selaimessa. Oikeaan kehitystyöhön suositellaan kuitenkin käytettäväksi joko Visual Studio 2017 tai Visual Studio Code työ- kaluihin sopivia liitännäisiä, jotka esikääntävät, pakkaavat ja julkaisevat sovelluksen Azureen. Käyttämällä tuettuja kehitysympäristöjä sovelluksen koodia on mahdollista seurata riveittäin ja korvata Azuren tallennusmedia paikallisella versiolla testaamista var- ten.
Azure Functionsin orkestrointi malli on nimeltään Durable Functions, tämä toiminnalli- suus mahdollistaa laajempien kokonaisuuksien luomisen ketjuttamalla tai ajamalla useita funktioita rinnakkain ja lopuksi reagoida ajettujen funktioiden lopputulokseen.
3.1 Laukaisimet
Azure Fuctions tarjoaa kehittäjille monenlaisia laukaisimia, jotka saavat funktion käyn- nistymään ja laukaisevat sen suorittamaan tehtävänsä. Tavanomaisesta PaaS sovelluk- sesta poiketen serveritön funktio on niin kutsutussa lepotilassa, kun sitä ei tarvita. Kun laukaisin sulkeutuu, funktiopalvelu käynnistää funktion ja suorittaa halutun komennon, tämän jälkeen funktio jää odottamaan, jos sitä tarvitaan uudestaan ja jos uusia kutsuja ei tule, funktiopalvelu ajaa funktion ja sen resurssit alas.
3.1.1 Web-laukaisin
Web-laukaisin odottaa standardi selainpyyntöä, joka sitten käynnistää funktion.
[FunctionName("HttpTriggerCSharp")]
public static async Task<HttpResponseMessage> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
HttpRequestMessage req, ILogger log) {
log.LogInformation("C# HTTP trigger function processed a request.");
return name == req.CreateResponse(HttpStatusCode.OK, "Hello World!“);
}
Esimerkkikoodi 1. Funkio vastaa esimerkiksi selaimella tehtyyn pyyntöön funktion url-osoit- teessa ja palauttaa tekstin ”Hello World!”
web-laukaisinta voidaan käyttää esimerkiksi RESTful rajapinnan rakentamiseen, jolloin sen kautta voidaan hakea, luoda, päivittää tai poistaa tietoa järjestelmästä.
3.1.2 Ajastin
Ajasti-laukaisin käynnistää funktion ennalta määrätyn aikataulun mukaan, ajastin käyttää Unix käyttöjärjestelmästä tuttua CRON syntaksia aikataulutukseen:
{second} {minute} {hour} {day} {month} {day-of-week}
[FunctionName("TimerTriggerCSharp")]
public static void Run([TimerTrigger("0 0 1 * * *")]TimerInfo myTimer, ILogger log)
{
log.LogInformation($"Siivotaan tietokanta");
… }
Esimerkkikoodi 2. Funktiopalvelu herättää funktion joka aamu kello 01:00 suorittamaan tehtä- väänsä.
Ajastinfunktiot sopivat erinomaisesti suorittamaan ajastettuja huoltotöitä sekä päivän ai- kana syötetyn tiedon ajoittaiseen keräilyyn ja analysointiin.
3.1.3 Sanomajono
Sanoma jonot ovat nykyään yleisiä suuremmissa tietojärjestelmissä, niitä käytetään eri- aikaiseen kommunikointiin eri palvelujen kesken. Yksinkertaisimmillaan kyse on siitä, että järjestelmä julkaisee sanoman jonoon ja toinen järjestelmä vastaanottaa sen.
[FunctionName("QueueTrigger")]
public static void QueueTrigger(
[QueueTrigger("new-todo-item")] string newTodoItem, ILogger log) {
log.LogInformation($"New todo item created: { newTodoItem }");
}
Esimerkkikoodi 3. Sanomajono ottaa vastaan viestin ”new-todo-item”-jonosta ja kirjoittaa sen sisällön logiin.
Sanomajonot ovat erityisen hyödyllisiä hajautetuissa järjestelmissä, kun tieto uuden tietueen saapumisesta halutaan välittää kiinnostuneille järjestelmille. Esimerkiksi web- kaupan hinnoittelujärjestelmä voi haluta tietää tuotteen varasto saldon täydennyksestä.
3.2 Pysyvän tiedon tallennus
Pysyvän tiedon tallennus pitää yleensä sisällään jonkinlaisen tietokannan tai muunlaisen tallennusmuoto, jonne sovelluksen pysyvä tieto tallennetaan. Koska funktiot ovat luon- teeltaan tilattomia, tallennusmedia on olennainen osa, jotta sovellus tekisi mitään pysy- väluonteista. Azure Functions tarjoaa lukuisia rajapintoja eri tallennusmuotoihin, mutta mikään ei estä käyttämästä myös perinteisiä tietokanta liittymiä suoraan sovelluksen koodista. Kaikki seuraavaksi mainitut tieto alustat yhdistyvät saumattomasti Azure Func- tions toteutusten kanssa ja valinta niiden välillä on lähinnä käyttötarkoitus ja kustannus kysymys.
3.2.1 Blob Storage
Azure Blob Storage niin kutsuttu objekti varasto, jonne käyttäjä voi tallentaa tiedoston tai tiedostoja. Tallennetulle tiedolle voidaan säätää erilaisia tietueen kahdennus vaihtoeh- toja, jotka vaikuttavat siihen, miten tietueen varmistus hoidetaan. Perus asetuksilla tieto on kahdennettuna paikallisessa palvelinkeskuksessa usealla fyysisellä koneella, jotta
yksittäisen laitteen toimintahäiriö ei vaikuta tiedon saatavuuteen. Suurimmassa skaa- lassa tieto voidaan kahdentaa useamman eri alueen välillä siten, että sen saatavuus ei katoa, vaikka yhteys kokonaiseen maanosaan katkeaisi.
Azure Fuction toteutus on mahdollista linkittää suoraan siten että uuden tietueen lisää- minen tai vanhan tietueen päivittämine laukaisee funktion, joka muokkaa tai analysoi tietoa ja mahdollisesti julkaisee ilmoituksen tiedon valmistumisesta käyttöön.
3.2.2 Cosmo DB
Azure Cosmo DB on Microsoftin modernein globaalisti hajautettu ja moni tietomallinen pilvi tietokanta. Cosmo DB ei tue perinteistä relaatiotietokanta mallia vaan sen tarjoamiin tietomalleihin lukeutuu perinteisesti NoSQL malleina tunnetut dokumentti-kanta, avain- arvo kanta, graafi tietokanta ja wide column tietokanta. Tietokanta mallin valintaan vai- kuttaa yleensä tiedon käyttötarkoitus ja kehittäjän mieltymykset.
Cosmo DB:n suurimpiin etuihin kuuluu hajautus ja saatavuus, sekä lukuisat tarjotut raja- pinnat, joita hyödyntämällä datan hallinta ja haku onnistuu eikä palvelun ominaisuuksien hyödyntäminen vaadi kokonaan uuden oppimista kehittäjän näkökulmasta.
3.2.3 Table Storage
Azure Table Storage on skeematon avain-arvo tietokanta, joka soveltuu suuren tietomal- littoman tiedon tallentamiseen taulukko muodossa. Se on optimoitu nopeiden haku ja kirjoitus operaatioiden suorittamiseen nopeilla avain hauilla. Table Storage on täysin pilvi pohjainen toteutus ja se tarjoaa REST-rajapinnan, jonka kautta tiedon hakuja muokkaa- minen tapahtuvat saumattomasti internet verkon yli.
3.3 Logiikan jakaminen funktioiden kesken
Azure Functions web työkaluilla luodut funktiot ovat usein hyvin yksinkertaisia, eivätkä ne voi viitata toisiinsa tai muuhun koodin. Monimutkaisemmat sovellukset vaativat joko
Visual Studion tai Visual Studio Code:n kaltaisen kehitysympäristön käyttöä. Nämä mo- nipuoliset työkalut mahdollistavat sovelluksen jakamisen eri projekteihin ja sovelluslogii- kan jakamisen näiden kesken. Näin tehtäessä funktiot voivat jakaa samoja tietomalleja ja operaatioita eri funktioiden kesken.
3.4 Autentikointi
Kun Azure Functio sovellus luodaan, se saa julkisen web osoitteen, josta sitä voi kutsua kuka tahansa maailmassa käyttäen web selainta. Jos funktiolla ei ole http-laukaisimia tämä kutsu ei tee mitään. Mutta jos http-laukaisin on olemassa, kehittäjän täytyy valita kuka funktiota saa kutsua. Mahdollisiin pääsy tasoihin lukeutuvat seuraavat:
• Anonymous, mahdollistaa pääsyn kenelle tahansa ja web-ositetta kutsuu.
• Function, web kutsun mukaan on lisättävä salainen funktio kohtainen avain, jonka voi määrittä erikseen Azure Portalissa.
• Admin, web kyselyn mukaan tulee lisätä niin kutsutun Host Key avaimen, jolla on pääsy kaikkiin funktioihin saman sovelluksen sisällä.
• System, Web kysely vaatii erikseen tietyn _master avaimen, jolla on korkeimman tason pääsy sovelluksessa.
• User, taso vaatii käyttäjää kirjautumaan sisään identiteetinhallinta palveluun joka kirjautumisen jälkeen oikean käyttäjän kutsua funktiota. Tuettuina ovat esimer- kiksi Google, Facebook ja Microsoft tunnistautumispalvelut.
Kuva 9. Avainten hallinta Azure Portalissa.
Jos sovelluksella on web-käyttöliittymä, on usein suositeltavaa käyttää User tason kir- jautumista vaativaa pääsy tasoa, eri tasoiset avaimet ovat yleensä käytössä, kun funktiot kutsuvat toisiaan verkon yli, eikä avaimen paljastumisesta ulkopuolisille ole riskiä.
4 Remindrs-sovellus
Remindrs-sovelluksen tarkoitus oli luoda hyödyllinen yksinkertainen web-sovellus, joka hyödynsi modernia serveritöntä pilviteknologiaa kaikkien komponenttiensa osalta. So- vellus tarjosi kehittäjälleen tilaisuuden oppia hyödyntämään Azuren pilvi ominaisuuksia ja luoda pohjaa monimutkaisempien serverittömien toteutusten tuottamiseen päivätyön parissa. Alun perin sovelluksen oli tarkoitus tarjota erilaisia listoja kuten tehtävälistoja, ostoslistoja ja toistuvia muistutuksia, joiden oli tarkoitus olla käyttäjäkohtaisia ja jaetta- vissa eri käyttäjien kesken. Aikataulu ja budjetti paineista johtuen sovelluksen ominai- suuksia karsittiin siten, että se lopulta toteutti globaalisti jaetun ostoslista komponentin.
4.1 Remindrs arkkitehtuuri
Sovelluksen arkkitehtuurin oli tarkoitus olla täysin serveritöntä pilveä hyödyntävä. Re- mindrs koostui kahdesta pääkomponentista, jotka kaikki hyödynsivät eri Azure pilvitek- nologioita. Remindrs-SPA oli Angular 7 web-sovellus joka oli rakennettu Angular Material
komponenteista ja toimi sovelluksen käyttäjälle tarjottuna graafisena käyttöliittymänä.
Remindrs-API oli Azure Functions sovellus toimi taustasovelluksena ja rajapintana käyt- töliittymän ja tiedontallennuksen välissä.
Kuva 10. Remindrs-sovelluksen arkkitehtuuri kaavio
Sovellus toimi siten, että käyttäjän kutsuessa Remindrs web osoitetta, pyyntö ohjattiin Azure Blob storageen josta käyttäjän selaimeen käynnistyi Remindrs-SPA Web sovellus.
Tämän jälkeen SPA keskusteli Remindrs-API:n kanssa tarjoten käyttäjälle mahdollisuu- den hallinnoida ja käyttää ostoslistoja (Kuva 10.). Ostoslistat olivat jaettavissa eri käyttä- jien kesken siten että yhden käyttäjään tekemät muutokset näkyivät myös muille. Re- mindrs-API tarjosi myös rajapinnan lisäksi ajastetun tietokannan analysoinnin. Analy- sointi funktio etsi suoritetut ostoslistat ja lisäsi ne poistojonoon, joka sitten siivosi käyttä- mättömät listan kohdat.
Remindrs sovelluksen teknologia valinnat perustuivat kahteen pääkriteeriin, serverittö- myyteen ja kustannuksiin. Remindrs-API sovellukseen ytimeksi valikoitui Azure Fuctions FaaS palvelu. FaaS palveluille ominainen serverittömyys ja Azuren tarjoama ensimmäi- set miljoona funktiokutsua ilmaiseksi takasivat molempien valintakriteerien täyttymisen.
Funktioiden kanssa helposti integroitaviksi serverittömiksi tietokannoiksi oli tarjolla kaksi vaihtoehtoa Cosmo DB ja Table Storage, näistä Table Storage on huomattavasti hal- vempi, joten se valikoitu tietokannaksi projektiin.
Remindrs-SPA toteutettiin käyttäen Angular 7 sovelluskehystä ja Angular Material käyt- töliittymäkomponentteja. Sovelluksen tiedostot eivät luonnollisesti itse tehneet mitään, joten se täytyi jotenkin saada käyttäjien saatavilla. Koska serverittömyys oli edelleen va- lintakriteeri valikoitui sijoituspaikaksi Azure Blob Storage, joka mahdollistaa staattisen web sisällön jakelun selainpyyntöön reagoiden. Nämä valinnat mahdollistivat koko so- velluksen toteuttamisen joko ilman, tai minimaalisin kuluin.
4.2 Remindrs-API kehitystyö
Sovelluksen kehitys alkoi työtilan luonnista Visual Studio 2017 kehitysympäristössä.
Työtila koostui kahdesta projektista Remindrs ja Remindrs.Models, näistä ensin mainittu piti sisällään funktio laukaisimet, jotka ohjaavat sovelluksen toimintaa. Jälkimmäinen Re- minrs.Models puolestaan huolehti sovelluksen tietomallista ja siitä, miten se muunnetaan joko tietokannan tai käyttöliittymän vaatimaan muotoon.
Ensimmäinen vaihe oli luoda niin kutsuttu Representational State Transfer (REST) raja- pinta tarjoamaan perinteiset luonti, luku, päivitys ja poisto (CRUD) operaatiot ostoslisto- jen hallintaan ja kytkeä ne käytössä olevaan Storage Table tietokantaan.
[FunctionName("GetShoppingLists")]
public static async Task<IActionResult> GetShoppingLists(
[HttpTrigger(AuthorizationLevel.Function, "get", Route="shoppinglists")]HttpRequest request,
[Table("shoppinglistitems", Connection = "AzureWebJobsStorage")] CloudTable shoppinglistItemsTable)
{
var query = new TableQuery<ShoppingListItemTableEntity>();
var queryResults = await
shoppinglistItemsTable.ExecuteQuerySegmentedAsync(query, null);
var groupedShoppingLists = queryResults.GroupBy(x => x.PartitionKey).Se lect(group => group).ToList();
var shoppingLists = new List<ShoppingList>();
foreach (var shoppingListGroup in groupedShoppingLists) {
shoppingLists.Add(shoppingListGroup.ToList().ToShoppingList());
}
return new OkObjectResult(shoppingLists);
}
Esimerkkikoodi 4. Funktio odottaa web kyselyä ostoslistoista, etsii kaikki listat ja palauttaa ne käyttäjän selaimeen.
Johtuen FaaS alustan luonteesta ja tietokantavalinnasta yksittäiset funktiot ovat koodiri- veiltään melko lyhyitä (Esimerkkikoodi 4.). CRUD metodien tuottaminen oli aluksi no- peaa, mutta sitten tietokannaksi valitun Storage Tablen rajoitukset alkoivat näkyä.
4.2.1 Tietokantamallin suunnittelu
Table storage-palveluun tallennettavat tietueet tuli periyttää TableEntity-luokasta. Tab- leEntity tarjosi perivälle luokalle kaksi uutta kenttää PartitionKey ja RowKey, näillä uusilla parametreillä tietokanta tunnisti kyseisen rivin tietokannan taulusta ja ne yhdessä mah- dollistavat tietueiden nopean löytymisen. Alkuperäinen suunnitelma oli käyttää jokaiselle tietotyypille omaa taulua ja hyödyntää näitä perinteisen relaatiokannan tavoin (Kuva 11.).
Kuva 11. Kahden taulun tietokanta malli
Tästä seurasi kuitenkin ongelmia, koska funktiot ovat luonteeltaan tilattomia sama funk- tio saattaa olla suorituksessa monen käyttäjän toimesta samaan aikaan eikä Table Sto- rage tarjoa mitään keinoa tiedon oikeellisuuden suojaamiseen transaktio käsittelyllä, ku- ten esimerkiksi SQL Server tietokanta olisi tehnyt. Syvempi sukellus Table Storagen
dokumentaatioon paljastikin pian, ettei tietokantaa ollut tarkoitus käyttää suunnitellulla tavalla vaan sen hyödyntäminen tehokkaasti vaatikin toisenlaista lähestymistapaa.
Kuva 12. Epänormalisoitu tietokanta malli.
Aiemman kaltaisen relaation hyödyntämiseksi Table Storage-tietokanta mallissa olikin suositeltavaa epänormalisoida tietue ja yhdistää useamman objektin tietoa samaan tau- luun [8.], tämä, SQL tietokantoihin tottuneelle, aluksi epäintuitiivinen lähestymistapa mahdollisti kuitenkin kokonaisten ostoslistojen tai vain yksittäisten rivien muokkaamisen nopeasti ja vähäisillä tietokanta haku määrillä.
4.2.2 Remindrs-API sovelluksen huoltofunktiot
Verkkorajapinnan lisäksi yleisiä toiminnallisuuksia aiemmin kehittämissäni mikropalve- luissa ovat olleet erilaiset ajastettavat toiminnallisuudet sekä sanoman julkaisu ja vas- taanotto palvelut. Näille löytyi myös Azure Funktioista omat vastaavat palvelunsa. Re- mindrs toteutuksen tarpeisiin luotiin ajastettu funktio, joka skannasi koko ostoslista tieto- kannan läpi puolen tunnin välein ja keräsi listan suoritetuista ostoksista. Listan kerätty- ään funktio julkaisi ilmoituksen poistettavista listan riveistä.
Ajastusfunktion julkaisemat poistoviestit käsiteltiin niin kutsutulla jonokäsittely funktiolla, joka käynnistyy viestin saapuessa. Viesti sisälsi tarkat tiedot siitä mistä listasta mikäkin
rivi tulisi poistaa ja funktio muodosti näistä kokoelma (batch) operaation, joka poisti pyy- detyt rivit yhdellä pyynnöllä (Esimerkkikoodi 5.).
[FunctionName("CleanupListener")]
public static async Task Run(
[QueueTrigger("clean-completed-items", Connection =
"AzureWebJobsStorage")]ItemsToDeleteMessage itemsToDelete,
[Table("shoppinglistitems", Connection = "AzureWebJobsStorage")] CloudTable shoppinglistItemsTable)
{
var deleteBatchOperation = new TableBatchOperation();
foreach (var item in itemsToDelete.KeyPairs) {
deleteBatchOperation.Add(TableOperation.Delete(
new TableEntity { PartitionKey = item.PartitionKey, RowKey = item.RowKey, ETag = item.ETag }));
}
if (deleteBatchOperation.Count > 0) {
await shoppinglistItemsTable.ExecuteBatchAsync(deleteBatchOperation);
} }
Esimerkkikoodi 5. Jonokuuntelija funktio tietokannan siivoamiseen.
4.3 Remindrs-SPA toteutus
Sovelluksen käyttöliittymän pohjaksi valikoitui Angular sovelluskehys perustuen sen ky- kyyn tuottaa rikkaita web-sovelluksia nopeasti ja natiiviin TypeScript tukeen. Angularin hyvin mukautuva ja selkeä moduulimalli mahdollisti sovelluksen laajentamisen myöhem- min. SPA:n käyttöliittymä komponenteiksi valittiin Angular Material kirjasto, joka tarjoaa moderneja helposti mukautettavia komponentteja
Kuva 13. Remindrs-SPA käyttöliittymä
Sovelluksen käyttöliittymästä (Kuva 13.) tuli melko yksinkertainen eikä sen kehitystyössä tullut vastaan suuria yllätyksiä. Se mahdollisti kaikki perus tarpeet ostoslistojen hallintaan ja toimi hyvin useiden käyttäjien kesken.
4.4 Web sovelluksen jakelu serverittömässä ympäristössä
Koska Remindrs sovelluksen tavoitteissa oli täydellinen serverittömyys, SPA sovelluk- sen jakelukanavaksi valittiin Azure Blob Storage. Web sisällön jakelu vaati Remindrs so- velluksen tallennus tilin (storage account) päivittämistä uuteen V2 tyyppiin. Päivityksen jälkeen valikkoon ilmestyi uusi vaihtoehto Static website, tämä mahdollisti Remindrs- SPA sovelluksen jakelun suoraan käyttäjän selaimeen selainta käyttäen.
Kuva 14. Azure Blob Storage Static website configuration.
Angular ja Blob storage eivät toimineet yhteen aivan saumattomasti, mutta onneksi on- gelman korjaaminen vaati vain pienen konfiguraatio muutoksen.
@NgModule({
imports: [RouterModule.forRoot(routes, {useHash: true})], exports: [RouterModule]
})
Esimerkkikoodi 6. Angular routing module hash-asetus.
Muutos (Esimerkkikoodi 6.) kertoi Blob Storage alustalle, että sovelluksen alisivu over- view-näkymä oli vain pääsivun osa eikä oma tiedostonsa.
https://subdomain.azurewebsites.net/#/overview
Näin kaikki yksittäiset komponentit olivat viimein valmiita ja lopuksi Remindrs-API ja Re- mindrs-SPA piti vielä liittää yhteen saumattomasti yhtenäisen käyttökokemuksen saa- vuttamiseksi. Tämä saatiin aikaan sillä, että Remindrs-API:in julkiseen URL-osoittee- seen konfiguroitiin välityspalvelinasetus, joka ohjaa käyttäjän lataamaan Reminds-SPA
sovelluksen kutsun tullessa. Näin lopulta käyttäjän toimet SPA sovelluksessa tallentuvat tietokantaan ja yhden käyttäjän muutokset näkyvät myös muille.
5 Pohdintaa
Olen oman työni parissa kehittänyt mikropalvelun kaltaista sovelluskokoelmaa viimevuo- sina. Nämä palvelut ovat kuitenkin olleet enemmän perinteisiä virtuaalipalvelimella ajet- tavia Windows Web- tai Service-sovelluksia ja minusta on aina tuntunut, että niistä puut- tuu jotain mikä tekisi niistä oikeasti automaattisesti skaalautuvia kevyitä palveluita. Sen sijaan että olisin alkanut perehtyä sovelluspalveluihin (PaaS) päätin koettaa hypätä ker- ralla modernin skaalautuvan pilviarkkitehtuurin kärkeen ja syventyä Microsoftin Azure Functions palveluun.
Azure Functions ja laajemmin serveritön arkkitehtuuri osoittautuivat mielenkiintoiseksi tutkimuskohteeksi. Idea serverittömästä arkkitehtuurista on ollut olemassa nyt muuta- man vuoden ja vaikka suorat kirjalliset teokset ovat vielä vähissä, ensimmäiset pioneerit jakavat tietoaan alan konferensseissa ympäri maailman.
Kaikki ei kuitenkaan ole aivan ruusuista serverittömässä maailmassa. Eräs funktiosovel- luksen omaisuuksista on, että kun palvelu ei ole käytössä FaaS-palvelu sammuttaa so- velluksen lepotilaan säästääkseen palvelun resursseja. Nykymuodossaan tutkielman osana kehitetyn Remindrs funktiosovelluksen nk. kylmäkäynnistys kestää noin 10-12 se- kuntia ja tämä voi osoittautua ongelmaksi, jos käyttäjä on kovin kärsimätön. Tämä ei tietysti ehdi muodosta ongelmaksi, jos käyttäjiä on useita ja sovellus ei ehdi lepotilaan käyttäjien välissä. Ongelmasta huolimatta Azure Functions vaikuttaa lupaavalta alustalta ja tulen varmasti jatkossa etsimään uusia tapoja hyödyntää sitä niin työni parissa kuin omissa projekteissanikin.
Ottaen huomioon miten pienillä resursseilla Remindrs-sovelluksen kaltainen pilvisovellus tänä päivänä voidaan kehittää, on helppo kuvitella, miten John McCarthyn visio tietojen- käsittelynä yleishyödykkeenä alkaa siirtyä tiedekuvaelmasta todellisuudeksi.
Lähteet
1 Tietotekniikan käyttö yrityksissä. Verkkodokumentti. Saatavissa:
http://www.stat.fi/til/icte/2016/icte_2016_2016-11-30_kat_003_fi.htmlLähdetieto viitattu: 27.10.2018
2 Pilvipalveluiden turvallisuus. Verkkodokumentti: Saatavissa:
https://www.viestintavirasto.fi/attachments/tietoturva/Pilvipalveluiden_tieto- turva_organisaatioille.pdf Viitattu: 27.10.2018
3 Pilvipalveluiden turvallisuus. Verkkodokumentti. Saatavissa:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf Viitattu: 30.10.2018
4 Architects of the Information Society: Thirty-Five Years of the Laboratory for Computer Science at MIT, Simson L Garfinkel and Harold Abelson (1999) s.1 5 Brief History of the Internet. Verkkodokumentti. Saatavilla:
https://www.internetsociety.org/internet/history-internet/brief-history-inter- net/#Origins Viitattu: 06.11.2018
6 Who Coined ’Cloud Computing’? Verkkodokumentti. Saatavilla:
https://www.technologyreview.com/s/425970/who-coined-cloud-computing/
Viitattu: 07.11.2018
7 Sundström, Henri 2016 Pilvipalvelut ja pilvipalveluiden soveltaminen yrityksissä.
Insinöörityö (AMK), Metropolia Ammattikorkeakoulu
8 Azure Storage Table Design Guide. Verkkodokumentti. Saatavissa:
https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-design- guide#denormalization-pattern Viitattu: 2.12.2018
9 Publish-Subscribe Channel. Verkkodokumentti. Saatavissa:
https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSub- scribeChannel.html Viitattu: 2.12.2018
10 Angular 6 application hosted on Azure Storage Static website.
Verkkodokumentti. Saatavissa:
https://about-azure.com/2018/07/03/angular-6-application-hosted-on-azure-sto- rage-static-website/ Viitattu 30.11.2018
