Skatteetaten er i en prosess der de ser på hvordan de kan senke forvaltningskostnadene, øke endringsevnen i systemporteføljen, og bygge systemer som i større grad vil svare på fremtidige utfordringer. De har etablert et arkitekturmålbilde som legger stor vekt på skalerbarhet, testbarhet, vedlikeholdbarhet, driftbarhet og automatisering. “Modernisering av grunnlagsdata (MAG)”- og “Elektronisk dialog med arbeidsgivere (EDAG)”-prosjektene realiserer deler av målbildet. Hør om erfaringer fra disse prosjektene med fokus på automatisert utrulling, miljøer og versjonering, konfigurasjon og koordingering mellom tjenester, overvåkning og verktøy for drift og administrasjon. Vi ser på hva som fungerer, hva som fortsatt skaper friksjon og aktuelle alternativer som kan forbedre de utfordringene vi står ovenfor. Speakers Anders Sveen Utvikler, Miles Anders Sveen er utvikler og arkitekt hos Miles i Oslo. Han har i det siste jobbet såpass mye med Bash og Linux at han har begynt å kalle seg for drifter. I utformingen av systemer er smidig system-utvikling viktig, og han forsøker å balansere effektivitet og hastighet med forutsigbarhet og stabilitet i produksjon. | Han har erfaring fra små, store, bra og dårlige smidige prosjekter, men lærer stadig nye ting. Gjennom erfaringen med drift og ansvar i produksjon har han erfart hvor viktig det er å få hele verdikjeden til å spille sammen, ikke bare utvikle kjapt. Det finnes få ting som er så gøy som å legge ut noe i produksjon én dag, måle den neste, og legge ut en korreksjon den tredje dagen. no.linkedin.com/in/anderssv twitter:anderssv Trond Arve Wasskog CTO, Bekk Consulting Trond Arve Wasskog er utvikler, arkitekt og CTO i Bekk Consulting. Han har jobbet med utvikling på Java-plattformen i hele sin karrière, og er nå løsningsarkitekt for MAG og EDAG. | | no.linkedin.com/pub/trond-arve-wasskog/0/692/83b | twitter: @ilmyggo

1. UAVGENGIGHET I PRAKSIS

2. Små biter, store tall
• 50 applikasjoner
• 2-8 prosesser
• 20 databaser
• 13 miljø
• Over 1000 kjørende prosesser (100 i prod)
• Over 200 databaser (20 i prod)
• Summen større enn bitene til sammen

3. Tid og dynamikk
• Forskjellig takt gir forskjellige behov
• Testing og uavhengighet er essensielt
• Miljø skal ikke være en knapphetsressurs
• Forskjellig kapasitet til forskjellige tider
• Skatteetaten noe større…

4. KONTINUERLIGE LEVERANSER

5. Kontinuerlige leveranser
Continuous delivery is a set of principles and
practices to reduce the cost, time, and risk of
delivering incremental changes to users.
– Jez Humble
http://www.thoughtworks.com/insights/blog/case-continuous-delivery

6. Kontinuerlige leveranser
•
•
•
•
Få funksjonalitet foran brukerne
Reduser risko
Forbedre stabilitet
Øke effektivitet og redusere kost

7. Teknikker…
The HP
LaserJet Firmware team re-architected their software so they could apply
these practices (even though they were not releasing the firmware any more frequently). In the excellent book they
published about their journey (from 2008 - 2011), they record the outcomes they achieved:
•
•
•
•
Overall development costs reduced by ~40%
Programs under development increased by ~140%
Development costs per program reduced by 78%
Resources driving innovation increased by 5x
http://www.thoughtworks.com/insights/blog/case-continuous-delivery

8. Kontinuerlige leveranser
•
•
•
•
•
•
Automatisering
Kvalitetssikring
Størrelse på endringer
Separasjon av endringer
Uavhengighet i tid
Felles målsetning

9. Kvalitet
• Hvem tester på tvers?
• Hvordan får du til akseptansetester?
• … som ikke i seg selv er hindring mot endring…
• Hva skjer når det går galt?

10. KONTINUERLIGE LEVERANSER I
PRAKSIS

11. Automatisering!
• For mange bevegelige deler
• For få mennesker
• Alt må automatiseres
–
–
–
–
–
Deploy
WebSeal/BigIP
Databaser
Filområder
SFTP
• Løsninger på problemer må automatiseres

