Fra classic til cloud - Cloud based build & deployment

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

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

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

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

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

6. 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

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

8. 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

9. 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

10. Teknologier

11. Build, test, deploy - Classic Repository Devel Staging Produktion Test • 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

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

13. 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

14. 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 Aug Launch USA • Ekstrem skalerbar forretning • 0 til 1.000.000 brugere på et kvartal

15. 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.

16. 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

17. Build arkitektur Mercurial Hudson Maven Nexus

18. Build, Test and Deploy

19. 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

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

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

22. Deploy Moduler fordelt på forskellige servere

23. 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

24. 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

25. 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.

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

27. 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

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