With the ascent of DevOps, microservices, containers, and cloud-based development platforms, the gap between state-of-the-art solutions and the technology that enterprises typically support has greatly increased. But some enterprises are now looking to bridge that gap by building microservices-based architectures on top of Java EE. In this webcast, Red Hat Developer Advocate Markus Eisele explores the possibilities for enterprises that want to move ahead with this architecture. However, the issue is complex: Java EE wasn't built with the distributed application approach in mind, but rather as one monolithic server runtime or cluster hosting many different applications. If you're part of an enterprise development team investigating the use of microservices with Java EE, this webcast will guide you to answers for getting started.

1. Java EE Microservices
Architecture
Evolving the monoliths

2. @myfear
blog.eisele.net
Red Hat Developer Advocate

3. monolith
/ ˈmɒn(ə)lɪθ/
noun
noun: monolith; plural noun: monoliths

5. The Curse Of The Monolith
We know how to operate them
• We know how to develop
• We know how to deploy
• We know how to scale
but there is a price to pay
• Large code-bases
• Hard to understand and modify
• Complex configuration

6. service oriented
/ˈsəːvɪs/
noun

8. The Curse Of SOA
Increased everything
• Interoperability
• Federation
• Business and technology alignment
but there is a price to pay
• Centralized infrastructures
• Restricted communication protocols
• Vendor driven movement

9. micro services
/ˈmʌɪkrəʊ/
noun

11. What Are Microservices?
SOA for DevOps
• Single, self-contained, autonomous
• Easy(er) to understand individually
• Scalability
• Testing independently
• Individually deployed, has own lifecycle
• Single service going down should not impact
other services
• Right technology stack for the problem
(language, databases, etc)
• Fail fast
• Faster innovation, iteration
We want flexible systems
and organizations that
can adapt to their
complex environments,
make changes without
rigid dependencies and
coordination, can learn,
experiment, and exhibit
emergent behavior.
„

12. Why now?
Why me?

14. Enterprise Goals and Objectives
Resistant to Change and Economically Efficient
Developers Left Alone
Technology-Centric Versus Business-Centric

15. Single Vendor Platform decisions increasingly unattractive
OpenSource moves quickly into this direction
Platform as a Service offerings mature
Increasing need for business value from software
Quicker turnaround cycles for changes required

16. We need to build systems
for flexibility and resiliency, not
just efficiency and robustness.

17. And we need to start building them
today with what we have.

18. From monolith to microservice architecture
?

19. Technology alone
won’t solve your problem.

20. Software Design
Outer Architecture
Methodology and Organization
Distributed Systems
Platform As A Service

21. Organisation
• Autonomous, self-directed teams
• Transparency
• Small (2-pizza rule)
• Purpose, Trust, Empathy driven
• Feedback
• Experimentation
• Respond quickly to change
• Own services, delivery, operations
• Build it, you own it

22. Model culture after open source
organizations: meritocracy, shared
consciousness, transparency,
network, platforms.
(Christian Posta, Red Hat)
„

23. DEV
Continuously deliver
software
Focus on adding value,
not maintenance
Deliver features
faster
OPS
Minimize manual,
repetitive work
Stabilize operating
environments
Encounter issues of
reduced complexity
Resolve problems
quicker

24. WATERFALL AGILE
http://blog.procademysoftware.com/agile-is-waterfall/

25. Software Design
Architecture Principles
• Single Responsible Principle
• Service Oriented
Architecture
• Encapsulation
• Separation of Concern
• Loose Coupling
• Hexagonal Architecture
Design Patterns
• Domain-driven Design
• Bounded Contexts
• Event Sourcing
• CQRS
• Eventual Consistency
• Context Maps

26. Design Constraints
• Availability
• Scalability
• Performance
• Usability
• Flexibility

27. Best Practices
• Design for Automation
• Designed for failure
• Service load balancing and automatic scaling
• Design for Data Separation
• Design for Integrity
• Design for Performance

28. Strategies For Decomposing
Verb or Use Case
e.g. Checkout UI
Noun
e.g. Catalog product service
Single Responsible Principle
e.g. Unix utilities

29. Distributed Systems
• The network is unreliable
• Design time coupling
• Unintended, run-time coupling
• Components will fail
• Design for resilience, not just
robustness

30. Control Dependencies
• What components depend on the
others
• Which teams need to engage to
make a change
• What services need to be changed
if one changes
• Coordination, contention,
synchronization, blocking
• Hidden dependencies

31. Platform as a Service
• Docker, Kubernetes
• Developer focused workflow
• Source 2 Image builds
• Build as first-class citizen
• Deployments as first-class citizen
• Software Defined Networking
(SDN)
• Docker native format/packaging
• Run docker images
• CLI/Web based tooling

32. Outer Architecture
Load
Balancer
ServiceAA DBClient Cache
APIGateway
Security
Service
Registry
Operational Capabilities (Scaling, SLA, Monitoring, Logging, Deployment)
Developer Enablement (Documentation, Discovery, Debugging)

33. Why now?
Why me?

34. Java EE 7 Features

35. Migration Approaches

36. Load Balancer
App
ServiceSDApp
ServiceSD
Java EE .ear
.war
.war
.jar
.jar
.jar
.jar
DBClient
App
ServiceSD
App
ServiceSD
ServiceAA
.war
.jar
.jar
DBCache
GLUE

37. Load Balancer
App
ServiceSDApp
ServiceSD
Java EE .ear
.war
.war
.jar
.jar
.jar
.jar
DB
Client
App
ServiceSD
App
ServiceSD
ServiceAA
.war
.jar
.jar
DBCache
/service
/order
Read-only
Access!

39. Let’s look at some patterns

40. Aggregator
App
Service1
App
ServiceSD
App
Service1
App
ServiceWQ
App
Service3
App
ServiceTR
DB
DB
DB
Client
Cache
Cache
Cache
Load
Balancer

41. LB / Proxy
App
Service1
App
ServiceSD
App
Service1
App
ServiceWQ
App
Service3
App
ServiceTR
DB
DB
DB
Client
Cache
Cache
Cache

42. Load
Balancer
App
Service1
App
ServiceBN
App
Service1
App
ServiceFD
App
Service3
App
ServiceSA
DB DB DB
Client
CacheCacheCache

43. Load
Balancer
App
Service1
App
ServiceRE
App
Service1
App
ServiceGH
App
Service3
App
ServiceDR
DB
DB DB
App
Service3
App
ServiceKJ
DB
Client
Cache
Cache
Cache Cache

44. Load
Balancer
App
Service1
App
ServiceXY
App
Service1
App
ServiceEW
App
Service3
App
ServiceCV
DB
DB
DB
App
Service3
App
ServiceTR
DB
App
Service3
App
ServiceYU
Load
Balancer
Client
Client
Cache
Cache
Cache
Cache

45. Respect The Challenge
• No silver bullet; distributed systems are *hard*
• Dependency hell, custom shared libraries
• Fragmented and inconsistent management
• Team communication challenges
• Health checking, monitoring, liveness
• Over architecting, performance concerns, things spiraling out
of control fast

46. http://martinfowler.com/bliki/MicroservicePremium.html
The fulcrum of whether or not to use
microservices is the complexity of the
system you're contemplating.
(M.Fowler)
“

47. Lessons Learned Today
• Correct functional decomposition is crucial for microservices:
• pretty hard to get right from the start
• a modular system can evolve to microservices
• balance the needs with the costs
• work on it evolutionary
• Java EE can be a platform for microservices
• You need a lot more than just technology

48. Fit all the pieces together

49. http://bit.ly/ModernJavaEE
• 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