Migrating from Java EE to cloud-native Reactive systems

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.
  @myfear
• 3.
  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.
  http://www.internetlivestats.com/internet-users/ J2EE Spring RoR Akka Reactive Manifesto Microservices Which technologyto choose?
• 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