ohjelmistoarkkitehtuuritohar/materiaali2016/luento08_weppipilvi.pdf · • jquery (suosituin ja...
TRANSCRIPT
OhjelmistoarkkitehtuuritNetti/pilvimaailmaa
Kevät 2016
Samuel Lahtinen
http://www.cs.tut.fi/~ohar/
1Ohjelmistoarkkitehtuurit 2016
Aiheita
• Yleisiä ratkaisumalleja verkkomaailmaan
• Asiakas-palvelin-ajatelman jatkokehitystä
• Palvelinpää ja jotain perusratkaisuja (toteutustekniikat,
REST, jne)
• Asiakaspään erilaisia toteutustekniikoita
• Pilvilaskenta/palvelut
• Mitä ne on?
• Palvelutasot: IaaS, PaaS, SaaS
• Pilveen siirtyminen?
• Pilviarkkitehtuureista kevyesti
Ajankohtaisuuksia
http://yle.fi/uutiset/automaattijarrujen_olisi_pita
nyt_pysayttaa_saksan_turmajunat/8660580
”Arkkitehtuurisuunnitelma”
• Käyttöliittymä tehdään weppipohjaisena
• Palvelinpuoli, ulkoistetussa pilvessä
• ”Miten järjestelmä skaalautuu?” se on pilvessä
• ”Miten tietojen tallennus jne.?” siellä on
pilvessä tietokantaa
• ”Miten käyttöliittymäpuoli toteutetaan?”
Selaimessa pyörii
Arkkitehtuuripäätösten syitä
• Tarjotaan kokonaispalvelu, vaikuttaa päätöksiin (toteutus,
ylläpito, palvelimet…)
• Tehdäänkö aito sovellus vai jotain selaimessa ajettavaa?
• Kehitysympäristö, mahdollinen CI-CD-putki
• Avoimmuus ja julkiset palvelut:
• Suljettu järjestelmä asiakkaan raudalle
• Nyt avoin järjestelmä, mutta usein muualla kun asiakkaan
koneilla
• lähdekoodi voidaan julkistaa, se on melko pieni osa
kokonaisuutta (toimittajan vaihtaminen ei ole helppoa,
vaikka lähdekoodi olisi saatavilla)
Mikä arkkitehtuuriratkaisu?
Single Page Application
• Halutaan tarjoa perinteisen sovelluksen kaltainen
käyttökokemus
• Halutaan päivittää käyttöliittymä tai osia
käyttöliittymästä hakematta palvelimelta kokonaan
uutta sivua
• HTML, JavaScript ja CSS haetaan yhdellä
latauksella, resurssit ladataan tarpeen mukaan,
usein käyttäjän toimiin perustuen
• Navigointi sovelluksessa, taustalla tapahtuu
kommunikaatiota asiakas-palvelin välillä
Single Page Application, piirteitä
• HTML, JavaScript ja CSS haetaan yhdellä latauksella
• Käytettävä tieto palasina, esimerkiksi JSON, sivu yhdistelmä HTML(5)
kamaa ja dynaamisesti tuotettua osuutta
• Frameworkit/kirjastot, kontrollerin/vastaavan hyödyntäminen, DOM, Ajax-
kutsujen hoitelu, mallien ja näkymien eriyttäminen
• Sivustolla navigointi ilman koko sivuston uudelleenlatausta (historian ja
selaimen navigoinnin hyödyntämiseen omia kirjastojaan)
• Selainpäähän tietojen tallentaminen (local storage), cookiet korvataan
näillä, suorituskyky paranee, vähemmän tarvetta latailla tavaraa
palvelimelta
• Kaksisuuntainen kommunikaatio, kaksisuuntainen tiedon sidonta
(Angular.js), palvelin voi viestiä asiakkaan suuntaan, päivittää tietoja
Single Page Application,
asiaskaspuolta lisää• Kirjastoja/sovelluskehyksiä: backbone.js (MVP), Angular.js (MVC),
Knockout.js (MVVM), Ember.js (MVC)…
• Muita kirjastoja:
• Handlebars (sivu-templatejen tekoon)
• Marionette.js (sovelluksen koostaminen, moduulien hallinta,
viestintä, esim. BackBonen kylkeen)
• Require.js (moduulien ja tiedostojen hallintaan)
• jQuery (suosituin ja yleisin kirjasto, helpottaa Ajax-touhuja, DOM-
käpistelyä jne.)
• Kehykset usein kutistumassa kontrolleriosan suhteen,
• Frameworkit/kehykset pyrkivät olemaan mahdollisimman
nopeita/”helppoja” käyttää, eivät välttämättä selkeimpiä, helpommin
ymmärrettäviä tai rakenteeltaan puhtaasti jonkun mallin mukaisia.
Kehysten määrittely usein sen mukaan mitä ne tekevät, eivät miten ne
tekevät jonkun halutun asian.
http://singlepageappbook.com/goal.html
Tiedon sidontaa näkymä—malli välillä,
tiedon päivitykset mallipalvelin
Single Page Application,
Jotain haasteita• Asiakas-palvelin-malli ja toteutuksen jakaminen, koodin toistumisen
välttäminen
• Hakukoneoptiomointi, sivustojen analyysi
• Selainhistoria (back/forward), oletus yksi sivu, back poistuminen sivulta
(selainhistorian tuominen URL hash fragment identifier)
• Sivun lataaminen hidasta, käyttö nopeaa, voi aiheuttaa ongelmia
Arkkitehtuuripäätöksiä
• Kuinka paksuna asiakaspää tehdään?
• Palvelimelta sivuja vs. palvelimella JSON API
• Tiedonsiirtopuoli, mitä siirretään, missä muodossa
• Tietomallikuvausta tms. Mitä kaikkea ohjelmassa on ja miten asiat
kytkeytyvät toisiinsa
• Millä asiakaspää toteutetaan?
• Mikä framework, miten tieto saadaan näkymään?
• Staattisempaa vs. dynaamista
• Näkymät malleihin sidonta vs. markup-vetoinen
• Miten ja missä muodossa tieto liikkuu asiakas-palvelin-välillä?
• Miten hallitaan käyttäjätietoja, istuntotietoja?
Laihemmat asiakkaat
• Perussivusto HTML+CSS
• Sivuilla skriptipaikkoja (HTML-CSS-erikoisrakenteita), joiden avulla
staattisen sivun päälle saa dynaamisuutta
• Yleisesti jokainen toiminto aiheuttaa uuden sivulataamisen
• Bootstrap (http://getbootstrap.com/ ) + LessCSS
• (esimerkki tyylisuunnan erikoisversiosta PJAX
http://yuilibrary.com/yui/docs/pjax/ )
Luettavaa
• Esimerkki (backbone+bootstrap): https://github.com/ccoenraets/directory-
backbone-bootstrap
• http://singlepageappbook.com/goal.html
• http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-
api/build-a-single-page-application-spa-with-aspnet-web-api-and-angularjs
Palvelinpuoli
• RESTiä, SOAPia vai mitä?
• Arkkitehtuuripäätöksiä liittyen palvelinpuoleen
• Omat serverit vai jotain muualta ostettua?
• Rautataso, käyttöjärjestelmä, palvelutaso, alusta…
• Tietojen tallennus ja haku, tietokannat
• Avointa lähdekoodia vai ostettua?
• Esimerkiksi LAMP tai ASP.net
LAMP
Kuva: http://blog.ipspace.net/2012/08/pvlan-vxlan-and-cloud-application.html
Palvelinpuoli
• RESTiä, SOAPia vai mitä?
• Arkkitehtuuripäätöksiä liittyen palvelinpuoleen
• Omat serverit vai jotain muualta ostettua?
• Rautataso, käyttöjärjestelmä, palvelutaso, alusta…
• Tietojen tallennus ja haku, tietokannat
• Avointa lähdekoodia vai ostettua?
• Mitä kieltä käytetään (Javascript, Python, C#, Java…)
• LAMP, ASP.net, Django
REST-valintaohje
• valitse REST, jos et keksi hyvää syytä tehdä käyttää SOAPia
• REST, kun haluat tarjota API:n, jonka kautta voi tehdä CRUD-operaatiota
resursseille. Yleisesti, kun haluat tarjota keinon hakea ja muokata tietoa.
• SOA(P): sovelluslogiikan osien tarjoaminen, nimetyt funktiot jne.
Komennon lähettäminen palvelulle (XML-data). Atomiset operaatiot, ACID.
• enterprise sovellukset, joissa tarvitaan tieto operaation
onnistumisesta eikä uudelleen yrittäminen ole (järkevä) vaihtoehto
(esim. pankkitoiminta). Tiukka tyypitys.
• WSDL Web Services Description Language, kieli jolla kuvataan SOAP-
rajapinta, pyyntö- ja vastausmuoto. Muutos APIssa, muutos WSDL:ssä ja
muutos asiakkaan koodin…
• WADL yrittää olla kuvauskieli RESTin puolella, ei tullut suosittua
• http://www.w3.org/Submission/wadl/
WADL-esimerkki (TTY ja EasiClouds –projekti, “REST-palveluiden mashupia”
<?xml version="1.0" encoding="UTF-8"?><wadl:application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wadl="http://wadl.dev.java.net/2009/02"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd">
<wadl:grammars></wadl:grammars><wadl:resources base="http://up.flickr.com/services">
<wadl:resource path="upload/"><wadl:method name="POST" >
<wadl:request><wadl:representation mediaType="multipart/form-data">
<wadl:param name="photo" type="image/*" style="query" /><wadl:param name="title" type="xsd:string" style="query" /><wadl:param name="description" type="xsd:string" style="query" />
</wadl:representation></wadl:request><wadl:response>
<wadl:representation mediaType="application/xml" /></wadl:response>
</wadl:method>
</wadl:resource></wadl:resources>
</wadl:application>
Tietokantapuolesta• Erillisenä omalla palvelimellaan vai samassa paketissa, samalla (virtuaali)koneella?
• Minkälaista tietoa halutaan tallentaa?
• Relaatiotietokannat vai dokumenttitietokantoja?
• Suoraan koodista vai tehdäänkö tietokantakyselyitä?
• Object relational Mapping (ORM)
• Erikoistusta, Active Record: Toimiva ratkaisu, jos tehdään melko yksinkertaisia sovelluksia,
joissa erittäin laiha businesslogiikkakerros, lähinnä dataa ja sen esittämistä (mutta ei sitten
muuhun…)
• Toteutuksen helppous vs. potentiaalinen hidastuminen ja tietokannan väärinkäyttö (ohjelman
rakenteelliset ongelmat)
• http://guides.rubyonrails.org/active_record_querying.html
• http://guides.rubyonrails.org/active_record_basics.html
• ja toisaalta: http://www.mehdi-khalili.com/orm-anti-patterns-part-1-active-record
• https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-
solid-design/
SQL or noSQL?
• SQL vs. NoSQL (relaatio- ja dokumenttitietokannat)
• Perinteinen malli:
• Tehokas pienten muutosten tekoon, tilastointiin, lokeihin ja tarvittaessa muutosten
palauttamiseen
• Hyvä, jos tarvitaan paljon yhtäaikaisia operaatiota (pieniä hakuja, muutoksia)
• Tietokanta osaa hoitaa tiedon järjestelyä, suodatusta jne.
• Testattua, pitkään käytössä ollutta, yleisesti tunnettua jne.
• Kaupallista ja avoimen lähdekoodin ratkaisua tarjolla rutkasti
• noSQL-tyyppiset jutut
• Dokumenttien, strukturoimattoman tiedon tallentamiseen (ei yhteyksiä, isompia tietoklönttejä,
vaihteleva tietomuoto jne.)
• Voidaan käyttää suoraan ohjelmointikielen rajapintoja (ei tarvetta osata SQL-kutsuja)
• Optimoitu kokonaisten dokumenttien tai isojen tietoalkioiden noutoon
• Tarjolla paljon toimivia avoimen lähdekoodin ratkaisuja
Palvelinpään arkkitehtuurivalintaa…
• Valinnan voi tehdä esimerkiksi osaamispohjaisesti, esim. mitä ohjelmointikieltä ja työkaluja osataan
parhaiten?
• Valinnassa voi painottaa teknologiaa, esim. servereissä Linux/FreeBSD/Windows, valitaan
ohjelmisto/pilvialusta (platform) sen perusteella. Platform-valinta rajaa esimerkiksi toteutuskielen
valintaa, otetaan Microsoft Azure, ASP.net, PHP Node.js tai Python, käytetään platformin tarjoamia
tietokantapalveluita jne.
• Järjestelmän koko ja monimutkaisuus:
• Yksinkertainen palvelinpuoli, ei järkeä kehitellä järeää LAMP Tomcat, Java EE, Framework-
settiä
• Yksinkertaisimmillaan palvelimella jokunen CGI-skripti ja HTML javascriptit minimimaalinen
palvelintoteutus
• Jotain siltä väliltä Ruby-on-Rails (MVC framework+muuta)
• Iso monipuolinen ja monimutkainen kokonaisuus, esim. Java+Scala/Clojure+tietokannat+…
• Skaalautuvuus, suorituskykyvaatimukset
• Eritasoista toiminnallisuutta, nopeita ja yksinkertaisia vs. aikaa vieviä ja monimutkaisia
toimintojen eriyttäminen, optimointimahdollisuus
Java-ratkaisuja• Java, voidaan käyttää joko palvelinpuolen tekemiseen tai koko ohjelman
vääntämiseen:
• Yleensä jonkun ohjelmistokehyksen/frameworkin käyttö järkevää, tyhjästä kaiken
yksin väkästeleminen ei välttämättä järkevintä
• SpringMVC: Javaa ja Java server Pages –hässäkkää, REST-palvelut jne. Hirvee
mötkö, kestää hetki päästä sisään
• Apache Struts:MVC framework
• Jos porukassa nihkeästi CSS, HTML, Javascript –guruja tai REST yms. tietämystä, voi
harkita:
• Google Web Toolkit: Javalla client-server-mallista ohjelmointia, asiakas-
puolella Javaa (vähän karsittuna), joka käännellään JavaScriptiksi
• Vaadin: isompi myyntivaltti, sovellusmainen ohjelmistokehitys, palvelinpuolen
käyttöliittymä. Kaiken tekeminen Javalla mahdollista, vähän tarvetta opetella
palvelinten käyttöä ja miettiä esim. rajapintojen tietoturvaa.
• GWT:hen eroavaisuuksia, sovellus pyörii (enemmän) palvelimen
päässä, selainpää vain näkymää ja käyttäjän syötteitä varten, helpompi
UI:n naittaminen muuhun ohjelmaan, raskaampi palvelimelle,
vaikeampi optimoida palvelinpuolta jne.
• Yksi harkittava asia: asiakkaiden määrä, laskennan painottuminen
asiakaalle tai palvelimelle
• Vaadin ja asiakaspuolen sovellukset: https://vaadin.com/docs/-
/part/framework/clientsideapp/clientsideapp-
overview.html#clientsideapp.overview
https://vaadin.com/docs/-/part/framework/architecture/architecture-overview.html
Kielivalintaa ja niihin liittyviä ratkaisuja
• Javascript:
• Node.js: tapahtumavetoinen palvelinpään toteutus Javascriptillä
(callback-kutsuja), sisältää palvelimen, soveltuu hyvin I/O-
tyyppiseen sovellukseen
(https://seroter.wordpress.com/2013/07/29/where-the-heck-do-i-
host-my-node-js-app/)
• Microsoftin ASP.net
• .NET-kielet: (CLI-ympäristö) C#, Visual Basic, F#, C++/CLI
(http://en.wikipedia.org/wiki/List_of_CLI_languages)
• Nykyään avointa lähdekoodia (Apache 2.0 lisenssi)
• Hyvä IDE-tuki (opiskelijoille kaikki työkalut ilmaisia, startupeille
tarjolla 3 vuoden ilmaisdiilejä)
• Mahdollisesti nopeampaa, käännetty koodi, mahdollisuus tehdä
perinteisempää ohjelman jakoa suoritusosiin
Ohjelmistokehys ohjaa arkkitehtuuria!
• Tutustu kehykseen ja älä koita tehdä asioita kehyksen vastaisesti,
vaikeuttaa ymmärtämistä, toteutustyötä, on typerää (valitse toinen
kehys jos se ei toimi haluamallasi tavalla)
• Kehyksistä lisää ohjelmistokehykset osiossa!
Pilvijutut
Mikä on pilveä?
• Periaate: pilvilaskenta tarjoaa näennäisesti loputtomat laskentaresurssit
tietoverkon yli
• Käyttäjä voi käynnistää, pysäyttää ja skaalata palveluita mielensä mukaan
• Palveluntarjoaja ja tekniikka toki asettavat rajoituksia touhuun
• Ideatasolla kuten vesi tai sähkö: Laskentaa tarjotaan samaan tapaan,
tarjotaan ja laskutetaan käytön mukaan, ei tarvitse itse huolehtia
“rautapuolen” asioista
• Yksityinen pilvi...
Mikä on pilveä?
Kriteeristöä:
• Palvelu on käytettävissä selaimen tai palvelurajapintojen avulla
(ei tarvetta erillisille asennuksille)
• Ei pääomainvestointeja käytön aloittamisen yhteydessä
• Maksat vain käytöstä
Pilvipalveluiden eri tasotlInfrastructure as a Service IaaS
Tietokonejärjestelmätason palvelu, usein virtuaalikone,
joka on heti käyttövalmis
lPlatform as a Service PaaS
Tarjoaa alustan ja ohjelmistot palveluna (kehityskalut,
tietovarastot jne.)
Usein PaaSin päällä ja sisältää SaaS sovelluksia
lSoftware as a Service SaaS
Iaas ja Paas tarkoitettu ohjelmistokehittäjille, SaaS
yleensä suoraan loppukäyttäjälle
Käyttö suoraan selaimella tai/ja API:n läpi (SOA-
palvelut)
Platform-taso hieman erilaisena
• Docker: https://www.docker.com
• Alusta, jolla sovelluksia voi siirtää, ajaa, paketoida
• Docker-kontin sisältö, sovellus ja sen kirjastot ja binäärit
• ”Kevyempi virtuaalikone”, Docker Engine ajaa dockeroituja
sovelluksia, voi ajaa useampia, jokaista omassa prosessissaan
(virtuaalikoneen kanssa mukana aina myös
käyttöjärjestelmäosa)
Mitä syitä siirtyä käyttämään
pilvipalveluita?
Mitä syitä siirtyä käyttämään
pilvipalveluita?
• Hinta, ei laitteistokuluja, henkilökuntaa (laitteistoon liittyen)
• Saavutettavuus (jos palveluiden tarjoajat luotettavia)
• Joustavuus, skaalautuvuus
• Helpompi dumpata epäonnistuneet projektit...
• Vuokrausperiaate
Arkkitehtuureista...
Hardware
Virtualization layer
Hardware
Host operating system
VM 1 VM 2 VM 3
Processing nodeProcessing node
Processing node
Job queue
Data
managerGet results
Push jobPublish
results
Get job
Grid application architecture
Korkean tason kerrosarkkitehtuuri
Separation of :
Presentation,
Business logic
Data storage
Transaktiopohjainen
sovellusarkkitehtuuri
Riskit/ongelmat?• Mitä huolenaiheita/riskejä pilveen siirtymisessä voisi olla?
• Mitkä tekijät omassa organisaatiossa voivat vaikuttaa
pilven/palvelutason valintaan?
Pilvikysymyksiä?lMitä asioita halutaan siirtää kolmannen osapuolen hallintaan?
lTietosuoja, varmuuskopiot, käytetyn palvelutoimittajan odotettu elinikä,
vendor lock, palvelusopimukset ja niiden muutokset, lisenssit, millä
tasolla palveluihin pääsee käsiksi, tarjolla olevat ohjelmistot jne.
l-->millä tasolla palveluita hankitaan?
lKustannukset ja osaaminen
Minkälaista osaamista porukasta löytyy?
Jotain sivistyneitä arvauksia kustannuksista?
Pilvi ja patternit ja arkkitehtuuritlPaljon yhteistä asiakas-palvelin-mallien kanssa (yllätys)
lHajautettavuus joko (virtuaali)konetasolla, komponenttitasolla
l-->yhteistä myös koneenohjausmaailman kanssa
Jotain ratkaisutapoja lMicro services architecture, tästä lisää vierailuluennolla
Pilvi ja patterneja / hyviä toimintatapojalNo single point of failure
lReplication, monitoring, load balancing,
backups, snapshots
l“separate real-time”
Priorisointi toimintojen tärkeyden perusteella
Permanent
storage
DB
master
DB
slaveCloud
front
internet
Esimerkki:
Kuorman
Tasaaja -
Load balancer
l cloudpatterns.org
http://aws.amazon.com/elasticloadbalancing/
https://msdn.microsoft.com/en-us/library/azure/dn655058.aspx
Tarkista pilvipalvelun tarjoajan tarjoamat vaihtoehdot!
Esimerkiksi palvelun automaattinen monistaminen virtuaalikonetasolla,
onko toimiva ratkaisu ongelmaasi?
Esimerkkejä pilvipalveluiden tarjoajien toteutuksista:
Viestijonot lMikä arkkitehtuurityyli tästä tulee mieleen?
lMissä muussa yhteydessä viestijonot tulivat esille?
Anna Ruokonen, PalPo
Rinnakkaiset asiakkaat ja palveluntuottajat
Pilvijutuista• Pilvimaailma ja palveluiden skaalaaminen jne.
• Joissain tilanteissa virtuaalikoneen saaminen pystyyn voi viedä puolikin tuntia,
skaalautumiseen jne. joutuu miettimään itsekin ratkaisuja (ei pelkästään
palveluntarjoaja taikoo meille lisää koneita aina kun tarve ilmenee)
• Asian helpottaminen, ohjelmiston jakamista osiin, ainakin tietojen käsittely
(tietokanta) ja sovelluslogiikka –> voidaan lisätä sovelluslogiikkaosia ja kuorman
jakaja, saadaan lisättyä tehoa (tai tietokantapuoli raskain, sinne lisää
potkua/hajautusta jne.)
Päätöksiä• Millä tasolla palvelua halutaan hankkia?
• Mikä laskutustapa sopii parhaiten?
• Miten lainsäädäntö sopii, voiko tiedon viedä maan ulkopuolelle?
• Pitääkö olla tarkka fyysinen paikka tiedolle?
Lisää pilvimaailman asioitalTTY:llä palvelupohjaiset järjestelmät kurssi: http://www.cs.tut.fi/~palpo/
• Palveluntarjoajista esimerkkejä (kannattaa kurkata mitä tarjoavat ohjelmistot jne.,
mihin hintaan jne.)
• https://cloud.google.com/
• Amazon Web Services: http://aws.amazon.com/ec2/
• Microsoft Azure: http://azure.microsoft.com/fi-fi/
• Nebula: http://www.nebula.fi/fi/palvelut/infrastruktuuri
• Pilveä itse säätäen:
• Omille palvelimille, Open Stack: https://www.openstack.org/
lEsimerkkejä suunnittelumalleista
http://www.cloudpatterns.org/
http://cloudcomputingpatterns.org/
https://msdn.microsoft.com/en-us/library/dn568099.aspx
Sisältää myös koodiesimerkkejä
Amazonin pilveen, Steve Riley: How to think cloud
http://www.scribd.com/doc/170852686/AWS-How-to-Think-Cloud-Steve-
Riley#scribd
YhteenvetolPilvi vai ei, pilvipalvelun tarjoajaa käyttämällä ei tarvitse miettiä niin tarkkaan paljonko
ja minkätyyppistä rautaa pitää hankkia
lSuunnittelussa täytyy kuitenkin miettiä, millä tasolla, mitä palveluja jne. käytetään
lSamoja ratkaisuja eri maailmoissa, jos ongelmat samankaltaisia, samankaltaiset
ratkaisutkin voivat toimia
Yleiskäyttöisyys
(Esimerkiksi: viestijonot, kahdennukset, työjonot, toiminnan seuranta)
Single Page Application
Palvelinpuoli, valitse REST, jos et keksi hyvää syytä SOAPiin
Tulevaisuuden ennustuksia, palvelut yhä enemmän hajautettuina, kirjautumispuoli,
tietojen tallennus, varsinaisen sovelluksen lataamispaikka. Omien palvelusalien jne.
käyttö vähenee.
Toisaalta kokonaispalvelua tarjoavat softatalot yleistymässä (esim. Vincit ja sen
ostokset)