• Perinteisen palveluarkkitehtuurin (SOA) ja Microservices suuntauksen eroavaisuudet • Ketteryyden säilyttäminen sovelluskehityksessä • miksi usein käy niin, että hyvin aloitettu ketterä kehittäminen muuttuukin kuukausien ja vuosien saatossa mateluksi?

1. Microservices -
Palveluarkkitehtuurin
uusi tuleminen
Lari Hotari, Pivotal Software Inc.
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

2. A NEW PLATFORM FOR A NEW ERA
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

3. Pivotal
At-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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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

5. Agenda
• Perinteisen palveluarkkitehtuurin (SOA) ja Microservices
suuntauksen eroavaisuudet
• Ketteryyden säilyttäminen sovelluskehityksessä
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

6. “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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

7. Mihin softakehityksessä kaivataan
ratkaisuja?
• Nopea mukautuminen liiketoiminnan muuttuviin tarpeisiin:
– uusien innovatiivisten palveluiden tuottaminen
– liiketoiminnan optimointi / kustannusten karsiminen
– mahdollisimman nopeasti ja kustannustehokkaasti
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

8. 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.”
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

9. 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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

10. Yhteisiä ominaisuuksia onnistuneille
softaprojekteille tai hankkeille
• Projektien pieni koko
• Yksinkertaisuus
• Modulaarisuus
Ben Moseley, Peter Marks: Out of the Tar Pit , 1986
https://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.”
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

11. Miksi ketteräkehitys muuttuu mateluksi?
source: https://twitter.com/mfloryan/status/517238405781274624
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

12. 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)
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

13. 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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

14. Käyttäjäkokemus / UX
• Loppukäyttäjän näkökulmasta mikropalvelut eivät saa
näyttäytyä.
• Koottu näkymä
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

15. No shared layers!
• Eroon monoliiteista!
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

16. There is no silver bullet
• Essential complexity and accidental complexity
Fredrik P. Brooks, Jr.: No Silver Bullet - Essense and Accident in Software Engineering , 1986
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

17. 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
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

18. 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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

19. Kiitos!
@lhotari
lhotari@pivotal.io
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹##››

20. A NEW PLATFORM FOR A NEW ERA
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›