Java + PaaS + Drift = Sant

Foredrag holdt på JavaZone 2013. Video tilgjengelig på http://vimeo.com/album/2525252/video/74444252 . Sorry, Norwegian only.

Transcript

1. Java + PaaS + Drift = Sant Anders  Sveen   JavaZone  2013  
2. Anders
3. #!/bin/bash   Python   Ruby   Puppet   Splunk>   Fabric   OpenShiD   KVM  
4. Cloud er fett!
5. Skalerbare, robuste applikasjoner The  way  it  always  should  be…  
6. Automatisert og effektiv utrulling The  way  it  always  should  be…  
7. Det er billigere per maskin Ikke  velg  cloud  fordi…  
8. Det gir økt fleksiblitet og forutsigbarhet Velg  cloud  fordi…  
9. Cloud?
10. Cloud? •  AutomaOsert!   •  Enkelt  og  kjapt  å  endre  resursser   •  “Ubegrenset”  med  resursser   •  Standard  kontrakter   •  Standard  oppseV  
11. All the little clouds •  SaaS   •  PaaS   •  IaaS   •  MaaS  
12. In house PaaS For  oss  i  dag…  
13. Why? In  house  PaaS…  
14. PaaS
15. Distribuert arkitektur For  oss…  
16. PaaS gir stabilitet og frihet til alle
17. En lang vei å gå
18. Ansvar! PaaS  kan  være  organisasjonsutvikling…  
19. At first there were standards…
20. Java 2 Enterprise Edition
21. Java 2 Enterprise Edition API   Standard   Roller   •  Tar  kontroll  over   classpath   •  Store  produkter   •  For  lite  automaOsering   •  Tregt  
22. Java 2 Enterprise Edition •  Pakker:  war,  ear   •  Cluster:  Session  fail  over,  deploy   •  Datasource   •  Kø   •  Transaksjoner  
23. Application Deployer and Administrator The  applicaOon  deployer  and  administrator  is  the  company  or  person  who  configures  and  deploys  applicaOon   clients,  web  applicaOons,  Enterprise  JavaBeans  components,  and  Java  EE  applicaOons,  administers  the  compuOng   and  networking  infrastructure  where  Java  EE  components  and  applicaOons  run,  and  oversees  the  runOme   environment.  DuOes  include  se`ng  transacOon  controls  and  security  aVributes  and  specifying  connecOons  to   databases.     During  configuraOon,  the  deployer  follows  instrucOons  supplied  by  the  applicaOon  component  provider  to  resolve   external  dependencies,  specify  security  se`ngs,  and  assign  transacOon  aVributes.  During  installaOon,  the  deployer   moves  the  applicaOon  components  to  the  server  and  generates  the  container-­‐specific  classes  and  interfaces.     A  deployer  or  system  administrator  performs  the  following  tasks  to  install  and  configure  a  Java  EE  applicaOon  or   components:   •  Configures  the  Java  EE  applicaOon  or  components  for  the  operaOonal  environment   •  Verifies  that  the  contents  of  the  EAR,  JAR,  and/or  WAR  files  are  well  formed  and  comply  with  the  Java  EE   specificaOon   •  Deploys  (installs)  the  Java  EE  applicaOon  or  components  into  the  Java  EE  server   hVp://docs.oracle.com/javaee/6/tutorial/doc/bnaca.html  
24. Scriptspråk og hosting Meanwhile…  
25. CGI, PHP, Python •  Upload   •  Request   •  StøVe  “over  alt”  
26. Ruby on Rails The  new  kid  on  the  block  
27. But works Not  enterpricey…  
28. So we need something proper But,  but,  but,  we’re  enterprise…  
29. Java EE 6/7/8/9… The  story  goes  on…  
30. PaaS i dag Midt  i  mellom…  
31. PaaS
32. Mosso Unlike  compeOtors  such  as  Joyent  or  Amazon,  Mosso's  system   does  not  offer  customers  root  level  access  to  their  servers.   Instead,  servers  are  preconfigured  with  a  range  of  soDware   opOons  and  are  fully  managed  similar  to  a  shared  hosOng   environment.  Keeping  their  hosOng  plamorm  standardized  is   what  allows  them  to  easily  monitor  and  scale  the  service  as   needed.  For  example,  last  week  Mosso  experienced  a   significant  spike  in  load  on  its  PHP  cluster  and  added  10  servers   without  customers  noOcing,  company  execuOves  told  me.   hVp://readwrite.com/2008/02/18/mosso_cloud_compuOng  
33. PaaS vs. IaaS? •  Mindre  frihet   •  Mer  automaOkk   •  Mindre  å  tenke  på   •  Dynamikk   •  Kombinere?  
34. PaaS og IaaS PaaS   IaaS   Hardware  
35. PaaS og IaaS PaaS   IaaS   Hardware  
36. PaaS og IaaS PaaS   Hardware  
37. Nivåer av PaaS SaaS   PaaS   IaaS  
38. Google App Engine •  Deploy  WAR  i  en  servlet  container   •  Belastes  for  bruk   •  Bruk  bestemte  API  for  bestemte  oppgaver   –  Persistens   –  Cache   –  Disk   •  Veldig  begrenset  modell   •  Får  smertefri  skalering  og  redundans  
39. Heroku •  Maven   –  Kompilérer   –  Kjører  tester   –  Pakker  sammen   •  Java  (m.  bash)   –  Start   –  Stop   •  LyV  på  port   •  Custom  build  packs  
40. Heroku •  Bash…   •  Wget?   •  Unzip?   •  Start  java-­‐uOl   •  Start  python?   •  Start  java   •  Custom  buildpacks…  
41. Java •  Maven  Appassembler   •  Maven  Assembly  plugin   •  Pakk  med  alle  avhengigheter   •  Ta  kontroll  over  classpath   •  LiV  bash  
42. In house PaaS
43. PaaS komponenter App   Stack   Tjeneste   Deployment   Konfigurasjon  
44. MinApp v1.7.5 •  Stack:  Glassfish  3.2.1   •  Tjenester   –  Oracle  11.0.2.4.18   –  LDAP  1.6.2   •  Deployment   –  512MB  minne   –  4  instanser,  max  20   –  Load  Balancer,  sOcky  session   •  Konfigurasjon   –  S3Bucket:  87d98sa7dasdsa987   –  AWS_Password:  hdsajhasd7921   –  AWS_User:  87291d2  
45. Stack Java 1.7 Java 1.6 Glassfish 3.2.1 (Java 1.7) Tjenester Oracle 11 MongoDB 2.4 MongoDB 2.2
46. Stack •  RunOme   •  Byggeverktøy   •  Porter   •  Defaults  deployment?   •  Biblioteker?   •  TilleggssoDware?   •  Tjenester?  
47. Deployment •  Minne   •  CPU   •  Disk   •  Instanser   •  ResponsOd  
48. Tjeneste •  Provisjonering   •  ConnecOon  detaljer   •  Kvoter   •  Backup   •  Drivere?  
49. Applikasjon •  Eier   •  Re`gheter   •  Status   •  Deploy  
50. Instans •  Status   •  Overvåkning   •  Overføring   •  Plassering  
51. Applikasjonen •  Beskriv  hva  du  trenger   •  Informasjon  injectes  runOme   •  Deploy  for  forskjellige  miljøer  fra  samme  kilde    
52. PaaS Plattform PaaS   Node  1   Node  2   Node  3   Node  4   A#1   A#1   A#2   A#2   A#3   A#1   A#3   A#2   A#5   A#4   A#1   A#3   A#5   A#4   A#2  
53. DevOps We  work  together…  
54. Drift •  Leverer  versjoner  av  stacks   •  Leverer  versjoner  av  tjenester   •  Monitorerer   •  Utvider   •  Varsler  
55. Utvikling •  Lager  applikasjoner   •  Provisjonerer   •  Velger  stack   •  Velger  tjenester   •  Deployer   •  Skalerer   •  Monitorerer  
56. Drift •  Stabiliserer  driDen  av  playormen   •  Tydelig  skille   •  Tilbyr  support  og  hjelp  med  utvikling  på   playormen   •  Vet  lite  om  hver  enkelt  applikasjon   •  Utvikler  nye  tjenester  og  stacks  
57. Utvikling •  Self  service   •  Bestem  selv  hvilke  stacks  og  tjenester  du  skal  ha   •  Deploy  når  du  vil   •  Det  forandrer  hva  du  gjør,  og  det  endrer  hvor   oDe  du  gjør  det  J  
58. Jump! •  DriD   –  Utvikling  av  stabiliserte  tjenester   –  Bredere  spekter  av  tjenester   –  Vet  lite  om  applikasjonene   •  Utvikling   –  Robusthet  og  ytelse   –  Ansvar  for  applikasjonene   –  Vaktordninger  
59. Jump! •  SluV  å  lage  manuelle  ruOner   •  SluV  å  gjøre  endringer  uten  release   •  Alt  må  automaOseres   •  Alt  må  versjonskontrolleres   •  Èn  kommando  deploy   •  Noen  få  minuVer  på  deploy  
60. In house PaaS •  Tydelig  grensesniV  mellom  utvikling  og  driD   •  Tydelige  konsepter  for  utvidelse   –  Stack   –  Tjeneste   •  Dynamikk   –  Monitorering   –  Feilhåndtering   –  Ressursallokering   •  Sikkerhet  og  mulO-­‐tenancy   •  Harmonisering  av  miljø   •  Self  service  og  fleksibilitet  
61. In house PaaS? •  AutomaOsering  av  deploy  og  applikasjoner   •  Ansvarsforhold   •  Robusthet  og  feiltoleranse   •  Modenhet   •  Kompleksitet   –  I  feilsituasjoner   –  Ved  utvikling  av  nye  applikasjoner  
62. In house PaaS Dagens  Olstand  
63. The contenders •  “Heroku  style”   •  Open  Source   •  Commercial  support   •  Det  finnes  mye  annet  også…  J  
64. CloudFoundry •  VMWare/Pivotal  Labs   •  IBM  er  med   •  V2  ute  nå   •  Enkle  konsepter   •  “StøVe”  for  Heroku  buildpacks   •  AkOv  community   •  Modent  minus   •  For  mye  kompleksitet?  (BOSH)  
65. OpenShift •  RedHat   •  V1.2  ute  nå   •  “Enkel”  implementasjon  med  få  knytninger  Ol   underliggende  lag   •  Kommandolinje-­‐verktøy   •  Puppet  oppseV   •  Modent  minus   •  Noe  svakere  community  
66. Flynn •  Open  Source  Heroku   •  Basert  på  Docker   •  MVP  i  Oktober   •  “Kickstarter”  80.000  USD   •  2  fyrer  med  lang  erfaring   •  “We’ll  do  it  anyway,  it’ll  just  take  longer”  
67. Roll your own? •  I  pity  the  fool…   •  Hovedumordringer   –  Overvåkning  og  monitorering   –  Isolasjon  mellom  Stacks   –  Rammeverk  for  Tjenester   –  Sikkerhet   –  Ressurs  isolasjon   •  Se  på  Heroku  sine  buildpacks   •  Se  på  Docker   –  Isolasjon   –  Sikkerhet  
68. Here be dragons •  We’re  not  there  yet…   •  Playorm  for  videre  utvikling,  finnes  ingen  enkelt   playorm  som  dekker  alt   •  Robusthet,  skalerbarhet  og  ytelse  kommer  først   og  fremst  an  på  applikasjonen   •  Må  det  virkelig  være  så  komplekst?  
69. More… •  The  twelve-­‐factor  app  –  hVp://12factor.net/   •  Docker  –  hVp://docker.io   •  OpenShiD  –  hVps://openshiD.redhat.com/   •  CloudFoundry  –  hVp://cloudfoundry.com/   •  Flynn  –  hVps://flynn.io/   •  Juju  –  hVp://juju.ubuntu.com    
70. Spørsmål?
71. @anderssv   hVp://github.com/anderssv   hVp://blog.f12.no   anders.sveen@miles.no