Spring in the Cloud
About me
•    Eberhard Wolff
•    Architecture & Technology Manager at adesso
•    adesso is a leading IT consultancy in Germany
•    Speaker
•    Author (i.e. first German Spring book)
•    Blog: http://ewolff.com
•    Twitter: @ewolff
•    eberhard.wolff@adesso.de
Content
•    What is the Cloud?
•    My First Cloud App
•    Scaling the App
•    Another Cloud Challenge
•    Java EE 7
•    Conclusion
What is the Cloud?
      Infrastructure                    Platform                        Software
    as a Service                   as a Service                    as a Service


>  Virtual Servers             >  Virtual Application Server   >  Software or Service
                                                                  that you use
>  Similar to Virtualization   >  Handles Scale-Out

                                                               >  Components that you
>  Manage Everything           >  Mostly Managed by               add/integrate into your
   Yourself                       Provider                        app
Why Cloud?
•  Compelling Economics
  –  Lower CapEx
  –  Cheaper handling of peak loads
•  Flexibility and better productivity for
   development
  –  Self service portal
  –  Much easier to set up environments
•  Better Service
  –  Redundancy across multiple data centers
  –  Lower latency because of local data centers
So: What Shall I use?
•  IaaS: Maximum control, but:
  –  Need to install infrastructure
  –  Need to install application
  –  How do you do application updates?


•  PaaS: Much easier to handle
  –  …but often less flexible
  –  Monitoring, deployment etc built in
  –  Probably the better choice
Google App Engine
•    Non relation data store (NoSQL)
•    (Limited) JPA interface to data store
•    Available Java classes limited (White List)
•    No control over web server, operating system
•    Strategic partnership SpringSource / Google

•  Spring works
Amazon Beanstalk
•    Tomcat + OpenJDK + Linux on EC2
•    + Monitoring, Versioning, Events…
•    Auto Scaling
•    Can add MySQL (RDS) with backup etc

•  Sample application uses Spring
Cloud Bees
•  Focus on DEV@Cloud
  –  Continuous Integration
  –  Maven Repository
•  RUN@Cloud: Tomcat+OpenJDK + Linux on
   EC2
•  Announce beta for Private Cloud
•  MySQL also available
•  Very limited scaling / SLAs

•  Spring works
VMware Cloud Foundry
•  Tomcat on VMware Public Cloud or Micro
   Cloud (i.e. laptop) or EC2 or …
•  Platform is Open Source
•  Can add MySQL, Redis, MongoDB
•  Services injected into application
•  Framework support needed
•  Spring: A MySQL DataSource is rewired to a
   MySQL service
Cloud Foundry Spring Integration
<cloud:data-source id="dataSource"/>	
<cloud:mongo id="mongo"/>	
<cloud:redis-connection-factory	
 id="redisConnectionFactory"/>
•  Cloud namespace: bind to Cloud Foundry
   services
•  Works with Spring 3.0.5

•  Note: No need for environment specific config
•  App can run unchanged in test / dev /
   production Cloud Foundry environments
PaaS Conclusion
•  Spring (+ Tomcat) own the Cloud
•  Also predominant non-Cloud Enterprise
   platform
•  Lightweight – more important for Cloud
  –  Pay any consumed resource
  –  PaaS: Need operations / monitoring / deployment
  –  Easier for a simple environment
•  Spring has always been about portability
•  Not just Java EE / Tomcat / … - also Cloud
Full Java EE Stack?
•  Spring & Tomcat:
   The Enterprise & Cloud Java dream team
•  Of course can also use other Java EE APIs
   on Tomcat

•  There is no offering for a full Java EE PaaS
   stack
•  i.e. including EJB, JMS, JTA …
My First Cloud App

      Tomcat
      Catalog
       Order




     RDBMS
My First Cloud App: Platform
•  Programming model
   Same as for Enterprise Java Apps
•  E.g. JSF + Spring + JPA …
•  Run on IaaS: Need to install infrastructure
  –  Must be automated

•  Google App Engine
  –  JSF probably won’t work
  –  Spring and GWT will
  –  No RDBMS - but NoSQL with (limited) JPA
My First Cloud App: Platform
•  Amazon Beanstalk
   Cloud Bees
   Cloud Foundry
  –  Environment you are used to: Tomcat + MySQL
  –  Cloud Foundry: Optional cloud namespace in the
     configuration


•  For a start a normal Spring application is OK
•  What are the limits?
How Is Cloud Different?
•  Need to be able to add new servers
•  Provided for by PaaS
•  New servers must be able to handle load
   instantly (warm cache)

