Pari sanaa ketteryyden,
DevOpsin ja Dockerin liitosta
Antti Vartiainen
14.10.2016 / AgileJKL meetup

asenne + ? = ketteryys

Mitä on ketteryys?
• Lean (filosofia) -> Agile (metodologia) -> esim. Scrum tai Kanban (menetelmät)
• Ketteryyttä ei voi omaksua ylhäältä päin johdettuna tai käskettynä
• Ei ole kahta samanlaista ketterää tiimiä
• Ketteryys vaatii toteutuakseen menetelmän
• ”Kun Scrum epäonnistuu, otetaan avuksi Kanban” – ei hoccuspoccuksia vaikka kokemus on ketterien
menetelmien soveltamisessa vahvuus
• Pelkkä menetelmä edes oikein sovellettuna ei mahdollista onnistumista, vaikka tiimi ja asiakas
olisivat täydellisen sitoutettuja lopputuloksen aikaansaamiseksi
• Ketterät menetelmät vastaavat henkisestä ohjauksesta, mutta tarvitaan myös konkreettisia
työkaluja
• Ketteryys on kykyä hallita epävarmuutta
• Ketteryys EI ole kristallipalloon katsomista

Rautalangasta väännettynä
LEAN
AGILE
SCRUM KANBAN+

DevOps = ketteryyden mahdollistaja
• Tuotantoputken (”build-pipeline”) hallinta (Ops) toteuttajien (Dev) käsissä
• versionhallinta (ja käytännöt)
• keskitetty käännösten hallinta (CI/CD)
• konfiguraation hallinta
• deploymenttien hallinta
• monitorointi
• Kaikki on automatisoitavissa – kaikki mikä on mahdollista myös automatisoidaan
• Metriikat – ohjelmistoa tehdään aina lähtökohtaisesti tuotantovalmiina
• Mahdollistaa ketteryyden aspektin joka jää yleensä puheen tasolle – voidaan milloin
tahansa mennä tuotantoon kun PO toteaa, että ”enough”

Kuva: Chef.io

DevOps Digialla
• Automatisointi tarkoittaa työvaihdein kuvaamista ”skriptaamalla”
• Älä usko DevOps-tuotteisiin
• Ei kahta samanlaista tiimiä tai ympäristöolosuhteita
• Visualisointi tärkeää, kaikki metriikat tukevat myös operatiivista käyttöä
• Ei pelkästään saarnata vaan tehdään
• Sisäisiä auditointeja samalla konsultatiivisella lähtökulmalla kuin asiakasauditointeja
• Valmiit referenssitototeutukset ja demottavat ympäristöt esim. Dockerin avulla
• ”build pipeline” tunnissa
• Tärkein kysymys lopuksi: mitä on managerointi? Voitaisiinko myös se automatisoida?

”Perinteinen” vs DevOps
Perinteinen DevOps
Yhden ”erän” koko Iso Mikro
Organisaatio Kehitys ja käyttöpalvelu
erikseen
Kehitys ja käyttöpalvelu
samasta tiimistä
Aikataulutus Keskitetty Hajautettu ja jatkuva
Julkaisu Iso riski Ei riskiä
Kulttuuri ”Älä epäonnistu!” ”Epäonnistu varhain!”
Mittarit Raha ja kapasiteetti Raha, kapasiteetti ja aika
Definition of Done Tein työni Valmis tuotantoon

Perinteinen vs DevOps - työviikko
Kuva: ZeroTurnaround
Study from 620 software engineers

Perinteinen vs DevOps – Julkaisuun
käytetty aika
Kuva: ZeroTurnaround
Study from 620 software engineers

Perinteinen vs DevOps – Järjestelmän
toipumiseen käytetty aika
Kuva: ZeroTurnaround
Study from 620 software engineers

DevOps = Time To Market –ajan
lyhentäminen

