Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scaling and Orchestrating Microservices with OSGi - N Bartlett

1,909 views

Published on

OSGi Community Event 2014

Published in: Technology
  • Be the first to comment

Scaling and Orchestrating Microservices with OSGi - N Bartlett

  1. 1. Scaling and Orchestrating Microservices with OSGi … OR: How to Write a Session Title That Will Get Your Talk Accepted at Any Conference Neil Bartlett — Paremus Ltd
  2. 2. OSGi is From the Future • Runtime resolve/assemble since 2005 • Software component repositories since 2003 • Continuous delivery since 1999 • Microservices since 1998 image credit: Sam Howzit (flickr.com/photos/aloha75/)
  3. 3. “The term ‘microservice’ was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring.” — Martin Fowler, March 2014 http://martinfowler.com/articles/microservices.html
  4. 4. “MICROSERVICES” YOU KEEP USING THAT WORD. I DO NOT THINK IT MEANS WHAT YOU THINK IT MEANS.
  5. 5. “What I am promoting is the idea of μServices, the concepts of an OSGi service as a design primitive.” — Peter Kriens, March 2010 http://blog.osgi.org/2010/03/services.html
  6. 6. API api api api Service Consumer Provider
  7. 7. “Fowler” Microservices OSGi Services “an approach to developing a single application as a suite of small services" ✔ “each running in its own process” ✘ “communicating with lightweight mechanisms” ✔ “built around business capabilities” ✔ “independently deployable by fully automated deployment machinery” ✔ “bare mininum of centralized management of these services” ✔ “may be written in different programming languages” ✔* “use different data storage technologies” ✔ * JVM languages only, for now
  8. 8. Why Separate Processes? • “One main reason … is that services are independently deployable.” … like OSGi Bundles • “you can expect many single service changes to only require that service to be redeployed.” … like OSGi Bundles • “Another consequence of using services as components is a more explicit component interface.” … like OSGi Services • “Often it's only documentation and discipline that prevents clients breaking a component's encapsulation.” … whereas OSGi enforces encapsulation
  9. 9. Isolation is a Continuum COST Java Classpath OSGi Services OS Process Docker VM Physical Box Data Centre local minima (sweet spots) ← Weaker ISOLATION Stronger →
  10. 10. Java OSGi Process Docker VM Physical Box Data Centre Services and Reuse Crash Isolation, Alternate Langs CPU/Mem Quotas Alternate OS Power Fail, Whole OS Crash Disaster Resilience
  11. 11. Scaling
  12. 12. Horizontal Process Process Process
  13. 13. Horizontal Process Process Process
  14. 14. When to Scale? • Q: “Should I expose this as a service for scaleability?” • Agilist Answer: “No… YAGNI*” *You Aren’t Gonna Need It
  15. 15. When to Scale (OSGi Style) Provider Consumer Config Switch Provider Consumer
  16. 16. OSGi Remote Services • Services can be selected for remoting post facto. • Small code change or pure config change. • Respond to rapidly changing demand. • TGTBT? In practice, devs should at least factor in the possibility of remoting.
  17. 17. Demo
  18. 18. Orchestrating
  19. 19. What Should I Run?? Where Should I Run It?? Where Is Everybody??
  20. 20. Local Discovery (Easy) Process Process Process
  21. 21. Remote Discovery (Hrrrmm) Process Process ?
  22. 22. State of the Art • Install X on this box, install Y on that box, etc… • Tell X where Y is (static config) • Tell Y where X is (static config)
  23. 23. OSGi RSA Discovery • Advertise / Discover using Pluggable Impls • E.g.: Bonjour, SLP, DDS, Gossip, ZooKeeper… • Dynamic Availability / Presence • Plug and Play!
  24. 24. Even for Non-Services… REST Provider Consumer Endpoint uri=http://<host>:<port>/<alias> HTTP Comunication
  25. 25. Even for Non-Java Services Mosquitto Packager Consumer Endpoint uri=mqtt://<host>:<port> MQTT Mosquitto (MQTT) Process
  26. 26. … and Non-Java Consumers REST Provider REST Provider NGinx Packager uri=http://<host>:<port>/<alias> NGinx Process REST Provider
  27. 27. Oh, and Docker Mosquitto Packager Consumer uri=mqtt://<host>:<port> MQTT Mosquitto (MQTT) Container Prosyst mPRM See: OSGi Alliance IoT Demo and Hackathon Packager Prosyst mPRM Container uri=mprm://<host>:<port> version=5.3.0 mPRM (custom HTTP)
  28. 28. What, Where, How Many? • OSGi Capabilities and Requirements — a generic software pattern. • Use to describe native executables, Docker images… • Machine capabilities define “where” • Policy defines “how many”.
  29. 29. Demo
  30. 30. Technology Used • Paremus RSA — implementation of OSGi Remote Services Admin specification • Paremus Packager — open source API • Paremus Service Fabric — secret sauce ;-)
  31. 31. Questions?

×