•    Prefer Scale Out instead of Scale Up
•    i.e. add new servers instead of bigger ones
•    Usually not an option with RDBMS
•    Scale up is possible but limited
How Is Cloud Different?
•  Complex networks setup
•  Nodes might be unavailable
•  Might want to run cluster across data center
   for availability
•  Server might and will fail
•  Very different from normal servers
How Is Cloud Different?
So How Is Cloud Different?
•  No operations department to blame
•  Unreliable and potentially slow network

•  How can you even dare to build reliable
   systems that way?
•  Amazon and Google accomplish that
•  Will happen in Enterprises as well
•  Much more efficient in operations /
   development
So How Is Cloud Different?
•  No operations department to deal with – just
   a portal!

•  Multiple world-wide distributed data centers
   available to you!
  –  Redundancy
  –  Low latency from any place
•  New virtual computers spun up in minutes!
•  Need a larger machine – just reboot!
Cloud is Just Another Trade Off
•  How can applications be successfully created
   in this environment?
CAP Theorem
•  C: Consistency: All nodes see the same data
•  A: Availability: Node failure does not prevent
   survivors from operating
•  P: Partition Tolerance: System works even
   though message are lost

•  Choose any two
•  No P in the Cloud?
•  So A or C?
Consistency


                            RDBMS
    Quorum                  2 Phase
                            Commit




Partition
Tolerance Replication DNS   Availability
My First Cloud App

Actually works   Tomcat
Now let’s
scale it up      Catalog
                  Order
…and enter
the globalized
world

                 RDBMS
Scaling My First Cloud App
                         Global
Replication?
               Tomcat    business
Across data
                         More
centers?
               Catalog   customers
Write
                Order    Reliable?
performance?
                         Fast?
Catalog used
a lot
more
than   RDBMS   RDBMS     RDBMS
Order
Scaling My First Cloud App
•  IaaS
  –  Can use other regions and scale datastore
  –  Limits of technology (RDBMS) still apply
  –  Need to installation / configuration it yourself
•  Google App Engine
  –  Datastore scales well
  –  Global data centers?
•  Amazon Beanstalk
  –  Turn key MySQL with replication (RDS)
  –  …but of you can’t change the limits of RDBMS
  –  Beanstalk only in US East at the moment
Scaling My First Cloud App
•  Cloud Bees
  –  Data center only in the US
  –  MySQL installation very limited
  –  Can use Amazon RDS

•  Cloud Foundry
  –  Data centers only in the US
  –  MySQL limited
•  You will need to do more yourself e.g. on EC2
•  Less support by the PaaS
My Second Cloud Application
     Tomcat                        Tomcat

     Catalog                       Catalog




                    Updates as messages
Catalog separated
                    Will be eventually delivered
Because of load
                    AP, but no C
My Second Cloud Application
•  Parts of application separated because of scaling
   scheme
•  Introduce “Eventual Consistency”
   –  Either using NoSQL (e.g. CouchDB)
   –  …or using messaging
   –  Might consider in memory or cache (Redis, memcached,
      GemFire)
•  RabbitMQ is the predominant approach for messaging
   in the cloud
   –  NASA’s nebula project
   –  #1 on EC2
   –  Support in Cloud Foundry planned
•  More messaging: Amazon SNS, SQS …
My Second Cloud Application
  Tomcat                       Tomcat

   Order                        Order




Orders are sent as messages
Will eventually be sent to the backend
Will eventually be handled by the backend
2nd Cloud App: Programming
                  Model
•  Very different from a normal Enterprise Java
   three tier application
•  Not so different from a portal
•  No one global database
•  Focus on messaging

•    Need support for RabbitMQ / AMQP
•    I.e. Spring AMQP (see other talk)
•    Programming model very much like Spring JMS
•    Can create message driven POJOs
2nd Cloud App: Programming
               Model
•  Need NoSQL / Caching / Data Fabric
•  See Spring Data talk
•  Spring supports many relational technologies
  –  iBATIS, Hibernate, JPA …
  –  E.g. common exception
  –  Uniform API approach
  –  Still specific API for each technology
•  These abstractions are flexible
•  Can be used for NoSQL as well!
Another Cloud Challenges
•    Catalog browsing statistics from log files
•    i.e. how many customer looked at X?
•    Sounds like a batch
•    File in, statistics out
•    With Spring Batch

•  But: Globally distributed data
•  A lot of data
•  Some systems might not be online
Spring Batch?
•  Spring Batch can be used to run batches
•  I.e. Jobs with steps
•  But:
  –  How do you deal with the distribution?
  –  No central place with all the data
  –  Do you prefer incomplete data or no data at all?


