Drupal distributed architectures
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Drupal distributed architectures

  • 3,444 views
Uploaded on

Slides for the presentation I gave in Timisoara

Slides for the presentation I gave in Timisoara

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
3,444
On Slideshare
3,424
From Embeds
20
Number of Embeds
5

Actions

Shares
Downloads
15
Comments
0
Likes
0

Embeds 20

http://www.slideshare.net 13
http://www.linkedin.com 3
http://drupalcamp.ro 2
http://dew 1
http://coderwall.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Distributed architectures in Drupal What to do when your site is getting cramped? Drupalcamp Timisoara 2010
  • 2. Introduction Kristof Van Tomme Co-founder PRONOVIX.com Drupal, Distributed architecture
  • 3. Goals of this session
    • Highlight 2 important code trends
    • 4. Classify architecture options
    • 5. Highlight the most important technologies
    • 6. Share our battle plan for world domination
  • 7. One-off modules -> API modules
  • 8.
      Site > code on your server
  • 9. Easy to reuse Easy to connect Custom code one-purpose sites Frameworks - One-purpose modules Installation profiles Frameworks - API modules Installation profiles with features Drupal service clouds - modular sites features
  • 10.
      We are moving from websites to webservices
  • 11.
      All in one sites pro
    • reduced maintenance costs
    • 12. greater flexibility (easy to put a block from one business application on a page of another)
    • 13. no data transfer required (bandwith)
    • 14. better performance (no network latency)
  • 15. All in one sites contra
    • module overbloat (slower performance and potential integration issues)
    • 16. Permission conflicts between sections
    • 17. Over-abstracted to accommodate different use cases
    • 18. Content pollution from other sections
    • 19. Navigation might become a mess
  • 20. What to serve?
  • 23. Functionality = data mapping
    • data transformations
    • 24. data mediation
    • 25. data relationship discovery
    • 26. data masking/de-identification
    • 27. data consolidation
  • 28. Sharing options
    • Common resource
    • 29. Just in time
    • 30. Just in time + caching
    • 31. Aggregation
  • 32. Common resource architectures
  • 36. Not flexible
  • 37. Just in time
  • 39. Network latencies
  • 40. Aggregation
  • 43. Not always up to date
  • 44. Just in time + caching
    • Content staging
    • 45. Remote blocks
    • 46. Remote nodes
  • 47. Best of both worlds
  • 48. Processed data
  • 51. The internet will be a collection of Service Providers and Mashups
  • 52. Drupal is already really good at consuming services
  • 53. Drupal is already really good at consuming services
  • 54. Drupal is pretty good at serving content
  • 55. What about the missing services?
    • data transformations
    • 56. data mediation
    • 57. data relationship discovery
    • 58. data masking/de-identification
    • 59. data consolidation
  • 60. If we can get better at producing easy to consume services we can conquer the world
  • 61. http://pronovix.com/blog
  • 62. @kvantomme