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)