Nine “Neins” – Where Java EE will never take you.
@myfearblog.eisele.net
https://keybase.io/myfear
Disclaimer
https://jcp.org/aboutJava/communityprocess/mrel/jsr342/
How did we get here?
Classical Architectures?
ApplicationServer
EAR- EnterpriseArchive
RESTMobileWebUI
.JAR.JAR.JAR
.JAR.JAR.JAR.JAR
.JAR.JAR.JAR
Browser RDBMS
ApplicationServer
ApplicationServer
ApplicationServer
EAR- EnterpriseArchive
RESTMobileWebUI
.JAR.JAR.JAR
.JAR.JAR.JAR.JAR
.JAR.JAR.JAR
Browser RDBMS
LL: Building and Scaling Monoliths• Monolithic application – everything is
package into a single .ear• Reuse primarily by sharing .jars• A “big” push to production once or twice a
year• Single database schema for the entire
application• >= 500k loc• >= Heavyweight Infrastructure• Thousands of Testcases• Barely New Testcases
• >= 20 Team Member• The single .ear requiring a multi-month
test cycle /• Huge bug and feature databases• User Acceptance Undefined• Technical Design Approach• Barely Business Components or Domains• Requiring multiple team involvement &
significant oversight• Technical Dept• Outdated Runtimes (Licenses, Complex
updates)• Grown applications
More users
http
://w
ww
.inte
rnet
lives
tats
.com
/inte
rnet
-use
rs/
J2EE
Spring
RoR
Akka
Reactive Manifesto
Microservices
New requirements• Rather than acting on data at rest, modern
software increasingly operates on data in near real-time.
• 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
“It’s increasingly obvious that the old, linear, three-tier architecture model is
obsolete.” - Gartner
Modernization!
Module
Module
Module
WebUI
.JAR.JAR.JAR
.JAR.JAR.JAR.JAR
.JAR.JAR.JARBrowser RDBMS
RDBMS
RDBMS
RoutingModule
TrackingModule
OrderModule
Tracker UIBrowser HistoryDB
OrderDB
RoutesDB
Tracker UI
Tracker UI
Browser
Browser
REQ: Building and Scaling Microservices
• Lightweight runtime• Cross – Service Security• Transaction Management• Service Scaling• Load Balancing• SLA’s• Flexible Deployment• Configuration• Service Discovery• Service Versions
• Monitoring• Governance• Asynchronous communication• Non-blocking I/O• Streaming Data• Polyglot Services• Modularity (Service definition)• High performance persistence (CQRS)• Event handling / messaging (ES)• Eventual consistency• API Management• Health check and recovery
What does Java EE bring to the table?
JAX-RS
JSON-PWeb SocketServlet
JSFELJSP JSTL
Bean
Val
idat
ion
Inte
rcep
tors
CD
I
Con
curre
ncy
JPA
JTA EJB JMS
Batch
JCA
Java EE 7
JavaMail
NINE “Neins”!
Definition: a “Nein” is a lost benefit of a microservice based system.
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
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)
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 only one query at 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
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 usually brings down the
complete application• No support for bulkheading. Clients have to handle
failures.
5) Java EE is implemented as 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)
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
7) Choice of data stores, use of transactions and eventual consistency• No NoSQL support in Java EE• Polyglot persistence only possible in very few
frameworks.• Heavily embracing distributed transactions with
2PC.• Eventual consistency is ignored and discouraged
http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf
8) No outer architecture – while still calling it a platform• Monitoring• Distributed Logging• Security• Service discovery• Service locator• API versioning• Routing• …
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
You can do it in this way, but then it sucks!
Possible Alternative:Reactive Application
(Lagom, Akka, Play, Vert.x, …)
http://www.reactivemanifesto.org/
Reminder:Technology alone
won’t solve all the new challenges
Software DesignSystem Architecture
Methodology and Organization
Distributed Systems Theory
Data Center Operating System
“Rules are for the obedience of fools and the guidance of wise men.”
Generally attributed to Douglas Bader
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
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
http://bit.ly/SustainableEnterprise
• 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
https://www.reactivesummit.org/
Links and further reading
ProjectSite:http://www.lightbend.com/lagom
GitHubRepo:https://github.com/lagom
Documentation:http://www.lagomframework.com/documentation/1.0.x/java/Home.html
CargoTrackerExample:https://github.com/lagom/activator-lagom-cargotracker
•Keep all data in memory!• Store all state changes as events• Replay all events of an actor to recreate it • Strong consistency for Actor (aggregate) and Journal• Eventual Consistency for Read Side
https://msdn.microsoft.com/en-us/library/jj554200.aspx
https://www.infoq.com/minibooks/domain-driven-design-quickly