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
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…
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
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
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?
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…
19. Pakking og standard deploy
• Leveransepakker
– Inspirasjon fra Heroku
– Versjoner via Nexus
• Migreringer
• Liten avhengighet til maskin
• Mange instanser fra samme pakke
24. Oppslagstjenesten
• Tjenesteregister
• Sparer oss for konfigurasjon
• Inspirasjon fra Netflix og AirBnB
• Fleksibilitet i fremtiden
• Noe vil alltid være i bevegelse
• Driftsinformasjon
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?
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