•  Need something different.
Map / Reduce
•  Map: Apply a function to all data
  –  Emit (item name, 1) for each log file line
•  Master sorts by item name
•  Reduce: Add all (item name, 1) to the total
   score                     Reduce

•  Map can be done on
   any node                   Map             Map
•  Master collects data
Map / Reduce Benefits
•  Data can stay on workers
•  Can done in parallel on many machines
•  Prefer answer on available data over no
   answer at all
•  Can deal with redundant storage
•  But:
  –  Lot of network communication
  –  More work in total
Spring Hadoop
•    Hadoop is a complete solution for Map/Reduce
•    HDFS Filesystem
•    HBase Database
•    Hive for Data Warehousing / ad hoc queries

•  Spring Hadoop adds templates and POJO based
   model
•  https://github.com/springsource/spring-hadoop
And What About Java EE 7?
•    Cloud is one of topics for Java EE 7
•    Theme: Multi-Tenant / Isolation of customers
•    New role: PaaS Administrator
•    Additional security
•    QoS
•    Application Metadata
•    Caching will become more important and will
     be covered by Java EE
The Cloud Challenge Java EE
          Does Not Solve
•  JTA = 2PC = CA, not P
•  JPA / JDBC = CA, not P
•  Will you use that in the Cloud?

•  NoSQL?

•  RabbitMQ?
Java EE 7 & Cloud
•  Multi tenant: Just one way to isolate users
•  Can also use virtual machines, individual servers
   etc
•  Multi tenant good for lots of small applications
•  Has been used for SaaS systems

•  Tomcat and Servlets dominate the Cloud market
•  When will certified Java EE 7 servers be
   available?
•  Who will provide a Cloud based on Java EE 7?
Conclusion
•  IaaS is very flexible
•  PaaS makes deployment, monitoring and operations
   easier
•  All Java PaaS support Spring
•  Demanding Cloud applications need
   –  AMQP messaging
   –  NoSQL / Caching
   –  Map/Reduce
•  Spring’s general abstractions can be extended to support
   this
•  Concepts you are used to!

•  Java EE is stuck with “traditional” enterprise systems
Wir suchen Sie als
    Software-Architekt (m/w)
    Projektleiter (m/w)
    Senior Software Engineer (m/w)


    Kommen Sie zum Stand und gewinnen Sie ein iPad 2!

 jobs@adesso.de
 www.AAAjobs.de

