Paas Design Patterns

2,547 views

Published on

Patterns I have observed in the wild in use by real users in a paas cloud (CloudBees) - that seem to work well for them.

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

No Downloads
Views
Total views
2,547
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
76
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Paas Design Patterns

    1. 1. PaaS design Patterns Michael Neale @michaelneale www.cloudbees.com
    2. 2. Agenda
    3. 3. Same old practices PortabilityOld and new: servers, networks, environments All Environments Are The Same Use Cloud APIs in builds Continuous Deployment SOA - same old architecture Service as unit of reuse Prefer Statelessness (easy to say) Fine grained scaling REST/api first design Don’t Roll your Own Services Skunkworks
    4. 4. Nothing New?Patterns are guides, usefulness varies with application Patterns here are mostly “good design” principles ..and kind of ‘classic’
    5. 5. Cloud Portability Follow the right patterns Avoid lock in to any cloud !In fact - easier to go cloud -> on premises than other way around Data is “sticky” so be careful with DBs
    6. 6. Classical enterprise tiers All your job Web Firewalls App App App Dev servers DB Repos and build Other services
    7. 7. PaaS cloud “tiers” Routing service Your job ! Repo App service App service CI serviceData services Services
    8. 8. Someone else’s problem All services are someone else’s problem Note transition from server -> service Similar, but nuanced
    9. 9. Classic enterprise servers Large, expensive Vertically scalable Intrinsic redundancy Capex not Opex outages rare**, but long Cost of provisioning: high in time and money ** Really?
    10. 10. Common cloud servers Numerous, cheap Horizontally scalable ** Outages more common, but short PaaS job is to hide all this ! Not your problem !Cost of provisioning: low in time and money ** Actually a lot of choice nowadays
    11. 11. Deployment Environments Classic: Dev, Test, UAT, Staging, Production Often anaemic hardware for non prod Work to move between Hardware/software not consistent
    12. 12. Dev and Prod parity Homogenous environments Dev and prod “identical” differ in name only No “server crunch” - so why compromise No “surprises” when promoting Only pay for what you use:hi-fidelity environments - start/stop as needed
    13. 13. Dev and Prod parityDevelopment and production environments differ in name only
    14. 14. Data cloningFor “modest” volumes of dataClone into each environment:
    15. 15. One App Many Deploys Parametrise via Environment varsWhen build “promoted” - same bits as tested !! “common sense” ??“Config varies substantially across deploys, code does not” ** ** (http://www.12factor.net/)
    16. 16. One App Many DeploysYou can have multiple concurrent versions as many as you need Differ in URL Slowly transition
    17. 17. NetworkingClassic: layered, partitioned, ops controlled firewalls Cloud: flatter networks, programmatic firewalls Firewalls also happen at server level A PaaS manages this for you
    18. 18. Hybrid Networking Need: cloud apps, but some “behind firewall data”Solutions: - replicate data - VPN - firewall rules on private network (fixed IPs) thatexpose select services
    19. 19. Use A CDN CDN=Content Delivery Network Fight latencyMove static/cacheable content to CDN edge nodes Examples: Amazon Cloudfront, Cachefly
    20. 20. Shift to cloud -> shift to remote servers (sometimes) Some users latency sensitive Use a CDN with geo-aware DNS (all of them) Bulk of “data” delivered can be cached in some cases
    21. 21. CDN == a better cache Use hash based asset paths (framework + build tools help) No expiry caching ==Maximum chance of cache hit and low latencyMassively improve experience of modern apps
    22. 22. Latency Friendly GUIsWeb interfaces: lightweight js + background loading (eg backbone.js style) Mobile apps: naturally latency friendly Classic request/response web apps are latency sensitive. Some latency inevitable, pick frameworks wisely
    23. 23. Use Cloud automation APIs All types of clouds have apis Make use of them from builds: Deploy time (easy roll back !) Development and testing (multiple environments) Cost saving: only run when needed STOP APP or HIBERNATE Hibernated apps will wake when testers need it (all free apps hibernate)
    24. 24. Deploy early and often When it is easy to roll back, it is easy to deploy Deliver smaller changes, more often (data breaking changes, you can take your time !)Risk in deployment is proportional to the time since last deployment Risk = X * (Now - LastDeployment)
    25. 25. Continuous Deployment CI == continuous integration Continuous deployment takes the next step Tests + Automation == Lower risk Deploy to “an environment” continuously (may not be production !)Need a “build/test/dev” automation workflow server (eg Jenkins)
    26. 26. Continuous DeploymentChange Deployment rules source build runtime If only someone had built this !
    27. 27. Build Workflow > 400 plugins
    28. 28. Dog Fooding
    29. 29. SOA Same Old Architecture?Got a bad name due to WS-* and Enterprise Vendors Is a very useful approach In use by all modern web companies Just not WS-* ! Build apps as composeable, re-useable services On paas cloud: http + rest
    30. 30. SOA Build multi tiered applications Separate out tiers Separate out background vs online GUI vs backoffice functionality UI appsServices WebApp iOS API Accounts Payment Jobs All are just apps on a PaaS
    31. 31. SOA Services are still just apps ! They are consumed by other appsDifferent apps/services can have different release cadences Use CI automation to help keep things in syncHTTP interfaces for your own use (health, business stats) - not just user facing
    32. 32. Prefer Stateless Easy to say - hard to do Stateless apps delegate state to:Databases, cookies, cache servers, external services Places state can “hide”: User sessions, caches, frameworks** ** example: grails + spring security
    33. 33. Prefer Stateless Session data:Use session service (CloudBees service) - cluster friendly (and transparent) cookies (modulo security) database
    34. 34. Maybe Stateful Stateful is actually ok: A cache that can be replaced eg Lift Web Framework not required to be replicatedIn this case - use “sticky sessions” - session affinity to a server (just a flag on cloudbees) Scale up vs out State is short lived
    35. 35. Prefer Stateless Why stateless? Allows fine grained scaling Allows scaling out (as well as up +1 dimension) High Availability Zero downtime deploys Client side UI state (eg mobile, HTML5) makes this easier than everWhy does a server care what tab a user has selected?
    36. 36. Prefer Stateless Inevitable:trend towards functional programming (immutability) tracking state and side effects will make all this easier (scala, clojure !)
    37. 37. Use fine grained scaling Smaller state-light apps Scale out quickly Autoscale(track stats, ensure SLA being met automatically) (no work for you !) Only pay for what you need
    38. 38. REST-api first design Increasingly common to build REST apis first Separate apps for Web, Mobile clients Server side becomes less GUI centric Shift in frameworks - choose wiselyServices, like databases, live on, are reused, and composed into new services
    39. 39. Use Add-ons Why host your own email serviceWhy host your own monitoring/analysis Rich ecosystem (send grid, new relic, for example)
    40. 40. Use Add-ons
    41. 41. Use Add-onsThis is the “re-use” we were “promised” many years ago Finally delivered Compose services together
    42. 42. Use Add-ons Worried about lock in?Data services are built on open source, you can always export your data and host it yourself Other services are less “latency sensitive” (eg newrelic is popular for on-prem systems too)
    43. 43. Use Natural ShardingMany apps have a “natural” way to split up data if needed either by data (eg accounts) -- or by functionality (services) As a way to scale out, split apps into multiple instances (data) Databases in to shardsCheap and easy to clone environments if needed.
    44. 44. Skunkworks “It is easier to ask forgiveness than it is to ask permission” -- Grace Hopper Cost of trying/building is cheap, so you can “just build it”Find a part of your application that could be split off into a cloud service on a paas “ask forgiveness”
    45. 45. Thank you

    ×