Embed Size (px)
Citation preview
Lean microserviceson OSGi
By Christian SchneiderOpen Source Architect at Talend
[email protected]@schneider_chris
Participate in Demo
Connect to irc network freenode
Channel #jbcnconf
Microservices...way of designing software applications as suites of independently deployable services.... organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. - Martin Fowler
● Create application out of independently deployable services● Verticals around business capabilities● Decentralized data● Automated deployment● 1 service per process● Lightweight communications between services (typically REST)
Spring boot● Framework for micro service development based on spring● Easy to start. Paste snippets of “starter” dependencies into pom● Convention over configuration● Good docker and cloud support
The Dark side of microservices
No, no, no. Quicker, easier, more seductive...
Are microservices stronger than OSGi?
Dependencies between microservices
OperationsContainer vessel - Application Server
Microservices operation - Theory
Microservices operation - Practice
Microservices can not cure bad design
Microservices with spring-boot…What is wrong with it?
● Lots of dependencies already at design time
● Microservices always must communicate remotely
● Proprietary Annotations / API● No flexibility in packaging
1 Microservice = 1 Deployment Unit = 1 Process
A small spring boot project
● Pollutes the classpath● Difficult to establish rules which APIs to use
90dependencies
20 MBjar file
Why is OSGi different?
● Coding against APIs and specs
● Self describing modules (bundles)
● OSGi services to communicate between bundles
● Semantic versioning
● Remote Service Admin for Remote calls and REST
● Flexible packaging
Semantic Versioning
● MAJOR version - incompatible API changes,● MINOR version - added functionality in a backwards-compatible manner● BUGFIX version - backwards-compatible bug fixes
Mind the difference between API and SPI.
Remote Service Admin
● Exports and imports OSGi services● Service Properties to mark for export and configure transports, …● Highly customizable (Policies, Transports, Serialization, Discovery)
Rest services with RSA
● Just JAX-RS annotations on interface
REST Endpoint User bundleHTTP
OSGi service
CXF Transport for Aries RSA
Creates
TopologyManager
Detects
Selectstransport
Lets see it in practice
Small chat application
● Modules talk to each other using an OSGi ChatListener interface described in API bundle
● IRC connector using camel● Shell integration using gogo● Tinkerforge Display and Motion
detector● Optional Remoting using Aries
RSA
Chat APIChat shell integrationTinkerforge LCD displayIRC Connector
IRC
All in one
● 1 Process● 6MB runnable jar● No remote calls inside application● Still modular as bundles only coupled
through API and OSGi service
Container vessel - OSGi deployment in one process
Chat APIIRC ConnectorAries RSA
IRC
Microservice Deployment
Chat APITinkerforge LCD and motion detectAries RSA
Chat APIChat shell integrationAries RSA
Zookeeper
Microservice Deployment
● Same bundles as before● As many deployment units as needed● Each deployment unit can scale● Runnable jars or docker containers● Cloud native if needed● Aries RSA overhead 300 KB + 800 KB zookeeper lib● Remote calls or local calls as needed● Many options for remotings (tcp, fastbin, SOAP, REST, JMS)
But beware of the same management issues as any other micro services
OSGi can scale from very small to very large
But no simple cure for the operational problems of microservices
Unsure if you actually need a microservice architecture?● Develop your application using modular bundles● Stay on single process as long as possible● Decide about the packaging and deployment as late as
possible● Deploy only as fine granular as needed
Further Reading
● Achim Nierbeck - Microservices on OSGi● Milen Dyankow - Microservices and
Modularity● OSGi Chat example code● Example for REST export using Aries RSA
and CXF
