Geodata har vært på AWS siden den spede begynnelse i 2008. Presentasjonen omhandler våre erfaringer og hvordan vi har benyttet AWS for å effektivisere vår utvikling av tjenester og løsninger.
3. Om Geodata
• Selskap med lang historie, etablert i 1988
• Samtlige eiere har fortsatt tilknytning til selskapet
• Solid selskap med jevn vekst
• Distributør av Esri-teknologi i Norge
• Ca 125 ansatte
Steinkjer
Oslo
Stavanger
4. Geodata er en «GIS-integrator»
• Leverer tjenester på tvers av
hele verdikjeden til kundene
• Programvare
• Prosjektleveranser
• Rådgivning
• Support
• Opplæring
• Innholdstjenester
• Datatilrettelegging
• Drift av løsninger
• Erfaring fra noen av de største
og tyngste
forvaltningsprosjektene
10. Vår reise i AWS
• 2008: Sped begynnelse, eksperimentering
• 2009: Noen få tjenester kjørende på en single EC2 boks
• 2010: Gradvis flere tjenester settes opp i AWS. Fremdeles helt manuell
workflow for oppsette og drift av infrastrukturen. Hver EC2 boks var en silo
• 2011: Gradvis en mer lagdelt infrastruktur
• Fillagring, Databaser, Tjenester/Apps
• 2012-2015: Gradvis mer automatisering av infrastruktur. Utvikling av egen
dataflyt og prosesseringsplattform
• 2015-2016: «All in» på VPC og CloudFormation, med cfn-init og
bootstrapping. Implementering av rutiner for continuous delivery for
tjenester og apps.
Alle tjenester, apps og selve infrastrukturen er underlagt
versjonskontroll.
• 2016: Fullstendig automatisert deploy av tjenester og apps, inkludert
tilbakerulling til tidligere versjoner. Hele infrastrukturen satt opp som
CloudFormation stacks. Auto Healing og Auto Failover
• 2017: Omorganisering av leveranseapparatet til DevOps team.
Migrering mot microservices på Kubernetes (Docker containers)
13. Hva betyr elgbørsen.no for Geodata?
Ingen medarbeidere utførte manuelt arbeid for å takle økt trykk på tjenestene
15. • Continuous integration
• Integrering eller «merge» av kode i nærsanntid, og samtidig sikre at funksjonalitet og
egenskaper ikke brytes. «Build» server som kontinuerlig lytter på endringer i
kildekodesystem og gjør forsøk på å bygge kode og kjøre tester
• Continuous delivery
• All kode som «leveres» skal være produksjonsklar og produksjonstestet. I prinsippet
skal koden kunne deployes om kunder og organisasjonen for øvrig er klar
• Continuous deployment
• Er å ta det enda et steg. All kode som leveres blir også regelmessig (om ikke
automatisk) kjør ut i produksjon.
• Hvorfor? For å korte ned tiden fra ideer og behov oppstår til
funksjonalitet kan rulles ut til kunder. Mindre sårbar som
organisasjon og mindre avhengig av enkeltpersoner.
• Amazon har flere mekanismer som muliggjør konseptene
rent praktisk
20. Vurderingskriterier
• Er det varians i bruk av løsningen gjennom
døgn/uke/måned
• Krav til SLA og oppetid
• Hva er din kjernevirksomhet?
• Hvor lang levetid skal løsningen ha
• Er det viktig å holde investeringer i infrastruktur nede?
25. Tenk på
• Public Cloud skiller seg vesentlig fra On-Premise
• Ingen investeringer up front, pay-as-you-go
• Infrastruktur blir «provisioned» som del av koden/appen
• Man deployer ikke servere, man deployer en plattform/kapasitet
• Tenk serverless apps og tjenester
• Benytt PaaS i stedet for IaaS så langt det lar seg gjøre
• AutoHealing, AutoFailover og AutoScaling hvis man designer plattformen smart
• Alt må automatiseres og scriptes, skal man ta ut gevinst
• Flytte en løsning fra on-premise til cloud «as is» er sjelden en suksess på sikt
• Provisioning og deploy kan i hovedsak kjøre uten innblanding av den tradisjonelle IT-
driftsavdelingen. Sikkert skremmende for noen
• Hybridløsninger, sammenkobling av on-premise og public cloud er vanlig. Vi har det i
Geodata
• Tjenester må ligge å nært opp til dataene som mulig, lav latency. Dataforvaltning og
dataoppdatering er normalt en større utføring ved å flytte løsninger til skyen, enn tjenester
og apps.
26. Organisasjon og DevOps
• Cloud gjør at man kan og bør jobbe på en annen måte
• En ofte svært liten gruppe «enabler» resten av organisasjonen til
å jobbe med cloud-ressurser
• Utviklere får tilgang på cloud-ressurser direkte i utviklingsverktøy
• Infrastruktur behandles som kode
• Direkte integrasjon med kildekodeverktøy, både app-kode,
tjenester og selve infrastrukturen blir underlagt versjonskontroll
• DEVOPS – Organisatoriske endringer for å lykkes
• Utviklere og «plattform-drift» jobber sammen om en «løsning»
• Utviklere blir i stor grad de som løser feil i applikasjonene, plattformen skal ikke feile slik at
det krever menneskelig innsats (når/hvis det skjer må plattformen forbedres)
• Ingen tradisjonell «handover» fra utvikling til drift. «If you build it, you run it»
• Microreleases