Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Aws på kartet - 2

160 views

Published on

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.

Published in: Technology
  • Be the first to comment

Aws på kartet - 2

  1. 1. AWS på kartet Pål Kristensen Teamleder plattform
  2. 2. 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
  3. 3. 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
  4. 4. Kunder på tvers av alle segmenter
  5. 5. • Innholdstjenester • Offline innhold • Hosting av apps • Hosting av tjenester
  6. 6. 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)
  7. 7. Hva betyr elgbørsen.no for Geodata? Ingen medarbeidere utførte manuelt arbeid for å takle økt trykk på tjenestene
  8. 8. • 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
  9. 9. The Amazon way
  10. 10. S3 «site»-staging.geodataonline.no «site».geodataonline.no CF OK signal Elastic Eksempel på en av våre CI pipelines
  11. 11. AWS - CloudFormation - «secret sauce» • Infrastruktur som kode
  12. 12. 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?
  13. 13. Norge i Bilder – Norges nasjonale ortofotoarkiv
  14. 14. Norge i Bilder – Norges nasjonale ortofotoarkiv
  15. 15. Spot - AutoScaling group Spot - Launch Configuration Spot On-Demand - AutoScaling group - Launch Configuration Elastic
  16. 16. Flytt funksjonalitet, ikke løsning
  17. 17. 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.
  18. 18. 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
  19. 19. Takk for oppmerksomheten! Pål Kristensen palk@geodata.no

×