Nine Neins - where Java EE will never take you
•
30 likes•12,465 views
Virtual JUG Session: http://www.meetup.com/virtualJUG/events/232052100/ 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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Nine Neins - where Java EE will never take you
Similar to Nine Neins - where Java EE will never take you (20)
More from Markus Eisele
More from Markus Eisele (11)
Recently uploaded
Recently uploaded (20)
Nine Neins - where Java EE will never take you
- 1. Nine “Neins” – Where Java EE will never take you. @myfear blog.eisele.net https://keybase.io/myfear
- 4. How did we get here?
- 8. 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
- 10. 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
- 11. “It’s increasingly obvious that the old, linear, three-tier architecture model is obsolete.” - Gartner
- 12. Modernization!
- 13. Module Module Module WebUI .JAR.JAR .JAR .JAR.JAR .JAR .JAR .JAR .JAR .JARBrowser RDBMS RDBMS RDBMS
- 14. Routing Module Tracking Module Order Module Tracker UIBrowser HistoryDB Order DB RoutesDB Tracker UI Tracker UI Browser Browser
- 15. 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
- 16. What does Java EE bring to the table?
- 17. JAX-RS JSON-P Web SocketServlet JSFEL JSP JSTL BeanValidation Interceptors CDI Concurrency JPA JTA EJB JMS Batch JCA Java EE 7 JavaMail
- 18. NINE “Neins”! Definition:a “Nein” is a lost benefit of a microservice based system.
- 19. 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
- 20. 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)
- 21. 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 http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009335.html
- 22. 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.
- 23. 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)
- 24. 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. http://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf
- 25. 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 http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf
- 26. 8) No outer architecture – while still calling it a platform • Monitoring • Distributed Logging • Security • Service discovery • Service locator • API versioning • Routing • …
- 27. 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
- 28. You can do it in this way, but then it sucks!
- 29. Possible Alternative: Reactive Application (Lagom, Akka, Play, Vert.x, …)
- 31. Reminder: Technology alone won’t solve all the new challenges
- 32. Software Design System Architecture Methodology and Organization Distributed Systems Theory Data Center Operating System
- 33. “Rules are for the obedience of fools and the guidance of wise men.” Generally attributed to Douglas Bader
- 34. 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 http://bit.ly/ReactiveMicroservice
- 35. 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 http://bit.ly/DevelopReactiveMicroservice
- 36. http://bit.ly/SustainableEnterprise • 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
- 41. •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 https://msdn.microsoft.com/en-us/library/jj554200.aspx