4 years ago, mid 2013, we have identified a gap in the cloud echo-system. The landscape of IaaS, PaaS and SaaS provides solutions for VMs, Container and Networking, platforms of different types for backend developers, Backends for mobile developers and ready made software for individuals and enterprises. What is missing in the middle is the platform for web-sites and web-apps. 4 years down the line, with the emergence of Serverless, there are still no players in this gap. We will talk about what makes a platform for web-sites and web-apps. Things frontend optimized javascript, SEO, visual builder, web methods & backend javascript as well as request time container boot. We have built Wix Code over the last 4 years targeting this exact gap – a serverless platform for website and web applications, and so … Wix is taking the risk of predicting the future of serverless computing and where it should be 4 years from now.

3. About me
Yoav Abrahami
Head of Wix Code, Wix.com
https://www.linkedin.com/in/yoavabrahami/
https://www.slideshare.net/yoavaa/
@yoavabrahami

4. What we will be talking about?
● What is Serverless
● What we at Wix learned by building a serverless platform
● The potential
● The Technology Challenges
● Disruption

5. 2013, The Cloud Space

6. 2013, The Cloud Space
We have identified a gap
in the cloud platforms space.
No platform aimed at Web Apps
No platform aimed at Websites
Mobile

7. 2013, The Cloud Space
We set out to build Wix Code
A Serverless Platform for
Web Apps and Websites
Mobile

8. So...
What is Serverless?

9. Amazon Lambda
var AWS = require('aws-sdk');
exports.handler = function(event, context) {
handleEvent(event, context);
};
function handleEvent(event, context) {
var cloudSearchDomain = new AWS.CloudSearchDomain({endpoint: config.SearchEndpoint});
var params = {query: event.searchTerm, size: 10, start: 0 };
cloudSearchDomain.search(params, function(err, data) {
if (err) {
context.fail(new Error('Error'));
} else {
context.succeed(processSearchResults(data));
}
});
}
Triggered by:
● S3 upload event
● Kinesis stream
● DynamoDB data change
● API Gateway for Mobile
● API Gateway for Web Apps

10. Amazon Lambda
var AWS = require('aws-sdk');
exports.handler = function(event, context) {
handleEvent(event, context);
};
function handleEvent(event, context) {
var cloudSearchDomain = new AWS.CloudSearchDomain({endpoint: config.SearchEndpoint});
var params = {query: event.searchTerm, size: 10, start: 0 };
cloudSearchDomain.search(params, function(err, data) {
if (err) {
context.fail(new Error('Error'));
} else {
context.succeed(processSearchResults(data));
}
});
}
Amazon Specific APIs
Triggered by:
● S3 upload event
● Kinesis stream
● DynamoDB data change
● API Gateway for Mobile
● API Gateway for Web Apps

11. Google Functions
// HTTP functions
exports.helloHttp = function helloHttp (req, res) {
res.send(`Hello ${req.body.name || 'World'}!`);
};
// background functions
exports.helloBackground = function helloBackground (event, callback) {
callback(null, `Hello ${event.data.name || 'World'}!`);
};
Triggered by:
● HTTP triggers
● Cloud Pub/Sub
● Cloud Storage Triggers

12. Google Functions
// HTTP functions
exports.helloHttp = function helloHttp (req, res) {
res.send(`Hello ${req.body.name || 'World'}!`);
};
// background functions
exports.helloBackground = function helloBackground (event, callback) {
callback(null, `Hello ${event.data.name || 'World'}!`);
};
Google Specific APIs
Triggered by:
● HTTP triggers
● Cloud Pub/Sub
● Cloud Storage Triggers

13. Microsoft Azure Functions
module.exports.hello = (context, req) => {
const res = {};
if (req.query.name || (req.body && req.body.name)) {
const name = req.query.name || req.body.name;
res.body = `Hello ${name}`;
} else {
res.status = 400;
res.body = 'Please pass a name on the query string or in the request body';
}
context.done(null, res);
};
// another example
module.exports.hello = function(context, item) {
context.log("Received item: ${item}");
context.done();
};
Triggered by:
● Data Processing
● Schedule
● Web Hook

