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.

Microservices & OSGi - Better Together? - Graham Charters

662 views

Published on

OSGi Community Event 2016 Presentation by Graham Charters (IBM)

Since the 1960s the industry has been rediscovering the benefits of modularity. Modularity comes in many different guises, from small software objects to deployed systems. Although many approaches to modularity exhibit common characteristics, a number also have unique benefits. This talk will introduce the concepts of modularity, Microservices and OSGi, and compare Microservices and OSGi against a Modularity Maturity Model (a measure of modularity capability and completeness). It will describe how the similarity in characteristics between Microservices and OSGi make these technologies an ideal pairing. Finally, it will cover some of the standard technologies to choose for OSGi technology-based Microservices and new technologies on the horizon.

Published in: Technology
  • Be the first to comment

Microservices & OSGi - Better Together? - Graham Charters

  1. 1. © 2016 IBM Corporation Graham Charters Senior Technical Staff Member, WebSphere Application Server Microservices and OSGi: Better together?
  2. 2. 2Page© 2016 IBM Corporation Agenda – Introduction to Modularity, Microservices & OSGi – Comparison of OSGi and Microservice capabilities – Microservices challenges – OSGi smoothing the way to Microservices
  3. 3. 3Page© 2016 IBM Corporation What is Modularity – “Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.” – “A module interface expresses the elements that are provided and required by the module. …” https://en.wikipedia.org/wiki/Modular_programming Photo by: https://www.flickr.com/photos/zaxl4/ License: https://creativecommons.org/licenses/by-sa/2.0/
  4. 4. 4Page© 2016 IBM Corporation http://martinfowler.com/articles/microservices.html (25 March 2014) What are Microservices
  5. 5. 5Page© 2016 IBM Corporation http://martinfowler.com/articles/microservices.html Microservices are Modularity      
  6. 6. 6Page© 2016 IBM Corporation What is OSGi – Enables products to be assembled from Modules – Modules callable through Services – Modules and their Services have a dynamic lifecycle BundleBundle Bundle listen provideuse Service
  7. 7. 7Page© 2016 IBM Corporation Not all modularity is equal • Not all module technologies enable the same capabilities • Modularity Maturity Model provides a way to compare technologies and understand the benefits • Inspired by customer experiences adopting OSGi “Towards a Modularity Maturity Model”, OSGi Community Event 2011 presentation @ http://slidesha.re/q8EHFp
  8. 8. 8Page© 2016 IBM Corporation Modularity Levels Level Name Summary 1 Ad Hoc Nothing 2 Modules Formal identity, decoupled from artifact 3 Modularity Formal module contracts, decoupled from identity 4 Loose-Coupling Services, semantic versioning, decoupled from implementation 5 Devolution Modularity-aware repositories, collaboration, governance, decoupled from ownership 6 Dynamism Life-cycle awareness and independence, decoupled from time
  9. 9. 9Page© 2016 IBM Corporation What was it Lewis and Fowler said? Level Name Summary 1 Ad Hoc Nothing 2 Modules Formal identity 3 Modularity Formal module contracts 4 Loose-Coupling Services, semantic versioning, Componentization via Services 5 Devolution Modularity-aware repositories, collaboration, governance, Organized around Business Capabilities 6 Dynamism Life-cycle awareness and independence, Design for failure
  10. 10. 10Page© 2016 IBM Corporation Filling in the gaps Level Name Summary 1 Ad Hoc Nothing 2 Modules Formal identity, Deployable service (likely a build artefact) 3 Modularity Formal module contracts, Service Contracts – e.g. Swagger 4 Loose-Coupling Services, semantic versioning, Componentization via Services 5 Devolution Modularity-aware repositories, collaboration, governance, Organized around Business Capabilities 6 Dynamism Life-cycle awareness and independence, Design for failure
  11. 11. 11Page© 2016 IBM Corporation Didn’t you just tell us we don’t need OSGi? https://creativecommons.org/licenses/by-nd/2.0/ https://www.flickr.com/photos/40601656@N07/
  12. 12. 12Page© 2016 IBM Corporation The answer’s Microservices, what’s the question? https://www.gartner.com/doc/3371727/hype-cycle-application-services- ByJeremykempatEnglishWikipedia,CCBY-SA3.0, https://commons.wikimedia.org/w/index.php?curid=10547051 Gartner says we’re here Early publicity produces a number of success stories—often accompanied by scores of failures. Some companies take action; most don't. Peak of Inflated Expectations
  13. 13. 13Page© 2016 IBM Corporation Evolution, not revolution Martin Fowler: “As I hear stories about teams using a microservices architecture, I've noticed a common pattern. 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.” http://martinfowler.com/bliki/MonolithFirst.html
  14. 14. 14Page© 2016 IBM Corporation Design is still hard http://www.codingthearchitecture.com/2014/10/01/modularity_and_testability.html Simon Brown: “Technologies like Spring Boot make creating and deploying microservices relatively straightforward, but the design thinking behind partitioning a software system into services is still as hard as it's ever been.” http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths
  15. 15. 15Page© 2016 IBM Corporation Document your poop
  16. 16. 16Page© 2016 IBM Corporation The costs of Microservices http://martinfowler.com/articles/microservice-trade-offs.html
  17. 17. 17Page© 2016 IBM Corporation So should we or shouldn’t we do Microservices? https://creativecommons.org/licenses/by/2.0/ https://www.flickr.com/photos/sufferingsocrates/
  18. 18. 18Page© 2016 IBM Corporation Look before you leap https://www.flickr.com/photos/ggabernig/ https://creativecommons.org/licenses/by/2.0/
  19. 19. 19Page© 2016 IBM Corporation Monolith-first Martin Fowler: “As I hear stories about teams using a microservices architecture, I've noticed a common pattern. 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.” http://martinfowler.com/bliki/MonolithFirst.html
  20. 20. 20Page© 2016 IBM Corporation Design is still hard http://www.codingthearchitecture.com/2014/10/01/modularity_and_testability.html Technologies like Spring Boot make creating and deploying microservices relatively straightforward, but the design thinking behind partitioning a software system into services is still as hard as it's ever been. http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths
  21. 21. 21Page© 2016 IBM Corporation Boundaries Microservices’ main benefit, in my view, is enabling parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard – or at least harder – to do the wrong thing: Namely, connecting parts that shouldn’t be connected, and coupling those that need to be connected too tightly. In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely. http://martinfowler.com/articles/dont-start-monolith.html Don’t start with a monolith … when your goal is a microservices architecture Stefan Tilkov
  22. 22. 22Page© 2016 IBM Corporation Boundaries “Often the true consequences of your architectural decisions are only evident several years after you made them. We have seen projects where a good team, with a strong desire for modularity, has built a monolithic architecture that has decayed over the years. Many people believe that such decay is less likely with microservices, since the service boundaries are explicit and hard to patch around.” http://martinfowler.com/articles/microservices.html
  23. 23. 23Page© 2016 IBM Corporation The modular monolith If you can't build a modular monolith, what makes you think microservices are the answer? http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
  24. 24. 24Page© 2016 IBM Corporation Getting to there from here… https://creativecommons.org/licenses/by/2.0/ https://www.flickr.com/photos/pss/
  25. 25. 25Page© 2016 IBM Corporation Key questions What will help me create and maintain a modular monolith? What’s the closest you can get to the microservices qualities without incurring all of the associated cost? http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths
  26. 26. 26Page© 2016 IBM Corporation Refresher… – Enables products to be assembled from Modules – Modules callable through Services – Modules and their Services have a dynamic lifecycle BundleBundle Bundle listen provideuse Service
  27. 27. 27Page© 2016 IBM Corporation The Modular Monolith – Use OSGi to modularise your Product – Not just Business as Usual - organize around business capabilities, modularize your data, etc. – A number of approach have been documented. • Services-first • Java EE -> OSGi • Strangler Pattern – These are equally applicable to OSGi & Microservice discovery ED B F A C H G
  28. 28. 28Page© 2016 IBM Corporation Evolving to Microservices – Identify Feature ‘Subsystems’ as individually deployable units – Continue to deploy to same process ED B F A C H G
  29. 29. 29Page© 2016 IBM Corporation Isolate your Subsystems – Make ‘boundary services’ remotable – Enforce isolation using Application Subsytems – Handle service unavailability – Continue to deploy to same process ED B F A C H G G B
  30. 30. 30Page© 2016 IBM Corporation Deployment independently – Deploy as independently scalable microservices – Automate deployment – Prove out remoting, latency, etc. E D B F A C H G G B
  31. 31. 31Page© 2016 IBM Corporation Modular Monolith+
  32. 32. 32Page© 2016 IBM Corporation Modular Monolith+
  33. 33. 33Page© 2016 IBM Corporation Remoting Services – OSGi Remote Services & Remote Services Admin providers – Or pick a JAX-RS implementation – Future: JAX-RS Whiteboard (RFC 217) RS Impl RS Impl register proxy discover register endpoint JAX-RS endpoint JAX-RS proxy https://github.com/osgi/design/tree/master/rfcs/rfc0217
  34. 34. 34Page© 2016 IBM Corporation Technology choices – MicroProfile 1.0 defines a technology set for Java EE • JAX-RS, CDI, JSON-P – What would the OSGi equivalent be? • JAX-RS, Declarative Services, JSON-P – Beyond the core • Externalize configuration – Config Admin (think 12-factor)
  35. 35. 35Page© 2016 IBM Corporation Summary – Microservices are an important approach to producing highly-available, maintainable applications – Microservices are not for-free, introducing new costs, such as distribution and operational complexity – Modular monoliths are seen as an important stepping stone to being able to produce Microservices – OSGi is an ideal fit for producing modular monoliths, going well-beyond their core characteristics – The OSGi standards cover the core capabilities essential for producing first- class Java-based microservices

×