A scalable server environment for your applications

675 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
675
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A scalable server environment for your applications

  1. 1. Building Applications for the Cloud - Challenges C a e ges & Best Practices est act ces Jeroen Remmerswaal Tricode Professional Services GigaSpaces Terrritory Partner BeNeLux DDHS 2010
  2. 2. Why Now? • No large upfront investments • Need to do more with the same or less resources • Maturity of virtualization technologies y g • Faster CPUs, memory, disks
  3. 3. The Challenges: • Deploying on the cloud introduces new challenges: • On demand scalability • R li bilit Reliability • Data security y • Deployment, monitoring & management t
  4. 4. Seasonal Peaks 1,300,000,000 A.B.S1 1,200,000,000 1,100,000,000 The Reality: 1,000,000,000 900,000,000 800,000,000 “A brokerage can lose up to $4M per 1ms 700,000,000 600,000,000 500,000,000 500 000 000 of latency” - The Tabb Group 400,000,000 300,000,000 “An additional 500ms delay resulted in y 200,000,000 100,000,000 0 J‐04 M‐04 M‐04 J‐04 S‐04 N‐04 J‐05 M‐05 M‐05 J‐05 S‐05 N‐05 J‐06 M‐06 M‐06 J‐06 S‐06 N‐06 J‐07 M‐07 M‐07 J‐07 S‐07 -20% traffic” - Google “An additional 100ms in latency resulted An in -1% sales” – Amazon
  5. 5. Slide 4 A.B.S1 animate them so they come one after the other Alit Bar Sadeh; 11-3-2008
  6. 6. The Reality: • “Every year, we take the busiest minute of the busiest hour of the busiest day and we built our systems to handle that y load and we went above and beyond that.” th t ” – Scott Gulbransen, Intuit Spokesman , p
  7. 7. Headaches! “
  8. 8. Traditional Architectures Simply Don t Fit Anymore Don’t
  9. 9. Traditional Architectures – See the Problem? Business tier • Hard to Web Tier install: • Bound to static resources (IPs, disk drives, etc.) Load Balancer • Separate clustering model for each tier • Hard to maintain Back-up p • Insecure Back-up Back-up • Non-scalable Messaging
  10. 10. There s There's a missing link
  11. 11. To take full advantage of the cloud, your application’s architecture needs to hit t d t change
  12. 12. It needs to be elastic: • Grow (and shrink) as needed, based on an SLA (such as work load) • But with no downtime, self-heal on failure, failure without data and transaction data- transaction- loss • And with a corresponding ((predictable) ) p performance improvement p
  13. 13. It needs to be memory-based: • No permanent off-premise storage • Not bound to static resources N tb d t t ti • Bonus: extreme performance p • Reliability achieved through memory replication li ti • Optionally o oad data to on/off site Opt o a y offload o /o s te persistent store
  14. 14. It needs to be easy to operate: y p • Deploying & monitoring on the cloud as simple and the same as doing it on- premises • Process should be repeatable • Application should be modular – update on the fly with no downtime
  15. 15. Web Business Processing Processing Units Units Load Balancer The l i Th solution: Users Application L A li ti Level Virtualization l Vi t li ti Primaries Backups
  16. 16. GigaSpaces XAP: • Linearly scalable and elastic via virtualization of the processing, messaging and data tiers f th i i d d t ti • Secure and ultra fast via in-memory in- infrastructure • Comprehensive cloud support for the simplest provisioning, deployment & monitoring • N -i t Non- Non intrusive: i • Adopts existing programming models • Cross platform & language
  17. 17. Can Your Application Take the Heat? How can your application y pp handle the load ??? Your Server
  18. 18. Can Your Application Take the Heat? GigaSpaces XAP will manage, monitor and scale your application on the fly on the cloud The Cloud
  19. 19. Some Practical Steps Value IMDG as Messaging System of Record Web Tier Remoting Effort On-demand provisioning Parallel Processing vs. Partitioned virtualized Partitioned virtualized Architecture vs. static, peak-based client-server servers vs. central server servers vs. central server 7 machines 90 machines 6x machines 6x machines Savings Examples (10 peak – 3 avg) (100 peak, 10 avg) (SBA/TBA benchmark) (SBA/TBA benchmark)  Self-healing  Automatic failover  Fast & Consistent  Basic caching  Map/Reduce  Commodity HW Low response time. Additional Benefits  Auto deployment  Async invocation latency (in-memory)  Commodity db vs. high-  Location transparency end
  20. 20. Auto-Scale the Web-Tier • If you have a standard J2EE WAR-file, deploy as-is into GigaSpaces • Fail-over / Self-healing comes out of the box • Add 'Auto-Scaling' for Scale-Up and Scale-Down • Add Session-Clustering
  21. 21. Remoting on the Cloud • Parallelize work over the cloud – Move from J2EE Remoting to GigaSpaces remoting – Giving you fault-tolerant, scalable, distributed remoting – Parallelize instead of serialize – Map/Reduce / Master/Worker / JSR223
  22. 22. Messaging on the Cloud • Use the IMDG as the fault-tolerant messaging bus – In-memory reliability – Can be as simple as re-wiring your JMS provider to use GigaSpaces – Use GigaSpaces Event Containers instead of MDB's • Benchmarks on the same hardware show 6+ times more throughput
  23. 23. IMDG over the Cloud • Fulfill your business transactions in memory – Have (most of) the data available in memory – Use the database because you want to, not because you have to – Use the database asynchronously but reliable • Benchmarks on the same hardware show 6-100 times more throughput 6 100
  24. 24. Typical use-cases and implementations • Handling peak-loads (by cloud-bursting) • Pay-per use • Always-On / High A il bilit Al O Hi h Availability • High Performance / High Throughput • Cost-reduction / Better utilization of hardware • Large scale testing • Disaster Recovery
  25. 25. Typical use-cases and implementations • Telco – Deploying discrete stand alone services in the Cloud – D l i carrier grade VOIP service t th Cl d Deploying i d i to the Cloud • Global Media – Using the Cloud to p g process events for innovative new TV p g programme – Cloud makes concept cost effective • Financial Services – U i th Cl d f a t di exchange Using the Cloud for trading h – Cloud lowers barrier to entry and makes proposition possible • Online Gaming g – Using the Cloud for testing and scaling – Able to test large scale user support early / easy on cloud, hard otherwise
  26. 26. GigaSpaces Home Page: g p g http://www.gigaspaces.com http://www.gigaspaces.nl http://twitter.com/gigaspaces Tricode Home Page: http://www.tricode.nl http://twitter.com/tricode

×