Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lean microservices using OSGi

Lean microservices using OSGi

Avatar for Christian Schneider

Christian Schneider

February 24, 2023

More Decks by Christian Schneider

Other Decks in Programming

Transcript

  1. 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)
  2. 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
  3. 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
  4. A small spring boot project • Pollutes the classpath •

    Difficult to establish rules which APIs to use 90 dependencies 20 MB jar file
  5. 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
  6. 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.
  7. Remote Service Admin • Exports and imports OSGi services •

    Service Properties to mark for export and configure transports, … • Highly customizable (Policies, Transports, Serialization, Discovery)
  8. Rest services with RSA • Just JAX-RS annotations on interface

    REST Endpoint User bundle HTTP OSGi service CXF Transport for Aries RSA Creates Topology Manager Detects Selects transport
  9. 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
  10. Chat API Chat shell integration Tinkerforge LCD display IRC 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
  11. Chat API IRC Connector Aries RSA IRC Microservice Deployment Chat

    API Tinkerforge LCD and motion detect Aries RSA Chat API Chat shell integration Aries RSA Zookeeper
  12. 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)
  13. OSGi can scale from very small to very large But

    no simple cure for the operational problems of microservices
  14. 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
  15. 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