View
5.622
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Presentation from my WJAX 2010 talk about modern Java Enterprise Architectures. Talks about dynamic changes to systems and approaches like Java, Java EE, OSGi, Cloud, Spring.
Citation preview
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)
• [email protected] • 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?