HOW TO PICK A FUTURE PROOF JAVA

ARCHITECTURE FOR THE NEXT 10+ YEARS?

Roko Roić

Advisor @ King ICT

Matija Capan

Chief architect @ King ICT

„People who live in the present often wind up exploiting the present to an extent that it starts removing the possibility of having a future.” [Alan Kay, UCLA/MIT/Atari/Turing award]

THE PROBLEM? THINGS CHANGE MAKING IT HARD TO STAY ON TARGET WITHIN 10+ YEARS. EVEN IN AGILE PROMOTED EVOLVING ARCHITECTURES. EVEN IF YOU DECIDE „AS LATE AS POSSIBLE”.

Goals of this talk

Define sustainability and reasons for even proposing this approach

View the problem from multiple angles and put it in plain sight

Propose an approach for long term Java architectures

What requires long term sustainability?

NEEDS TO RUN FOR

DECADE(S)

NEEDS FUNCTIONAL UPGRADES FOR THE ENTIRE

LIFESPAN

NEEDS GROWING

SCALABILITY FOR THE ENTIRE

LIFESPAN

NEEDS TO WORK IN A CHANGING

ENVIRONMENT

Changing environment Client operating systems change

Application runtimes change (e.g. browser)

Systems you integrated to also change

JVMs change

Server infrastructure changes

Security standards change

Application servers change

Problem areas

Maintaining knowledge

Building scalability in

Changing environment Young guns know only the lastest thing

Seniors are hard to find

…especially for non standard architectures

…especially for middleware-heavy architectures

People (and knowledge) leave the company

Problem areas

Maintaining knowledge

Building scalability in

Changing environment Allowing functional growth over time

Allowing capacity growth over time

Allowing easy deployment and easy rollback

Allowing partial or full refactoring (coverage is king)

Problem areas

Maintaining knowledge

Building scalability in

THE SOLUTION, PLEASE? JUST THE APPROACH TODAY,

BUILD YOUR OWN SOLUTION

WE ARE GOING TO DO THIS BOTTOM UP SO PLEASE BEAR

WITH US

“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”

Arnon Rotem-Gal-Oz in Agile Architecture

FACT: JAVA 7 WAS MADE AVAILABLE IN JULY 2011. AND MADE DEAD IN APRIL 2015.

LET’S START WITH THE RUNTIME. JVM? WHICH

VERSION?

FACT: JAVA IS THE NEW COBOL. IT WILL STICK LIKE SOMETHING YOU PICKED UP ON A BACHELOR’S PARTY

UP THE LADDER IS THE LANGUAGE. THERE’S MORE

THAN 50 ON THE JVM.

FACT: TIOBE INDEX, JOB MARKET INDEX, COLLEGE EDUCATION – ALL PREFER JAVA TO OTHER JVM

LANGUAGES

FACT: THERE IS THE EE AND THE SE APPROACH. EACH WILL LIVE TO TELL,

BUT WHAT ABOUT THE IMPLICATIONS TO THE OVERALL SOLUTION?

WHICH JAVA EDITION WILL HELP ME STAY ON TARGET FOR

THE NEXT 10+ YEARS?

FACT: THERE’S THOUSANDS OF FRAMEWORKS AND MODULES AROUND, WE’LL TRY TO GIVE SOME GUIDANCE ON

PICKING THE SUSTAINABLE ONES.

LET’S BE HONEST, DEVELOPERS DO NOT DEVELOP REALLY THAT

MUCH. THEY USE FRAMEWORKS AND MODULES.

IS THERE AN

ESCAPE HATCH?

TRACK RECORD OF BACKWARD COMPATIBLI

TY

IS THERE AN ECOSYSTEM AROUND IT?

IS IT EASY FOR A

JUNIOR TO LEARN?

COMMUNITY SIZE &

ENGAGEMENT

DO I REALLY

NEED IT?

FACT: WEB IS THE STANDARD, BUT WITHOUT STANDARDISATION. KEEP IT

SIMPLE, BOOTSTRAP SHOULD BE ENOUGH.

USER INTERFACE APPROACH? WEB, NATIVE DESKTOP,

MOBILE, HYBRID DESKTOP, HYBRID MOBILE, … IT USED TO

BE SO SIMPLE

NO SOFTWARE ARCHITECTURE IS AN

ISLAND. IT SHARES SPACES WITH ITS SYSTEM

ARCHITECTURE

APPLICATION MIDDLEWARE

Embedded HTTP server

Microservices based arachitecture is possible

Low impact on knowledge transfer

Architecture based on BPM or similar

Can you afford the knowledge transfer?

Architecture based on the app server over JVM

Do you NEED to use the features of the app server?

Can you afford scaling the server up?

Can you afford the operations cost?

JUST THE APP SERVER ADVANCED MIDDLEWARE NO MIDDLEWARE

Can you afford scaling the server up?

Can you afford the operations cost? Easy migration and upgrade, cheap scalability

INTEGRATION MIDDLEWARE

Higher operating cost

Scalability built in

Future proof

Smaller operating cost

Difficult to manage

DIRECT INTEGRATION ESB APPROACH

Difficult to upgrade

Difficult to scale Manageable

FINAL WORDS…

TAKEWAYS BY PROBLEM AREA

Use the Microservices architecture (where applicable)

Use TDD or other approach to enlarge coverage

Use Continuous deployment,especially with Microservices

Use Java as the default language

Use as few frameworks as possible

Use the latest JVM

Go light on the APP middleware

Be wary of frontend frameworks

Plan an escape hatch

CHANGING ENVIRONMENTS

MAINTAINING KNOWLEDGE

BUILDING SCALABILITY IN

Do not build your own frameworks,

unless you are Google

AND ONE MORE THING…

STAY CONSERVATIV

E!