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
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.
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
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
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
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
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
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.
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!
The importance of high availability varies among applications. However, the need to deliver increasing levels of availability continues to accelerate as enterprises re-engineer their solutions to gain competitive advantage. Most often, these new solutions rely on immediate access to critical business data. When data is not available, the operation can cease to function. Downtime can lead to lost productivity, lost revenue, damaged customer relationships, bad publicity, and lawsuits.
If a mission-critical application becomes unavailable, then the enterprise is placed in jeopardy. It is not always easy to place a direct cost of downtime. Angry customers, idle employees, and bad publicity are all costly, but not directly measured in currency. On the other hand, lost revenue and legal penalties incurred because SLA objectives are not met can easily be quantified. The cost of downtime can quickly grow in industries that are dependent upon their solutions to provide service.
UPTAKE USE CASE
At Uptake, a single client can produce over 12500 requests-per-second, 24 hours-per-day, 365 days-per-year. Any downtime could result in an unplanned service outage potentially costing our clients tens of thousands of dollars per hour. The ability to consume each of these requests is critical to our business.
PEAPOD USE CASE
At Peapod we interact with several third parties services, databases etc. We need to be able to deploy changes to this third party services without affecting the remaining services and thus without affecting the customer experience.
Mariano
2 Bundles are normal jar files with extra manifest headers. Another term worth to mention Feature, which is a set of bundles. There are some ways of installing a group bundles into a OSGi framework:
Features are available through maven repos or filesystem
3 Difference between traditional application server where you have a single classpath for all the artifacts. Each bundle has there own “classpath”
4 Does not exist in the standalone JVM
Mariano
1 Robust dependency specification.
2 Implementations hide from the other components. Communication through OSGi services
3 Without bringing down the full container
4 Important for legacy applications
Mariano
Mariano
Transition between all of the status of the lifecycle without stopping the JVM.
Mariano
1. Hard to deny there's a clear movement in the Java ecosystem towards micro services
2. Putting all your code into monolithic application.
Mariano
Mariano -> Rob
ROB
HA is not just sticking a load balancer in front of your application or creating a cluster of applications.
Load Balance: The app is heavy and needs more than one server so that they can divide the load.
Clustering: Running more than one server in such a way that they seem as one server to end user.
Rob
Master/slave architecture
Redundancy
ROB
High availability doesn't mean the same thing to everybody. It can't and it shouldn't.
High availability is really the determined by the amount of downtime is minimally impactful to your business
Varies from system-to-system, business to business
For example, Google posted $66B in revenue last year. That equates to $660K for every .00001% of up time.
Determined by or described in your service-level agreement
But what we’re really referencing when we say “high-availability” is 99% uptime and above.
This is typically referred to as the “class of nines”.
For example, 99.99% is called “four nines”.
Or 99.999% is called “five nines”.
And the law of diminishing returns sort of applies here.
It takes significantly more money and effort to move from five to six nines (which could require something like regional hot/hot datacenters)
than it does to move from 90% to 95% which could be as simple as rolling restarts of your servers.
ROB
Redundant (which helps achieve the elimination of single points of failure)
Decoupled (which allows components operate independent of each other’s availability)
Responsive (which means that despite failures the application continues to respond to requests quickly, it's not really helpful if it takes 30s for your app to respond)
Resilient (automatically detects and recovers from failures as they occur)
Rob
Spring tries to solve this problem with microservices created with Spring Boot.
OSGi automatic restarting of bundles helps, but isn’t quite good enough.
Coordination between development / build and release process in order to avoid downtime
Is much easier to deploy a single artifact (traditional EAR or WAR file) than several microservices (bundles).
Rob -> Mariano
Mariano
For those who don’t know Hazelcast is an in memory data grid.
Combines Jcache and JMS
Multicast -> is sufficient to have an invitation for the whole group
After the discovery process everything is TCP/IP
Rob
If for any reason the bundle implementation goes down, you want to continue receiving messages
Rob
Rob
Developed by LinkedIn originally to serve as a page view logging system and open sourced to the Apache Foundation.
Fast - a single node can handle hundreds of megabytes of reads and writes per second
Scalable - It can be elastically and transparently expanded without downtime. And data written to it is partitioned over the nodes in the cluster.
Cluster centric that takes into account fault tolerance.
Persistent. And since it replicates all of the messages across the cluster, data loss is unlikely.
Rob
./zookeeper-server-start.sh ../libexec/config/zookeeper.properties &
./kafka-server-start.sh ../libexec/config/server-1.properties &
./kafka-server-start.sh ../libexec/config/server-2.properties &