A lot of businesses that never before considered themselves as “technology companies” are now faced with digital modernization imperatives that force them to rethink their application and infrastructure architecture. On the path to becoming a digital, on-demand provider, development speed is the ultimate competitive advantage. https://info.lightbend.com/webinar-java-ee-to-cloud-modernization-register.html

1. Migrating From Java EE 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 the Fortune 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 Direction should 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 Java EE
Applications Still Suitable Today?

7. http://www.internetlivestats.com/internet-users/
J2EE
Spring
RoR
Akka
Reactive Manifesto
Microservices
Which technology to choose?

8. When Building a New 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 And The 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 ‘data in 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 obvious that the old,
linear, three-tier architecture model
is obsolete.
- Gartner
“

12. Monoliths Have Allowed Us 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,
Our Consistent 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 in monoliths
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 Towards Real-Time Streaming Systems

16. Design
distributed
systems and
Reactive
principles
• Message-driven means 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 lesson from 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 before thinking 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 streaming architecture 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 Systems Unlock Higher
Cloud ROI

21. 21
“Akka has consistently allowed 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 Product teams 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 with Lightbend

24. We enable Product teams 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 EE To 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 for architects 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 detailed example 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
Design Patterns
• 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
Markus Eisele
@myfear
blog.eisele.net