Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Scaling and Orchestrating Microservices with OSGi - N Bartlett
1. Scaling and Orchestrating
Microservices with OSGi
… OR:
How to Write a Session Title That Will Get
Your Talk Accepted at Any Conference
Neil Bartlett — Paremus Ltd
2. OSGi is From the Future
• Runtime resolve/assemble
since 2005
• Software component
repositories since 2003
• Continuous delivery since
1999
• Microservices since 1998
image credit: Sam Howzit (flickr.com/photos/aloha75/)
3. “The term ‘microservice’ was
discussed at a workshop of
software architects near Venice
in May, 2011 to describe what
the participants saw as a
common architectural style that
many of them had been recently
exploring.”
— Martin Fowler, March 2014
http://martinfowler.com/articles/microservices.html
5. “What I am promoting is the
idea of μServices, the
concepts of an OSGi service
as a design primitive.”
— Peter Kriens, March 2010
http://blog.osgi.org/2010/03/services.html
7. “Fowler” Microservices OSGi Services
“an approach to developing a single application as a suite of
small services" ✔
“each running in its own process” ✘
“communicating with lightweight mechanisms” ✔
“built around business capabilities” ✔
“independently deployable by fully automated deployment
machinery” ✔
“bare mininum of centralized management of these services” ✔
“may be written in different programming languages” ✔*
“use different data storage technologies” ✔
* JVM languages only, for now
8. Why Separate Processes?
• “One main reason … is that services are independently
deployable.” … like OSGi Bundles
• “you can expect many single service changes to only
require that service to be redeployed.” … like OSGi Bundles
• “Another consequence of using services as components is
a more explicit component interface.” … like OSGi Services
• “Often it's only documentation and discipline that prevents
clients breaking a component's encapsulation.” … whereas
OSGi enforces encapsulation
9. Isolation is a Continuum
COST
Java
Classpath
OSGi
Services
OS Process
Docker
VM
Physical
Box
Data
Centre
local minima
(sweet spots)
← Weaker ISOLATION Stronger →
10. Java
OSGi
Process
Docker
VM
Physical
Box
Data
Centre
Services and Reuse
Crash Isolation, Alternate Langs
CPU/Mem Quotas
Alternate OS
Power Fail, Whole OS Crash
Disaster Resilience
14. When to Scale?
• Q: “Should I expose this as a service for scaleability?”
• Agilist Answer: “No… YAGNI*”
*You Aren’t Gonna Need It
15. When to Scale (OSGi Style)
Provider Consumer
Config Switch
Provider Consumer
16. OSGi Remote Services
• Services can be selected for remoting post facto.
• Small code change or pure config change.
• Respond to rapidly changing demand.
• TGTBT? In practice, devs should at least factor in the
possibility of remoting.
