microservices & osgi - better together? - graham charters

© 2016 IBM Corporation

Graham Charters

Senior Technical Staff Member,

WebSphere Application Server

Microservices and OSGi: Better together?

2 Page © 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/

https://en.wikipedia.org/wiki/Software_design

https://en.wikipedia.org/wiki/Software_design

https://en.wikipedia.org/wiki/Computer_program

4 Page © 2016 IBM Corporation http://martinfowler.com/articles/microservices.html (25 March 2014)

What are Microservices

http://martinfowler.com/articles/microservices.html (25

http://martinfowler.com/articles/microservices.html (25

5 Page © 2016 IBM Corporation http://martinfowler.com/articles/microservices.html

Microservices are Modularity

http://martinfowler.com/articles/microservices.html



What is OSGi

– Enables products to

be assembled from

Modules

– Modules callable

through Services

– Modules and their

Services have a

dynamic lifecycle

Bundle Bundle

Bundle

listen

provide use

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?

htt

ps:/

/cre

ativecom

mons.o

rg/lic

enses/b

y-n

d/2

.0/

htt

ps:/

/ww

w.f

lickr.

com

/photo

s/4

0601656@

N07/


The answer’s Microservices, what’s the question?

htt

ps:/

/ww

w.g

art

ne

r.co

m/d

oc/3

37

17

27

/hyp

e-c

ycle

-ap

plic

atio

n-s

erv

ices-

By J

ere

myke

mp

at E

ng

lish

Wik

iped

ia, C

C B

Y-S

A 3

.0,

htt

ps:/

/co

mm

on

s.w

ikim

ed

ia.o

rg/w

/in

dex.p

hp

?cu

rid=

10

54

70

51

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

htt

ps:/

/ww

w.f

lickr.

com

/photo

s/g

gabern

ig/

htt

ps:/

/cre

ativecom

mons.o

rg/lic

enses/b

y/2

.0/


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.


http://projects.spring.io/spring-boot/

http://projects.spring.io/spring-boot/


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

https://www.innoq.com/blog/st/

https://www.innoq.com/blog/st/


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.”



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://creativecommons.org/licenses/by/2.0/

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

Bundle Bundle

Bundle

listen

provide use

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

E D

B

F

A

C

H

G


Evolving to Microservices

– Identify Feature ‘Subsystems’

as individually deployable

units

– Continue to deploy to same

process

E D

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

E D

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