Lean microservices on OSGi

  • View
    1.437

  • Download
    0

  • Category

    Software

Preview:

Citation preview

Lean microserviceson OSGi

By Christian SchneiderOpen Source Architect at Talend

chris@die-schneider.net@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

Recommended