microservices - palveluarkkitehtuurin uusi tuleminen - emc forum 2014

‹#›© 2014 Pivotal Software, Inc. All rights reserved. ‹#›© 2014 Pivotal Software, Inc. All rights reserved.

Microservices - Palveluarkkitehtuurin uusi tuleminenLari Hotari, Pivotal Software Inc.

‹#›© 2014 Pivotal Software, Inc. All rights reserved.

A NEW PLATFORM FOR A NEW ERA


PivotalAt-a-Glance


• New Independent Venture: Spun out & jointly owned by EMC & VMware

• Top Talent: 1700~ employees• Proven Leadership: Paul Maritz, CEO• Global Customer Validation:

+1000 Tier-1 Enterprise Customers• Strategic Backing: $105M investment by

GE• Bold Vision: New platform for a new era,

focused on the intersection of Big Data, PaaS, and Agile Software Development


Pivotal Analytics


Agenda

• Perinteisen palveluarkkitehtuurin (SOA) ja Microservices suuntauksen eroavaisuudet

• Ketteryyden säilyttäminen sovelluskehityksessä


http://fi.wikipedia.org/wiki/Palvelukeskeinen_arkkitehtuuri

“SOA on suunniteltu ratkaisemaan samalla kertaa

ainakin kaksi keskeistä haastetta:

- uusien järjestelmien nopeamman kehittämisen ja

jakelun

- eri järjestelmien välisen integroinnin.”

http://fi.wikipedia.org/wiki/Palvelukeskeinen_arkkitehtuuri


Mihin softakehityksessä kaivataan ratkaisuja?

• Nopea mukautuminen liiketoiminnan muuttuviin tarpeisiin:– uusien innovatiivisten palveluiden tuottaminen– liiketoiminnan optimointi / kustannusten karsiminen– mahdollisimman nopeasti ja kustannustehokkaasti


Perinteisten palveluarkkitehtuuri (SOA) hankkeiden keskeisiä ongelmia

• Tuote ja teknologialähtöisyys ja riippuvaisuus– käyttäjäkeskeisyys heikkoa– tuoteostoja, ei todellisia tekoja

• Ratkaisujen – epärealistisuus– eivät vastaa tarpeita

• Organisaation huomioimatta jättäminen (Conwayn laki)• Tavoitteita ei ole pystytty täyttämään

kustannustehokkaasti.“SOA on suunniteltu ratkaisemaan

samalla kertaa ainakin kaksi keskeistä haastetta:

- uusien järjestelmien nopeamman kehittämisen ja jakelun

- eri järjestelmien välisen integroinnin.”


Conwayn laki

• Melvin Conway esitti vuonna 1968, että järjestelmäarkkitehtuuri ja sitä kehittävän tai ylläpitävän organisaation rakenne alkavat muistuttaa toisiaan.

• "Jos organisaation osat eivät tarkkaan heijasta oleellisia osia tuotteen rakennetta (tai päin vastoin), niin projekti on pulassa. Sen vuoksi varmista, että organisaatio on yhteensopiva tuotteen arkkitehtuurin kanssa."• Coplien and Harrison (July 2004). Organizational

Patterns of Agile Software Development. ISBN 978-0-13-146740-8.


Yhteisiä ominaisuuksia onnistuneille softaprojekteille tai hankkeille

• Projektien pieni koko• Yksinkertaisuus• Modulaarisuus

Ben Moseley, Peter Marks: Out of the Tar Pit , 1986https://github.com/papers-we-love/papers-we-love/raw/master/design/out-of-the-tar-pit.pdf“The “software crisis” was first identified in 1968 [NR69, p70] and in the intervening decades has deepened rather than abated. The biggest problem in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand.”


Miksi ketteräkehitys muuttuu mateluksi?

source: https://twitter.com/mfloryan/status/517238405781274624

https://twitter.com/mfloryan/status/517238405781274624


Microservices

• Suunnittelussa lähdetään siitä, että tavoiteltava ratkaisu on systeemi pienempiä systeemejä

• Systeemillä (mikropalvelulla) oma tietovarasto / tietokanta– ei jaettuja resursseja tai tietokantoja!

• Teknologia/tuote ei ole ratkaisu• Adaptiivisuus, oppiminen, lean, agile, pragmaattisuus• API-ajattelu• Palvelut tehdään tarpeeseen (pull vs. push)• Tarvittaessa "samaan asiaan" tehdään useampi erilainen

rajapinta sen ollessa järkevää (esim. client-tyyppi spesifiset rajapinnat)


Microservices• Yksittäiset palvelut voidaan päivittää milloin tahansa.

• Integraatiotestauksen sijaan keskitytään tuotannossa tapahtuvaan monitorointiin ja ongelmatilanteisiin reagointiin

– esim. Blue/Green (Canary) -deployment malli

– Pyritään mahdollistamaan jatkuva integrointi suoraan tuotantoon ilman ylimääräisiä vaiheita. Tämä sen vuoksi, että hukkatyötä on tällöin mahdollisimman vähän. Varmistelu ja testaaminen ei itsessään tuota lisäarvoa.

– ei poista tai korvaa esim. yksikkötestausta

• Palvelujen käytössä varaudutaan tilanteisiin, jolloin toinen palvelu ei ole käytettävissä - järjestelmä suunnitellaan toimimaan esimerkiksi rajoitetuilla ominaisuuksilla, kun jokin yksittäinen palvelu ei ole toiminnassa.


Käyttäjäkokemus / UX

• Loppukäyttäjän näkökulmasta mikropalvelut eivät saa näyttäytyä.

• Koottu näkymä


No shared layers!

• Eroon monoliiteista!


There is no silver bullet

• Essential complexity and accidental complexity

Fredrik P. Brooks, Jr.: No Silver Bullet - Essense and Accident in Software Engineering , 1986http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

http://worrydream.com/refs/Brooks-NoSilverBullet.pdf


Haasteet ja uudet ongelmat

• Datan konsistenttius• hajautetut tietovarastot aiheuttaa uudenlaisia

haasteita• CAP teoreema

• Hajautettujen järjestelmien ongelmat– 1. sääntö: älä hajauta

• Erilliset tietosaarekkeet (data island) joista aiemmin pyrittiin eroon– Älä unohda Master Data Management (MDM) tarvetta,

tosin sen pitää myös mukautua uuteen malliin


Periaatteita pitää muuttaa

• Mikropalvelujen käyttö saattaa tarkoittaa sitä, että esimerkiksi asiakastietoja on useammassa järjestelmässä eikä niitä ole keskitetty kuten useammassa asiakastietojen keskittämishankkeessa saattaa olla tavoitteena.– Tarvitaan uutta innovatiivista ajattelua, jossa

optimoidaan haluttuja asioita ja muutetaan järjestelmäperiaatteita tilanteen vaatimalla tavalla

– Uudenlainen Master Data Management (MDM, Perustiedot) on tarpeen. Perinteinen MDM voi olla voimakkaassa konfliktissa mikropalveluperiaatteiden kanssa.


@lhotari

Kiitos!

[email protected]


A NEW PLATFORM FOR A NEW ERA