DevOps - Mitä ja Miksi

class: center, middle, title
count: false

<img src="../styles/nitor_logo_fi.png" width="70%">
# DevOps
## Mitä ja Miksi

---
class: center, middle, me

# Pasi Niemi
## Principal Cloud Architect

???

* Ohjelmistoalalla ~20vuotta
* Vedän Nitorin pilviosaamisen kehittämistä
* Sukkuloinut kehityksen ja asiakkaiden operointiorganisaatoiden väliä 
  2000-luvun alusta
<table>
<tr><td>Nokia</td><td>Vodafone</td><td>Sonera Zed</td><td>Radiolinja</td></tr>
<tr><td>T-Mobile, Alankomaat</td><td>Finnair</td><td>Telefonica, Espanja</td><td>M1, Singapore</td></tr>
<tr><td>Etisalat, UAE</td><td>MTC, Bahrain</td><td>QTel, Qatar</td><td>STC, Saudi Arabia</td></tr>
<tr><td>MTC Touch, Libanon</td><td>Dubai Police</td><td>Luottokunta</td><td>Kesko</td></tr> 
<tr><td>MTV3</td><td>Eurotel, Tsekki</td><td> </td><td> </td></tr>
</table>
* 2016 AWS reInvent GameDay voittaja
* Aiheeseen liittyviä OSS komponentteja
  * https://github.com/NitorCreations/nitor-deploy-tools
    * Jenkinsiin integroituva CloudFormation työkalupakki
    * Tuotannossa asiakkailla (erään palvelun 100x skaalaus tänä vuonna)
  * https://github.com/NitorCreations/willow
    * Monitorointi ja operointi palvelin
---
class: center, middle, definition

# Määritelmä

???

* DevOps ei ole hyvin määritelty
* Taustalla kitka (QA,) operointi ja kehitysorganisaatioiden välillä
  * Operointiorganisaatio haluaa maksimoida palvelujen saatavuuden
  * Hyvät kehitysorganisaatiot haluavat maksimoida palvelujen tuoman arvon
  * Kehitysorganisaatiot kokevat operointiorganisaatioiden hidastavan kehitystä
  * Operointiorganisaatiot kokevat kehitysorganisaation vaarantavan palvelujen
    stabiiliuden
  * Kommunikointihaasteet usein johtavat kommunikaation formalisointiin, joka
    usein ennestään heikentää kommunikaatiota
* Ammattilaiset, jotka olivat nähneet molempia organisaatioita, alkoivat jakaa
  kokemuksiaan DevOpsDays konfferensseissa ja twitterissä #DevOpsDays -> #DevOps
* http://itrevolution.com/the-history-of-devops/

---
class: center, middle, emergent

# Emergentti

???

* Ei standardointi järjestöä, määritelmädokumenttia
* Kokoelma ammattilaisten kokemuksia toimivista ratkaisuista
  * Ehkä juuri se syy, miksi itse koen samaistuvani DevOps lähestymiseen
* Jotkut tietenkin yrittävät myydä erilaisia asioita DevOps otsikolla
* En usko että DevOpsin tiukka määrittäminen auttaa käytäntöjen kehittämistä

---
class: center, middle, why

# Miksi

???

* Ohjelmoistoilla tuotetut palvelut tuovat nykyään merkittävää kilpailuetua
* Sen lisäksi että palvelut on saatavilla, on niitten oltava kilpailijoita parempia
* On kyettävä liikkumaan nopeasti
  * Organisaatiorajat (DEV, QA, OPS) siirrettäessä ratkaisuja tuotantoon
    välttämättä hidastavat etenemistä
  * Kun projekteja on useita ja niillä on riippuvuuksia toisistaan, hitauden
    aiheuttamat ongelmat kasvavat eksponentiaalisesti
* Kustannuspaineet
* Kokeilukulttuuri
* Molemmilla organisaatioilla on opittavaa toisistaan
  * Nopea sykli mahdollistaa nopean palautteen ja ongelmien korjaamisen
  * Pienemmistä muutoksista pienemmät asiat rikki
  * Desing for failure
  * Kommunikaatio keskeistä, jotta riskit ymmärretään ja voidaan mitigoida
    * Paranee tekijöitä tiivistämällä, ei niinkään työkaluilla
  * Infrastructure as code

---
class: center, middle, example

# Käytännön esimerkki

???

* iso java ja CORBA pohjainen CMS
  * CORBA on 90-luvulla kehitetty, ohjelmien väliseen kommunikaatioon tarkoitettu määritelmä
  * Liian raskaana ja vaikeasti skaalattavana se on jäänyt ulos laajasta käytöstä