Terminologia
Sovellukset
Data
Ajoympäristö
Middleware
OS
Virtualisointi
Palvelimet
Tallennustila
Tietoliikenne
Oma palvelinympäristö
Asiakasvastaa
Sovellukset
Data
Ajoympäristö
Middleware
OS
Virtualisointi
Palvelimet
Tallennustila
Tietoliikenne
Pilvipalvelin (IaaS)
AsiakasvastaaPalveluntarjoajavastaa
Sovellukset
Data
Ajoympäristö
Middleware
OS
Virtualisointi
Palvelimet
Tallennustila
Tietoliikenne
Sovellusalusta (PaaS)
AsiakasvastaaPalveluntarjoajavastaa
Sovellukset
Data
Ajoympäristö
Middleware
OS
Virtualisointi
Palvelimet
Tallennustila
Tietoliikenne
Sovellus (SaaS)
Palveluntarjoajavastaa
Sovellusalustan avulla kehittäjä voi keskittyä ainoastaan sovelluksen
ja sen tietojen toteuttamiseen. Ei enää tarvetta käyttää aikaa palvelimien, käyttöjärjestelmien,
kuormantasaajien, verkkoympäristön tai konesalien pystyttämiseen ja ylläpitämiseen.
Dockerin koti

Lyhyesti: mikä ovat kontit?
Lähde: https://www.docker.com/whatisdocker/
Virtuaalikoneet
Yksittäinen virtuaalikone sisältää varsinaisen sovelluksen lisäksi
täydellisen käyttöjärjestelmä kopion, jonka koko voi olla jopa 10
gigatavua (GB).
Kontit
Konttimoottorin avulla ajettava ”kontti” (eng. container) sisältää ainoastaan
sovelluksen ja sen riippuvuudet. ”Kontti” on eristetty prosessi joka jakaa
isäntäkäyttöjärjestelmän suoritinytimen muiden mahdollisten konttien
kanssa ollen huomattavasti siirrettävämpi ja keveämpi kuin perinteiset
virtuaalikoneet.

Raudasta virtuaalikoneisiin ja Dockeriin
Aika ennen 2000-lukua… Konsolidointi virtualisoimalla Sovellusten kontitus
Virtuaalikoneet Docker
Edut tuettuina kaikki käyttöjärjestelmät, minkä tahansa laitteiston
emulointi
kevyesti siirrettävät sovellukset ”kontti”-periaatteella, ei
välttämättä lisenssikuluja ajoalustasta, nopea jakelu ja
operointi, käyttöjärjestelmäresurssien tehokas hyödyntäminen
Haitat virtualisointikerroksen käytössä ”hukkaan kuluvat” resurssit,
lisensointi, raskaat käyttöjärjestelmän levynkuvat mistä
johtuen hidas jakelu ja operointi
ei tukea vielä kaikille käyttöjärjestelmille, esim. AIX, HP-UX ja
Windows 8 tai aiemmat

Mihin Docker sopii ja ei sovi?
• Sopii parhaiten:
• Tuotteet, joiden halutaan skaalautuvan ja toimivan alustariippumattomasti
• Kontitetut ”oheistuotteet”, esim. mikropalveluarkkitehtuurin middleware
• Yleensä no-go:
• ”single shot” -räätälöityjen sovellusten jakelu suljetussa ympäristössä – ei lisäarvoa – perinteiset
”DevOps-menetelmät” (automatisoitu konfiguraationhallinta ja deploymentit) toimivat yhtä hyvin tai
jopa paremmin
• Toisaalta:
• Jos sovellus on hyvin monimutkainen kontittamisen avulla voidaan rakentaa esim.
tuotantoympäristön kaltainen konfiguraatio kehittäjän työasemalle lyhyessä ajassa, voi
kontittaminen olla hyvä ratkaisuvaihtoehto…

Kiitos!
Antti Vartiainen, ratkaisuarkkitehti
etunimi.sukunimi@digia.com | www.digia.com