By Zeus! Become an Application God with Serverless Swift

In April, Meyume Ltd released "Weather Gods": an app that enables users to receive custom, personalised, push notifications about the weather. As well as providing rich visualisations, graphics and audio allowing you to see hear and feel the weather, Weather Gods is unique in being built using an fully Serverless backend and being written entirely in Swift. In this session we'll introduce you to Serverless, how to build serverless backends in Swift, and show you how the Weather Gods app was built.

Transcript

1. By Zeus! Become an Application God with Serverless Swift Ian Partridge @alfa AltConf 7 June 2017
2. Weather Gods An exciting new premium weather app for iOS, using the characterful metaphor of Gods together with data visualisation to bring a whole new way to look at the weather. Serverless An emerging architectural pattern which allows developers to focus on Dev more than Ops. Execute back-end logic in response to events, and forget about managing infrastructure. OpenWhisk An open source platform for serverless event-driven programming, easily hosted on cloud infrastructure, with a commercial offering available on IBM Bluemix. Agenda 2
3. Weather Gods 3
4. Weather Gods • Premium app from Meyume Ltd. • Offers a rich interactive experience unlike other weather apps. • Sources high quality weather data from multiple providers including The Weather Company. • Features configurable push notifications built on a serverless backend. • Plus widget, 3D touch, and stickers! 4
5. Serverless 5
6. 6 Serverless • Cloud is rapidly disrupting the way that applications are built. • Developers can write apps better, faster, and cheaper than ever. • Cloud providers offer a variety of deployment and charging models. • Infrastructure, Containers, Platforms and Functions are all provided “as a Service”. Decreasing concern (and control) over stack implementation Increasing focus on business logic IaaS CaaS PaaS FaaS
7. IaaS Provision a Virtual Machine or bare metal server. Manage the server yourself. Cloud compute options 7 CaaS Build your app into a Docker container. Orchestrate using tools like Kubernetes. PaaS App-centric runtime environments for deploying applications to the cloud. FaaS Write event-driven business logic and treat compute resources as utilities.
8. 8 Event-driven apps • Spend time on business logic that adds value, not configuring and managing VMs. • Easily consume third-party services without grappling with integration, credentials and SDKs. • Pay only by the resources used, instead of GB/hr for a mostly idle server. • Focus on writing cool apps, not DevOps plumbing!
9. 9 Workloads for event-driven apps • Execute app logic in response to database triggers. • Execute app logic in response to sensor data. • Execute app logic in response to cognitive trends. • Execute app logic on a pre-defined timer schedule. Provide an easy server-side backend for mobile apps.
10. 10 Scaling out microservices Monolithic application 1. 2. 3. 4. Region A Region B Break into microservices Add High Availability Protect against provider outages +
11. 11 Several factors make serverless compelling • Serverless offloads most of the 12 Factor concerns to the cloud provider, freeing the developer. • Event driven workloads need automated scaling which is still challenging with today’s DevOps workflows. • Cost models for serverless are more efficient and provide a clear link between work done and resources used. • Consequently, serverless platforms and frameworks are gaining traction in the market.
12. OpenWhisk 12 whisk \ˈhwisk, ˈwisk\ (v): to move nimbly and quickly
13. 13 OpenWhisk • A fabric and platform for serverless event-driven programming. • An open source FaaS project and ecosystem. • Currently in incubation at the Apache Software Foundation. • Easily hosted on your local machine, an IaaS provider, or use IBM’s commercial offering on Bluemix.
14. 14 OpenWhisk building blocks • Services emit events as triggers. • Developers write actions in response, and bind them to triggers via rules. • Packages are used to bundle and share actions. T A R P
15. 15 Triggers • A class of event that can happen. • For example: • A database update • An IoT sensor activation • A GitHub hook or Slack notification • Or simply an incoming REST request from web or mobile
16. 16 Actions • Small idempotent pieces of code. • For example: • Detect the faces in an image. • Post a tweet. • Retrieve some content from a remote web service. • Can be written in Swift, Node.js, Java, or Python. • Any arbitrary binary can be run via a Docker container. • Must return a JSON payload.
17. 17 Actions • Actions can be composed into sequences. • Sequences encourage actions to be light-weight, and promote action reuse.
18. 18 Rules • Associations of triggers to actions. • Each rule defines a one-to-one mapping between a trigger and an action. • By creating multiple rules, many-to-many mapping can be created.
19. 19 Packages • A shared collection of triggers and actions.
20. OpenWhisk demo 20
21. 21 OpenWhisk debugging • OpenWhisk provides the wskdb debugger • Built as a Node.js package • npm install -g openwhisk-debugger • Uses the appropriate debugger for your action language • Swift: lldb • Python: pdb • Node.js: node debug
22. Serverless in Weather Gods 22
23. 23 Notifications in Weather Gods • The app allows users to choose up to 7 favourite places. • For each favourite place the name, lat/long, timezone and a list of notifications is stored. • Each notification consists of • type (rain, snow etc.) • schedule (evening, morning, or live) • options (e.g. only notify about heavy rain).
24. 24 The road to serverless • The first release of Weather Gods used an Amazon EC2 backend. • The team felt their use case would fit well into a serverless model. • OpenWhisk was chosen due to the open nature of the platform, the native support for Swift actions, and the availability of pre-installed packages including The Weather Company, Cloudant, and push notifications. • For the first experiment with serverless, one OpenWhisk action was used to trigger notification processing on the iOS device.
25. 25 Serverless in Weather Gods • At installation time, devices are registered into one of 60 groups, chosen by the minute of the hour the app was installed. For example, if the app was installed at 15 minutes past the hour the device is enrolled in the weatherGodsRemoteHeartBeat15 group. • An OpenWhisk alarm triggers every 3 minutes and invokes an action to select the group of users to process. • Once the group of users is chosen, a silent push notification is sent to the iOS devices. • Querying weather APIs and generating user notifications occurs locally on the device.
26. 26 Group selection 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 2. Using the chosen colour, select the group based on the minute of the hour. 1. Choose a colour from the hour of the day. 0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Each group is selected once every 3 hours.
27. 27 First OpenWhisk flow in Weather Gods • Initially, OpenWhisk was used to trigger a silent push notification to initiate activity in the app. 3-minute alarm Group scanner Push notification service
28. 28 OpenWhisk flow in Weather Gods • For the next step, application logic was lifted from the app and moved to Swift actions in OpenWhisk. 3-minute alarm Group scanner Weather collector Wind scanner Rain scanner Fog scanner Alarm trigger Alarm trigger Alarm trigger Send push Send push Send push Push notification service
29. OpenWhisk Swift SDK 29
30. 30 OpenWhisk Swift SDK • Mobile client SDK for iOS and watchOS. • Fire remote triggers and invoke remote actions. • Swift 3, iOS9+ and watchOS 3. • Install by using CocoaPods, Carthage, Swift Package Manager, or from the source directory. https://github.com/apache/incubator-openwhisk-client-swift
31. 31 Getting Started // Specify credentials, from `wsk property get —-auth` let credentialsConfiguration = WhiskCredentials(accessKey: "myKey", accessToken: "myToken") let whisk = Whisk(credentials: credentialsConfiguration!) // Specify your OpenWhisk endpoint whisk.baseURL = "http://localhost:8080"
32. 32 Actions // Invoke an action and read the result var params = [String: String]() params["payload"] = "Hello" do { try whisk.invokeAction(name: "hello", parameters: params, hasResult: true, callback: {(reply, error) -> Void in if let error = error { print("Error invoking action \(error.localizedDescription)") } else { var result = reply["result"] print(“Got result \(result)") } }) } catch { print("Error \(error)") }
33. 33 Triggers // Fire a trigger with a payload of the current location var locationParams = [String: String]() locationParams["payload"] = “{\"lat\":37.330680, \"lon\":-121.888329}" do { try whisk.fireTrigger(name: "locationChanged", parameters: locationParams, callback: {(reply, error) -> Void in if let error = error { print("Error firing trigger \(error.localizedDescription)") } else { print("Trigger fired!") } }) } catch { print("Error \(error)") }
34. Conclusion 34 Serverless is a compelling pattern for developing mobile backends quickly. OpenWhisk is a production-ready platform for writing serverless apps, available now on IBM Bluemix. Weather Gods uses OpenWhisk to power a premium weather experience.
35. Thank you 35 Weather Gods weathergodsapp.com
 OpenWhisk openwhisk.org
 OpenWhisk Swift SDK github.com/apache/incubator-openwhisk-client-swift
 Slides speakerdeck.com/ianpartridge/by-zeus-become-an- application-god-with-serverless-swift