Automaatio mahdollistaa Software as a Service - arkkitehtuurin Softatyön trendit 11.6.2015 käytännön kokemuksia kehittämistyöstä Jussi Haaja Senior Systems Specialist Twitter @jussihaaja
Esityksen sisältö Software as a Service arkkitehtuuri Mikä se on? Miksi sitä kannattaa tavoitella? SaaS-arkkitehtuurin avainkomponentteja Ohjelmallisesti hallittava infrastruktuuri Paketinhallinta Konfiguraationhallinta Orkestraatio Miten tämä liittyy seminaarin aiheeseen? Mitä tästä pitäisi IT-ammattilaisena ajatella? Käytännön kokemuksia aiheesta 2
Jussi Haaja Senior Systems Specialist Ambientialla vuodesta 2010 Ambientia Cloudin Concept Owner JIRA ja Confluence SaaSina Ratkaisun omistaja Tradenomi (ylempi AMK) Opinnäytetyön aiheena Software as a Service -arkkitehtuurin suunnittelu, validointi ja vaikutukset liiketoimintamalliin Twitter @jussihaaja 3
Software as a Service Suoraan käytettävissä olevia sovelluksia, joita palveluntarjoaja tarjoaa asiakkailleen hallinnoimastaan infrastruktuurista (Mell & Grance 2011) 4
Software as a Service -arkkitehtuuri SaaS-arkkitehtuuri = arkkitehtuuri, joka mahdollistaa Software as a Service palveluiden tuottamisen Verraten ASP (Application Service Provider) malliin SaaS-palvelut ovat: - Paremmin vakioituja (kaikilla asiakkailla on sama, usein jaettu, ohjelmistoversio) - Korkeasti automatisoituja (ympäristöjen provisointi uusille asiakkaille tapahtuu vaivattomasti) - Monitenanttisia, eli sama sovellusinstanssi palvelee useita asiakkaita 5
Miksi palveluita kannattaisi tarjota SaaSina? SaaS-toimintamalli mahdollistaa usein paremman liiketoiminnan skaalautumisen laajemmalle asiakaskunnalle. Pienempikin organisaatio voi palvella tehokkaasti varsin suurta asiakaskuntaa. Ei tietenkään sovi osaksi kaikkia liiketoimintamalleja. (Luoma & Rönkkö 2011) 6
Miksi palveluita kannattaisi tarjota SaaSina? Maailma muuttuu! Asiakkaat eivät jatkossa ehkä suostu yskimättä nielemään kalliita käyttöönottoprojekteja, kun osa toimijoista voi provisioida järjestelmiä sormia napsauttamalla. 7
Mitä SaaS-arkkitehtuuriin sitten tarvitaan? 8
Ohjelmallisesti hallittava infrastuktuuri Automaatiolla käyttöönotettavaa sovellusta on ajettava jossain Monitenanttista sovellustakin on voitava skaalata vaivatta Kutakuinkin sama asia kuin Infrastructure as a Service ratkaisujen pohjalla Software Defined Networking/Storage/Datacenter jne Verkkoja, tallennustilaa, virtuaalikoneita, containereita toistettavasti ja ilman manuaalisia työvaiheita Toteuta itse tai osta palveluna (Amazon, OpenStack) 9
Paketin- ja konfiguraationhallinta Käytännössä kaikki sovellukset koostuvat kolmesta komponentista: Sovellusbinäärit Konfiguraatio Sovellusdata Paketinhallinta on ratkaisu erityisesti sovellusbinäärien levittämisen hallintaan Linux-jakeluissa paketinhallinta on ollut ensimmäisen luokan kansalainen jo pitkään (RPM, DEB jne.) Windows-maailmassa tullaan perästä Chocolatey/NuGetratkaisujen kanssa 10
Paketin- ja konfiguraationhallinta Paketinhallintatyökaluilla voidaan siis ratkaista binäärien levittäminen, mutta miten ratkaistaan konfiguraation levittäminen? Onnistuu paketinhallintajärjestelmilläkin, mutta kaikki konfiguraatiomuutokset vaativat uuden paketin julkaisua Huolellisella suunnittelulla mahdollista mutta käytännössä.. 11
Paketin- ja konfiguraationhallinta..on jonkin verran konfiguraatioita joita on varsin vaikea paketoida Kaikki konfiguraatio ei ole vain tekstitiedostoja levyllä Tietokantaskeema ja sen oikeuksien määritys Aivan ehdottomasti tämä on konfiguraatiota Mutta miten se esitetään tiedostoina levyllä? Paketinhallintajärjestelmä on hyvä levittämään tiedostoja, mutta huono tekemään mitään muuta 12
Paketin- ja konfiguraationhallinta Erillinen konfiguraationhallintajärjestelmä on joustavampi ratkaisu Se on juuri tätä tarkoitusta varten tehty Konfiguraationhallintajärjestelmä osaa lähes poikkeuksetta kytkeytyä järjestelmän paketinhallintajärjestelmään Täsmällisiä pakettiversioita voidaan ohjata konfiguraationhallintajärjestelmästä Kokonaisvaltainen paketinhallinta + konfiguraationhallinta = kaunis kokonaisuus 13
Orkestraatio, eli millä tämä kaikki kasataan Edellä esitetyt järjestelmät toimivat periaatteessa toisistaan itsenäisesti, vaikka osaavatkin osittain keskustella keskenään Lisäksi tarvitaan jokin orkestraatiokomponentti, joka voi ohjata ainakin: Uuden infrastruktuurin provisointia Konfiguraationhallintaa Ja sitä kautta paketinhallintaa Amazon CloudFormation OpenStack Heat 14
Ja sitten niitä käytännön kokemuksia 15
Esimerkkiarkkitehtuuri #1 (Haaja 2015) 16
Esimerkkiarkkitehtuuri #2 (Kirschnick, Alcaraz Calero, Wilcock, Edwards 2010) 17
Onko tästä sitten oikeasti hyötyä? Lyhyesti: on - Erityisesti jos: - Liiketoiminnan skaalautumishaasteet ovat vastaavia kuin muinoin ASPmallissa - Löytyy halua vakioida palveluita 18
Hyödyn määrä Kun sovellus on hyvin vakioitu eikä asiakaskohtaisiin poikkeuksiin tarvi varautua Käytännön kokemukset ovat osoittaneet että sovelluksilla, joita ei ole suunniteltu SaaS-arkkitehtuuria silmälläpitäen voidaan saavuttaa 2-3 kertaa lyhyempi läpimenoaika sekä käyttöönotoille että versiopäivityksille Versiopäivityksissä hyöty on jopa suurempi, 4-5 kertainen Jos sovelluksen voi suunnitella SaaS-arkkitehtuurin ehdoilla (esim. siten että se tukee useita asiakkaita samassa instanssissa) hyöty on vielä suurempi. 19
Käytännön vinkkejä Vastusta kiusausta tehdä kaikki paketinhallintajärjestelmällä Vastusta kiusausta tehdä kaikki itse Valmiita ratkaisuja on jo Valitse sellaiset komponentit jotka tukevat olemassaolevaa infrastruktuuria Red Hat -> RPM, Puppet 20
Mitä kannattaa opetella? Paketinhallinta Miten paketoin oman sovellukseni käyttäen käyttöjärjestelmän paketinhallintaa Konfiguraationhallinta Miten automatisoin sovellukseni käyttöönoton käyttämällä konfiguraationhallintatyökalua Rajapintaohjelmointi Miten orkestroin uuden ympäristön provisioinnin? Amazon, OpenStack En halua operoida infrastruktuuria itse, miten voin helposti ohjata muiden infrastruktuuria? 21
Kiitoksia mielenkiinnosta! Kysymyksiä? 22