zero downtime with osgi - chicago coder conference 05-15-2015
TRANSCRIPT
Downtimewith OSGi
Slides: http://tiny.cc/zero-downtime-soa-slides
Code: http://tiny.cc/zero-downtime-soa-code
Speaker Introductions
Mariano GonzalezMariano 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.
Speaker Introductions
Rob MillsRob 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.
Downtime {● Lost productivity● Lost revenue● Damaged relationships● Bad publicity● Lawsuits
OSGi Introduction
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.
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.
OSGi LifecycleBundle 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.
Microservices
1. No precise definition though, but at least should be services that are:i. smallerii. light weightiii. Independently deployable
2. Monolithic Vs Micro Service
3. OSGi and microservices concepts are very similar
OSGi and Microservice
OSGi implementations:1. Eclipse Equinox > Virgo2. Apache Felix > Karaf3. Knopflerfish4. Jboss AS 7
Alternatives to OSGi:5. Spring Boot6. DropWizard7. Vert.x
Implementations and Alternatives
HA Introduction
What is HA?
● Load balanced
● Clustered
In addition...
● Only one server is active and takes all the load.
● The remaining server(s) only comes into picture if primary is down.
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
Key traits
● Redundant● Decoupled● Responsive● Resilient
● 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
To the rescue...
Cellar, an OSGi clustering solution
OOTB Cellar supports:
1. Discovery:Automatically join the cluster of other Cellar nodes (No configuration required):
● Multicast● Unicast
2. Cluster Group ManagementResources will be synchronized between nodes of the same group:
● Node Grouping
Note: Runs on top of Hazelcast
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
Demo: Karaf + Cellar
Hello ${name}! REST API
● Two bundles: o rest serviceo service implementation
1. Bring down master Karaf node > Slave node still responds.2. Bring back the master Karaf node3. Bring down slave > Master again gets the requests
OSGi topology diagram
OSGi tips during developmentSyntaxbundle:watch [options] [urls]
Optionsurls 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
Redundant/resilient...now what?
Decoupled with messaging
Brokers available:1. ActiveMQ2. RabbitMQ3. 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)
What’s wrong with the traditional broker?
● Managing all the JMS headers / properties cumbersomeo Normally an ESB (like Camel) can take care of this, but still.
● Tuning of the broker never endso A lot configuration on both producer / consumers
● Not distributed by nature o Persistent topics / Virtual Topics (ActiveMQ)
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!
Demo: Kafka
Hello ${name}! REST API (async)
1. Two Kafka brokers orchestrated by Zookeeper: i. Leaderii. Follower
2. Bring down Leader broker > Consumer still gets the messages.
3. Bring back broker > Consumer still gets the messages.
Broker topology
Putting it all together
1. Two Kafka brokers orchestrated by Zookeeper: i. Leaderii. Follower
2. Two Karaf instances coordinated by Cellar: i. Masterii. Slave
3. Bring down Master / Leader i. Slave / Follower Stills responds!
Complete topology
Slides:Code:
Camel:Karaf:Kafka:Cellar:
Zookeeper Ensemble:
http://tiny.cc/zero-downtime-soa-slideshttp://tiny.cc/zero-downtime-soa-codehttp://camel.apache.org/user-guide.htmlhttp://karaf.apache.org/manual/latest/quick-start.htmlhttp://kafka.apache.org/documentation.htmlhttps://karaf.apache.org/index/subprojects/cellar.htmlhttp://myjeeva.com/zookeeper-cluster-setup.html