Fra classic til cloud - Cloud based build & deployment IT & Telestyrelsen 2010 Møde d. 13 april 2010

Agenda • Introduktion - Hvad betyder skyen • Paradigmeskifte – Fra ”classic” til ”cloud” • Case: TradeShift – Lessons learned • Build, deploy og operation • Erfaringer og opsummering • Spørgsmål

I think there is a world market for maybe five computers -- ”Berømt” citat af Thomas Watson, IBM 1943

De fem computere i verden • Amazon EC2 • Google AppEngine • Microsoft AZURE • Salesforce Force.com • Facebook Applications

Vi er en forholdsvis lille planet • beboere (wikipedia.com) • er on-line (internetworldstats.com) • er på Facebook (facebook.com) – De bruger i øvrigt minutter per måned (23 timer/bruger/måned) – Ca. 25% af markedet – FB viser Ads per år. (mashable.com)

Cloud – et ny paradigme • Internet hastighed og båndbredde til alle • WiFi og Mobil høj(nok)hastighed ”overalt” • Ekstrem skalerbar service – 1 til 100 servere på ”no time” • Integration med andre systemer – REST, Soap, XML, JSON • Apps til kundespecifikke funktioner

Fra Classic til Cloud Classic Som vi gjorde for 10 år siden Classic Som vi gjorde for 10 år siden Cloud Som vi gør det I dag Cloud Som vi gør det I dag

Erfaringer– Classic • SDC – Netbank, Aktie handels portal, CMS til 150 penge institutter i Norden, performance optimering • CSC, PBS – Payment gateway, Logistic hub integration Deutche Post • Nykredit, KMD – Konsulent arbejde • FedEx, Aldo, DHL, LaPoste, Sydney Airport, … – Logistik styrings opgaver og integration

Erfaring(er)- Cloud • Tradeshift – Global E-faktura – Amazon EC2, github, zendesk, • Bookieman.net – Vagt planlægning og afvikling – Rackspace, bitbucket • OfficeDesign – Mindre dansk, nu ”virtuelt” firma – Basecamp, Highrise, Bitbucket, Gmail, GAE, Hyperspin, e- conomics

