OSGi Community Event 2012

1. © 2012 IBM Corporation
Using OSGi as a Cloud Platform
Jan S. Rellermeyer – IBM Austin Research Lab
24 October 2012

2. © 2012 IBM Corporation
The Cloud - Challenges
 Cloud Computing is the economies of scale
– E.g., system of engagements
 Traditional software stacks usually do not scale well
– Often designed for vertical scalability.
– If they were not designed to scale horizontally, they don’t.
 Monolithic software cannot be expected to be elastic.
2
Image: Pixomar / FreeDigitalPhotos.net

3. © 2012 IBM Corporation
The Cloud - Challenges
 Cloud Computing is outsourcing
– Computation by the hour
– Focus on the software, no longer control the platform
 Problem: Dependability
– Amazon EC2: 22 minutes of connection issues on 03/15 in
the US-EAST-1 zone due to router configuration problems
– Microsoft Azure: ½ day partial service outage on 02/29 due
to leap day bug
– Zoho: 3h45 full outage on 02/20 through a power failure at
an Equinix data center. Full recovery took another 6 hours.
 You need to design for failure?!?
– Availability is a software issue, not a platform issue
3
Image: twobee / FreeDigitalPhotos.net
http://news.ycombinator.com/item?id=3707590
http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx
http://www.zoho.com/general/blog/our-friday-outage-and-actions-we-are-taking.html

4. © 2012 IBM Corporation
The Problem
 Both vertical scalability and redundancy (design for failure) require a distributed systems
approach
 Distribution adds complexity and its own failure models.
Example: Kerberos, Distributed File Systems
 Modular systems are easier to design
– Focus on functional partitioning and composition, not
communication
 Well-designed modular systems can be turned into
distributed systems
– Let’s bring OSGi to the cloud
– Let’s see what is already in OSGi
4
Image: Danilo Rizzuti / FreeDigitalPhotos.net

5. © 2012 IBM Corporation
Modularity
 Declaratively Self-Contained
– A module is self-contained with regard to its own content and its declared dependencies
 Encapsulated
– A module exposes its content solely through well-defined interfaces
 Decomposed
– modules are created by segregating a larger problem into smaller sub-problem so
that a module ideally only deals with a single, not further separable concern and the
content of the module is highly cohesive.
 Composable
– modules are created for reuse in different applications and can be composed into
new applications. Declared dependencies and declared interfaces put constraints on
the validity of compositions. Ideally, the degree of coupling between modules is low
so that composition is facilitated and not prohibited.
 Substitutable
– two modules (or sets of modules) providing the same interfaces can be exchanged
for one another.
 Localized Behavior
– modules are designed to behave locally, i.e., the effect of the code is restricted to the
content of the module or its declared dependencies. A module should not make any
assumptions about its dependents other than the ones expressed through the declared
dependencies.
5
Image: Danilo Rizzuti / FreeDigitalPhotos.net

6. © 2012 IBM Corporation
Modularity in OSGi
 Package dependencies = tight coupling
 Services = loose coupling
 How far can we get in terms of dependability with plain loose coupling?
=> now components can fail independently.
6
Module A
Module B
Module C

7. © 2012 IBM Corporation
Parrot
 Talk to the parrot
 Parrot repeats what it has heard
 Problem: Parrots are inherently unreliable
 Solution: Design for microreboots
7
Image: Arvind Balaraman / FreeDigitalPhotos.net
ParrotPerson
ConfigAdmin
Failure model: single component fails

8. © 2012 IBM Corporation
State and Identity
 ConfigAdmin gives each service an identity
– Can be set through the PID
 Each individual service can have state
 Managing the state through the ConfigAdmin by
attaching it to the identity
– By value for a small amount of state
– By reference for a large state
8
Image: twobee / FreeDigitalPhotos.net

9. © 2012 IBM Corporation
Distributed System: Remote Service Admin
 And now for something completely different.
 Remote Service Admin: Mechanism
– Expose this local service
– Import this remote service
 Topology Manager: Magic
– Which service from where, …
9
Image: OSGi Alliance

10. © 2012 IBM Corporation
Parrot - Version 2.0
 Person listens to Parrot (poll)
 Parrot autonomously fetches the most popular terms from
Twitter
10
Image: Arvind Balaraman / FreeDigitalPhotos.net
ParrotPerson
Dependability
Service
registers itself manages and monitors
Parrot
Failure model: entire node fails

11. © 2012 IBM Corporation
Dependability as a Service
 Manage the available resources in the cloud deployment.
– As a sensor and as an actor
 Manage the identity of reliable services in the cloud deployment.
 Act when a reliable service experiences a failure.
 Prototype based on Remote Services for OSGi (was: R-OSGi), Zookeeper, optionally a key-
value store
– Remote Services for OSGi can re-bind service proxies
 Using it on my Eucalyptus cloud as well as external providers
 Interesting implications: Hot Spares
11
Image: digitalart / FreeDigitalPhotos.net

12. © 2012 IBM Corporation
OSGi as a Cloud Platform
 Instance creation is likely to remain vendor-specific
 REST API provides access to the running instance
 Can be easily integrated into languages other than Java.
 Examples:
– GET http://my_host/framework/bundles/representations
– POST http://my_host/framework/bundles
– GET http://my_host/framework/bundle/5/state
– GET http://my_host/framework/services/representations/(objectClass=org.osgi.*)
 This is work in progress (RFC 182)
 http://www.osgi.org/download/osgi-early-draft-2012-10.pdf
12

13. © 2012 IBM Corporation
OSGi as a Cloud Platform
13

14. © 2012 IBM Corporation
Architecture
14
Framework
Instance
Framework
Instance
Framework
Instance
REST
http://mycloud.com:8080/instances/20132
WebSocket

15. © 2012 IBM Corporation
HTTP Service++
 State of the art
 Pluggable web applications
 Elastic web portal
15
Component A Component B Component C
Bundle A Bundle B Bundle C

16. © 2012 IBM Corporation
Authentication and User Management
 UserAdmin is flexible enough to represent different concepts
– User Identity through OpenID
– Authorization through OAuth
 Most cloud-implementations would be read-only though.
16
Image: Salvatore Vuono / FreeDigitalPhotos.net

17. © 2012 IBM Corporation
Other possible services
 Key-Value Store
 BlockStorage
 Message Queue
 …
 Problem: common abstraction?
 What is the consistency model of my key-value-store?
– equivalent to /dev/null?
– ACID?
– Can I read my own writes?
17
Image: Renjith Krishnan / FreeDigitalPhotos.net

18. © 2012 IBM Corporation
Conclusions
 Modularity as in OSGi solves a major issue with architecting elastic applications for the
cloud.
 It helps to structure applications in a more flexible way.
 It enables platform support for making software more dependable.
 Existing standards like ConfigAdmin, RemoteServiceAdmin, UserAdmin can be used with no
or little modifications
 Other standards like HttpService are not yet fit for the cloud and need to be reworked.
 The REST API is an important addition for bootstrapping cloud deployments.
18
What would you like to see in the cloud?