PaaL for SaaS
Transition into SaaS
- Small scale (just one customer)
- Full control (you can tweak the software)
- Secure by default (access from customer's network)
From per-customer deployment
- Large scale (all customers)
- One-size-fits-all
- Open to the Internet
To a single deployment
Open to the Internet
- Not secure by default: Anyone can access
- User privacy becomes your concern
- Data from different customers resides on the same database
- It is your job to prevent a leak...
One Size Fits All
- Cannot do per-customer customization using code changes.
- Cannot do per-customer customization using config files!
- Per-customer customization needs to be part of the state of the application, just like user data!
Size does Matter!
- No SQL...
- Sharding / NoSQL
- Data Denormalization
Tweeter-like Example
class User:
def __init__(self):
self.tweets = []
self.followers = []
self.followees = []
def tweet(self, tweet):
self.tweets.append(tweet)
def follow(self, other):
self.followees.append(other)
other.followers.append(self)
def timeline(self):
for followee in self.followees:
for tweet in followee.tweets:
yield tweet
Denormalization Example
class User:
def __init__(self):
self.tweets = []
self.followers = []
self.followees = []
self.timeline = []
def tweet(self, tweet):
self.tweets.append(tweet)
for follower in self.followers:
follower.timeline.append(tweet)
def follow(self, other):
self.followees.append(other)
other.followers.append(self)
for tweet in other.tweets:
self.timeline.append(tweet)
Denormalized Joins
- When adding a tweet
- When deleting a tweet
- When starting to follow
- When stopping to follow
Denormalization loops are needed:
The Eventual Consistency Problem
What happens when user A starts following user B at about the same time when user B tweets T?
def tweet(self, tweet):
self.tweets.append(tweet)
for follower in self.followers:
follower.timeline.append(tweet)
def follow(self, other):
self.followees.append(other)
other.followers.append(self)
for tweet in other.tweets:
self.timeline.append(tweet)
A follows B
B tweets T
The Problem is Dichotomy!
The Problem is not SaaS
Dichotomy in Applications
Business Logic
Data
Programming Language
Business Logic
Programmer
User
What:
Web Server
Database
Where:
How:
Who:
Programmers vs. Users
- A "one size fits all" application
- Customers need a way to customize their solution
- The app needs to provide a sophisticated customization model
- ... which is, in a way, a programming language
- Making the user a programmer...
PL vs. BL vs. Data
- The implementation of a PL takes the BL as its data
- The BL reads the data and acts upon it
- Interprets it...
- Smart Customization: The BL is a programming language...
Web Server vs. Database
- Traditionally, Web servers and Databases are mutually exclusive...
- Apache CouchDB is a counterexample...
The Vision:
Business Logic
Data
Programming Language
Business Logic
Programmer
User
What:
Web Server
Database
Where:
How:
Who:
=
=
=
=
Side by Side
Instead of being a heirarchy:
PL → BL → Data
Can they be placed side by side?
Software library, not an interpreter...
Now This is Crazy Talk!
Data using BL as a software library?
Reminder: There's a demo at the end...
Deductive Databases
- Databases based on Logic Programming
- Traditionally, based on Datalog
- See the world as two kinds of axioms:
- Facts
- Rules
Facts
- follows(alice, bob)
- tweeted(bob, "Hello")
Rules
follows(A, B)→
tweeted(B, T)→
timeline(A, B, T)
Evaluation (1)
follows(A, B)→
tweeted(B, T)→
timeline(A, B, T)
+
follows(alice, bob)
tweeted(bob, T)→
timeline(alice, bob, T)
Evaluation (2)
+
tweeted(bob, "Hello")
tweeted(bob, T)→
timeline(alice, bob, T)
timeline(alice, bob, "Hello")
Yeh, but deductive databases are practically dead for 20 years...
- Datalog gave in to SQL
- SQL gave in to NoSQL...
So, what's next?
NoDatalog
- Deductive databases for the 21st century
- Rules evaluated on update
- Denormalization
- Compound terms
- Think documents in NoSQL...