Modern (Java) Enterprise Architectures

transcript

Modern Enterprise-‐Architectures

Eberhard Wolff, SpringSource – A division of VMware

About me •  Eberhard Wolff •  Principal Technologist •  Consultant & Trainer •  Author (e.g. first German Spring book)

•  ewolff@vmware.com •  TwiGer: @ewolff •  Blog: hGp://ewolff.com

A division of VMware

Lightweight App RunOme

Virtual App Environment

Hybrid Cloud

Spring tc Server

Lightweight App Framework

Overview •  IntroducOon

•  Java EE Deployment opOons

•  OSGi

•  Cloud

Which PlaWorm Shall I use? •  Actually two decisions:

– Which server environment? – Which programming model?

•  Java EE is both •  Spring is a programming model •  i.e. you can use Spring with any server environment

•  i.e. you can update Spring versions without updaOng the server

Infrastructure (Server)

Programming Model

Your App

Spring

Java EE

So? •  Spring is the beGer programming model •  I am biased… •  hGp://jandiandme.blogspot.com/2010/10/ spring-‐vs-‐java-‐ee-‐and-‐why-‐i-‐dont-‐care.html

•  More producOvity only with new tools, not framework

•  Spring Roo offers a much broader approach –  Inspired by Ruby on Rails: Generator –  Raises the level of abstracOons –  Covers build –  Introduces tools –  No similar technology for Java EE available!

•  Other languages (Groovy / Grails, Scala …) •  So I will focus on the server infrastructure

Programming Model

Your App

Roo / Grails …

Modular Programming •  Key to developing socware producOvely

•  Much improvement in the last few years •  Dependency management is ubiquitous •  Architecture management

•  What is the next level?

Modular Deployment •  What is the granularity of deployment?

•  Let's assume a Java EE applicaOon •  Customer module •  Payment module •  Dependency: Payment depends on Costumer

•  How do we get this deployed?

Approach: Everything in One Unit •  Everything is in one unit (i.e. WAR / EAR) •  TradiOonal Java EE model

WAR / EAR

Customer Payment

One Unit: Advantages •  Every class in the system only once

•  including e.g. libraries

•  Efficient

One Unit: Challenges •  ModularizaOon might not be as good as you think

–  as runOme does not enforce it •  Complex build process

–  If you use EARs •  Long deployment •  Small changes require complete redeployment •  Might influence turn around Ome during development •  ConOnuous integraOon

•  Note: If you set up a completely new system for producOon anyway this might be not such a big issue

Approach: 1 Module = 1 Deployment •  Each module is a unit (e.g. WAR) •  Unorthodox Java EE model •  Units are isolated: no shared classes nor objects •  No direct communicaOon possible

customer.war

payment.war

ClassLoader isolation HTTP (Web Services, REST, HTTP Invoker, …)

must include classes from customer.war

1 Module = 1 Deployment: Advantages •  Each module can be deployed independently

•  i.e. a change in the payment module can be deployed independently from the rest

•  Might be an advantage •  Process (e.g. retesOng) must sOll be followed •  If you install a completely new system anyway that does not maGer

•  Faster turn around •  Only one module built and redeployed

1 Module = 1 Deployment: Challenges •  CommunicaOon between modules complex •  No shared classes

•  e.g. domain classes for communicaOon

•  Perm Gen space •  Stores loaded classes •  Each class loaded once per deployment •  e.g. all libraries (Spring, JPA, …)

These are limits of Java EE's Class-‐Loader-‐per-‐App and

deployment model

ClassLoader isolation

How can we answer the challenge… •  It must be possible to

•  share classes between deployment units •  add or remove deployment units at runOme •  That was the whole point

•  This opens up all kinds of interesOng challenges •  Deployment units with classes come and go at runOme •  ImplementaOons should be exchangeable at runOme

Either you accept these limitaOons or you have to

choose a different approach

Main concern: Class Loader

ClassLoader isolation

OSGi •  Solves these issues •  Should disOnguish between import of packages and services

•  API update sOll requires restart of payment •  But an update of the service implementaOon in the running system is possible

Customer API Payment

Customer Service

import packages

import services

OSGi Advantages •  Each module can be deployed independently

– Same issues as before (e.g. retesOng) •  Faster turn around

– Only one module built and redeployed •  CommunicaOon between modules easily possible (OSGi services)

•  Sharing classes between modules possible •  More efficient use of Perm Gen Space •  Your architecture might benefit:

