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  

VM  

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, …)

JMX

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?