When building and maintaining large applications in a world that is rapidly evolving, keeping up with changing requirements and non-functionals over time is a huge challenge. Architecting your application in a modular way and loosely coupling modules using micro services provides you with a nicely decoupled system that still works very efficiently. Designing, evolving and versioning a micro service architecture is not easy, and over time, several design patterns and best practices have evolved that help you. Code examples can be found here: https://bitbucket.org/marrs/javaone-2014-microservices

1. Modular Architectures
using Micro Services

2. About Me
Marcel Offermans
Director at Luminis Technologies
Member at the Apache Software Foundation
@m4rr5

3. Agenda
• Modular Architectures
• Micro Services
• OSGi in 60 seconds
• Amdatu
• Demo

4. Modular Architectures

5. The case for modularity

6. Maintainability

7. Adaptability

8. Quest for Reuse
Copy / Paste

9. Quest for Reuse
Object Oriented

10. Quest for Reuse
Component Based

11. Micro Services

12. The term "Microservice Architecture" has sprung up
over the last few years to describe a particular way
of designing software applications as suites of
independently deployable services. While there is no
precise definition of this architectural style, there are
certain common characteristics around organization
around business capability, automated deployment,
intelligence in the endpoints, and decentralized
control of languages and data.
Source: http://martinfowler.com/articles/microservices.html

13. Business Capabilities
• Should be leading when splitting an application
into components
• Different from more traditional technology driven
“layering” (UI, application logic, database)
Conway’s Law: Any organization that designs a
system will produce a design whose structure is a
copy of the organization's communication structure.
!
Melvyn Conway, 1967

14. Component owns Data
• Each service manages its own data
• Can lead to polyglot persistence
• Leverage Domain-Driven Design: bounded context
often maps naturally to components
• Use transaction-less coordination between
services: build for eventual consistency and have a
reversal process to deal with mistakes

15. Products
• Make the team responsible for the whole life cycle
of a product or component
• Brings developers closer to the customers
Amazon:”You build it, you run it!”

16. Services
• Provide a public, versioned contract for a
component
• Have their own life cycle, so they can be
separately deployed
• Hide all implementation details

17. Dumb Pipes
• HTTP request/response
• lightweight messaging

18. Decentralized
• Services decouple and abstract away components,
leaving us free to choose implementation
languages
• Less focus on formal standards, more on
proven, open source
technology

19. Automated Deployment
• Continuous Integration
• Continuous Deployment

20. Design for Change
• How to break a system into components? Consider
rate of change, high cohesion, low coupling, …
• Version your services, and make them tolerant to
change
• Stay flexible!
The only constant is change.

21. Design for Failure
• Applications need to be able to deal with failures
• Services can always fail or become unavailable
• Monitoring is an important aspect
Netflix: Chaos Monkey to
introduce random instance failures
Michael Jordan: I’ve missed more than 9000 shots in
my career. I’ve lost almost 300 games. 26 times, I’ve
been trusted to take the game winning shot and
missed. I’ve failed over and over and over again in
my life. And that is why I succeed.

22. OSGi in 60 seconds

23. What is OSGi?
• Provides components that can be easily deployed
and versioned
• Hides implementation details and leverages a
service registry that allows components to publish
and consume services
• It’s the de-facto module system for Java: proven
technology, works on all Java versions, usable from
embedded to enterprise

24. OSGi
META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Bundle-Activator: store.fs.osgi.Activator
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1, 2)"

25. META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Bundle-Activator: store.fs.osgi.Activator
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1, 2)"
class Activator implements BundleActivator {
ServiceRegistration sr;
public void start(BundleContext bc) {
sr = bc.registerService(Store.class.getName(), new StoreImpl(), null);
}
public void stop(BundleContext bc) {
sr.unregister();
}
}
OSGi

26. OSGi
META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Bundle-Activator: store.fs.osgi.Activator
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1, 2)"
class Activator implements BundleActivator {
ServiceRegistration sr;
public void start(BundleContext bc) {
sr = bc.registerService(Store.class.getName(), new StoreImpl(), null);
}
public void stop(BundleContext bc) {
sr.unregister();
}
}

27. OSGi
META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1, 2)"
class Activator implements BundleActivator {
ServiceRegistration sr;
public void start(BundleContext bc) {
sr = bc.registerService(Store.class.getName(), new StoreImpl(), null);
}
public void stop(BundleContext bc) {
sr.unregister();
}
}
bundles
resolver store;version="2.5"
Bundle-Activator: store.fs.osgi.Activator

28. OSGi
META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1,2)"
1, 2)"
class Activator implements BundleActivator {
ServiceRegistration sr;
public void start(BundleContext bc) {
sr = bc.registerService(Store.class.getName(), new StoreImpl(), null);
}
public void stop(BundleContext bc) {
sr.unregister();
}
}
bundles
META-INF/MANIFEST.MF
org/foo/log/Log.class
org/foo/log/syslog/SysLogImpl.class
org/foo/log/syslog/Activator.class
store;version="2.5"
org.foo.log;version="1.3"
resolver
Bundle-Activator: store.fs.osgi.Activator

29. OSGi
META-INF/MANIFEST.MF
Bundle-SymbolicName: store.fs
store/Store.class
store/Key.class
store/fs/StoreImpl.class
store/fs/FileSystem.class
store/fs/StreamUtil.class
store/fs/osgi/Activator.class
lib/fsutil.jar
Bundle-Version: 1.0.2
Bundle-Classpath: ., lib/fsutil.jar
Export-Package: store;version="2.5"
Import-Package: org.foo.log;version="[1,2)"
1, 2)"
class Activator implements BundleActivator {
ServiceRegistration sr;
public void start(BundleContext bc) {
sr = bc.registerService(Store.class.getName(), new StoreImpl(), null);
}
public void stop(BundleContext bc) {
sr.unregister();
}
}
service registry
bundles
META-INF/MANIFEST.MF
org/foo/log/Log.class
org/foo/log/syslog/SysLogImpl.class
org/foo/log/syslog/Activator.class
store;version="2.5"
org.foo.log;version="1.3"
resolver
store.Store { service.id = 1 }
Bundle-Activator: store.fs.osgi.Activator

30. Remoting
service registry
OSGi framework
java virtual machine
bundle
bundle
bundle
service registry
bundle
bundle
OSGi framework
java virtual machine
service registry
bundle
OSGi framework
bundle
bundle
java virtual machine
bundle

31. Amdatu

32. What is Amdatu?
Amdatu is an open source community effort focussed on
bringing OSGi to the cloud. It contains components to create
RESTful, scalable and distributed web applications that use
NoSQL data stores, transparent multi-tenancy and much more.

33. Development Model
• Modular design based on OSGi
• Fast deployment using Bndtools
• Git fork/merge based workflow
• Extensive Atlassian tool support
• Apache ACE integrated with build servers
• Gradle based build

34. Demo

35. Wrapping Up

36. We’ve…
• …explored modularity and micro services
• …introduced OSGi and Amdatu
• …seen how to develop and run a modular
application
• …seen how OSGi allows you to be flexible in how
you group and deploy components

37. Eclipse OSGi plugin!
http://bndtools.org/ !
Provisioning Server!
http://ace.apache.org/!
Cloud OSGi services!
http://www.amdatu.org/
That’s us!
http://luminis-technologies.com/
Demo code!
https://bitbucket.org/marrs/javaone-2014-microservices/

38. Takk
Grazie
Thank!
you
Obrigado
Mahalo
Danke
Dank U
Merci
Gracias