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.

Nine Neins - where Java EE will never take you


Published on

Virtual JUG Session:

With Microservices taking the software industry by storm, classical Enterprises are forced to re-think what they’ve been doing for almost a decade. It’s not the first time, that technology shocked the well-oiled machine to it’s core. We’ve seen software design paradigms changing over time and also project management methodologies evolving. Old hands might see this as another wave that will gently find it’s way to the shore of daily business. But this time it looks like the influence is bigger than anything we’ve seen before. And the interesting part is, that microservices aren’t new from the core. Talking about compartmentalization and introducing modules belongs to the core skills of architects. Our industry also learned about how to couple services and build them around organizational capabilities.

The really new part in microservices based architectures is the way how truly independent services are distributed and connected back together. Building an individual service is easy with all technologies. Building a system out of many is the real challenge because it introduces us to the problem space of distributed systems. And the difference to classical, centralized infrastructures couldn’t be bigger. There are very little concepts from the old world which still fit into a modern architecture.
And there are more differences between Java EE and distributed and reactive systems. For example, APIs are inherently synchronous, so most Java EE app servers have to scale by adding thread pools as so many things are blocking on I/O (remote JDBC calls, JTA calls, JNDI look ups, even JMS has a lot of synchronous parts). As we know adding thread pools doesn't get you too far in terms of scalability.

This talk is going to explore the nine most important differences between classical middleware and distributed, reactive microservices architectures and explains in which cases the distributed approach takes you, where Java EE never would.

Published in: Technology
  • Be the first to comment