Teknologier ClassicCloud Udviklings paradigmeVandfaldAgil Programmerings sprogStatisk (Java, C#, C++)Dynamisk (Python, Ruby, Scala) SCMVCS (CVS, SVN)DVCS (Mercurial, git) RepositoryIntern serverBitbucket, github, code.google.com, codeplex HostingInterne servereAmazon, Google, AZURE, Salesforce, Facebook Mail og kalenderExchange, GroupWise, Notes Gmail, Google Apps Projekt styringMS ProjectBasecamp, PODIO, Timelog Issue trackingExcel, AccessTrac, Jira CRMMS CRM, SuperOfficeSalesforce, highrise

Build, test, deploy - Classic Devel Test Staging Produktion Repository •Single repository (Subversion, CVS) •Lokale udviklingsmaskiner •Testsetup er nedskaleret version af produktion •Staging ligner produktion •Kode skubbes fremad i systemet, ofte med manuelle operationer •Stor forskel på Test og Produktions miljø •Produktion står stille medens ny kodebase installeres •Rollback kan være svær

Build, test, deploy - Cloud Build Test Produktion2 Repository Devel Artifacts Produktion1Produktionn •Distribueret versions kontrol •Test, Staging og Produktion er ens •Pull arkitektur •Switch Staging til Produktion

Drift, support og overvågning • Classic • Drift – Bemandet kontrol rum • Overvågning – TNG, Tivoli, OpenView • Support – Lokal løsning • Cloud • Drift – Hotline/SMS • Overvågning – Hyperspin, site24x7.com, Hyperic • Support – Zendesk

Case - TradeShift • Global e-faktura management – Med Social media dimension • Historie – 2009 Dec Første design møde – 2010 Maj Produktion DK – 2010 Jul Launch EU – 2010 AugLaunch USA • Ekstrem skalerbar forretning – 0 til brugere på et kvartal

Amazon Elastic Compute Cloud (EC2) • AMI – Amazon Machine Image: Et image som er gemt. • S3 – Snapshot af AMI gemmes her. • Instans: Kørende version af AMI. En ”PC” der kan installeres og konfigureres efter behov. • EBS – Elastic Block Store: Persistent lagring. • EIP – Elastic IP Addresses: Reservering af ”fast” IP adresse. • Security groups: Amazon firewall som kobles på instanser når de startes. • CloudWatch: Metrikker på en instans. • Auto Scaling: Oprettelse af nye instanser baseret på metrikker. • ELB – Elastic Load Balancing: Distribuering af trafik imellem instanser.

Amazon EC2 i use case contekst Frontend Backend PostgreSQL ESB (API) I.S. Public zone DMZ Private zone

Build • ”Single” click build og release af projekter. • Build – Fleksibel, åben og næsten standard. • Versionering af pakker, moduler og releases. • Cloud baseret build/deploy servere. • Nye releases kan automatisk deployes • Nye instanser startes automatisk

Build arkitektur Mercurial Hudson Nexus Maven

Build, Test and Deploy

Deploy • ”Single” click deployment af servere og services, hvor alt sættes op automatisk. • Automatiserede tests køres efter deploy. • Minimalt manuelt arbejde sikrer maksimal tiltro til deploy. • Fleksibel overgang fra test til staging, og videre til produktion. • Opstramning i release proceduren konfigureres efter behov. • Framework er allerede lavet. Konfigureres vha. XML. • Nye komponenter tilføjes i Python

Deployment cycle Hudson build Hudson build Change production servers Configure servers Install packages Restore Backup snapshot Create packages Create servers Test deployment

Operation • Hyperic – Overvågning af instanser og deploys. • Hyperic agenter konfiguration igennem deployment. • Hyperic server er placeret i EC2. • 24/7 hotline.

• Module release • Tradeshifts release Software release

Deploy • Software release – Moduler der skal fordeles

Deploy • Moduler fordelt på forskellige servere

Deploy • Hvordan deployes der til Amazon instanser – Deploy tool opbygning Test Staging Production Id Step 1 Step 2 Step 3 Step n Step 2 Step 3 Step 5 Step 2 Step 7 Step 8 (Data)

Deploy • Hvordan deployes der til Amazon instanser – Deploy opdelt i ansvarsområder / steps 1.”Capture data” fra fra kørende build 2.”Instantiate amazon resources” 1.Instance, EIP, EBS, S3 access, SQS etc 3.”Configure modules” dynamisk konfiguration af moduler i forhold til det aktuelle deploy 4.”Create install packeges” pak software + konfiguration + installere i zip filer til brug på nye amazon instanser 5.”Install instances” kopier og intaller software på amazon instanser 6.”Restore persistent data” tag test/produktions data fra backup og ”rul ud” på nye instanser 7.”Integrations test” test at systemet fungere med test/produktions data

Dynamisk konfiguration af moduler i forhold til det aktuelle deploy (Data) Konfigurations- database Server layout Ekstra konfigurations værdier ’Secrets’ Module A Module B Module C

Konfiguration af deploy • Deploy konfiguration – Software release – definere software releasen der skal benyttes (version, snapshot, beta, rc, final) – Server layout – Service – information om diverse services – Security group – firewall konfiguration – Instance type – server størrelsen – Elastic ip – ved brug af fast ip – Elastic blok store – hardisk snapshot der skal benyttes – Software component – En component svarer til Maven artifact, e.g. Tradeshift-backend

Konfiguration af deploy • Deploy specifikke værdier – Forskellige backup lokationer – Loglevel - Debug i Test – Forskellige setups, alle mails til test eller rigtig udsendelse – Opsætning af database driver: e.g. postgres til test, oracle til produktion – Generelt kan der gives ekstra konfiguration med heri

Konfiguration af deploy • Håndtering af ’secrets’ – keys – Key filer – ssh, keystore, ssl certifikater – Password • Deploy server er ”trusted” og indeholder alle ’secrets’ – Man refererer fra deployConfiguration.xml til stier / filer på build serveren – Deploy konfigurerer moduler med adgang til databaser, backup, nøgler mm.

Konfiguration af deploy • Modulers ’config’ folder – Mulighed for at customisere en installerings sekvens på serveren – Mulighed for at medbringe filer, zip filer, kataloger m.m. – Konfiguration af.xml og.properties filer med • Konfiguration af værdier som først er kendt på deploy tidspunkt – Private / public ip’er af servere – Private / public ip’er af forskellige software serivices • Deploy specifikke værdier – Modul specifikke værdier – Værdier fra deployment

Konfiguration af deploy • Eksempel på.properties fil • Eksempel på.xml fil commercial = ${server.Frontend-Product.privateDns} product = ${server.Frontend-Commercial.privateDns} commercialPublic = ${server.Frontend-Product.publicDns} productPublic = ${server.Frontend-Commercial.publicDns} tradeshift-backend

Erfaringer • Lokal test bliver sværere for udviklere – Men fuld deploy og test er meget nemmere. • Forholdet til servere og testmiljø ændrer sig væsentligt for udviklere. – Nu er der løbende forsøg på at reducere antal kørende servere • Der er altid styr på konfiguration. – Der kan ikke deployes uden • Continuous integration fungerer.

Forbrug og priser • 9 dages periode ~ 17 instanser i gennemsnit • 1 måned – 1 instans ~ 78$ – Samt det løse

Næste projekt – lessons learned • Overvågning fra anden sky – Fx. Google • DVCS frem for VCS – Mercurial frem for Subversion • Pull frem for Push under deploy • Endnu mere dynamik – Python frem for Java • Fleksibilitet frem for performance

Referencer Logistics…  Sikre track and trace på alle det Britiske forsvars forsendelser.  Udvikler interface system til kommunikation mellem PostDanmark’s systemer – for alle pakker sendt med PostDanmark.  Sikre at de I Charles De Gaul fragt terminal kan udføre statistik på hele deres operation – så der kan optimeres på processerne.  Håndtere den interne styring af kufferter mellem flyene I Lufthavnen I Sydney.

Kontakt info René Nejsum Tlf Logistics A/S Gasværksvej 26B 9000 Aalborg