Microservices and OSGi: Better together?

© 2016 IBM Corporation
Graham Charters
Senior Technical Staff Member,
WebSphere Application Server
Microservices and OSGi:
Better together?

2Page© 2016 IBM Corporation
Agenda
– Introduction to Modularity, Microservices & OSGi
– Comparison of OSGi and Microservice capabilities
– Microservices challenges
– OSGi smoothing the way to Microservices

What is Modularity
– “Modular programming is a software
design technique that emphasizes
separating the functionality of a
program into independent,
interchangeable modules, such that
each contains everything necessary to
execute only one aspect of the desired
functionality.”
– “A module interface expresses the
elements that are provided and
required by the module. …”
https://en.wikipedia.org/wiki/Modular_programming
Photo by: https://www.flickr.com/photos/zaxl4/
License: https://creativecommons.org/licenses/by-sa/2.0/

http://martinfowler.com/articles/microservices.html (25 March 2014)
What are Microservices

http://martinfowler.com/articles/microservices.html
Microservices are Modularity







What is OSGi
– Enables products to
be assembled from
Modules
– Modules callable
through Services
– Modules and their
Services have a
dynamic lifecycle
BundleBundle
Bundle
listen
provideuse
Service

Not all modularity is equal
• Not all module technologies
enable the same capabilities
• Modularity Maturity Model
provides a way to compare
technologies and understand
the benefits
• Inspired by customer
experiences adopting OSGi
“Towards a Modularity Maturity Model”,
OSGi Community Event 2011 presentation @ http://slidesha.re/q8EHFp

Modularity Levels
Level Name Summary
1 Ad Hoc Nothing
2 Modules Formal identity, decoupled from artifact
3 Modularity Formal module contracts, decoupled from identity
4 Loose-Coupling Services, semantic versioning, decoupled from implementation
5 Devolution Modularity-aware repositories, collaboration, governance,
decoupled from ownership
6 Dynamism Life-cycle awareness and independence, decoupled from time

What was it Lewis and Fowler said?
Level Name Summary
1 Ad Hoc Nothing
2 Modules Formal identity
3 Modularity Formal module contracts
4 Loose-Coupling Services, semantic versioning, Componentization via Services
Organized around Business Capabilities
6 Dynamism Life-cycle awareness and independence, Design for failure

Filling in the gaps
Level Name Summary
1 Ad Hoc Nothing
2 Modules Formal identity, Deployable service (likely a build artefact)
3 Modularity Formal module contracts, Service Contracts – e.g. Swagger
4 Loose-Coupling Services, semantic versioning, Componentization via Services
Organized around Business Capabilities
6 Dynamism Life-cycle awareness and independence, Design for failure

Didn’t you just tell
us we don’t need
OSGi?
https://creativecommons.org/licenses/by-nd/2.0/
https://www.flickr.com/photos/40601656@N07/

The answer’s Microservices, what’s the question?
https://www.gartner.com/doc/3371727/hype-cycle-application-services-
ByJeremykempatEnglishWikipedia,CCBY-SA3.0,
https://commons.wikimedia.org/w/index.php?curid=10547051
Gartner
says we’re
here
Early publicity produces a number of
success stories—often accompanied by
scores of failures. Some companies take
action; most don't.
Peak of Inflated Expectations

Evolution, not revolution
Martin Fowler:
“As I hear stories about teams using a microservices architecture, I've noticed a
common pattern.
1. Almost all the successful microservice stories have started with a monolith that
got too big and was broken up
2. Almost all the cases where I've heard of a system that was built as a
microservice system from scratch, it has ended up in serious trouble.”
http://martinfowler.com/bliki/MonolithFirst.html

Design is still hard
http://www.codingthearchitecture.com/2014/10/01/modularity_and_testability.html
Simon Brown:
“Technologies like Spring Boot make creating and deploying
microservices relatively straightforward, but the design thinking
behind partitioning a software system into services is still as
hard as it's ever been.”
http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths

Document your
poop

The costs of Microservices
http://martinfowler.com/articles/microservice-trade-offs.html

So should we or shouldn’t we do Microservices?
https://creativecommons.org/licenses/by/2.0/
https://www.flickr.com/photos/sufferingsocrates/

Look before you leap
https://www.flickr.com/photos/ggabernig/