* Pelkkä kääntäminen ja paketointi kesti 40minuuttia
  * maven, joka ajaa ant skriptejä, jotka ajaa maven targetteja, ei rinnakkaisuutta
  * maven on yleisin javan kääntämiseen ja paketointiin käytetty työkalu
  * ant on vanhempi, vähän alemman tason työkalu, jota käytetään samanlaisiin tehtäviin
  * molemmilla on nyttemmin vähän huono maine johtuen verboosista xml konfiguraatiosta
* Dev ympäristö päivitettiin öisin, joka yleensä epäonnistui ja oli suuren osan
  päivästä pois käytöstä. Tämäkin asennus kesti tunteja.
* Integraatiotesti ympäristöä ryhdyttiin päivittämään lähempänä sprintin loppua
  * Ensimmäinen paikka missä bugit aidosti ilmaantuvat -> useita käsin asennuksia
* Ei luottamusta  QA buildin laatuun
* CI (Jenkins) palvelin oli jaettu usean projektin kesken, vanha ja hidas
  * Ei mahdollisuutta kokeilla mitään uutta
---
class: center, middle, tools

# Työkaluja

???

<table>
<tr><td>Jenkins</td><td>Maven</td><td>FindBugs</td></tr>
<tr><td>PMD</td><td>CPD</td><td>xdelta</td></tr>
<tr><td>fpm</td><td>bash</td><td>expect (tcl/tk)</td></tr>
<tr><td>jasmine</td><td>graphviz</td><td> </td></tr>
</table>

* Itse työkalut ei ole tärkeitä
* Tiimi valitsi itse ne työkalut, jotka koettiin tehokkaiksi
  * Kokemuksella paljon merkitystä tässä
---
class: center, middle, work

# Mitä tehtiin

???

* Kääntäminen ja paketointi uusiksi
  * Nopea palaute
    * Buildin tai staattisen analyysin rikkojalle  mailia parin minuutin sisään
    * Ehdoton vaatimus tiimin tuottavuuden kannalta
* Oma jenkins, johon saa kaikki halutut pluginit ja joka on riittävän nopea
* Iso näyttö jossa buildien ja ympäristöjen tilanne
  * Koodinlaatu metriikat näkyville
* Automate all the things
  * Deploymentit
  * Testaus
  * Prototyypin muutosten seuranta ja integrointi (html, javascript ja css)
  * Version mukana menevät tietokantamuutokset osaksi deploymenttia
  * Eri tyyppisiä tietokantoja, joista kukin vaati omanlaisensa ratkaisun
  * Tietoturvapäivitykset osaksi uuden version tuotantoonvientiä

---
class: center, middle, outcome

# Lopputulokset

???

* https://www.researchgate.net/profile/Laanti_Maarit/publication/300711022_Case_Study_in_Responsive_Web_Design_Pragmatic_Agile_and_Hero_Team_Approach_-_Time_and_Cost_Savings_with_Quality_Improvement/links/5756a1ff08ae10c72b6980a4/Case-Study-in-Responsive-Web-Design-Pragmatic-Agile-and-Hero-Team-Approach-Time-and-Cost-Savings-with-Quality-Improvement.pdf
* Toki DevOps malli ei ollut ainoa asia, mitä parannettiin
* 90% nopeampi build
* 95% nopeampi build to test env sykli (silloin kun alkuperäinen test env edes toimi)
* Joka yö luotettavasti päivittyvä integratiotestiympäristö
* QA ja tuotantoympäristöjen asennus manuaalisesta ~16 tuntisesta tehtävästä
  2.5 tuntiseen automatisoituun
* Pienemmällä porukalla enemmän ja laadukkaampia tuloksia osaltaan näitten
  parannusten ansiosta

---
class: recommendations

# Suositukset

* Keskity palautteen laatuun, nopeuteen ja näkyvyyteen
* Testaa oikeilla tasoilla
* Mittaa testauksen kattavuus
* Tiimissä oltava pääsy tuotantoon asti
* Automaattinen version asennus samaksi kaikkiin ympäristöihin
* Mieti miten käytännöt tukee tai voisi tukea laajempaa toimintaa

???

* Palautteen nopeudella ja näkyvyydellä iso vaikutus tiimin tehokkuuteen
* 100% unit test kattavuus on tuhlausta
* Staattinen koodianalyysi on myös tavallaan testausta
* Testauksen automaatio parantaa kattavuutta ja nopeutta
* Koko pinon testaus on merkityksellisempää
* Muutoksen riskit voi ymmärtää vain jos tietää miten sitä ympäröivä
  toiminnallisuus on testattu
* Ongelmien selvittämisen nopeus
* Tiimin tulisi itse kehittää asennusautomaatio
* Kehittyvä järjestelmä usein vaatii muutoksia asennukseen
* Asennus on myös koodia, jota on testattava
* Laajempi tavoite on tientenkin läpimenoaikojen minimointi
  * Voidaan reagoida uuteen dataan tai mahdollisuuteen