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

  • 1,856 views
Uploaded 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 …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,856
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
19
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

  • 1. HOW WE TOOK OUR SERVER-SIDE APPLICATION TO THECLOUD……and liked what we got
  • 2. Agenda Where we started What we did Paradigm shift 2
  • 3. BACKGROUND
  • 4. Who‟s talking? Fred Simon @freddy33 Chief Architect of JFrog Also Head of DevOps Co-author of Artifactory 4
  • 5. Artifactory what? Since 2006 Binary Repository Manager Open Source Standard Java Web Application > Spring > Spring Security > Wicket > JCR > Jersey 5
  • 6. Yet Another Java Server App 6
  • 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. Artifactory SaaS Benefits for the user: > Zero maintenance › Backups › Updates › Infrastructure > Support Drawbacks for the user: > Can‟t install user plugins 8
  • 9. Artifactory SaaS etc. 9
  • 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. A load of Artifacts! 11
  • 12. JOURNEY TO THE CLOUD
  • 13. THE *AAS BUZZ
  • 14. * As A Service Self Service Multi-tenant
  • 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. AaaE: Amazon as an ExampleProduct Self Multi- * aaS Service tenantAmazon store   Not *aaS, web-appaStore   SaaSAmazon Elastic Beanstalk   PaaSAmazon Elastic Cloud   IaaS 16
  • 17. The SaaS Pains - Overview Multi-tenancy Platform selection > PaaS or IaaS DB schema updates 17
  • 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. GaaE for Multi Tenancy TypesProduct Muli-tenancy TypeGoogle Apps Data SeparationGoogle App Engine Application SeparationGoogle Compute Engine Process Separation 19
  • 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. 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. 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. 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. Separate Application: Tomcat Root┌── lib├── webapps│ ├── customer-name│ ├── other-customer-name│ └── many other customers└── other dirs (bin, conf, log, etc) 24
  • 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. 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. 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. THE QUEST FORSHAREDLIBRARIES
  • 29. Spring Framework Perfect Make sure the context is bounded to thread/war 29
  • 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. 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. 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. Apache Wicket Was good New versions added static map of applications > Lesson learned: Recheck on each version upgrade 33
  • 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. 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. Race conditions on central locks Examples > Transaction ID > Tomcat ClassLoader Solving race condition generates synchronous initialization 36
  • 37. CATS Software 37
  • 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. Heap-wide Caches Lucene and other cache solutions are adjusted for the whole heap size Use SoftReference based caches 39
  • 40. THE QUEST FOR SHARED LIBRARIES:RESULTS
  • 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. 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. 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. 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. THE DEVOPS
  • 46. Providing Self Service Self Service Platform > Registration > Instance generation › DB › Backup › Virtual Host › WAR > Customer account management 46
  • 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. 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. THE PROCESS
  • 50. Diversity 3 Versions 3 Deployment formats > WAR > ZIP > RPM Lots of dependencies 50
  • 51. Recursive Slide (w. baby picture) We eat our own dog food Artifactory is built with Artifactory 51
  • 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. Right Tools for the Job Deploying to production using Chef Other options: > Puppet > Build Server plugins > ZT LiveRebel > Scripts 53
  • 54. THE PARADIGMSHIFT
  • 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. Consequences > Rapid feedback > Host server access > Developers must think big > Standalone updates well tested by SaaS > Standalone application is kind of LTS version 56