Cloud patterns

1,037 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,037
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
25
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Cloud patterns

  1. 1. PatternsNicolas De Loof - cloudbees
  2. 2. This talk is a mashup • « PaaS design » Michael Neale, CloudBees • « Cloud Best practices » Eric Bottard, VMWare • my own …
  3. 3. <me>
  4. 4. Support engineer
  5. 5. Maven & Jenkins commiter
  6. 6. BreizhJUG leader
  7. 7. </me>
  8. 8. PaaS IaaS End Users Application Developers Infrastructure Architects SaaS PaaS IaaS Few world-scale providers A Dozen platforms Thousands ApplicationsSaaS
  9. 9. Cloud On premiseseasy May be difficult for legacy appsrefactor
  10. 10. Green field applications • Can select modern solutions most (not all) frameworks are well designed for Cloud • Started on cloud, discovers and adapts to constraints  mix-it.fr  cfp.breizhcamp.org
  11. 11. « Classic » applications • Not such modern solutions common frameworks may not fit cloud constraints • Started on premises, single server hit cloud constraints
  12. 12. The Devoxx apps • Call for Paper and Registration • High traffic two months a year • Self hosted (parleys.com infra) moved to CloudBees PaaS • Wicket, Spring, MySQL No hype, like 99% java applications
  13. 13. ScaleSc
  14. 14. Scale up • Still possible, but will hit a limit • Not optimal M1 small Then ?M1 large M3 double extra large
  15. 15. M1 extra large • 64 bits • 15 Gb memory • 4 Vcore, 2 cpu unit (~2.5Gh) • 1.6 Tb HD aka « my personnal laptop »
  16. 16. Scale out Adapt resources to actual load Design for clustering Pay only for actual use
  17. 17. What a PaaS actualy does … M1 large • slice a server into cells • Multi-tenant app hosting vitrualisation
  18. 18. Multi-tenancy • Hardware level (IaaS) • OS level (hypervisor) • OS virtualization (cgroups, LXC) • Middleware ? Java 9 to be multi-tenant ?
  19. 19. State Less … if you can be
  20. 20. RESTFul, Stateless • Linear horizontal scaling But … • Application - User « conversation » has a state • Stateless apps mostly use caches then cache needs to be distributed
  21. 21. Stateless, really ? • Beware your frameworks ! Grails security plugin Spring-security HttpSession
  22. 22. Does Stateless really exist ? • Client side state with browser cookies  higher network traffic, security • Use http session (servlet frameworks)  memcache session replication  sticky session • Use a central service (DB)  SPoF, DB scalability
  23. 23. Lock-inPrefer portable API beware
  24. 24. Standards • Use standard, portable APIs (aka Java EE, the good parts) • Set runtime configuration via env variables / system properties • at least use some abstraction to insulate vendor-specific code
  25. 25. Some Standards • Java EE • Java Servlet • JVM • LAMP • Node.js • RVM • ..
  26. 26. File System Beware
  27. 27. Cloud uses Schrödinger FS Looks like it’s alive, but it’s not
  28. 28. PaaS == pool of servers Your host at this time Your host after (re)deployment
  29. 29. FileSystem is ephemeral (and not distributed) Use store engine (S3, DB Blob, …) Use fileSystem wrappers(s3fs) Use ephemeral as a cache
  30. 30. … aren’t Singletons
  31. 31. Sample: Quartz Job Scheduler Job will be triggered on all nodes !  Use Persistent (JDBC) Job Store  Use dedicated cron service
  32. 32. matters Latency
  33. 33. Measure • Chrome DEV Tools • Google Pagespeed • YSlow
  34. 34. Improve • Use HTTP cache headers • Use unique path per deployment hash, or just ?version= • Use a CDN
  35. 35. Migrate to Cloud
  36. 36. Yes!
  37. 37. (the right way)
  38. 38. Small is beautifull • small, specialized, elastic services • Communicate with REST on HTTP/MQ Users frontend Backend indexer
  39. 39. Consume Services
  40. 40. *aaS ecosystem • *aaS is about service, not software • Integrate services, don’t try to setup your own infrastructure • AWS, the place to be for *aaS
  41. 41. Private cloud is non-sense • Do you produce your own electricity ? • Security is about humans, not firewals
  42. 42. Designfor Failure
  43. 43. It May Will fail
  44. 44. Beware resource • Don’t hang the app when resource fails • Run asynch • Use MQ
  45. 45. Cloudis anyway
  46. 46. Some metrics • In 2012, CloudBees suffered 2 major outages 20 then 10 minutes  99,99% (What’s your actual availability rate ?) Cloud outages are visible
  47. 47. Disaster recovery • All deployed artifact  S3 • DB on EBS, then daily  S3 + your own backup strategy http://wiki.cloudbees.com/bin/view/Documentation/BackupPolicies
  48. 48. Need more ? • Multi-zone High-Availability • Mutli-region redundency  data sync to handle network latency  Short TTL DNS No « turn key » solution
  49. 49. for Cloud Ops
  50. 50. Infra is managed ... not app • Need to instrument and monitor
  51. 51. Ops for Cloud apps One team, One goal, One platform
  52. 52. Cloud is the best place to embrace DevOps Traditional Cloud Environment DEV / INT / PROD identical Delivery Mostly manual full automation API based DEV Process Fire and forget Continuous delivery Team Dev vs Ops vs QA DevOps
  53. 53. ContinuousIntegration deployment delivery
  54. 54. Continuous … • Git push • Build • Test • Git push • Build • Test • Deploy • Production • Git push • Build • Test • Ready for production • Production Integration Deployment Delivery
  55. 55. Resourcesas manage code
  56. 56. Manage Database you can connect tools to your DB
  57. 57. But how to … • Replicate environment • Manage DB upgrades • Tag versions (and DB schema) • ..
  58. 58. All in SCM • Application configuration • Runtime properties • Resources binding • Database scripts… App deployment is 100% reproductible
  59. 59. Use agile DB tools
  60. 60. concurrent 0 downtime deployment
  61. 61. 0 downtime http://demo.nicolas.cloudbees.net router
  62. 62. Beware resources migration App Vn running App Vn+1 starting DB schema Vn DB schema Vn+1
  63. 63. • Vn+1 schema to be Vn compatible • Vn+2 can do some cleanup i.e. « @deprecated » for DB Or … temporary deploy a « maintenance » page
  64. 64. DeploymentIs not an anymore event
  65. 65. Green / Blue http://martinfowler.com/bliki/BlueGreenDeployment.html
  66. 66. A/B testing
  67. 67. Canary testing
  68. 68. Pretotyping
  69. 69. You thank

×