This document discusses Liferay as a microservice platform. It begins by describing some issues with monolithic applications, such as high complexity, limited scalability and reusability. It then introduces microservices as an approach to break applications into independently deployable services. While microservices reduce complexity within each component, they can increase operational overhead and introduce new challenges around network communication and coordination. The document argues that Liferay's use of OSGi addresses many microservice goals while avoiding some of the operational overhead, and that its modular architecture provides a natural path for applications to evolve from monoliths to microservices over time.

1. Liferay as a Microservice
Platform
Daniel Reuther
Senior Consultant, Liferay GmbH

2. The Monolith
Unmanageable complexity:
• Costly to modify and extend
• Unattractive to develop for
• Limited reusability
• One-dimensional scalability
Known concepts:
• Operations
• Deployment
• Development, Testing
#LRFRS2017

3. The Microservice
As a deployment option:
• One application = several services
• Individually deployable
• Lightweight communication
• Decentralized governance & data storage
• Iterative development
#LRFRS2017
flickr.com/trondheimhavn

4. http://martinfowler.com/articles/microservices.html
Reduced complexity!Reduced complexity?
The Microservice
#LRFRS2017
flickr.com/trondheimhavn

5. #LRFRS2017
Automation and Monitoring
Messaging Channel
Management, Configuration, Discovery, Routing
Inner Architecture
Microservice A
Loadbalancing
Microservice B
Loadbalancing
Container
Microservice C
Loadbalancing
Container
Microservice D
Loadbalancing
Container
API Gateway
Tomcat
Jetty
Spring Boot
Dropwizard
Runtime
Docker
OpenVZ
LXC
Container
VMware
Hyper-V
Xen
Virtualization
AWS
Azure
GCP
Cloud
AMQP
MQTT
Messaging
Zookeeper
Kubernetes
Curator
Amazon ELB
Management
Logstash
Kibana
Puppet
Chef
…
Ops
Container

6. The Microservice
Operational overhead:
• Instead of one clustered application
several micro applications that need to be
clustered, instrumented and operated
• Instead of a single application server
several micro application with potentially
different runtime environments
#LRFRS2017
flickr.com/trondheimhavn

7. flickr.com/trondheimhavn
The Microservice
Design challenges:
• Network latencies
• Fault tolerance
• Serialization
• Distributed transactions
• Monitoring
#LRFRS2017

8. The Microservice
#LRFRS2017
“
”
[…] all you are doing is shifting
complexity from inside a component to
the connections between components
[…] it moves it to a place that's less
explicit and harder to control
Martin Fowler (2014)
http://martinfowler.com/articles/microservices.html

9. The Platform
#LRFRS2017

10. #LRFRS2017
The Platform
OSGi as a core technology of Liferay DXP
• Defined best practices can be helpful
• Transparent platform valuable for developers
• Opportunity for iterative modularization
• Support
• Benefit from the lessons we learned!

11. #LRFRS2017
The Platform
“
”
[…] you shouldn't start with a
microservices architecture. Instead begin
with a monolith, keep it modular, and split
it into microservices once the monolith
becomes a problem.
Martin Fowler (2014)
http://martinfowler.com/articles/microservices.html

12. OSGi μServices
#LRFRS2017
“
”
What I am promoting is the idea of
μServices, the concepts of an OSGi
service as a design primitive.
Peter Kriens (2010)
http://blog.osgi.org/2010/03/services.html

13. #LRFRS2017
OSGi μServices
flickr.com/alexhealing
Bundle A
1.0
Bundle B
1.0
register get
listen
S
Bundle A
1.1
register
Bundle A
1.0

14. #LRFRS2017
OSGi μServices
flickr.com/alexhealing
Microservice according to Fowler
http://martinfowler.com/articles/microservices.html
OSGi
μServices
single application as a suite of small services
running in its own process
communicating with lightweight mechanisms
built around business capabilities
independently deployable
minimum of centralized management
may be written in different programming languages
use different data storage technologies
✔
✔
✔
✔
✔
✔
✔
✘

15. #LRFRS2017
OSGi μServices
flickr.com/alexhealing
Separate processes do come with a benefit:
• full isolation
• easy scalability
OSGi Remote Services!
Two OSGi specifications:
• Remote Services
Transport
• Remote Service Admin
Topology, Service Discovery

16. #LRFRS2017
OSGi μServices
flickr.com/alexhealing
The best of both worlds?
• Independent deployment, iterative development
• Fault tolerant – but no full isolation
• No network latencies, reduced call stack
• More freedom to choose technology stack
• Less demanding for operations
• Established monitoring and deployment strategies

17. Thank you!daniel.reuther@liferay.com
https://github.com/danielreuther