Microserverless on GCP
millions of requests, dozens of dollars
Joseph Lust mabl engineer @lustcoder
overview
■ Our serverless future
■ Serverless microservices on GCP & GCF
■ Serverless Pain
■ Taming GCF microservices @ mabl
2
startups must push or perish
3
serverless just works
■ No Provisioning
■ Transparent Scaling
■ Event Driven
■ Pay only for Use
4
how developers deploy code
2014
2007 2013
VPS
Machine
Image
Docker
Containers
war File
AWS
Lambda
5
2000
Container Era
Serverless Era
Firebase
CF
Serverless functions
GCF
2016 2017
AF
event driven all the way
■ Only run code on events
▲ Cloud Storage blob changes
▲ Pubsub message arrival
▲ HTTP endpoint requests
▲ DB/Auth/Conversion changes
■ No machines consuming 2% CPU all day
6
exports.myService = function(event) {
console.log(‘hello world’);
}
mvf
exports.myService = () => console.log(‘hello world’);
mvf
es6+
but what do functions cost?
9
gcf is the cheapest function provider
Vendor FREE req/mo req/$
Google Cloud Functions 2M 5M
Firebase Cloud Functions 2M 2.5M
AWS Lambda 1M 5M
Azure Functions 1M 5M
10
See full details in Google Spreadsheet calculator
* Also see execution time, bandwidth, and memory costs
gcf cheapest counting free monthly allowances
11
* Also see execution time, bandwidth, and memory costs
gcf differentiators
■ Largest possible function memory: 2 GBytes
■ Guaranteed CPU per memory allotment
■ Node first focus
■ Easy to use UI and tools
■ Stackdriver Logging & Error Reporting
Source: GCP Pricing, FB Pricing, AWS Lambda Pricing, Azure Pricing
12
but, what about Microservices?
13
the bane of classic monoliths: tomcat to fat cats
■ Large code bases
■ Larger surface area
■ Server memory bloat
■ Deploy rarely, if ever
14
microservices solve many pains
■ Minimize code size
▲ Can scale servers, not developers’ minds
■ Minimize deploy speed/code
■ Minimize blast radius
■ Decoupling, Coherence, Singleness of Purpose
15
∴, MicroServerless!
16
but, there are some speed bumps...
17
functions are not designed for failure*
18
* retry
functions require total trust
19
blazing fast function deployment
20
lossy pubsub deployments
21
work arounds to the rescue
22
how we solved these issues @ mabl
23
how do you decouple services and handle discovery
■ We Don’t Do Discovery
■ Event Driven Queues
▲ HTTP endpoints for external services
▲ Blob change events for files
▲ Message queue events for everything else
■ No Daemons
▲ Don’t waste time spinning
24
decoupled async functions pattern
25
how do you handle changing microservice/models?
■ Versioned Payloads over the wire
▲ New service can handle older versions
■ Add Consumers, then Suppliers
■ Upgrade, don’t replace
■ Lazy read repair
▲ Pessimistic data upgrade and transform
▲ Upgrade path from old version
26
how do make slow deploys fast?
■ Multi-repo git layout
■ File change exclusion masks
■ Deploy functions in parallel
■ Harness CI & CD (e.g. Codeship)
27
how do you handle GCG outages?
■ Durable Pubsub subscriptions
■ No microservices on fast path
▲ Backend processing
▲ Keep the UI and lights on via Firebase
■ It’s Beta ;)
28
request costs round up
■ Requests billed per 100ms
■ Increments round up
■ Faster functions are not always cheaper
▲ 17ms → 100ms
▲ 101ms → 200ms
29
Run Time:
17ms
Billed Time: 100ms
Wasted
Time
minimizing your request costs
■ Batch multiple fast work units to fill the time (e.g. 100ms chunks)
30
Work Unit:
17ms
Billed Time: 100ms
Work Unit:
17ms
Work Unit:
17ms
Work Unit:
17ms
Work Unit:
17ms
Wasted
Time
minimizing your request costs
31
■ Use a middle man to shield file events from high memory loads
▲ Filter/light weight checks in middle man
▲ Send heavy lifting to larger function
■ Different inputs to same service have different resource needs
▲ e.g. 90% requests need 128MB ram, 10% need 512GB
▲ e.g. 80% requests complete in 30s, 20s take 2min
32
maximizing performance
■ Tune your CPU & Memory to the job
▲ Profile your microservices - CPU or memory bound?
■ More memory runs faster
▲ Greater CPU dedicated to larger memory allocation functions
▲ 128MB → 200 MHz
▲ 2048MB → 2.4GHz
▲ CPU/Memory costs increase linearly
■ Cache expensive objects between requests
▲ PubSub connections
▲ Firebase Admin instances
▲ Login tokens
33
but seriously, what’s this cost you?
34
track everything, from bits to cents
■ Metrics for every execution
▲ Every Byte of memory use
▲ Every Processor Cycle of runtime
▲ Every Byte of egress
▲ Every Invocation
■ Direct Billing to Big Query export
▲ Easy to explore and query (demo)
▲ Easy to visualize with Data Studio (demo)
35
BigQuery and DataStudio Demo
36
37
38
billing tips
■ Label functions on deploy
▲ Labels propagated to billing
▲ Can track Memory, CPU, Invocation, Ingress, Egress costs per function
■ Don’t forget the egress bandwidth
▲ Keep your data stores in the same region (Iowa)
▲ GCF only deployable to Iowa
39
gcloud beta functions deploy <your_fn> 
--labels=”app_name=<your_fn>” 
...
so, in conclusion
40
embrace gcf microserverless
■ For low latency, event driven demands
■ For decoupled, cohesive, independent services
■ For painless deployment and auto-scaling
■ For reduced opex
41
gcp serverless resources
■ FB CF Examples Repo: github.com/firebase/functions-samples
■ GCF Examples: github.com/GoogleCloudPlatform/nodejs-docs-samples
■ Jason Polites (great) Examples: github.com/jasonpolites/gcf-recipes
■ I/O 2017 CF Presentations
▲ Building the Fire!sale demo app: youtu.be/G-MBeEW92v4
▲ FB and ML with CF: youtu.be/RdqV_N0sCpM
▲ FB CF and Testability: youtu.be/SnWwkURpwxs
▲ Data Pipelines with CF: youtu.be/guo-4IOqx2M
42
@lustcoder
Questions?
Meetup, Coming up...
■ Google speakers
■ Need your great talks
■ Need your favorite topics
▲ Survey to follow
44
Thanks for coming!

