Download to read offline
Uploaded byMarkus Eisele
Migrating from Java EE to cloud-native Reactive systems
The document discusses the transition from Java EE to cloud-native reactive systems, emphasizing the challenges and requirements for modernizing applications. Key topics include the limitations of monolithic architectures, the need for microservices, and the importance of real-time data processing. It also highlights the benefits of reactive systems and provides resources for developers to adapt to new technologies.
Migrating from Java EE to cloud-native Reactive systems
- 1. Migrating From JavaEE To Cloud-Native Reactive Systems With Markus Eisele, Director of Developer Advocacy at Lightbend, Inc. WEBINAR | THURSDAY JUN 6TH, 9:00 AM PT / 12:00 ET / 16:00 GMT / 18:00 CET
- 2.
- 3.
- 4. 4 Java developers worldwide of theFortune 500 are using Java EE of companies use Java to build over 80% of their applications 10M+ 90% 43% Stability Specifications Availability of developers #1 #2 #3
- 5. What Technical Directionshould Java EE evolve into? Eclipse Foundation survey of over 1800 developers 5 Top 3 for building microservices include Jersey, Spring, Eclipse MicroProfile, Node.js & Kubernetes Currently building microservices or planning to <1 yr Say large memory requirements most challenging aspect of working with Java EE Java EE chosen for Java applications is stability Say Foundation should prioritize better support for microservices https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/ 67% Top Frameworks 1. Better support for microservices 2. Native integration with Kubernetes 3. A faster pace of innovation 40% #1 Reason 60% critical areas cited for improvement
- 6. But are JavaEE Applications Still Suitable Today?
- 7.
- 8. When Building aNew Business Application, Which Technology do You Use? Twitter survey on 5.16.19* 8 Other Reactive (e.g. Play) Microprofile (services) Jave EE (monolith) 17% 28% 30% 25% *962 respondents
- 9. Cloud Native AndThe Future Of Java EE Complexity kills development velocity and only fosters infrequent releases • Development team agility is constantly blocked. • Big teams and heavy apps create long release cycles. • Complex code bases and fearful engineers lead to technical debt. Scaling monoliths is too expensive for the cloud • Monoliths are difficult and expensive to scale. • Monoliths lead to resource inefficiency. 9
- 10. Streams and ‘datain motion’ need to be supported • Real-time streaming data is a first-class citizen in today’s applications. • Insights and value must be harvested from data. • Non-traditional data persistence models must be used. • Shortened time-frames for putting changes into production • New business models evolve from existing ones • New questions need to be answered by existing applications • Datacenter costs need to go down constantly 10
- 11. 11 It’s increasingly obviousthat the old, linear, three-tier architecture model is obsolete. - Gartner “
- 12. Monoliths Have AllowedUs to Take Consistency for Granted With a single database, the world is easy Transactions give us an illusion of a single, consistent, current state • We can think of our data as a static thing • It sits there at rest, waiting for our operation • Failure is handled • No partial updates • Consistency is enforced • Concurrency is handled • No uncommitted reads 12 Transaction 1 Transaction 2
- 13. With Distributed Applications, OurConsistent View of the World Breaks Down With many databases, the world is hard There are now many states, all constantly changing • Different services have different ideas of current state • Our data is in motion, not at rest, not static • Failure is not handled for us • Partial updates likely • No enforcement of consistency • Concurrency is inherent • Operations take time to propagate 13 G ? C ? F ? B ? E ? A ? D ?
- 14. What worked inmonoliths CRUD • Depends on consistent single state Relying on transactions • Depends on a single database REST • Depends on failure and consistency being handled in the database 14 Needed for distributed applications Events • Events convey facts • Facts remain true regardless of what else happens in the system At least once messaging • Ensures events can be reliably propagated throughout the system Stream-centric view • Our data is the events • Some may be at rest, some are in motion • No single state • Rather, system is constantly converging, propagating • Control this, using streams What Worked in Monoliths Will Not Work Anymore
- 15. The Shift TowardsReal-Time Streaming Systems
- 16. Design distributed systems and Reactive principles • Message-drivenmeans more than just non- blocking I/O. • Resilience goes further than fault tolerance. • Elasticity means efficient, cost-conscious scalability. • Responsive systems always serve customers.
- 17. Take a lessonfrom Events-First Domain Driven Design • Use encapsulation to improve flexibility. • Apply isolation to encourage loose coupling and avoid the cascade effect. • Separate domains of concern to reduce complexity. 17 Bounded Context Bounded Context Search Service Search Service Product Service Product Service Product Service Product Service Search Cache Product DB
- 18. Prioritize resilience beforethinking about elastic scaling in the cloud • Automate supervision to minimize human intervention. • Isolate and contain failures to enable self-healing. • Master resilience and elasticity to achieve system responsiveness. 18
- 19. Utilize a streamingarchitecture to achieve distribution, concurrency, supervision, and resilience 19 Kafka myTopic .subscribe() Akka Streams .map(kafkaMessage -> new WebSocketMessage( kafkaMessage.getPayload() ) ) WebSocket response .send(publisher) Reactive Streams Backpressure Reactive Streams Messages By modelling a system using streams, we embrace events, no longer need a single state, and can take eventual consistency for granted
- 20. Distributed, Reactive SystemsUnlock Higher Cloud ROI
- 21. 21 “Akka has consistentlyallowed us to cut 80% of infrastructure, or increase overall application performance by 5x, when compared to the traditional systems we replaced.” - Akara Sucharitakul, Principal MTS at PayPal “
- 22. We enable Productteams to: • Focus on the business logic, not low- level protocols. • Eliminate bottlenecks and single points of failure. • Realize true ROI from investing in cloud infrastructure. • Focus on what matters to your business. 22
- 23. Instant Advantages withLightbend
- 24. We enable Productteams to: • Enhancing customer engagement with data-driven insights • Unleashing innovation to protect or capture markets • Improving agility and time to value • Reducing compute costs while scaling elastically • Increasing developer happiness and productivity 24
- 25. From Java EETo Cloud Native: The End Of The Heavyweight Era How to modernize traditional Java EE applications for cloud-native infrastructure WHITE PAPER | BY MARKUS EISELE AND JAMES ROPER, LIGHTBEND INC. 28 http://bit.ly/JavaEE2CloudNative
- 26. Reactive Microservices Architecture 29 Written forarchitects and developers that must quickly gain a fundamental understanding of microservice-based architectures, this free O’Reilly report explores the journey from SOA to microservices, discusses approaches to dismantling your monolith, and reviews the key tenets of a Reactive microservice: • Isolate all the Things • Act Autonomously • Do One Thing, and Do It Well • Own Your State, Exclusively • Embrace Asynchronous Message-Passing • Stay Mobile, but Addressable • Collaborate as Systems to Solve Problems http://bit.ly/ReactiveMicroservice
- 27. Developing Reactive Microservices 30 The detailedexample in this report is based on Lagom, a new framework that helps you follow the requirements for building distributed, reactive systems. • Get an overview of the Reactive Programming model and basic requirements for developing reactive microservices • Learn how 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 technologies to start a successful migration away from legacy systems http://bit.ly/DevelopReactiveMicroservice
- 28. Modern Java EE DesignPatterns • Understand the challenges of starting a greenfield development vs tearing apart an existing brownfield application into services • Examine your business domain to see if microservices would be a good fit • Explore best 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 31 http://bit.ly/SustainableEnterprise
- 29. Thank You Page MarkusEisele @myfear blog.eisele.net