Fred Simon discusses JFrog's journey to moving their server-side application Artifactory to the cloud as a Software-as-a-Service (SaaS) offering. They evaluated different multi-tenancy strategies like separating data, applications, and processes. They worked to share libraries across tenants to avoid memory issues. JFrog implemented a self-service portal and DevOps processes to automate provisioning and updates. The transition resulted in improved performance and a paradigm shift where versions are first continuously released to the cloud and later packaged for download.

1. HOW WE TOOK OUR SERVER-
SIDE APPLICATION TO THE
CLOUD…
…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 Example
Product Self Multi- * aaS
Service tenant
Gmail
  Not *aaS,
web-app
Google Apps
  SaaS
Google App Engine
  PaaS
Google Compute Engine
  IaaS
15

16. AaaE: Amazon as an Example
Product Self Multi- * aaS
Service tenant
Amazon store
  Not *aaS, web-app
aStore
  SaaS
Amazon Elastic Beanstalk
  PaaS
Amazon 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 Types
Product Muli-tenancy Type
Google Apps Data Separation
Google App Engine Application Separation
Google Compute Engine Process Separation
19

20. Comparing the Strategies
Strategy Pros Cons
Separating data  Normal Java Application  Manual state
separation
 Complicated and
critical schema
Separating  No shared state  Stay tuned…
application  Or is it?
 Simple transition from
existing
Separating processes  No shared state  JVM per tenant!
 Simple transition from
existing
20

21. Comparing the Strategies

Strategy Pros Cons
Separating data  Normal Java Application  Manual state
separation
 Complicated and
critical schema
Separating  No shared state  Stay tuned…
application  Or is it?
 Simple transition from
existing
Separating processes  No shared state  JVM per tenant!
 Simple transition from
existing
21

22. Comparing the Strategies

Strategy Pros Cons
Separating data  Normal Java Application  Manual state
separation
 Complicated and
critical schema
Separating  No shared state  Stay tuned…
application  Or is it?
 Simple transition from

existing
Separating processes  No shared state  JVM per tenant!
 Simple transition from
existing
22

23. Comparing the Strategies

Strategy Pros Cons
Separating data  Normal Java Application  Manual state
separation
 Complicated and
critical schema

Separating  No shared state  Stay tuned…
application  Or is it?
 Simple transition from

existing
Separating 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 FOR
SHARED
LIBRARIES

29. Spring Framework
 Perfect
 Make sure the context is bounded to
thread/war
29

30. Spring Framework
public 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 Framework
public 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 Framework
public 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 PARADIGM
SHIFT

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