Your SlideShare is downloading. ×
0
HOW WE TOOK OUR SERVER-SIDE APPLICATION TO THECLOUD……and liked what we got
Agenda Where we started What we did Paradigm shift                     2
BACKGROUND
Who‟s talking?   Fred Simon   @freddy33   Chief Architect of JFrog   Also Head of DevOps   Co-author of Artifactory  ...
Artifactory what?   Since 2006   Binary Repository Manager   Open Source   Standard Java Web Application    >   Spring...
Yet Another Java Server App                              6
Moving Forward Community success JFrog established in 2008 JavaOne 2009  > Pro version  > Software as a Service (SaaS v...
Artifactory SaaS Benefits for the user:  > Zero maintenance     › Backups     › Updates     › Infrastructure  > Support ...
Artifactory SaaS  etc.                   9
Moving Forward 3 product flavors in production  > Challenging support tasks  > Completing, not competing 30 million requ...
A load of Artifacts!                       11
JOURNEY TO THE CLOUD
THE *AAS BUZZ
* As A Service     Self Service   Multi-tenant
GaaE: Google as an ExampleProduct                 Self      Multi-   * aaS                        Service   tenantGmail   ...
AaaE: Amazon as an ExampleProduct                    Self      Multi-   * aaS                           Service   tenantAm...
The SaaS Pains - Overview Multi-tenancy Platform selection  > PaaS or IaaS DB schema updates                           ...
Multi-tenancy Java 9 already! Until then select one of the following:  > Use single application, separate data  > Use se...
GaaE for Multi Tenancy TypesProduct                 Muli-tenancy TypeGoogle Apps             Data SeparationGoogle App Eng...
Comparing the StrategiesStrategy            Pros                           ConsSeparating data         Normal Java Applic...
Comparing the Strategies Strategy            Pros                           ConsSeparating data         Normal Java Appl...
Comparing the Strategies Strategy            Pros                           ConsSeparating data         Normal Java Appl...
Comparing the StrategiesStrategy            Pros                           ConsSeparating data         Normal Java Appli...
Separate Application: Tomcat Root┌──   lib├──   webapps│     ├── customer-name│     ├── other-customer-name│     └── many ...
Separate Application Using standard Java WAR classloader isolation Creating standard WAR with dependencies in  „lib‟, cl...
Separate Application Using standard Java WAR classloader isolation Creating standard WAR with dependencies in  „lib‟, cl...
The Quest for Shared Libraries The solution – move libraries to shared  classloader  > Both 3rd party and application  > ...
THE QUEST FORSHAREDLIBRARIES
Spring Framework Perfect Make sure the context is bounded to  thread/war                                        29
Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware {      private static ApplicationContext ctx;...
Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware {      private static ApplicationContext ctx;...
Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware {      private static ApplicationContext ctx;...
Apache Wicket Was good New versions added static map of  applications  > Lesson learned: Recheck on each version    upgr...
Thread Pools They are not shared – good! Need global management to adjust the  size to match all the tenants  > Without ...
Logger Logger fields are (almost)  always static  > Can‟t fight it  > We MITM-ed the    LoggerFactory  > Keeps Loggers pe...
Race conditions on central locks Examples  > Transaction ID  > Tomcat ClassLoader Solving race condition  generates sync...
CATS Software                37
Jackrabbit Heap-wide temp file cleaner thread  > A static thread destroying the temp files of    the other tenants  > Not...
Heap-wide Caches Lucene and other cache solutions are  adjusted for the whole heap size Use SoftReference based caches  ...
THE QUEST FOR SHARED LIBRARIES:RESULTS
Tomcat Root – Where‟s the JARs?┌──   lib├──   webapps│     ├── customer-name│     │   ├── favicon.ico│     │   ├── META-IN...
Tomcat Root – In Global Lib!┌──   lib│     ├── artifactory│     │   ├── artifactory-*.jar│     │   ├── jackrabbit-core-jfr...
PaaS or IaaS? Custom Tomcat (our own  jars in Tomcat‟s lib) Custom Machine Image  with our customized  software and conf...
What was it about DB upgrade? Distributed software is concerned with  DB upgrade procedures  > User experience involved ...
THE DEVOPS
Providing Self Service Self Service Platform  > Registration  > Instance generation     ›   DB     ›   Backup     ›   Vir...
Separating Concerns Customer account is only in SaaS Centralized Self-Service portal Intercommunication with the provis...
Outcome: DevOps 4 TB of storage 33 TB of traffic per month Increasing overall performance  in an order of magnitude  in...
THE PROCESS
Diversity 3 Versions 3 Deployment formats  > WAR  > ZIP  > RPM Lots of dependencies                         50
Recursive Slide (w. baby picture) We eat our own  dog food Artifactory is built  with Artifactory                       ...
Right Tools for the Job Snapshots are built,  tested & deployed on  your build server of  choice  > With Artifactory plug...
Right Tools for the Job Deploying to production using Chef Other options:  > Puppet  > Build Server plugins  > ZT LiveRe...
THE PARADIGMSHIFT
Reversing the Cycle Before:  1. Planning downloadable version release  2. Converting it to SaaS version Today: 1. Contin...
Consequences > Rapid feedback > Host server access > Developers must think big > Standalone updates well tested by SaaS > ...
How we took our server side application to the cloud and liked what we got
Upcoming SlideShare
Loading in...5
×

How we took our server side application to the cloud and liked what we got

1,982

Published on

Taking traditional Java server-side applications to the multi-tenant Cloud introduces lots of challenges. In this session, we will share our experience of creating a SaaS offering, which is currently being used successfully by the Java community. We will start by reviewing the challenges we faced during the SaaS conversion. Next, we will share our experience with the EC2 platform. We will discuss the importance of automation and how we use tools like Chef and Puppet for SaaS provisioning. Finally, we will describe how creating a SaaS version of our product shifted our way of thinking about software release. We will recommend what’s required to successfully release both SaaS and downloadable versions of your product.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,982
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Going to talk about JFrog in 2 slidesGoing to talk about why DevOps in 3 slidesGoing to talk about Artifactory next
  • Transcript of "How we took our server side application to the cloud and liked what we got"

    1. 1. HOW WE TOOK OUR SERVER-SIDE APPLICATION TO THECLOUD……and liked what we got
    2. 2. Agenda Where we started What we did Paradigm shift 2
    3. 3. BACKGROUND
    4. 4. Who‟s talking? Fred Simon @freddy33 Chief Architect of JFrog Also Head of DevOps Co-author of Artifactory 4
    5. 5. Artifactory what? Since 2006 Binary Repository Manager Open Source Standard Java Web Application > Spring > Spring Security > Wicket > JCR > Jersey 5
    6. 6. Yet Another Java Server App 6
    7. 7. Moving Forward Community success JFrog established in 2008 JavaOne 2009 > Pro version > Software as a Service (SaaS version) › Heavly used by OSS community 7
    8. 8. Artifactory SaaS Benefits for the user: > Zero maintenance › Backups › Updates › Infrastructure > Support Drawbacks for the user: > Can‟t install user plugins 8
    9. 9. Artifactory SaaS etc. 9
    10. 10. Moving Forward 3 product flavors in production > Challenging support tasks > Completing, not competing 30 million requests/week > Mostly in the Pacific Time Monday mornings 4 TB of artifacts 10
    11. 11. A load of Artifacts! 11
    12. 12. JOURNEY TO THE CLOUD
    13. 13. THE *AAS BUZZ
    14. 14. * As A Service Self Service Multi-tenant
    15. 15. GaaE: Google as an ExampleProduct Self Multi- * aaS Service tenantGmail   Not *aaS, web-appGoogle Apps   SaaSGoogle App Engine   PaaSGoogle Compute Engine   IaaS 15
    16. 16. AaaE: Amazon as an ExampleProduct Self Multi- * aaS Service tenantAmazon store   Not *aaS, web-appaStore   SaaSAmazon Elastic Beanstalk   PaaSAmazon Elastic Cloud   IaaS 16
    17. 17. The SaaS Pains - Overview Multi-tenancy Platform selection > PaaS or IaaS DB schema updates 17
    18. 18. Multi-tenancy Java 9 already! Until then select one of the following: > Use single application, separate data > Use separated applications > Use separated processes 18
    19. 19. GaaE for Multi Tenancy TypesProduct Muli-tenancy TypeGoogle Apps Data SeparationGoogle App Engine Application SeparationGoogle Compute Engine Process Separation 19
    20. 20. Comparing the StrategiesStrategy Pros ConsSeparating data  Normal Java Application  Manual state separation  Complicated and critical schemaSeparating  No shared state  Stay tuned…application  Or is it?  Simple transition from existingSeparating processes  No shared state  JVM per tenant!  Simple transition from existing 20
    21. 21. Comparing the Strategies Strategy Pros ConsSeparating data  Normal Java Application  Manual state separation  Complicated and critical schemaSeparating  No shared state  Stay tuned…application  Or is it?  Simple transition from existingSeparating processes  No shared state  JVM per tenant!  Simple transition from existing 21
    22. 22. Comparing the Strategies Strategy Pros ConsSeparating data  Normal Java Application  Manual state separation  Complicated and critical schemaSeparating  No shared state  Stay tuned…application  Or is it?  Simple transition from existingSeparating processes  No shared state  JVM per tenant!  Simple transition from existing 22
    23. 23. Comparing the StrategiesStrategy Pros ConsSeparating data  Normal Java Application  Manual state separation  Complicated and critical schema Separating  No shared state  Stay tuned…application  Or is it?  Simple transition from existingSeparating processes  No shared state  JVM per tenant!  Simple transition from existing 23
    24. 24. Separate Application: Tomcat Root┌── lib├── webapps│ ├── customer-name│ ├── other-customer-name│ └── many other customers└── other dirs (bin, conf, log, etc) 24
    25. 25. Separate Application Using standard Java WAR classloader isolation Creating standard WAR with dependencies in „lib‟, classes in „classes‟ Creating per-user database Done! 25
    26. 26. Separate Application Using standard Java WAR classloader isolation Creating standard WAR with dependencies in „lib‟, classes in „classes‟ Creating per-user database Done! Perm Gen explodes after deploying 4 WARs > Even when set to 1Gb! 26
    27. 27. The Quest for Shared Libraries The solution – move libraries to shared classloader > Both 3rd party and application > 25 Mbs of JAR files Not as easy as it sounds Review the source code of 3rd party libraries one by one > Open Source FTW 27
    28. 28. THE QUEST FORSHAREDLIBRARIES
    29. 29. Spring Framework Perfect Make sure the context is bounded to thread/war 29
    30. 30. Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware { private static ApplicationContext ctx; public AppCtxHolder() { } public void setApplicationContext(ApplicationContext applicationContext) { ctx = applicationContext; } public static ApplicationContext getApplicationContext() { return ctx; }} 30
    31. 31. Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware { private static ApplicationContext ctx; public AppCtxHolder() { } public void setApplicationContext(ApplicationContext applicationContext) { ctx = applicationContext; } public static ApplicationContext getApplicationContext() { return ctx; }} 31
    32. 32. Spring Frameworkpublic class AppCtxHolder implements ApplicationContextAware { private static ApplicationContext ctx; public AppCtxHolder() { } public void setApplicationContext(ApplicationContext applicationContext) { ctx = applicationContext; } public static ApplicationContext getApplicationContext() { return ctx; }} 32
    33. 33. Apache Wicket Was good New versions added static map of applications > Lesson learned: Recheck on each version upgrade 33
    34. 34. Thread Pools They are not shared – good! Need global management to adjust the size to match all the tenants > Without global thread pool 34
    35. 35. Logger Logger fields are (almost) always static > Can‟t fight it > We MITM-ed the LoggerFactory > Keeps Loggers per application instead of static 35
    36. 36. Race conditions on central locks Examples > Transaction ID > Tomcat ClassLoader Solving race condition generates synchronous initialization 36
    37. 37. CATS Software 37
    38. 38. Jackrabbit Heap-wide temp file cleaner thread > A static thread destroying the temp files of the other tenants > Not as funny as it sounds 38
    39. 39. Heap-wide Caches Lucene and other cache solutions are adjusted for the whole heap size Use SoftReference based caches 39
    40. 40. THE QUEST FOR SHARED LIBRARIES:RESULTS
    41. 41. Tomcat Root – Where‟s the JARs?┌── lib├── webapps│ ├── customer-name│ │ ├── favicon.ico│ │ ├── META-INF│ │ └── WEB-INF│ │ ├── web.xml│ │ └── classes│ │ └── DUMMY.TXT│ ├── other-customer-name│ │ ├── favicon.ico│ │ │ └── META-INF│ │ └── WEB-INF│ └── many other customers└── other dirs (bin, conf, log, etc) 41
    42. 42. Tomcat Root – In Global Lib!┌── lib│ ├── artifactory│ │ ├── artifactory-*.jar│ │ ├── jackrabbit-core-jfrog-2.2.8c.jar│ │ ├── spring-core-3.1.1.RELEASE.jar│ │ ├── wicket-core-1.5.3.jar│ │ └── other jars│ ├── catalina.jar│ ├── servlet-api.jar│ └── other jars├── webapps└── other dirs (bin, conf, log, etc) 42
    43. 43. PaaS or IaaS? Custom Tomcat (our own jars in Tomcat‟s lib) Custom Machine Image with our customized software and configuration Infrastructure as a Service 43
    44. 44. What was it about DB upgrade? Distributed software is concerned with DB upgrade procedures > User experience involved Since we came from there, we have “Converters” > Our SaaS version got it for free 44
    45. 45. THE DEVOPS
    46. 46. Providing Self Service Self Service Platform > Registration > Instance generation › DB › Backup › Virtual Host › WAR > Customer account management 46
    47. 47. Separating Concerns Customer account is only in SaaS Centralized Self-Service portal Intercommunication with the provisioned application of specific tenant > UI Branding > Virtual host control > Backups 47
    48. 48. Outcome: DevOps 4 TB of storage 33 TB of traffic per month Increasing overall performance in an order of magnitude in the last 18 months 48
    49. 49. THE PROCESS
    50. 50. Diversity 3 Versions 3 Deployment formats > WAR > ZIP > RPM Lots of dependencies 50
    51. 51. Recursive Slide (w. baby picture) We eat our own dog food Artifactory is built with Artifactory 51
    52. 52. Right Tools for the Job Snapshots are built, tested & deployed on your build server of choice > With Artifactory plugin Artifactory “snapshot promotion” to sandbox 52
    53. 53. Right Tools for the Job Deploying to production using Chef Other options: > Puppet > Build Server plugins > ZT LiveRebel > Scripts 53
    54. 54. THE PARADIGMSHIFT
    55. 55. Reversing the Cycle Before: 1. Planning downloadable version release 2. Converting it to SaaS version Today: 1. Continuously release to the cloud 2. Once in a while “freezing” it to downloadable version 55
    56. 56. Consequences > Rapid feedback > Host server access > Developers must think big > Standalone updates well tested by SaaS > Standalone application is kind of LTS version 56
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×