Monolith-first
Martin Fowler:
“As I hear stories about teams using
a microservices architecture, I've
noticed a common pattern.
1. Almost all the successful
microservice stories have started
with a monolith that got too big
and was broken up
2. Almost all the cases where I've
heard of a system that was built
as a microservice system from
scratch, it has ended up in
serious trouble.”
http://martinfowler.com/bliki/MonolithFirst.html

Design is still hard
http://www.codingthearchitecture.com/2014/10/01/modularity_and_testability.html
Technologies like Spring
Boot make creating and
deploying microservices
relatively straightforward,
but the design thinking
behind partitioning a
software system into
services is still as hard as
it's ever been.

Boundaries
Microservices’ main benefit, in my view, is
enabling parallel development by
establishing a hard-to-cross boundary
between different parts of your system.
By doing this, you make it hard – or at least
harder – to do the wrong thing: Namely,
connecting parts that shouldn’t be
connected, and coupling those that need to
be connected too tightly. In theory, you
don’t need microservices for this if you
simply have the discipline to follow clear
rules and establish clear boundaries
within your monolithic application; in
practice, I’ve found this to be the case only
very rarely.
http://martinfowler.com/articles/dont-start-monolith.html
Don’t start with a monolith
… when your goal is a microservices architecture
Stefan Tilkov

Boundaries
“Often the true consequences of your
architectural decisions are only evident
several years after you made them. We
have seen projects where a good team,
with a strong desire for modularity, has
built a monolithic architecture that has
decayed over the years. Many people
believe that such decay is less likely with
microservices, since the service
boundaries are explicit and hard to
patch around.”
http://martinfowler.com/articles/microservices.html

The modular
monolith
If you can't build a
modular monolith,
what makes you
think microservices
are the answer?
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

Getting to there from here…
https://www.flickr.com/photos/pss/

Key questions
What will help me create and
maintain a modular
monolith?
What’s the closest you can
get to the microservices
qualities without incurring all
of the associated cost?

Refresher…
– Enables products to
be assembled from
Modules
– Modules callable
through Services
– Modules and their
Services have a
dynamic lifecycle
BundleBundle
Bundle
listen
provideuse
Service

The Modular Monolith
– Use OSGi to modularise your Product
– Not just Business as Usual - organize
around business capabilities,
modularize your data, etc.
– A number of approach have been
documented.
• Services-first
• Java EE -> OSGi
• Strangler Pattern
– These are equally applicable to OSGi
& Microservice discovery
ED
B
F
A
C
H
G

Evolving to Microservices
– Identify Feature ‘Subsystems’
as individually deployable
units
– Continue to deploy to same
process
ED
B
F
A
C
H
G

Isolate your Subsystems
– Make ‘boundary services’
remotable
– Enforce isolation using
Application Subsytems
– Handle service unavailability
– Continue to deploy to same
process
ED
B
F
A
C
H
G
G
B

Deployment independently
– Deploy as independently
scalable microservices
– Automate deployment
– Prove out remoting, latency,
etc.
E
D
B
F
A
C
H
G
G
B

Modular Monolith+

Remoting Services
– OSGi Remote Services &
Remote Services Admin
providers
– Or pick a JAX-RS
implementation
– Future: JAX-RS Whiteboard
(RFC 217)
RS Impl RS Impl
register
proxy
discover
register
endpoint
JAX-RS
endpoint
JAX-RS
proxy
https://github.com/osgi/design/tree/master/rfcs/rfc0217

Technology choices
– MicroProfile 1.0 defines a technology set for Java EE
•JAX-RS, CDI, JSON-P
– What would the OSGi equivalent be?
•JAX-RS, Declarative Services, JSON-P
– Beyond the core
•Externalize configuration – Config Admin (think 12-factor)

Summary
– Microservices are an important approach to producing highly-available,
maintainable applications
– Microservices are not for-free, introducing new costs, such as distribution
and operational complexity
– Modular monoliths are seen as an important stepping stone to being able to
produce Microservices
– OSGi is an ideal fit for producing modular monoliths, going well-beyond their
core characteristics
– The OSGi standards cover the core capabilities essential for producing first-
class Java-based microservices

Microservices and OSGi: Better together?

Recommended

More Related Content

Viewers also liked (20)

Similar to Microservices and OSGi: Better together? (20)

More from Graham Charters (10)

Recently uploaded (20)

Microservices and OSGi: Better together?

Editor's Notes