A scalable server environment for your applications

A scalable server environment for your applications

• 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.
  Why Now? • Nolarge upfront investments • Need to do more with the same or less resources • Maturity of virtualization technologies y g • Faster CPUs, memory, disks
• 3.
  The Challenges: • Deployingon the cloud introduces new challenges: • On demand scalability • R li bilit Reliability • Data security y • Deployment, monitoring & management t
• 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.
  Slide 4 A.B.S1 animate them so they come one after the other Alit Bar Sadeh; 11-3-2008
• 6.
  The Reality: • “Everyyear, 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.
  Headaches! “
• 8.
  Traditional Architectures Simply Dont Fit Anymore Don’t
• 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.
  There s There's amissing link
• 11.
  To take fulladvantage of the cloud, your application’s architecture needs to hit t d t change
• 12.
  It needs tobe 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.
  It needs tobe 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.
  It needs tobe 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.
  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.
  GigaSpaces XAP: • Linearlyscalable 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.
  Can Your ApplicationTake the Heat? How can your application y pp handle the load ??? Your Server
• 18.
  Can Your ApplicationTake the Heat? GigaSpaces XAP will manage, monitor and scale your application on the fly on the cloud The Cloud
• 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.
  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.
  Remoting on theCloud • 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.
  Messaging on theCloud • 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.
  IMDG over theCloud • 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.
  Typical use-cases andimplementations • 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.
  Typical use-cases andimplementations • 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.
  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