Vip Call Girls Noida ➡️ Delhi ➡️ 9999965857 No Advance 24HRS Live
Microservices: The OSGi way A different vision on microservices
1. Microservices: The OSGi way
A different vision on microservices
!
Miguel Ángel Pastor Olivar
Senior Software Engineer
2. About me
Who am I?
!
• Just a random guy
!
• Member of the Liferay core infrastructure team
!
• Email: miguel.pastor@liferay.com
!
• @miguelinlas3
#LRNAS2014
3. Synopsis
What are we going to talk about?
!
• Traditional approaches for development and deployment
!
• Micro services: demystifying it!
!
• An OSGi based vision of it
!
• How does it relate to Liferay?
!
• Questions (and hopefully answers)
#LRNAS2014
5. The monolith
#LRNAS2014
Web Browser
Relational Database
App Server
Load Balancer
UI
Business Services
Domain Model
War File
Mobile
Device
6. The monolith
Benefits
!
• Easier to develop
!
• Simple to deploy
!
• Simple to scale
!
• Works well for small applications
#LRNAS2014
7. The monolith
Drawbacks
!
• Unwieldy for big and complex applications
!
• Hard to understand, maintain and reason about
!
– Hard to get up to speed
!
• Complex “continuous deployment” scenarios
!
– Deploy the whole entity on every change
!
• Extremely hard to try/adopt new technologies/architectures
#LRNAS2014
8. The monolith
Drawbacks
!
• Scaling can become difficult
!
– Only one dimension scaling
!
• Scaling development teams
!
– Hard to focus teams and efforts
#LRNAS2014
12. The scale cube
X-Axis scaling
!
• Multiple copies running behind a load balancer
!
• Ideally, each copy handles 1/N of the load
!
• Great way to improve capacity and availability
!
• Common approach to scaling
#LRNAS2014
13. The scale cube
Server 1
#LRNAS2014
X-Axis scaling
Load Balancer
Web Browser
Mobile
Device
Server N
1/N
1/N
15. The scale cube
Z-Axis scaling
!
• Each server runs and identical copy of the code
!
– Similar to X-axis scaling
!
• But each server is in charge of a subset of the data
!
• We need smarter routing
!
• We can apply the similar concepts to applications
!
• Sharding, SLA, …
#LRNAS2014
16. The scale cube
#LRNAS2014
Load Balancer
Web Browser
Mobile
Device
SLA 99.99%
Y-Axis scaling
Server 1 Server 2
Server 4 Server 3
Server 1 Server 2
Server 4 Server 3
SLA 99%
17. The scale cube
Z-Axis scaling: Benefits
!
• Each server deals with a subset of the data
!
• Cache and memory usage are improved
!
• I/O traffic is reduced
!
• Transaction scalability is improved
!
• Improved fault isolation
#LRNAS2014
18. The scale cube
Z-Axis scaling: Drawbacks
!
• Application complexity increases
!
• Partitioning scheme needs to be implemented
!
• Doesn’t solve the problems of increasing development and
application complexity
#LRNAS2014
20. The scale cube
Y-Axis scaling
!
• Functional decomposition
!
• Each service is in charge of 1 (or multiple) tightly related
functions
!
• No golden rule
!
– Verb based decomposition
!
– Entity/resources related operations
#LRNAS2014
21. The scale cube
#LRNAS2014
UI
Business Services
War File
Business Services
Business Services
UI
UI
Business Services
22. The scale cube
Y-Axis scaling: Benefits
!
• Each service is reasonably small
!
• Faster startup
!
• Independent scaling
!
– X-axis or Y-axis scaling on every single service
!
• Fault isolation improvements
!
• Breakage with long term tech commitments
#LRNAS2014
23.
24. The scale cube
Y-Axis scaling: drawbacks
!
• Distributed systems are hard!!
!
• Really really hard!!
!
• Interprocess communication
!
• Operational complexity introduced
!
• Stronger coordination among teams
!
• Not suitable for everybody
#LRNAS2014
26. Communications: Gateway pattern
Browser
#LRNAS2014
Business Services
War File
Business Services
Business Services
Mobile Device
Business Services
API Gateway
27. Gateway API
Gateway API
!
• API tailored client
!
• Encapsulation
!
• Composition
!
• Different evolution
#LRNAS2014
29. Interprocess communications
Synchronous RPC
!
• REST or SOAP
!
• Both are “simple?” and familiar
!
• Firewall friendly
!
• Discovery service (Zookeeper, Etcd, …)
!
• IMHO, there is better options than HTTP
#LRNAS2014
30. Interprocess communications
Asynchronous messaging
!
• “AMQP like” message broker
!
• Decouple producers from consumers
!
• New element to deploy and manage (the message broker)
!
• Actor model?
#LRNAS2014
32. Data management
Decentralized data management
!
• Each service, potentially, could have its own database
!
• Even different types of databases (SQL, NoSQL, …)
!
• Distributed transactions come into place :(
• 2PC, 3PC, …
!
• Event-driven asynchronous updates
!
• Different consistency model
#LRNAS2014
36. OSGi μServices
Features
!
• Run within the same JVM
!
• Highly dynamic
!
• Implemented within the Service registry
!
• Runtime lifecycle management
#LRNAS2014
39. Focused components
OSGi modules and services
!
• Modules allow us to hide implementations and decouple
!
• Use service layer to communicate each other
!
• They can be deployed independently
!
– For now we are talking about single JVM
!
• Modules/services can disappear at any point in time
– Highly dynamic
!
– Closely related to distribution (more details later on)
#LRNAS2014
41. Fault isolation
Not real fault isolation
!
• We get independent deployments through bundles
!
• Living within the same JVM. No real fault isolation
!
• A service could consume the whole CPU/memory or
saturates the network
!
• Some research work on multi tenant JVM by IBM
#LRNAS2014
43. Tech commitment
Partial breakage with long tech commitments
!
• We already have isolated and highly focused pieces
!
• Communication is done through services
!
• Some nice JVM based alternatives: Scala, Clojure, Groovy,
…
!
• Cannot use a completely different tech: Erlang, Go, …
#LRNAS2014
45. Missing pieces
We are still missing …
!
• Independent scaling of every service
!
• Real isolation
!
• Solutions to the previous problems
!
• Process (JVM)
!
• Linux Containers (Solaris Zones, …)
!
• Distribution
#LRNAS2014
46. Missing pieces
A typical approach
!
• Deploy your app in a different machine/container/process
!
• Communicate them using your preferred approach
!
• REST
!
• ZeroMQ
!
• AMQP
#LRNAS2014
47. Missing pieces
OSGi Remote Services
!
• Near transparent extension to the Services model
!
• No explicit infrastructure API in user land
!
• Non mandatory technology (HTTP, JMS, RMI, …)
!
• Two OSGi specifications
!
• Remote Services: mechanics of transport
!
• Remote Service Admin: topology, service discovery
#LRNAS2014
65. Liferay
Can we apply this to Liferay?
!
• OSGi as one of the core techs of the product
!
• Split the product into small and independent focused
components/services
!
• Independent deployments
• Still within the same JVM
!
• Focused teams and efforts
#LRNAS2014
