Build event driven, low latency, decoupled microservices on the serverless GCP infrastructure with Cloud Functions, PubSub, and Cloud Storage. Don't pay for what you don't use. Don't wait for daemons to sink up. Take computing actions when their needed, rapidly, cheaply, and robustly with microserverless.

1. Microserverless on GCP
millions of requests, dozens of dollars
Joseph Lust mabl engineer @lustcoder

2. overview
■ Our serverless future
■ Serverless microservices on GCP & GCF
■ Serverless Pain
■ Taming GCF microservices @ mabl
2

3. startups must push or perish
3

4. serverless just works
■ No Provisioning
■ Transparent Scaling
■ Event Driven
■ Pay only for Use
4

5. 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

6. 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

7. exports.myService = function(event) {
console.log(‘hello world’);
}
mvf

8. exports.myService = () => console.log(‘hello world’);
mvf
es6+

9. but what do functions cost?
9

10. 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

11. gcf cheapest counting free monthly allowances
11
* Also see execution time, bandwidth, and memory costs

12. 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

13. but, what about Microservices?
13

14. the bane of classic monoliths: tomcat to fat cats
■ Large code bases
■ Larger surface area
■ Server memory bloat
■ Deploy rarely, if ever
14

15. 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

16. ∴, MicroServerless!
16

17. but, there are some speed bumps...
17

18. functions are not designed for failure*
18
* retry

19. functions require total trust
19

20. blazing fast function deployment
20

21. lossy pubsub deployments
21

22. work arounds to the rescue
22

23. how we solved these issues @ mabl
23

24. 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

25. decoupled async functions pattern
25

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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. 32

33. 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

34. but seriously, what’s this cost you?
34

35. 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

36. BigQuery and DataStudio Demo
36

37. 37

38. 38

39. 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>”
...

40. so, in conclusion
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. Questions?

44. Meetup, Coming up...
■ Google speakers
■ Need your great talks
■ Need your favorite topics
▲ Survey to follow
44
Thanks for coming!