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.

Modular Architectures using Micro Services

When building and maintaining large applications in a world that is rapidly evolving, keeping up with changing requirements and non-functionals over time is a huge challenge. Architecting your application in a modular way and loosely coupling modules using micro services provides you with a nicely decoupled system that still works very efficiently. Designing, evolving and versioning a micro service architecture is not easy, and over time, several design patterns and best practices have evolved that help you. Code examples can be found here: https://bitbucket.org/marrs/javaone-2014-microservices

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Modular Architectures using Micro Services

  1. 1. Modular Architectures using Micro Services
  2. 2. About Me Marcel Offermans Director at Luminis Technologies Member at the Apache Software Foundation @m4rr5
  3. 3. Agenda • Modular Architectures • Micro Services • OSGi in 60 seconds • Amdatu • Demo
  4. 4. Modular Architectures
  5. 5. The case for modularity
  6. 6. Maintainability
  7. 7. Adaptability
  8. 8. Quest for Reuse Copy / Paste
  9. 9. Quest for Reuse Object Oriented
  10. 10. Quest for Reuse Component Based
  11. 11. Micro Services
  12. 12. The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. Source: http://martinfowler.com/articles/microservices.html
  13. 13. Business Capabilities • Should be leading when splitting an application into components • Different from more traditional technology driven “layering” (UI, application logic, database) Conway’s Law: Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. ! Melvyn Conway, 1967
  14. 14. Component owns Data • Each service manages its own data • Can lead to polyglot persistence • Leverage Domain-Driven Design: bounded context often maps naturally to components • Use transaction-less coordination between services: build for eventual consistency and have a reversal process to deal with mistakes
  15. 15. Products • Make the team responsible for the whole life cycle of a product or component • Brings developers closer to the customers Amazon:”You build it, you run it!”
  16. 16. Services • Provide a public, versioned contract for a component • Have their own life cycle, so they can be separately deployed • Hide all implementation details
  17. 17. Dumb Pipes • HTTP request/response • lightweight messaging
  18. 18. Decentralized • Services decouple and abstract away components, leaving us free to choose implementation languages • Less focus on formal standards, more on proven, open source technology
  19. 19. Automated Deployment • Continuous Integration • Continuous Deployment
  20. 20. Design for Change • How to break a system into components? Consider rate of change, high cohesion, low coupling, … • Version your services, and make them tolerant to change • Stay flexible! The only constant is change.
  21. 21. Design for Failure • Applications need to be able to deal with failures • Services can always fail or become unavailable • Monitoring is an important aspect Netflix: Chaos Monkey to introduce random instance failures Michael Jordan: I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.
  22. 22. OSGi in 60 seconds
  23. 23. What is OSGi? • Provides components that can be easily deployed and versioned • Hides implementation details and leverages a service registry that allows components to publish and consume services • It’s the de-facto module system for Java: proven technology, works on all Java versions, usable from embedded to enterprise
  24. 24. OSGi META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Bundle-Activator: store.fs.osgi.Activator Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1, 2)"
  25. 25. META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Bundle-Activator: store.fs.osgi.Activator Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1, 2)" class Activator implements BundleActivator { ServiceRegistration sr; public void start(BundleContext bc) { sr = bc.registerService(Store.class.getName(), new StoreImpl(), null); } public void stop(BundleContext bc) { sr.unregister(); } } OSGi
  26. 26. OSGi META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Bundle-Activator: store.fs.osgi.Activator Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1, 2)" class Activator implements BundleActivator { ServiceRegistration sr; public void start(BundleContext bc) { sr = bc.registerService(Store.class.getName(), new StoreImpl(), null); } public void stop(BundleContext bc) { sr.unregister(); } }
  27. 27. OSGi META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1, 2)" class Activator implements BundleActivator { ServiceRegistration sr; public void start(BundleContext bc) { sr = bc.registerService(Store.class.getName(), new StoreImpl(), null); } public void stop(BundleContext bc) { sr.unregister(); } } bundles resolver store;version="2.5" Bundle-Activator: store.fs.osgi.Activator
  28. 28. OSGi META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1,2)" 1, 2)" class Activator implements BundleActivator { ServiceRegistration sr; public void start(BundleContext bc) { sr = bc.registerService(Store.class.getName(), new StoreImpl(), null); } public void stop(BundleContext bc) { sr.unregister(); } } bundles META-INF/MANIFEST.MF org/foo/log/Log.class org/foo/log/syslog/SysLogImpl.class org/foo/log/syslog/Activator.class store;version="2.5" org.foo.log;version="1.3" resolver Bundle-Activator: store.fs.osgi.Activator
  29. 29. OSGi META-INF/MANIFEST.MF Bundle-SymbolicName: store.fs store/Store.class store/Key.class store/fs/StoreImpl.class store/fs/FileSystem.class store/fs/StreamUtil.class store/fs/osgi/Activator.class lib/fsutil.jar Bundle-Version: 1.0.2 Bundle-Classpath: ., lib/fsutil.jar Export-Package: store;version="2.5" Import-Package: org.foo.log;version="[1,2)" 1, 2)" class Activator implements BundleActivator { ServiceRegistration sr; public void start(BundleContext bc) { sr = bc.registerService(Store.class.getName(), new StoreImpl(), null); } public void stop(BundleContext bc) { sr.unregister(); } } service registry bundles META-INF/MANIFEST.MF org/foo/log/Log.class org/foo/log/syslog/SysLogImpl.class org/foo/log/syslog/Activator.class store;version="2.5" org.foo.log;version="1.3" resolver store.Store { service.id = 1 } Bundle-Activator: store.fs.osgi.Activator
  30. 30. Remoting service registry OSGi framework java virtual machine bundle bundle bundle service registry bundle bundle OSGi framework java virtual machine service registry bundle OSGi framework bundle bundle java virtual machine bundle
  31. 31. Amdatu
  32. 32. What is Amdatu? Amdatu is an open source community effort focussed on bringing OSGi to the cloud. It contains components to create RESTful, scalable and distributed web applications that use NoSQL data stores, transparent multi-tenancy and much more.
  33. 33. Development Model • Modular design based on OSGi • Fast deployment using Bndtools • Git fork/merge based workflow • Extensive Atlassian tool support • Apache ACE integrated with build servers • Gradle based build
  34. 34. Demo
  35. 35. Wrapping Up
  36. 36. We’ve… • …explored modularity and micro services • …introduced OSGi and Amdatu • …seen how to develop and run a modular application • …seen how OSGi allows you to be flexible in how you group and deploy components
  37. 37. Eclipse OSGi plugin! http://bndtools.org/ ! Provisioning Server! http://ace.apache.org/! Cloud OSGi services! http://www.amdatu.org/ That’s us! http://luminis-technologies.com/ Demo code! https://bitbucket.org/marrs/javaone-2014-microservices/
  38. 38. Takk Grazie Thank! you Obrigado Mahalo Danke Dank U Merci Gracias

    Be the first to comment

    Login to see the comments

  • pbrada

    Oct. 1, 2014
  • ikysil

    Oct. 7, 2014
  • AchimNierbeck

    Nov. 24, 2014
  • delinfo1

    Feb. 3, 2015
  • fasoulas

    Mar. 22, 2015
  • LynFam

    Sep. 12, 2015
  • manners

    Feb. 17, 2016

When building and maintaining large applications in a world that is rapidly evolving, keeping up with changing requirements and non-functionals over time is a huge challenge. Architecting your application in a modular way and loosely coupling modules using micro services provides you with a nicely decoupled system that still works very efficiently. Designing, evolving and versioning a micro service architecture is not easy, and over time, several design patterns and best practices have evolved that help you. Code examples can be found here: https://bitbucket.org/marrs/javaone-2014-microservices

Views

Total views

2,219

On Slideshare

0

From embeds

0

Number of embeds

22

Actions

Downloads

47

Shares

0

Comments

0

Likes

7

×