12. Automatisering!
• Deploy
– En kommando
– Oppgradering av data
– Automatiserer resursser
• Hvordan løser du det når noe går galt?
–
–
–
–
Analyse
Rulle tilbake?
Rulle fremover
Manuelle fikser
• Men…

13. DevOps

14. DevOps
Kode
Team
Konfigurasjon
Tjenester
Team
Operativsystem
Drift
Nettverk
Drift
Hardware

15. Stack
Java 1.7
Java 1.6
Glassfish 3.2.1 (Java 1.7)
Tjenester
Oracle 11
MongoDB 2.4
MongoDB 2.2
Webseal

16. Tydelig grensesnitt
• Utvikling
– Utvikler basert på tilgjengelige stack og tjenester
• Plattformdrift
– Lager stacks og tjenester
– Drifter plattformen
• Drift
– Sørger for maskiner
– Tilgjengelige ressurser
• Reduserer båndbredde og sikrer likhet på tvers av miljø
• PaaS

17. PaaS
• Felles målsetning?
• Fleksibilitet i plattform
• Nyutvikling av stacks og tjenester
• Alle trenger en IaaS
– Gulerot eller pisk?

18. THE GOOD PARTS

19. Pakking og standard deploy
• Leveransepakker
– Inspirasjon fra Heroku
– Versjoner via Nexus
• Migreringer
• Liten avhengighet til maskin
• Mange instanser fra samme pakke

20. Teknologier
Hazelcast
Akka
Elastic Search
Java
Glassfish
Guice
Jetty
Grizzly

21. Distribuert arkitektur
•
•
•
•
•
Uavhengighet mellom applikasjoner
Build pipeline…
Oppslagstjenesten…
Driftsdashboardet…
Robusthet…

22. Build pipeline
• Release når alt ser bra ut
–
–
–
–
–
–
Tester
Pakking
Release
Kodesjekker
Deploy til miljø
Grensesnittstester
• Jenkins
– Groovy automatisering
• Øker automatisering og kvalitetssikring
• Akseptansetester…

23. Build pipeline

24. Oppslagstjenesten
• Tjenesteregister
• Sparer oss for konfigurasjon
• Inspirasjon fra Netflix og AirBnB
• Fleksibilitet i fremtiden
• Noe vil alltid være i bevegelse
• Driftsinformasjon

25. Oppslagstjenesten
Oppslagstjenesten
Partsregisteret
Partsregisteret
Magnetsaldorente
Magnetsaldorente
Magnetsaldorente

26. Oppslagstjenesten

27. Driftsdashboardet
• Oversikt for ett miljø
• Helsesjekker
• Systemer med tjenester
• Hvis alt er rødt, hvor begynner du?
• Hvis alt er grønt, hva skal du sjekke i tillegg?

28. Driftsdashboardet

29. Robusthet i applikasjoner
•
•
•
•
Feil kontrollert
Selvbevisste applikasjoner
Sjekk omgivelser
Prøv igjen når situasjonen ikke eksisterer
lenger

30. Helsesjekker
• Hva er feil?
– Internt
– Eksternt
– Forventet/uventet
• Hvor alvorlig er det?
– Vent og se
– Sjekk et annet sted
– Debug

31. Helsesjekk

32. FREMTIDEN

33. Fremtiden
Begrensede resursser
på driftssiden kan
håndtere store
mengder
applikasjoner og
teknologier
Utvikling må ha frihet
til å velge, innovere og
bevege seg i forskjellig
takt

34. Fremtiden
• Høyere kvalitet
– Testdata
– Akseptansetester
– Verdikjeder
•
•
•
•
•
•
Mindre konfigurasjon
Mindre (manuell) overvåkning
Raskere deploy
Mindre deler som deployes oftere
Nye teknologier
Nye tjenester

35. Lykke til
•
•
•
•
Alt må automatiseres
Robusthet må bygges inn
Kvalitet bygges inn
Feedback looper kortes ned
• Det hjelper å gjøre det 
• Det er forskjellig fra system til system,
organisasjon til organisasjon

36. SPØRSMÅL?

37. Trond Arve Wasskog
trond.arve.wasskog@bekk.no
@ilmyggo
Anders Sveen
anders.sveen@miles.no
@anderssv