14. Microsoft Azure Functions
module.exports.hello = (context, req) => {
const res = {};
if (req.query.name || (req.body && req.body.name)) {
const name = req.query.name || req.body.name;
res.body = `Hello ${name}`;
} else {
res.status = 400;
res.body = 'Please pass a name on the query string or in the request body';
}
context.done(null, res);
};
// another example
module.exports.hello = function(context, item) {
context.log("Received item: ${item}");
context.done();
};
Azure Specific APIs
Triggered by:
● Data Processing
● Schedule
● Web Hook

15. Twilio Functions
exports.handler = function(context, event, callback) {
const response = new Twilio.Response();
response.setBody({
hello: 'world'
});
response.appendHeader('Content-Type', 'application/json');
response.appendHeader('MyHeader', 'MyContent');
callback(null, response);
};
Triggered by:
● Incoming Voice calls
● Incoming Messages

16. Twilio Functions
exports.handler = function(context, event, callback) {
const response = new Twilio.Response();
response.setBody({
hello: 'world'
});
response.appendHeader('Content-Type', 'application/json');
response.appendHeader('MyHeader', 'MyContent');
callback(null, response);
};
Twilio Specific APIs
Triggered by:
● Incoming Voice calls
● Incoming Messages

17. Wix Code - Web Modules
// server code - calculator.jsw
export function calculateLoad(latency, concurrency, traffic) {
let opsPerMinite = 60000 / latency;
return {
idle: Math.max((1 - traffic / opsPerMinite), 0),
utilization: traffic / opsPerMinite / concurrency
};
}
// client code
import {calculateLoad} from 'backend/calculator';
function doLoadCalculation() {
calculateLoad($w('#latency').value, $w('#concurrency').value, $w('#traffic').value)
.then(res => {
$w('#utilized').text = `${toPercent(res.utilization)} Utilized`;
$w('#idle').text = `${toPercent(res.idle)} Idle`;
});
}

18. Wix Code - HTTP Functions
// server code
import {ok} from 'wix-functions';
export function get_calculateLoad(request) {
let latency = request.query.latency;
let concurrency = request.query.concurrency;
let traffic = request.query.traffic;
let opsPerMinite = 60000 / latency;
return ok({
body: {
idle: Math.max((1 - traffic / opsPerMinite), 0),
utilization: traffic / opsPerMinite / concurrency
}
});
}
// a call from a client
curl https://yoav68.wixsite.com/load-calculator/_functions-dev/calculateLoad?latency=10&
concurrency=20&traffic=1000

19. … Server-Side logic ...
… written by the application developer …
... run in stateless compute containers ...
... event-triggered, ephemeral (...),
and fully managed by a 3rd party
-- Martin Fowler quoting ThoughtWorks

20. The Magic Pitch
● No Servers to Manage
● Magic Scaling
● Pay only for what you use
● Just throw your code
Almost sounds like:
Serverless is the DevOps holy grail - Just throw your code over the wall...

21. The Trade
Going Serverless means a trade:
You trade your Freedom for a Managed Service
Sign here
to use my
Serverless

22. The Trade
You trade your Freedom for a Managed Service
Select web framework
Websockets
HTTP streaming / chunked
TCP / IP / UDP
Select programming
Language

23. The Future of Serverless

24. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
Ease of use
Freedom

25. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
Ease of use
Freedom

26. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
EC2
Ease of use
Freedom

27. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
EC2
AppEngine
Ease of use
Freedom

28. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
EC2
AppEngine
Parse.com
Ease of use
Freedom

29. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
EC2
AppEngine
Parse.com
Managed
Containers
Amazon
Lambda
Ease of use
Freedom

30. History of Serverless
ManagedSolution
1995 1999 2006 2008 2012 2014 2017
Hosted
PHP
J2EE
EC2
AppEngine
Parse.com
Managed
Containers
Amazon
Lambda
Wix Code
Ease of use
Freedom

