Mariano Gonzalez and Rob Mills presented on achieving zero downtime with OSGi and microservices architectures. They discussed how OSGi bundles can be deployed as microservices and how OSGi implementations like Apache Karaf support dynamic updating. However, OSGi alone does not provide high availability features. They demonstrated how Cellar clustering adds redundancy to Karaf and how using Kafka as an asynchronous messaging middleware between microservices allows services to remain available even if the Karaf instance or Kafka broker goes down. Topics included OSGi lifecycles, microservice patterns, high availability concepts, the Cellar demo, and integrating Kafka for asynchronous communication between redundant microservices.

1. Downtime
with OSGi
Slides: http://tiny.cc/zero-downtime-soa-slides
Code: http://tiny.cc/zero-downtime-soa-code

2. Speaker Introductions
Mariano Gonzalez
Mariano is a Chicago-based computer geek originally from Mexico. He
loves working with all types of middleware technologies such as Apache
Camel, IBM Integration Bus, Mule and Spring Integration just to mention a
few. He has been using Java for almost 10 years, implementing multiple
kinds of applications for different business fields (insurance, banking, and
trade shows). Mariano used to work for IBM before joining Peapod.com in
2014 where he is the Software Lead Engineer on the Java Team. He
enjoyed sharing his knowledge about Java platforms SE/EE and it's huge
ecosystem.
mariano.gonzalez.mx@gamil.com

3. Speaker Introductions
Rob Mills
Rob is a technology enthusiast and born problem solver originally
from Boston. His experience covers the full stack, including mobile
applications, rich single page javascript UIs, e-Commerce
applications, enterprise middleware integration applications, and
document management applications for clients and employers in a
number of verticals. He loves sharing his passion for software
engineering in all languages but has a professional background in
mostly Java stacks. Rob currently works for Uptake, a predictive
analytics/big data/IoT company, as the Platform Development
Manager.
me@robgmills.com

