Introduction to Serverless Computing and Docker

1. Serverless Computing
&
Docker
07-Jan-2017, Docker Bangalore Meetup @Go-Jek
Thomas Chacko
thomasch (at) iconnexions.com

2. What is Serverless Computing ?
Is a cloud-native platform & app design paradigm
( which DOES involves Servers which are ‘invisible’ to developers [& Ops] ! )
for
short-running, stateless computing
and
(primarily) event-driven applications
which
aims to radically simplify development and operations
and
scales up and down instantly and automatically at runtime
and
billed for actual usage of compute time ( and/or memory)
at millisecond granularity
Serverless == React Compute == FaaS == No Servers To Manage (*)

3. source : martinfowler.com
Monolith
Application
μ Srv μ Srv μ Srv
f(x) f(x) f(x) f(x)
Tier-App Tier-App
Tier-App
Serverless Architecture

4. What is Serverless architecture suitable for ?
Serverless is suitable for
short-running,
stateless,
event-driven workload
Serverless is NOT suitable for
long-running,
stateful,
number crunching workload
Microservices Transactional databases
Mobile Backends Deep learning/ML training
Bots, ML interfacing Heavy-duty stream analytics
IoT Spark/Hadoop analytics jobs
Data (Stream,Log) processing Numerical Simulations
Image processing, Cognitive Video Streaming

5. Why is Serverless gaining popularity?
Efficiency Costs Complexity
Developers : Simple coding - bits of code
Enhanced scalability
Focus on feature and UE - deliver value
( abstract away Infrastructure )
Accelerate MVP, TTM
IT/Ops : Pay by millseconds - pay per execution model
Optimisation of resource
Gain infrastructure utilisation (time sliced)

6. Serverless offerrings
Vendor / Framework Maturity Support for functions coded in
Amazon Lambda GA Node.js , Python, Java , C#
Google Cloud Function Alpha Node.js
Microsoft Azure function GA - v1.0 JS, Python, C#, PHP, scripting bash, PS
IBM OpenWhisk JS , Swift, Python, Java, Any (via Docker)
iron.io ( Iron Function ) Alpha-2 Any language ( via Docker packaging )
Docker PoC Any language ( via Docker packaging )

7. IronFunction demo
• Fire up an Iron/function containter
$ docker run --rm -it --name functions --privileged -v ${pwd}/data:/app/data -p 8080:8080 iron/functions
• Write a function e.g. func.go
• create func.yaml file, replace $USERNAME with your Docker Hub username.
$ fn init $USERNAME/hello
• Build, test the function and if ok - push to docker hub
$ fn build
$ fn run
$ fn push
• Create an app ‘myapp’ and set a route to map /hello to function.
An App is a grouping of function == API gateway
$ fn apps create myapp
$ fn routes create myapp /hello
• Call the function from ‘anywhere’ . Each APP has its own namespace
$ curl http://localhost:8080/r/myapp/hello ; curl
$ fn call myapp/hello ; CLI
$ echo '{"name":"All Ye Docker Enthusiasts"}' | fn call myapp /hello ; parameter pass at runtime
• Supports async function calls too for CPU heavy tasks like image/data/video processing. Non-blocking as async
function calls go in message queue and executed when resource become eventually available.

8. Demo 1 : Serverless App with Docker
voting app
msg queue
worker
database
result app
entry point
database
handle vote
HTTP request
handle result
HTTP request
process vote
tasks
continous runnng services
continous runnng servicesf(x) container on demand
source : Ben Firshman donkerconf 2016 demo
backends : worker & message queue replaced with Docker container run on demand (
practically should scale to swarm ‘size’ on demand )
web frontends : voting app , result app replaced with Docker containers which spins up serving
single HTTP request -> triggerred by a light weight HTTP
server (entry point ~ LB )
( practical ?? latency of container cold start ~ 300ms - 1 s )
http://node-ip/vote
http://node-ip/result

9. Demo 2 : Using Funker on Swarm mode
voting app
database
result app
process_vote
continous runnng services
continous runnng servicesf(x) container on demand
Funker (package): Function as Docker container
Define function as services
When initiated, opens a TCP port and wait for connection
To call function - another docker service connects to
function at its hostname (any node within swarm)
process_vote/handler.js :
var funker = require('funker');
funker.handle(function(args, callback) {
// Return immediately so this fx runs in
background
callback();
.. process vote ...
}
vote/app.py
funker.call("process-vote", voter_id=voter_id,
vote=vote)
node-ip:5000 node-ip:5001

10. One perspective of where we are headed with this…