Going Microserverless on Google Cloud @ mabl

  • 1.
    Microserverless on GCP millionsof requests, dozens of dollars Joseph Lust mabl engineer @lustcoder
  • 2.
    overview ■ Our serverlessfuture ■ Serverless microservices on GCP & GCF ■ Serverless Pain ■ Taming GCF microservices @ mabl 2
  • 3.
    startups must pushor perish 3
  • 4.
    serverless just works ■No Provisioning ■ Transparent Scaling ■ Event Driven ■ Pay only for Use 4
  • 5.
    how developers deploycode 2014 2007 2013 VPS Machine Image Docker Containers war File AWS Lambda 5 2000 Container Era Serverless Era Firebase CF Serverless functions GCF 2016 2017 AF
  • 6.
    event driven allthe way ■ Only run code on events ▲ Cloud Storage blob changes ▲ Pubsub message arrival ▲ HTTP endpoint requests ▲ DB/Auth/Conversion changes ■ No machines consuming 2% CPU all day 6
  • 7.
    exports.myService = function(event){ console.log(‘hello world’); } mvf
  • 8.
    exports.myService = ()=> console.log(‘hello world’); mvf es6+
  • 9.
    but what dofunctions cost? 9
  • 10.
    gcf is thecheapest function provider Vendor FREE req/mo req/$ Google Cloud Functions 2M 5M Firebase Cloud Functions 2M 2.5M AWS Lambda 1M 5M Azure Functions 1M 5M 10 See full details in Google Spreadsheet calculator * Also see execution time, bandwidth, and memory costs
  • 11.
    gcf cheapest countingfree monthly allowances 11 * Also see execution time, bandwidth, and memory costs
  • 12.
    gcf differentiators ■ Largestpossible function memory: 2 GBytes ■ Guaranteed CPU per memory allotment ■ Node first focus ■ Easy to use UI and tools ■ Stackdriver Logging & Error Reporting Source: GCP Pricing, FB Pricing, AWS Lambda Pricing, Azure Pricing 12
  • 13.
    but, what aboutMicroservices? 13
  • 14.
    the bane ofclassic monoliths: tomcat to fat cats ■ Large code bases ■ Larger surface area ■ Server memory bloat ■ Deploy rarely, if ever 14
  • 15.
    microservices solve manypains ■ Minimize code size ▲ Can scale servers, not developers’ minds ■ Minimize deploy speed/code ■ Minimize blast radius ■ Decoupling, Coherence, Singleness of Purpose 15
  • 16.
  • 17.
    but, there aresome speed bumps... 17
  • 18.
    functions are notdesigned for failure* 18 * retry
  • 19.
  • 20.
    blazing fast functiondeployment 20
  • 21.
  • 22.
    work arounds tothe rescue 22
  • 23.
    how we solvedthese issues @ mabl 23
  • 24.
    how do youdecouple services and handle discovery ■ We Don’t Do Discovery ■ Event Driven Queues ▲ HTTP endpoints for external services ▲ Blob change events for files ▲ Message queue events for everything else ■ No Daemons ▲ Don’t waste time spinning 24
  • 25.
  • 26.
    how do youhandle changing microservice/models? ■ Versioned Payloads over the wire ▲ New service can handle older versions ■ Add Consumers, then Suppliers ■ Upgrade, don’t replace ■ Lazy read repair ▲ Pessimistic data upgrade and transform ▲ Upgrade path from old version 26
  • 27.
    how do makeslow deploys fast? ■ Multi-repo git layout ■ File change exclusion masks ■ Deploy functions in parallel ■ Harness CI & CD (e.g. Codeship) 27
  • 28.
    how do youhandle GCG outages? ■ Durable Pubsub subscriptions ■ No microservices on fast path ▲ Backend processing ▲ Keep the UI and lights on via Firebase ■ It’s Beta ;) 28
  • 29.
    request costs roundup ■ Requests billed per 100ms ■ Increments round up ■ Faster functions are not always cheaper ▲ 17ms → 100ms ▲ 101ms → 200ms 29 Run Time: 17ms Billed Time: 100ms Wasted Time
  • 30.
    minimizing your requestcosts ■ Batch multiple fast work units to fill the time (e.g. 100ms chunks) 30 Work Unit: 17ms Billed Time: 100ms Work Unit: 17ms Work Unit: 17ms Work Unit: 17ms Work Unit: 17ms Wasted Time
  • 31.
    minimizing your requestcosts 31 ■ Use a middle man to shield file events from high memory loads ▲ Filter/light weight checks in middle man ▲ Send heavy lifting to larger function ■ Different inputs to same service have different resource needs ▲ e.g. 90% requests need 128MB ram, 10% need 512GB ▲ e.g. 80% requests complete in 30s, 20s take 2min
  • 32.
  • 33.
    maximizing performance ■ Tuneyour CPU & Memory to the job ▲ Profile your microservices - CPU or memory bound? ■ More memory runs faster ▲ Greater CPU dedicated to larger memory allocation functions ▲ 128MB → 200 MHz ▲ 2048MB → 2.4GHz ▲ CPU/Memory costs increase linearly ■ Cache expensive objects between requests ▲ PubSub connections ▲ Firebase Admin instances ▲ Login tokens 33
  • 34.
    but seriously, what’sthis cost you? 34
  • 35.
    track everything, frombits to cents ■ Metrics for every execution ▲ Every Byte of memory use ▲ Every Processor Cycle of runtime ▲ Every Byte of egress ▲ Every Invocation ■ Direct Billing to Big Query export ▲ Easy to explore and query (demo) ▲ Easy to visualize with Data Studio (demo) 35
  • 36.
  • 37.
  • 38.
  • 39.
    billing tips ■ Labelfunctions on deploy ▲ Labels propagated to billing ▲ Can track Memory, CPU, Invocation, Ingress, Egress costs per function ■ Don’t forget the egress bandwidth ▲ Keep your data stores in the same region (Iowa) ▲ GCF only deployable to Iowa 39 gcloud beta functions deploy <your_fn> --labels=”app_name=<your_fn>” ...
  • 40.
  • 41.
    embrace gcf microserverless ■For low latency, event driven demands ■ For decoupled, cohesive, independent services ■ For painless deployment and auto-scaling ■ For reduced opex 41
  • 42.
    gcp serverless resources ■FB CF Examples Repo: github.com/firebase/functions-samples ■ GCF Examples: github.com/GoogleCloudPlatform/nodejs-docs-samples ■ Jason Polites (great) Examples: github.com/jasonpolites/gcf-recipes ■ I/O 2017 CF Presentations ▲ Building the Fire!sale demo app: youtu.be/G-MBeEW92v4 ▲ FB and ML with CF: youtu.be/RdqV_N0sCpM ▲ FB CF and Testability: youtu.be/SnWwkURpwxs ▲ Data Pipelines with CF: youtu.be/guo-4IOqx2M 42 @lustcoder
  • 43.
  • 44.
    Meetup, Coming up... ■Google speakers ■ Need your great talks ■ Need your favorite topics ▲ Survey to follow 44 Thanks for coming!