31. Predictions

32. More Serverless Freedom
● Expanding for full support of HTTP, including
● WebSockets
● Streaming / chunked
● Additional protocols - TCP, UDP
● Memoise as a Service - For stateless, side-effect-free functions
● Native serverless options - Go, Rust, C, etc.

33. Consolidation
● Vendors will start to offer similar offerings
● Cross-vendor libraries to ease vendor lock
Partial adoption, vendor ‘added value’ features.
import futureLibrary from 'FUTURE_LIBRARY';
futureLibrary.initMagic(exports, 'AWS');
futureLibrary.eventFunction = function handleEvent(event) {
event.respond(...);
}
● Standards will arise
All vendors will join, never to fully support.
‘added value’ extras

34. Containers

35. Future of Containers
Containers and Kubernetes have a hard choice to make
● Serverless over Kubernetes -
Kubernetes will evolve into runtime for serverless
Move to deploy functions directly, not containers
● Kubernetes and Containers will be abstracted out
Become less and less relevant over time

36. Containers vs Serverless
● Containers and Kubernetes are a system product built by developers
○ Building Docker images
○ Managing running instances
● Serverless are developer facing products
○ Trivial packaging
○ Instances are no longer a concern
● Serverless is a higher level of abstraction

37. Serverless Orchestration
● A serverless runtime will emerge for serverless application Orchestration
● Will run on premise or on cloud
● Based on containers or not
Photo: https://www.secsign.com/cloud-vs-premise-file-sharing-business-4-practical-issues-consider/

38. The Cold Start Problem

39. What is Cold Start?
Have you ever seen this message?

40. Solving the Cold Start Problem
New technology will emerge, taking Cold Start time to under 100 mSec
● Start a VM / Container / Unikernels / Sandbox in under 100 mSec.
If your applications starts in 10 mSec
● Do you need an application instance running 24x7?
● Do you need a fallback instance running 24x7?
● Do you need your database running 24x7?

41. Solving the Cold Start Problem
Solving cold start Changes Cloud Economy
● Imaging a server
0.8% Utilized
84% Idle
Latency: 10 ms / request
Can handle 20 concurrent requests
Traffic: 1000 RPM

42. Solving the Cold Start Problem
Solving cold start Changes Cloud Economy
● Imaging a server
0.8% Utilized
84% Idle
Latency: 10 ms / request
Can handle 20 concurrent requests
Traffic: 1000 RPM
It takes 150,000 daily users,
10 requests each, to generate
1000 RPM

43. Solving the Cold Start Problem
Solving cold start Changes Cloud Economy
● Imaging a server
0.8% Utilized
84% Idle
Latency: 10 ms / request
Can handle 20 concurrent requests
Traffic: 1000 RPM
It takes 150,000 daily users,
10 requests each, to generate
1000 RPM
At Wix - with over 100,000,000 users...
of 2,500 running processes
Only 10% are over 1000 RPM

44. Pay only for what you use
● Functions - You only pay when your function is running
● Interesting fact - the marketing pitch of VMs 10 years ago was
“only pay for what you use”
● Interesting fact - the marketing pitch of App Engine 8 years ago was
“only pay for what you use”
● What went wrong?
Cold Start Latency

45. Cold Start Latency Explained
The time it takes for a process that is not running to respond to the first user
Functions Cold Start time - about 600ms - 2 seconds
~10 mSec
Request
Handler
~100-1000 mSec
Start
process
First Browser
HTTP request
First
response
Scheduler
Overhead
2-120 Sec
Start
instance
● VMs - about 2 minutes
● Containers - about 2 seconds

46. Cold Start Latency
What it means?
● Functions are great for offline events
● Functions are ok for web apps APIs / REST / AJAX
● Functions are fine for high traffic websites - HTML
● Functions are not usable for websites - HTML

