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