Fra classic til cloud Cloud based build deployment

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: Trade. Shift – 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 EC 2 Google App. Engine Microsoft AZURE Salesforce Force. com Facebook Applications

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

Cloud – et ny paradigme • Internet hastighed og båndbredde til alle • Wi. Fi 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 Cloud Som vi gjorde for 10 år siden 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 • Fed. Ex, Aldo, DHL, La. Poste, Sydney Airport, … – Logistik styrings opgaver og integration

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

Teknologier Udviklings paradigme Classic Cloud Vandfald Agil Programmerings sprog Statisk (Java, C#, C++) Dynamisk (Python, Ruby, Scala) SCM VCS (CVS, SVN) DVCS (Mercurial, git) Repository Intern server Bitbucket, github, code. google. com, codeplex Hosting Interne servere Amazon, Google, AZURE, Salesforce, Facebook Mail og kalender Exchange, Group. Wise, Notes Gmail, Google Apps Projekt styring MS Project Basecamp, PODIO, Timelog Issue tracking Excel, Access Trac, Jira CRM MS CRM, Super. Office Salesforce, highrise

Build, test, deploy - Classic Repository Devel • Single repository (Subversion, CVS) • Lokale udviklingsmaskiner • Testsetup er nedskaleret version af produktion • Staging ligner produktion Test Staging 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 Devel Repository • Distribueret versions kontrol • Test, Staging og Produktion er ens Produktion 1 Build Artifacts Produktion 2 Test • Pull arkitektur • Switch Staging til Produktionn

Drift, support og overvågning • Classic • Drift – Bemandet kontrol rum • Overvågning – TNG, Tivoli, Open. View • Support – Lokal løsning • Cloud • Drift – Hotline/SMS • Overvågning – Hyperspin, site 24 x 7. com, Hyperic • Support – Zendesk

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

Amazon Elastic Compute Cloud (EC 2) • AMI – Amazon Machine Image: Et image som er gemt. • S 3 – 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. • Cloud. Watch: Metrikker på en instans. • Auto Scaling: Oprettelse af nye instanser baseret på metrikker. • ELB – Elastic Load Balancing: Distribuering af trafik imellem instanser.

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 Maven Nexus

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 Create packages Create servers Hudson build Install packages Configure servers Change production servers Backup snapshot Test deployment Restore

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

Deploy • Moduler fordelt på forskellige servere

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 email setups, alle mails til test eller rigtig email udsendelse – Opsætning af database driver: e. g. postgres til test, oracle til produktion – Generelt kan der gives ekstra konfiguration med heri

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

Kontakt info René Nejsum e-mail: rne@logistics. as Tlf. 29 99 19 70 Logistics A/S Gasværksvej 26 B 9000 Aalborg