4. Downtime
{
● Lost productivity
● Lost revenue
● Damaged relationships
● Bad publicity
● Lawsuits

5. OSGi Introduction

6. What is it?
● Initially develop in the context of embedded systems. It is finding more and more usage in
enterprise Java-based systems.
● OSGi works with bundles, which contain a set of specifications that define a dynamic Java
component.
o Features
● Each bundle defines their own dependencies.
● It is possible to run multiple applications simultaneously within a single JVM.

7. Why should I use it?
● It enables applications to be separated into smaller, reusable modules
● Simplifies the development and deployment, decoupling the bundle’s specification from its
implementation.
o OSGi Services
● The OSGi module system is dynamic: it allows modules to be added and removed at runtime.
● OSGi has very good support for versioning: In fact, it allows multiple versions of the same jar to
coexist in the same runtime, thus allowing greater flexibility to deployers.
● OSGi platform encourages a more service-oriented approach.

8. Java 1.9 will support OSGi !?
JSR-376 Mark Reinhold

9. OSGi Lifecycle
Bundle Status
Installed This status indicates that the installation step has been successfully completed. In this
case, neither dependency analysis nor class loading is made. Only required steps are
performed, such as defining bundle properties analysing its Manifest file
Resolved Bundle is found in this status when OSGi resolves and satisfies all of its dependencies and
makes class loading operations. This is the state that comes before starting and stopping
and bundle
Starting This is the state that the bundles is found when the “start” method of the Activator is called,
but not yet as successfully finished or unfinished
Active The bundle is successfully started and running meaning the “start” method of the Activator
resulted success.
Stopping This is the state that the bundles is found when the “stop” method of the Activator is called,
but not yet as successfully finished or unfinished.
Uninstalled This is the state when the bundle is removed from the system. In this situation, there is no
transition to another state. The component must be installed again.

10. Microservices
1. No precise definition though, but at least should be services that are:
i. smaller
ii. light weight
iii. Independently deployable
2. Monolithic Vs Micro Service
3. OSGi and microservices concepts are very similar
OSGi and Microservice

11. OSGi implementations:
1. Eclipse Equinox > Virgo
2. Apache Felix > Karaf
3. Knopflerfish
4. Jboss AS 7
Alternatives to OSGi:
1. Spring Boot
2. DropWizard
3. Vert.x
Implementations and Alternatives

12. HA
Introduction

13. What is HA?
● Load balanced
● Clustered

14. In addition...
● Only one server is active and takes all the load.
● The remaining server(s) only comes into picture if primary is down.

15. How high is “high”?
● Amount of downtime is minimally
impactful to your business
● Determined by your SLA
● "Class of nines”? 99.999% = "Five
nines"
● Diminishing returns

16. Key traits
● Redundant
● Decoupled
● Responsive
● Resilient

17. ● Neither OSGi (nor Spring) were created to solve problems
such as high-availability, clustering or load-balancing.
● Is not distributed.
● No failover.
● Complicated deployment process of micro-services across boundaries.
● It is possible to build an OSGi cluster, but you are probably going to need something else, such
as a way to detect and communicate load levels, events, etc.
OSGi and HA

18. To the rescue...

19. Cellar, an OSGi clustering solution
OOTB Cellar supports:
1. Discovery:
Automatically join the cluster of other Cellar nodes (No configuration required):
● Multicast
● Unicast
1. Cluster Group Management
Resources will be synchronized between nodes of the same group:
● Node Grouping
Note: Runs on top of Hazelcast

20. 3. Distributed Features and Configuration Admin:
Automatic deployment of all features and bundles (micro-services) to all nodes
Distributes configuration data, both of Cellar-specific and Karaf etc/*.cfg configuration files
4. Provisioning Tools:
Easy management of all nodes
● Shell commands for cluster provisioning

21. Demo: Karaf + Cellar
Hello ${name}! REST API
● Two bundles:
o rest service
o service implementation
1. Bring down master Karaf node > Slave node still responds.
2. Bring back the master Karaf node
3. Bring down slave > Master again gets the requests

22. OSGi topology diagram

23. OSGi tips during development
Syntax
bundle:watch [options] [urls]
Options
urls The bundle IDs or URLs
Arguments
--help Display this help message
--stop Stops watching all bundles
-i Watch interval
--list Displays the watch list
--remove Removes bundles from the watch list
--start Starts watching the selected bundles

24. Redundant/resilient...now what?

25. Decoupled with messaging
Brokers available:
1. ActiveMQ
2. RabbitMQ
3. Many others
Advantages of a traditional broker:
● Can be asynchronous
● Decoupled (very easy to change the provider without touching the
bundle implementation)
● Fast
● Persistent by default (JMS specification)

26. What’s wrong with the traditional broker?
● Managing all the JMS headers / properties cumbersome
o Normally an ESB (like Camel) can take care of this, but still.
● Tuning of the broker never ends
o A lot configuration on both producer / consumers
● Not distributed by nature
o Persistent topics / Virtual Topics (ActiveMQ)

27. Instead…
● Not fast, super fast!
● Scalable - easy to add new nodes
● Cluster - centric OOTB
o Required Acks
● Not persistent, super persistent!
o Replication Factor
Gotcha: Not JMS compliant!

28. Demo: Kafka
Hello ${name}! REST API (async)
1. Two Kafka brokers orchestrated by Zookeeper:
i. Leader
ii. Follower
1. Bring down Leader broker > Consumer still gets the messages.
1. Bring back broker > Consumer still gets the messages.

29. Broker topology

30. Putting it all together
1. Two Kafka brokers orchestrated by Zookeeper:
i. Leader
ii. Follower
1. Two Karaf instances coordinated by Cellar:
i. Master
ii. Slave
1. Bring down Master / Leader
i. Slave / Follower Stills responds!

31. Complete topology

33. Slides:
Code:
Camel:
Karaf:
Kafka:
Cellar:
Zookeeper Ensemble:
http://tiny.cc/zero-downtime-soa-slides
http://tiny.cc/zero-downtime-soa-code
http://camel.apache.org/user-guide.html
http://karaf.apache.org/manual/latest/quick-start.html
http://kafka.apache.org/documentation.html
https://karaf.apache.org/index/subprojects/cellar.html
http://myjeeva.com/zookeeper-cluster-setup.html