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?
• 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. The Challenges:
• Deploying on 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:
• “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
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
11. To take full advantage of
the cloud,
your application’s
architecture needs to
hit t d t
change
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. 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. 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. 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:
• 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. Can Your Application Take the Heat?
How can your application
y pp
handle the load ???
Your Server
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. 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 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. 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. 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. 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. 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. 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
