Ultra-scalable Architectures for Telecommunications and Web 2.0 Services

Mauricio ArangoBernd Kaponig

Sun Microsystems

October 27, 2009

2

Web 2.0 Impact on Communications Applications

• Information-sharing, social media services such as Facebook, Twitter – experiencing fast & enormous growth

• Growth handled via horizontal scaling vs. vertical scaling – no forklift upgrades – agile and lower-cost

• Involves handling parallelism challenge in telecommunications service software

3

Impact of New Communications Applications - cont.

• Telecom service providers launching Web 2.0-like services– Nokia Ovi– Vodafone 360

• Expansion of services based on telecom network advantages - event-driven– Location-based– M2M– Metered realtime billing– SLA management

4

Parallel Application Architecture Model (server side)

● Parallelize – breakup into pieces– Application– Data

● Requires middleware– Coordination

(communication)– Data management

5

Price of Horizontal Scaling • Requires software that can be distributed and has high degree

of parallelism - – Applications broken into components– Components run in parallel in a distributed processing infrastructure

Monolithic application Parallel application

6

Good News – Event-driven apps have high parallelism

• Web and telecommunications applications are event-driven– User-generated events– Monitoring and sensing

events– Network events

• Data stream-driven• Event-based coordination

pattern

7

Other Parallel Application Design Patterns

• Master-worker

• Pipeline Phase 1Stage 1 Stage 2 Stage N

• HybridPhase 1Stage 1 Stage 2 Stage N

Phase 1Stage 1 Stage 2 Stage N

Phase 1Stage 1 Stage 2 Stage N

Master

Worker N

Worker 2

Worker 1

Master

8

Communications Middleware• Coordination – interaction required when an

application is split into multiple components

Direct communication Indirect communication

• Request-response, Notification• Tightly coupled – every node needs to

know about other nodes' address and functions – non-scalable complexity for developer

• Poor at handling node failures

• A node only needs to know about the intermediate entity

• Space decoupling• Time decoupling• Three mechanisms

– Tuple Space– Message Queue– Publish/Subscribe

9

Tuple Space• Invented by David Gelernter in early 80s• Simple functionality – via four operations

– out()- deposits tuple– in()- removes matching tuple– read() - reads matching tuple– notify() - registers for notification

on matching tuple

• Space & time decoupling across components

• Shared associative object (tuple) store

• Inherent load-balancing• Event processing framework• Natural fit with business

processes

Component 1

out( )

Component 2

in( ) out( )

Tuple Space

Component 4

Component 3

read( )read( )

10

Message Queue• Intermediate entity: set of queues• Communicating components only need to know queue names• Basic functions:

– sendMsg(queueName, message)– getMsg(queueName)

• Can be mapped as a subset of Tuple Space using:– out(queueName, message) for sendMsg– in(queueName) for getMsg

Message queue 1

Message queue 2

Component 1

sendMsg(queue-2, )

sendMsg(queue-1, )Component 2

Component 3

getMsg(queue-1)

getMsg(queue-2)

11

Publish/Subscribe• Intermediate entity: broker• Basic functions:

– subscribe(template)– publish(message)

• Can be mapped as a subset of Tuple Space using:– out(tuple) for publish()– notify(template) for subscribe()

12

Surge of Indirect Messaging Middleware

● Blitz (JavaSpaces)

● Gigaspaces

● Rinda

● Gruple

● Semispace

● Open source JMS

– Sun Open Message Queue – Apache ActiveMQ

● Amazon Simple Message Queue Service

● Rabbit MQ – based AMQP standard

● Gearman

● XMPP Pub/Sub

● Pubsubhubbub

13

Data Management Middleware• Scaling via parallelization and

caching• Parallelization

– Replication – read-most data– Partitioning/sharding – write &

read• Distributed caching

– Shares scaling techniques with communications middleware

– Use of Distributed Hash Tables (DHT)

14

Use Case – Twitter-like, many-to-many Messaging System

• Process new message – out(message_list_update, follower,

message_publisher, message_content)

• Update message list – in(message_list_update, ?r, ?t) – Put(new message)

• Retrieve message list – get(messages)

15

Conclusions• Horizontal scalability requires parallel application

architectures from day one• Parallelization involves simple communications

middleware models & simple APIs– Tuple Space simplest & superset model

• Distributed caching – scalable foundation for both communications and data management middleware

• Parallel application architectures key in telecommunications evolution

16

Additional information

● Paper (includes references): http://blogs.sun.com/arango/resource/ICIN-09-Ultra-Scalable-Architectures.pdf

● Blog: http://blogs.sun.com/arango/