47. Website Latency requirement
Functions are not usable for websites - HTML
● Must meet a strict SLA - time to first byte
● Fast websites aim for under 100 mSec (measured on server)
● 200-500 mSec is standard
● Over 2 Sec is considered slow and can harm a website ranking

48. Cold Start Latency
What it means?
● Functions are great for offline events
● Functions are ok for web apps APIs / REST / AJAX
● Functions are fine for high traffic websites - HTML
● Functions are not usable for websites - HTMLNote:
In terms of latency, VMs and
Containers are just as good
for offline events, web apps and
high traffic websites.

49. How we Solved Cold Start
<100 mSec Minutes to hours
Cold
start time
Working
process
Start
process
First Browser
HTTP request
stopping
process
Inject & Load
user code

50. Tailored Serverless

51. Tailored Serverless
Solves a specific business problem
● Twilio - serverless reaction to phone or SMS events
● CloudFlare - serverless proxy logic
● Wix Code - serverless platform for the frontend
● We will see more examples like
Data Processing, Edge logic or Real-time Video processing

52. Serverless replacing Configuration
● Fact - the #1 configuration representation is Javascript
● Fact - the #2 configuration representation is JVM Bytecode
export function newEmailHook(email) {
If (email.from ===
'axis-dev@ws.apache.org')
email.labels.push('J2XB');
}

53. Let’s take Serverless for Frontend
as another example
(Wix Code is such a platform)

54. Why Serverless for the Frontend?

55. What it means, Serverless for
Web Apps?
Websites?

56. What is the difference between
Web Apps and Websites?
SEO

57. Let’s see this in action
Example
● An image gallery - lightGallery
● How browseo bot sees lightGallery
● How evolvedwebsites bot sees lightGallery
Tools to visualize how a bot sees your site
● Google Search Console
● http://www.browseo.net/
● http://www.evolvedwebsites.com.au/googlebot/view.php

58. Web Apps ↔ Websites?
Actually, it is Search Engine Compatibility
Website
Search
Engines
Social
Networks
Bots
Server Side
Rendering
Found By
Found By
Indexed by
read by
expects

59. Web Apps ↔ Websites?
Actually, it is Search Engine Compatibility
Website
Search
Engines
Social
Networks
Bots
Server Side
Rendering
Found By
Found By
Indexed by
read by
expects
Challenging

60. Traditional model - server side language (Ruby, PHP, Java)
client built with React, Angular, Vue, etc.
● Double development, traditionally done by different people
Emerging model - server and client side using javascript
rendering using React, Angular, Meteor, etc.
● Challenging as server rendering time is easily in the 200-600 mSec for a
simple website
● Challenging to setup and configure
Server Side Rendering - Challenging to Develop

61. Lets to the trade again
Going Serverless for frontend
You trade your Freedom for a Managed Service
Sign here
to use my
Serverless

62. Solving Server Side Rendering
Server Side Rendering with time to first byte under 100 mSec
~10 mSec 200-600 mSec
Router
Function
Rendering
Function
100-1000 mSec
Head
received
Browser Loading
Scripts
DOMContentLoaded
Rendering Function
on client
<100 mSec
Cold Start
Time
Browser makes
HTTP request

63. Rethink the Web Server
● Controller Functions
Server functions, handle HTTP request and render HTML, Json, etc.
● Router Functions
Server function, handles HTTP request and selects a page
● Rendering Functions
Isomorphic function that renders the page HTML / DOM.

64. Serverless for Frontend
What you gain
● Cold Start Solution
● Server side rendering
● HTTP Streaming
● Router & Rendering functions
● REST / AJAX functions
● CDN, Domain, Assets, etc.
What you lose
● Choice of a frontend framework
● Choice of a server framework
● Choice of FE build process
Minification, Aggregation, ES6
compile, etc.

65. Takeaway

66. Serverless
Serverless
Orchestration
Disrupts
Containers
Cold Start
Disrupt
Clouds
Tailored
Serverless
Disrupt
Frontend Dev
Disrupt
Configuration

67. Stickers