Nine Neins - where Java EE will never take you

  1. 1. Nine “Neins” – Where Java EE will never take you. @myfear
  2. 2. Disclaimer
  3. 3. How did we get here?
  4. 4. Classical Architectures?
  5. 5. Application Server EAR - Enterprise Archive RESTMobile Web UI .JAR.JAR .JAR .JAR.JAR .JAR .JAR .JAR .JAR .JAR Browser RDBMS
  6. 6. Application Server Application Server Application Server EAR - Enterprise Archive RESTMobile Web UI .JAR.JAR .JAR .JAR.JAR .JAR .JAR .JAR .JAR .JAR Browser RDBMS
  7. 7. LL: Building and Scaling Monoliths • Monolithicapplication –everything is package into a single .ear • Reuse primarily by sharing .jars • A “big” pushto productiononce or twice a year • Single database schema for the entire application • >= 500k loc • >= Heavyweight Infrastructure • ThousandsofTestcases • Barely New Testcases • >= 20 Team Member • The single.ear requiringa multi-month test cycle / • Huge bug and featuredatabases • User Acceptance Undefined • Technical Design Approach • Barely BusinessComponentsor Domains • Requiringmultiple team involvement & significant oversight • Technical Dept • Outdated Runtimes (Licenses,Complex updates) • Grown applications
  8. 8. More users J2EE Spring RoR Akka Reactive Manifesto Microservices
  9. 9. New requirements • Rather than acting ondata at rest, modern software increasingly operates ondata in near real-time. • Shortenedtime-frames for putting changes into production • New business models evolve from existing ones • New questions need to be answered by existing applications • Datacenter costs needto go down constantly
  10. 10. “It’s increasingly obvious that the old, linear, three-tier architecture model is obsolete.” - Gartner
  11. 11. Modernization!
  12. 12. Module Module Module WebUI .JAR.JAR .JAR .JAR.JAR .JAR .JAR .JAR .JAR .JARBrowser RDBMS RDBMS RDBMS
  13. 13. Routing Module Tracking Module Order Module Tracker UIBrowser HistoryDB Order DB RoutesDB Tracker UI Tracker UI Browser Browser
  14. 14. REQ: Building and Scaling Microservices • Lightweight runtime • Cross– Service Security • TransactionManagement • Service Scaling • Load Balancing • SLA’s • Flexible Deployment • Configuration • Service Discovery • Service Versions • Monitoring • Governance • Asynchronouscommunication • Non-blocking I/O • Streaming Data • Polyglot Services • Modularity (Servicedefinition) • High performancepersistence(CQRS) • Event handling / messaging (ES) • Eventual consistency • API Management • Health check and recovery
  15. 15. What does Java EE bring to the table?
  16. 16. JAX-RS JSON-P Web SocketServlet JSFEL JSP JSTL BeanValidation Interceptors CDI Concurrency JPA JTA EJB JMS Batch JCA Java EE 7 JavaMail
  17. 17. NINE “Neins”! Definition:a “Nein” is a lost benefit of a microservice based system.
  18. 18. 1) Java EE helps building distributed monoliths • 100s of libraries are part of the base platform • Upgrading individual libraries partly impossible (e.g. RIs) • Requires client libraries (e.g. JAX-RS and JMS) <= logic drifts into the client. • Doesn’t support other languages and can’t really embrace the polyglot approach to microservices • No independent technical evolution in teams because of the common base platform
  19. 19. 2) Java EE has a threading-model that isn’t ideal for microservices • Request to thread binding. • Can’t be scaled to thousands of servers easily. • Responsiveness isn’t build in from the core. • Clustering isn’t part of the specification and relies on vendor specific features. • No standardized asynchronous approach for endpoints (e.g. JAX-RS, JAX-WS)
  20. 20. 3) Java EE doesn’t support the notion of data in motion (streams) • JDBC and JPA block on Socket I/O • important methods are synchronized, thereby allowing onlyone queryat a time on one connection. • Batch processing as default way to handle bulk updates. • Not even Java 8 Lambdas usable because Fork/Join and Concurrency Utilities doesn’t play nicely together in a managed environment
  21. 21. 4) Java EE doesn’t support resiliency • No notion of replication, containment, isolation or delegation. • With the exception of vendor specific features (which require clustering) • Failures are propagated and not contained • One component failure usuallybrings down the complete application • No support for bulkheading. Clients have to handle failures.
  22. 22. 5) Java EE is implementedas containers – no service elasticity • Containerless development impossible • Testing is hard (Arquillian makes it bearable) • No simple development models • Compile, Build,Deploy – cycles for every microservice • No class-reloading (unless you use AMAZING tools like JRebel :-D) • No increasing or decreasing of resources under various workloads.(Back-pressure) • With the exception of vendor specific features (which require clustering)
  23. 23. 6) No notion of immutability • Handling of large amounts of data within distributed systems requires immutability for data • Immutable services are the new paradigm in load balancing, high availability, and dynamic resource sharing. • JPA works well with RDBMS • CQRS and Event-Sourcing work well with immutable data-structures and are beneficial for microservices.
  24. 24. 7) Choice of data stores, use of transactions and eventual consistency • No NoSQL support in Java EE • Polyglot persistence onlypossible in very few frameworks. • Heavily embracing distributed transactions with 2PC. • Eventual consistencyis ignored and discouraged
  25. 25. 8) No outer architecture – while still calling it a platform • Monitoring • Distributed Logging • Security • Service discovery • Service locator • API versioning • Routing • …
  26. 26. 9) Java EE doesn’t know services • No service component model • No service templates • Hardly any endpoint documentation (WSDLs) • No service boundaries • No way to enforce decoupling
  27. 27. You can do it in this way, but then it sucks!
  28. 28. Possible Alternative: Reactive Application (Lagom, Akka, Play, Vert.x, …)
  29. 29.
  30. 30. Reminder: Technology alone won’t solve all the new challenges
  31. 31. Software Design System Architecture Methodology and Organization Distributed Systems Theory Data Center Operating System
  32. 32. “Rules are for the obedience of fools and the guidance of wise men.” Generally attributed to Douglas Bader
  33. 33. Written for architects and developersthat must quickly gain a fundamental understandingof microservice-basedarchitectures, this freeO’Reilly reportexploresthe journey fromSOAto microservices,discussesapproachesto dismantling your monolith,and reviews the key tenets ofa Reactive microservice: • Isolate all the Things • Act Autonomously • Do OneThing, and Do It Well • Own Your State, Exclusively • Embrace AsynchronousMessage-Passing • Stay Mobile,but Addressable • Collaborate as Systems to Solve Problems
  34. 34. The detailed example inthis reportis based on Lagom, a new frameworkthat helps you follow the requirementsfor buildingdistributed,reactive systems. • Get an overview of the Reactive Programming model and basic requirementsfor developing reactive microservices • Learnhow to create base services, expose endpoints,and then connect them with a simple, web-based user interface • Understand how to deal with persistence,state, and clients • Use integration technologiesto start a successfulmigration away fromlegacy systems
  35. 35. • Understand thechallenges ofstartinga greenfield development vs tearingapart an existing brownfield application into services • Examine your business domain to see if microservices would bea good fit • Explorebest practices for automation,high availability, data separation,and performance • Align your development teams around business capabilities and responsibilities • Inspect design patterns such as aggregator, proxy, pipeline, or shared resources to model service interactions
  36. 36.
  37. 37. Links and further reading
  38. 38. Project Site: GitHub Repo: Documentation: Cargo Tracker Example:
  39. 39. •Keep all data in memory! • Store all state changes as events • Replay all events of an actor to recreate it • Strong consistencyfor Actor (aggregate) and Journal • Eventual Consistencyfor Read Side
  40. 40.