OSGi Community Event 2014

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

4. “MICROSERVICES”
YOU KEEP USING THAT WORD. I DO NOT THINK IT
MEANS WHAT YOU THINK IT MEANS.

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

6. API
api
api api
Service
Consumer Provider

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

11. Scaling

12. Horizontal
Process
Process
Process

13. Horizontal
Process Process Process

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.

17. Demo

18. Orchestrating

19. What Should I Run??
Where Should I Run It??
Where Is Everybody??

20. Local Discovery (Easy)
Process
Process
Process

21. Remote Discovery (Hrrrmm)
Process Process ?

22. State of the Art
• Install X on this box, install Y on that box, etc…
• Tell X where Y is (static config)
• Tell Y where X is (static config)

23. OSGi RSA Discovery
• Advertise / Discover using Pluggable Impls
• E.g.: Bonjour, SLP, DDS, Gossip, ZooKeeper…
• Dynamic Availability / Presence
• Plug and Play!

24. Even for Non-Services…
REST
Provider
Consumer
Endpoint
uri=http://<host>:<port>/<alias>
HTTP Comunication

25. Even for Non-Java Services
Mosquitto
Packager
Consumer
Endpoint
uri=mqtt://<host>:<port>
MQTT Mosquitto
(MQTT)
Process

26. … and Non-Java Consumers
REST
Provider
REST
Provider
NGinx
Packager
uri=http://<host>:<port>/<alias>
NGinx
Process
REST
Provider

27. Oh, and Docker
Mosquitto
Packager
Consumer
uri=mqtt://<host>:<port>
MQTT
Mosquitto
(MQTT)
Container
Prosyst mPRM
See: OSGi Alliance IoT Demo and Hackathon
Packager
Prosyst mPRM
Container
uri=mprm://<host>:<port>
version=5.3.0
mPRM (custom HTTP)

28. What, Where, How Many?
• OSGi Capabilities and Requirements — a generic
software pattern.
• Use to describe native executables, Docker images…
• Machine capabilities define “where”
• Policy defines “how many”.

29. Demo

30. Technology Used
• Paremus RSA — implementation of OSGi Remote
Services Admin specification
• Paremus Packager — open source API
• Paremus Service Fabric — secret sauce ;-)

31. Questions?