Spring in the Cloud

  • 1.
  • 2.
    About me •  Eberhard Wolff •  Architecture & Technology Manager at adesso •  adesso is a leading IT consultancy in Germany •  Speaker •  Author (i.e. first German Spring book) •  Blog: http://ewolff.com •  Twitter: @ewolff •  eberhard.wolff@adesso.de
  • 3.
    Content •  What is the Cloud? •  My First Cloud App •  Scaling the App •  Another Cloud Challenge •  Java EE 7 •  Conclusion
  • 4.
    What is theCloud? Infrastructure Platform Software as a Service as a Service as a Service >  Virtual Servers >  Virtual Application Server >  Software or Service that you use >  Similar to Virtualization >  Handles Scale-Out >  Components that you >  Manage Everything >  Mostly Managed by add/integrate into your Yourself Provider app
  • 5.
    Why Cloud? •  CompellingEconomics –  Lower CapEx –  Cheaper handling of peak loads •  Flexibility and better productivity for development –  Self service portal –  Much easier to set up environments •  Better Service –  Redundancy across multiple data centers –  Lower latency because of local data centers
  • 6.
    So: What ShallI use? •  IaaS: Maximum control, but: –  Need to install infrastructure –  Need to install application –  How do you do application updates? •  PaaS: Much easier to handle –  …but often less flexible –  Monitoring, deployment etc built in –  Probably the better choice
  • 7.
    Google App Engine •  Non relation data store (NoSQL) •  (Limited) JPA interface to data store •  Available Java classes limited (White List) •  No control over web server, operating system •  Strategic partnership SpringSource / Google •  Spring works
  • 8.
    Amazon Beanstalk •  Tomcat + OpenJDK + Linux on EC2 •  + Monitoring, Versioning, Events… •  Auto Scaling •  Can add MySQL (RDS) with backup etc •  Sample application uses Spring
  • 9.
    Cloud Bees •  Focuson DEV@Cloud –  Continuous Integration –  Maven Repository •  RUN@Cloud: Tomcat+OpenJDK + Linux on EC2 •  Announce beta for Private Cloud •  MySQL also available •  Very limited scaling / SLAs •  Spring works
  • 10.
    VMware Cloud Foundry • Tomcat on VMware Public Cloud or Micro Cloud (i.e. laptop) or EC2 or … •  Platform is Open Source •  Can add MySQL, Redis, MongoDB •  Services injected into application •  Framework support needed •  Spring: A MySQL DataSource is rewired to a MySQL service
  • 11.
    Cloud Foundry SpringIntegration <cloud:data-source id="dataSource"/> <cloud:mongo id="mongo"/> <cloud:redis-connection-factory id="redisConnectionFactory"/> •  Cloud namespace: bind to Cloud Foundry services •  Works with Spring 3.0.5 •  Note: No need for environment specific config •  App can run unchanged in test / dev / production Cloud Foundry environments
  • 12.
    PaaS Conclusion •  Spring(+ Tomcat) own the Cloud •  Also predominant non-Cloud Enterprise platform •  Lightweight – more important for Cloud –  Pay any consumed resource –  PaaS: Need operations / monitoring / deployment –  Easier for a simple environment •  Spring has always been about portability •  Not just Java EE / Tomcat / … - also Cloud
  • 13.
    Full Java EEStack? •  Spring & Tomcat: The Enterprise & Cloud Java dream team •  Of course can also use other Java EE APIs on Tomcat •  There is no offering for a full Java EE PaaS stack •  i.e. including EJB, JMS, JTA …
  • 14.
    My First CloudApp Tomcat Catalog Order RDBMS
  • 15.
    My First CloudApp: Platform •  Programming model Same as for Enterprise Java Apps •  E.g. JSF + Spring + JPA … •  Run on IaaS: Need to install infrastructure –  Must be automated •  Google App Engine –  JSF probably won’t work –  Spring and GWT will –  No RDBMS - but NoSQL with (limited) JPA
  • 16.
    My First CloudApp: Platform •  Amazon Beanstalk Cloud Bees Cloud Foundry –  Environment you are used to: Tomcat + MySQL –  Cloud Foundry: Optional cloud namespace in the configuration •  For a start a normal Spring application is OK •  What are the limits?
  • 17.
    How Is CloudDifferent? •  Need to be able to add new servers •  Provided for by PaaS •  New servers must be able to handle load instantly (warm cache) •  Prefer Scale Out instead of Scale Up •  i.e. add new servers instead of bigger ones •  Usually not an option with RDBMS •  Scale up is possible but limited
  • 18.
    How Is CloudDifferent? •  Complex networks setup •  Nodes might be unavailable •  Might want to run cluster across data center for availability •  Server might and will fail •  Very different from normal servers
  • 19.
    How Is CloudDifferent?
  • 21.
    So How IsCloud Different? •  No operations department to blame •  Unreliable and potentially slow network •  How can you even dare to build reliable systems that way? •  Amazon and Google accomplish that •  Will happen in Enterprises as well •  Much more efficient in operations / development
  • 22.
    So How IsCloud Different? •  No operations department to deal with – just a portal! •  Multiple world-wide distributed data centers available to you! –  Redundancy –  Low latency from any place •  New virtual computers spun up in minutes! •  Need a larger machine – just reboot!
  • 23.
    Cloud is JustAnother Trade Off •  How can applications be successfully created in this environment?
  • 24.
    CAP Theorem •  C:Consistency: All nodes see the same data •  A: Availability: Node failure does not prevent survivors from operating •  P: Partition Tolerance: System works even though message are lost •  Choose any two •  No P in the Cloud? •  So A or C?
  • 25.
    Consistency RDBMS Quorum 2 Phase Commit Partition Tolerance Replication DNS Availability
  • 26.
    My First CloudApp Actually works Tomcat Now let’s scale it up Catalog Order …and enter the globalized world RDBMS
  • 27.
    Scaling My FirstCloud App Global Replication? Tomcat business Across data More centers? Catalog customers Write Order Reliable? performance? Fast? Catalog used a lot more than RDBMS RDBMS RDBMS Order
  • 28.
    Scaling My FirstCloud App •  IaaS –  Can use other regions and scale datastore –  Limits of technology (RDBMS) still apply –  Need to installation / configuration it yourself •  Google App Engine –  Datastore scales well –  Global data centers? •  Amazon Beanstalk –  Turn key MySQL with replication (RDS) –  …but of you can’t change the limits of RDBMS –  Beanstalk only in US East at the moment
  • 29.
    Scaling My FirstCloud App •  Cloud Bees –  Data center only in the US –  MySQL installation very limited –  Can use Amazon RDS •  Cloud Foundry –  Data centers only in the US –  MySQL limited •  You will need to do more yourself e.g. on EC2 •  Less support by the PaaS
  • 30.
    My Second CloudApplication Tomcat Tomcat Catalog Catalog Updates as messages Catalog separated Will be eventually delivered Because of load AP, but no C
  • 31.
    My Second CloudApplication •  Parts of application separated because of scaling scheme •  Introduce “Eventual Consistency” –  Either using NoSQL (e.g. CouchDB) –  …or using messaging –  Might consider in memory or cache (Redis, memcached, GemFire) •  RabbitMQ is the predominant approach for messaging in the cloud –  NASA’s nebula project –  #1 on EC2 –  Support in Cloud Foundry planned •  More messaging: Amazon SNS, SQS …
  • 32.
    My Second CloudApplication Tomcat Tomcat Order Order Orders are sent as messages Will eventually be sent to the backend Will eventually be handled by the backend
  • 33.
    2nd Cloud App:Programming Model •  Very different from a normal Enterprise Java three tier application •  Not so different from a portal •  No one global database •  Focus on messaging •  Need support for RabbitMQ / AMQP •  I.e. Spring AMQP (see other talk) •  Programming model very much like Spring JMS •  Can create message driven POJOs
  • 34.
    2nd Cloud App:Programming Model •  Need NoSQL / Caching / Data Fabric •  See Spring Data talk •  Spring supports many relational technologies –  iBATIS, Hibernate, JPA … –  E.g. common exception –  Uniform API approach –  Still specific API for each technology •  These abstractions are flexible •  Can be used for NoSQL as well!
  • 35.
    Another Cloud Challenges •  Catalog browsing statistics from log files •  i.e. how many customer looked at X? •  Sounds like a batch •  File in, statistics out •  With Spring Batch •  But: Globally distributed data •  A lot of data •  Some systems might not be online
  • 36.
    Spring Batch? •  SpringBatch can be used to run batches •  I.e. Jobs with steps •  But: –  How do you deal with the distribution? –  No central place with all the data –  Do you prefer incomplete data or no data at all? •  Need something different.
  • 37.
    Map / Reduce • Map: Apply a function to all data –  Emit (item name, 1) for each log file line •  Master sorts by item name •  Reduce: Add all (item name, 1) to the total score Reduce •  Map can be done on any node Map Map •  Master collects data
  • 38.
    Map / ReduceBenefits •  Data can stay on workers •  Can done in parallel on many machines •  Prefer answer on available data over no answer at all •  Can deal with redundant storage •  But: –  Lot of network communication –  More work in total
  • 39.
    Spring Hadoop •  Hadoop is a complete solution for Map/Reduce •  HDFS Filesystem •  HBase Database •  Hive for Data Warehousing / ad hoc queries •  Spring Hadoop adds templates and POJO based model •  https://github.com/springsource/spring-hadoop
  • 40.
    And What AboutJava EE 7? •  Cloud is one of topics for Java EE 7 •  Theme: Multi-Tenant / Isolation of customers •  New role: PaaS Administrator •  Additional security •  QoS •  Application Metadata •  Caching will become more important and will be covered by Java EE
  • 41.
    The Cloud ChallengeJava EE Does Not Solve •  JTA = 2PC = CA, not P •  JPA / JDBC = CA, not P •  Will you use that in the Cloud? •  NoSQL? •  RabbitMQ?
  • 42.
    Java EE 7& Cloud •  Multi tenant: Just one way to isolate users •  Can also use virtual machines, individual servers etc •  Multi tenant good for lots of small applications •  Has been used for SaaS systems •  Tomcat and Servlets dominate the Cloud market •  When will certified Java EE 7 servers be available? •  Who will provide a Cloud based on Java EE 7?
  • 43.
    Conclusion •  IaaS isvery flexible •  PaaS makes deployment, monitoring and operations easier •  All Java PaaS support Spring •  Demanding Cloud applications need –  AMQP messaging –  NoSQL / Caching –  Map/Reduce •  Spring’s general abstractions can be extended to support this •  Concepts you are used to! •  Java EE is stuck with “traditional” enterprise systems
  • 44.
    Wir suchen Sieals   Software-Architekt (m/w)   Projektleiter (m/w)   Senior Software Engineer (m/w)   Kommen Sie zum Stand und gewinnen Sie ein iPad 2! jobs@adesso.de www.AAAjobs.de