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
- Slides: 28