Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

How would ESBs look like, if they were done today.

10 302 vues

Publié le

Looking past former hype topics such as enterprise application integration, ESBs, and SOA, the fact is that the need for reliable integration solutions that are manageable and scalable is growing. More devices and datasources, combined with new and upcoming use cases and exciting wearables in a cloudified and heterogeneous infrastructure, require more bits and pieces than just a central ESB with some rules and point-to-point connections. What would that look like? And how can we keep the resultant solutions manageable? Attend this session to find out.

Publié dans : Technologie
  • DOWNLOAD FULL. BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

How would ESBs look like, if they were done today.

  1. 1. 1 How would ESBs look like, if they were done today? Markus Eisele, @myfear Developer Advocate markus@jboss.org October, 2015
  2. 2. “What’s right isn’t always popular. What’s popular isn’t always right” Howard Cosell
  3. 3. Application Server Large Java EE / J2EE based applications Application Server EAR EAR EAR WAR JAR JAR JAR JAR JAR JAR WAR JAR JAR EAM <?> LoadBalancer
  4. 4. • Monolithic application – everything is package into a single .ear • Reuse primarily by sharing .jars • A “big” push to production once or twice a year • Single database schema for the entire application • >= 500k loc • >= Heavyweight Infrastructure • Thousands of Testcases • Barely New Testcases TechnicalImplications
  5. 5. 5 • >= 20 Team Member • The single .ear requiring a multi-month test cycle / • Huge bug and feature databases • User Acceptance Undefined • Technical Design Approach • Barely Business Components or Domains • Requiring multiple team involvement & significant oversight TeamandQAImplications
  6. 6. 6 • Still changing requirements. • New features tend to be HUGE! • Cross-cutting concerns nearly impossible to implement. Andevennow…
  7. 7. 7 Why?
  8. 8. 8 Technical Dept! We’re lazy! Inexperienced! No education! Outdated Infrastructure! We always did it like that. Outdated Designpattern? Grown application Outdated Runtimes!
  9. 9. 9 Where did we go from here?
  10. 10. 10 We treated everything as a legacy system and try to solve integration problems.
  11. 11. 11 ENTERPRISE! CENTRALIZE! STANDARDS! LICENSES! INTEGRATION? Enterprise Service Bus Orchestration
  12. 12. 12 • Still very large codebases • Overloaded IDEs • Hard to understand and modify • Hard to test • Complex dependencies • Small Changes generate big Impact • Difficult to scale • Mostly not rewritten but “re-wired” • Data Segmentation not defined • Scaling difficult TechnicalImplications
  13. 13. 13 Hmmm … and where are we today?
  14. 14. 14
  15. 15. 15 Name it whatever you like.
  16. 16. 16 We’re decomposing monoliths and evolve them into microservices architectures.
  17. 17. 17 Reduce Impact of Change by Encapsulating Source of Change http://martinfowler.com/articles/microservices.html
  18. 18. 18 How to find the Right Services?
  19. 19. 19 Domain Driven Design Bounded contexts Designed For Automation Designed for Failure Independently Deployable FromScratch
  20. 20. 20 Verb or Use Case e.g. Checkout UI Noun e.g. Catalog product service Single Responsible Principle e.g. Unix utilities EvolutionFromExisting
  21. 21. 21 What did ESBs do?
  22. 22. 22 • Monitor and control routing of message exchange between services • Resolve contention between communicating service components • Control deployment and versioning of services • Marshal use of redundant services • Cater for commodity services like • event handling, • data transformation and mapping, • message and event queuing and sequencing, • security or exception handling, • protocol conversion and • enforcing proper quality of communication service
  23. 23. 23 Let’s deconstruct the $hit.
  24. 24. 24 ”Monitor and control routing of message exchange between services”
  25. 25. 25 • Not really anymore. • “Services do one thing well” • Bunch of different approaches to service design and interaction. • No centralized point of “control”
  26. 26. 26 Aggregator Pattern w or w/o Proxy Chained Pattern Branch Pattern …..
  27. 27. 27 ”Resolve contention between communicating service components”
  28. 28. 28 “Smart endpoints and dumb pipes” - Martin Fowler http://martinfowler.com/articles/microservices.html
  29. 29. 29 “Control deployment and versioning of services”
  30. 30. 30 - Deployment - Configuration - Profiles / App Packaging - Service Discovery - Versions - Monitoring - Governance
  31. 31. 31 “Marshal use of redundant services”
  32. 32. 32 “Decentralized Governance” - Martin Fowler http://martinfowler.com/articles/microservices.html#DecentralizedGovernanc e
  33. 33. 33 “Cater for commodity services”
  34. 34. 34 • a lightweight service runtime • Cross – Service Security • Transaction Management • Service Scaling • Load Balancing • Deployment • Configuration • Profiles / App Packaging • Service Discovery • Versions • Monitoring • Governance • Failure Handling • Asynchronous vs. Synchronous • Cross – Service Logging • ...
  35. 35. 35 An approach.
  36. 36. 36 Container Container Load Balancer ServiceAA DBClient Cache APIGateway Security Service Registry ContainerContainer Apossiblesolution...
  37. 37. 37 The Pieces
  38. 38. 38 http://undertow.io/
  39. 39. 39 http://www.apiman.io/
  40. 40. 40
  41. 41. 41
  42. 42. 42 • Implemented with Docker and Kubernetes • Use any JVM (or any technology) • Docker images, encourage static, well- defined, well-tested deployments • Provides networking, JVM isolation, orchestration, auto-scaling, health checks, cloud deployments • Still in community! • Supports OpenShift v3 Fabric8 V2
  43. 43. 43 And keep in mind….
  44. 44. 44  Operations and development are skills, not roles. Delivery teams are composed of people with all the necessary skills.  Delivery teams run software products - not projects - that run from inception to retirement DevOps .. Is a culture.
  45. 45. 45 Let’s take one step at a time and not solve everything at once. aka “Evolutionary Design”
  46. 46. 46 Easy As That?
  47. 47. 47 • No silver bullet; distributed systems are *hard* • Dependency hell, custom shared libraries • Fragmented and inconsistent management • Team communication challenges • Health checking, monitoring, liveness • Over architecting, performance concerns, things spiraling out of control fast WARNING: Challenges ahead!
  48. 48. 48  Complex Runtime: many moving parts  Distributed Systems are inherently complex  Services are deployed on multiple instances  Decentralized Data (Distributed Transactions vs eventual consistency)  Communication between services (Network and Configuration)  Synchronous vs. Asynchronous vs. Messaging Communication  Communication overhead (n2n)  Failure Handling (Circuit Breaker)  Service-/Metadata Registry WARNING: Challenges ahead!
  49. 49. 49 ? Load Balancing API Management Configuration Deployment Monitoring SecurityGovernance Nodes Cartridges Versions Patches Changes
  50. 50. 50 And this is only the beginning... The industry is still learning a lot.
  51. 51. 51
  52. 52. 52 Correct functional decomposition is crucial for microservices: • pretty hard to get right from the start • a modular system can evolve to microservices • balance the needs with the costs • work on it evolutionary Takeaway:
  53. 53. 53 Are they here to stay?
  54. 54. 54 Nobody knows.
  55. 55. 55 Take with you today:
  56. 56. 56 • There is no single successor to ESBs. • The whole turned into pieces. • We’re still evolving them.
  57. 57. 57 http://bit.ly/virtualJBUG @vJBUG
  58. 58. 58 http://developers.redhat.com/promotions/distributed-javaee-architecture
  59. 59. 59
  60. 60. 61 http://www.lordofthejars.com/2014/07/rxjava-java8-java-ee-7-arquillian-bliss.html http://www.lordofthejars.com/2014/09/defend-your-application-with-hystrix.html http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html http://martinfowler.com/articles/microservices.html http://microservices.io/patterns/microservices.html http://techblog.netflix.com/2013/01/optimizing-netflix-api.html http://www.infoq.com/articles/microservices-intro https://sites.google.com/a/jezhumble.net/devops-manifesto/

×