– Enforces modularizaOon at runOme – Supports versioning (Java's missing feature)

Main benefit: Probably enforcing the modularizaOon at runOme

Not dynamic deployment of new modules

OSGi Challenges •  More complex

– Have to deal with import / exports of packages / services –  Just a result of the modularizaOon

•  Web support and byte code manipulaOon (e.g. JPA) might be challenges

•  Approaches like Eclipse Virgo (runOme environment) help

•  Different deployment model and server environment from Java EE – OperaOons might not like that

•  API changes sOll require a restart of dependent modules

OSGi is just a tool •  It won't solve all your problems •  The applicaOon / architecture must allow for dynamic updates •  State in services is not a brilliant idea •  MulOple versions at the same Ome •  What about database schemas?

•  Have to deal with API updates •  Well known problem in distributed environments

•  RetesOng •  Can you reproduce your producOon environment?

Dynamic changes to random parts are hard.

Dynamic changes to random parts are probably not needed

and not wanted.

You need to idenOfy which parts of the system change frequently.

What are some ways to deal with dynamic behavior?

Dealing with dynamics •  Update the logic on parts of your cluster •  The rest runs the old version

•  Eventually the whole cluster is migrated •  …or rolled back

•  SOll need to deal with the database or external clients for example

Dealing with dynamics •  Some technologies support changes to the behavior without changing code •  Rule engines •  Dynamic / script languages (can be reloaded at runOme) •  Workflow engines

•  Obviously they also have other features •  SomeOmes they are used primarily because of dynamics

An Anecdote "We have issues because we use a complex rule base."

"Well, have you thought about using code instead?"

"We can't." "Why?" "Because every code change will go through a complex retesOng phase. Rules are just configuraOon and not tested."

Numerous other examples •  "The Spring configuraOon should be read from the database."

•  "Can you change the Spring configuraOon dynamically?"

Something is wrong here •  Either the retesOng is unnecessary

– Then it should not be done independent of the technology

– …and you are wasOng money •  …or it is necessary

– Then it should not be done independent of the technology

– …and you are tesOng in producOon (risk maximizing)

•  AnO PaGern: Hide logic away from operaOons and processes in configuraOon

Processes: OperaOons vs. Developers

DevOps to the Rescue? •  Processes, methods and systems for •  CommunicaOon, collaboraOon and integraOon •  Between Development, Technology OperaOons and Quality Assurance (QA)

•  More and smaller changes: less risk •  Giving developers more environment control •  Giving infrastructure more applicaOon-‐centric understanding

•  Clearly arOculaOng simple processes •  AutomaOng as much as possible •  CollaboraOon between dev and ops

If you only remember one slide from my talk – make it this one.

What about…

The Cloud

What is Cloud CompuOng? •  “Cloud” is an abstracOon…

•  Provide IT as a service •  Self serviced •  Pay as you go

•  Just like…

Clouds •  Infrastructure as a Service – IaaS

–  Computer infrastructure as a service –  Amazon EC2, VMware vCloud Director –  Typically plaWorm virtualizaOon environment

•  PlaWorm as a Service – PaaS –  CompuOng plaWorm and/or soluOon stack as a

service –  Google App Engine, VMforce –  Ocen consuming cloud infrastructure –  Ocen sustaining cloud applicaOons.

•  Socware as a Service – SaaS –  Socware as a service over the Internet –  Salesforce.com –  EliminaOng the need to install and run the

applicaOon on the customer's own computers –  Simplifying maintenance and support

Socware

PlaWorm

Infrastructure

Clouds •  Private: My data center

•  Public: Someone else's data center

•  Managed: Managed for me

•  Hybrid: Mix Private Cloud Public Cloud

Cloud is inevitable •  Clear economically benefits

•  BeGer compuOng resource uOlizaOon

•  Flexibility

•  Self serviced: A developer can just create a test environment •  Massive producOvity gain

How is this relevant?

Cloud is self serviced •  Developers starts the (tesOng) environment all by himself.

•  OperaOons define policies, approved infrastructure etc. •  Otherwise developers use a public cloud •  Processes might be changed radically •  I.e. more responsibility and influence for developers

Cloud = Pay as you Go •  Higher load requires more resources •  Less load should consume less resources

•  More (or less) systems will share the load •  It must be possible to create (and remove) systems on the fly

•  You can't afford a complex installaOon processes •  You will be handled like a SaaS

Puqng Things into ProducOon •  A deployment to a new piece of metal has to be automated – Otherwise you can't handle increased demand –  IaaS: Do it yourself – PaaS: Taken care of

•  Deployment process will be radically different •  Might eliminate the need for dynamic changes •  A real deployment is fast enough

•  Note: TesOng / quality must sOll be assured

Commit = Deploy?

Logical conclusion of Agility •  Lots of small improvements in producOon •  ApplicaOon always compileable / executable •  Automated tests •  ConOnuous integraOon •  ConOnuous Deployment •  Why bother with dynamic reconfiguraOon of parts?

Programming Model again •  Spring based soluOons

•  Google App Engine •  VMforce (VMware / SpringSource + Salesforce)

•  No Java EE based PaaS •  Focus on lightweight infrastructure important

•  Less resources to start up new (virtual) computers •  Technology agnosOc approach important

•  Cloud has different model •  See Google App Engine and its limited Java / JPA … •  See NoSQL for data storage (Spring Data) •  See AMQP for messaging (Spring AMQP) •  Roo/Grails should be able to level these differences

Conclusion

Conclusion •  Java EE's model is limited by class loader isolaOon

– doesn't maGer if you install a system completely afresh anyway

•  OSGi solves this problem •  But you will define hot spots for changes •  and could use rule engines etc. instead •  Important: TesOng, process, operaOons •  Cloud will change this completely

– much faster, self service deployment on fresh system, programming model

What is the slide you should have remembered?

DevOps to the Rescue? •  Processes, methods and systems for •  CommunicaOon, collaboraOon and integraOon •  Between Development, Technology OperaOons and Quality Assurance (QA)

•  More and smaller changes: less risk •  Giving developers more environment control •  Giving infrastructure more applicaOon-‐centric understanding

•  Clearly arOculaOng simple processes •  AutomaOng as much as possible •  CollaboraOon between dev and ops

QuesOons?