2. Please Note:
2
• IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole
discretion.
• Information regarding potential future products is intended to outline our general product direction and it should not be relied on in
making a purchasing decision.
• The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any
material, code or functionality. Information about potential future products may not be incorporated into any contract.
• The development, release, and timing of any future features or functionality described for our products remains at our sole
discretion.
• Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual
throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the
amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
3. Agenda
• OpenWhisk in a nutshell
• What OpenWhisk is and how it works
• Usage scenarios
• OpenWhisk programming model
• OpenWhisk architecture
• Live demo
• Summary & Questions
3
4. OpenWhisk in a nutshell
Cloud platform to execute code in response to events
5. Whisk in a nutshell
Serverless deployment & operations model
We hide infrastructural and operational complexity allowing you to focus on coding:
You provide code – we execute it! – FaaS = Function as a Service
Optimal utilization, fair pricing at any scale
We provide you exactly the resources you need – neither less nor more - and charge
you only for code really being executed
Flexible programming model & powerful tooling
We support multiple languages (incl. Swift) and custom logic via docker containers, plus
tools to declaratively chain your code snippets
Open & open ecosysten
Open to run anywhere to avoid any kind of vendor lock-in and to accelerate the
development of a powerful ecosystem
6. Execute app logic in response to data triggers
Execute app logic in response to sensed data (IoT)
Execute app logic in response to cognitive trends
Execute app logic in response to scheduled tasks
Provide easy server-side backend for mobile app
Typical Scenarios
7. OpenWhisk: Another way to build apps…
BYOC: Bring Your Own Code
Ease of getting started Full stack Control
OpenWhisk
Event-driven apps
deployed in a
serverless
environment
Instant
Runtimes
App-centric
runtimes
based on
Cloud Foundry
IBM Containers
Portable delivery
of your app
without having to
manage an OS
Virtual Machines
Most flexibility
and control
with VMs
8. Meet Dave & his team
Dave is lead architect of an online photo community and marketplace
– Operate a platform to
– share and photos
– edit and categorize photos via manual tagging
8
9. Meet Dave & his team
To be competitive, Dave‘s team need to continously add innovative features
– Idea: Provide a mobile app that allows to automatically sharpen, noise-
reduce and semantically tag photos being uploaded
9
10. Design requirements
Dave & his team want to focus on developing value-adding code
instead of low-level infrastructural & operational details
11. OpenWhisk solution
Flexible programming environment
Open ecosystem of building blocks
Outsource computing tasks to the cloud
No servers to manage or maintain
Automatic scaling with load
Built-in fault tolerance
Pay as you go
12. Some usage Scenarios
OpenWhisk can help power
various mobile, web and IoT app
usecases by simplifying the
programming model of
orchestrating various services
using events without a dedicated
backend.
Digital app workloads Big Data/Analytics pipeline
Complex data pipeline for Big
Data/Analytics tasks can be scripted
using changes in data services or
streams for near real-time analytics
and feedback.
DevOps & infrastructure as code
OpenWhisk can be used to
automate DevOps pipeline based
on events triggered from
successful builds or completed
staging or a go-live event.
Micro-Services builder
Whisk can be used to easily build
micro-services given the footprint
and programming model desired by
micro services
13. OpenWhisk: How does it work?
Incoming HTTP request, e.g.
HTTP GET
coolapp.com/customers
11
Invoke OpenWhisk
action getCustomers
Browser
Mobile App
Web App
Variety of
languages
Variety of
languages
22
JS Swift Docker …
OpenWhisk
14. OpenWhisk: How does it work?
Event
Providers
Cloudant
Git
Weather
…
Trigger execution of associated
OpenWhisk action
22
…
JS Swift Docker …
Data event occurs, e.g. commit on a Git
repository, CRUD operation on Cloudant
11
OpenWhisk
15. Programming model
Services define the events they emit as triggers, and developers
associate the actions to handle the events via rules
TT AA RR
20. Programming model
Actions: Can be chained to create sequences to increase flexibility and
foster reuse
AA
AA
AA := A1
A1 + A2
A2 + A3
A3
AB
AB := A2
A2 + A1
A1 + A3
A3
AC
AC := A3
A3 + A1
A1 + A2
A2
22. Programming model
Packages: A shared collection of triggers and actionsPP
AA
AA read
write
TT changes AA translate AA forecast
AA post
TT topic
Open
Source AA myAction
TT myFeed
Yours
TT commit
Third
Party
23. OpenWhisk Core – System Architecture
23
Edge
Proxy
Log
Forwarder
UI
Consul
Registrator
Log Forwarder
EntitlementController
E
Registrator
Log Forwarder
Invoker
Master
30. Summary
• OpenWhisk…
– allows you to focus on developing value-adding code
– provides you with a flexible programming model for small agile teams
– provides you with access to an open ecosystem of building blocks
– allows you to compose powerful solutions using modern abstraction
and chaining
– allows you to share and reuse what you have build
– allows you to outsource load & calculation intensive tasks
– only charges you for what you really use
– is available as open solution in which you can participate
31. Summary
• What else have we seen & learnt?
– Actions are executed, blocking or non-blocking, in response to events
– Actions can be in Node, Swift, or even Docker containers to execute
custom logic… and there is more to come
– Actions can even be chained to compose powerful solutions
– Out of the box support for event sources such as Cloudant and Github
as well as scheduled actions
– Tooling comprised of CLI, REST API, and iOS SDK
• What have we not seen? Complexity!
34. Notices and Disclaimers Con’t.
34
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not
tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the
ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other
intellectual property right.
IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®,
FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®,
PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®,
StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business
Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
37. OpenWhisk: Comparison to traditional
models
• OpenWhisk
– Introduces event programming model
– Charges only for what is used
– Auto-scales Pool of actions
Swift DockerJS
Trigger
11
Running
action
Running
action
Running
action
33
Deploy action within millisecs,
run it,
free up resources
OpenWhisk
Engine
22
Today I’m going to present an overview of OpenWhisk, discuss what it is, how can you use it, present the programming model it introduces and if the demo gods approve, I’ll conclude with a live demo of an integration of Slack and OpenWhisk.
How many of you have heard of serverless computing? How many of you think they run a function in a serverless platform?
OpenWhisk is a cloud platform that allows users to execute code in response to events. It really is an event-based distributed system.
From the user’s point of view, the deployment of the code is serverless. That doesn’t mean that there are no servers, it means that the user doesn’t have to worry about that. All the user has to do is to provide a function and specify the event that should trigger the execution of the function. From that point of view, I find severless confusing, so I much prefer the “FaaS” name
So today we’ll try to understand what’s the fuss about FaaS
One of the most important characteristics of such a model of computation is that autoscaling comes for free. The system is responsible with allocating resources on behalf of the user to run the code in response to the demand load. In addition, the pricing follows a “pay-as-you-go” model, which means that the user pays for the amount of time the code executed. This is unlike traditional cloud computation where you have to pay for as long as the server is up and running, irrespective of whether there is load or not, so you pay even when your server is sitting idle.
Such FaaS platforms offer a flexible programming model as they support multiple languages and ways to compose the code in sophisticated patterns.
In addition, something that is unique to OpenWhisk is that the project is open-source. This is great as it avoids vendor-lockin and it also leverages the power of the community.
FaaS platforms ca be used in many scenarios. As I mentioned, these systems are event-based systems, so one of the most important aspect is the source of events. You can imagine writing applications that react to events from database events, IoT devices, financial trends or any other analytics-based trends. You can even schedule periodic tasks. Last but not least, OpenWhisk can be used to move the backend logic of mobile apps out of the mobile device. As we support Swift, mobile developers can do this migration gradually, and working in the same ecosystem.
How does OpenWhisk fit in the Bluemix line of services? OpenWhisk is one of the Compute options offered by Bluemix. At one end of the spectrum, you can use VMs which offers full control over the computational stack. You can also use containers as the unit of deployment. There is also the option of deploying instant runtimes. OpenWhisk is really the easiest and lowest entry-point, where the unit of deployment is really a function.
Let’s think from the perspective of a small startup. Meet Dave and his team. They’re all working on a photo community and marketplace and they operate a platform to show off your photos and edit and tag photos.
To stay competitive, Dave and his team need to come up with features that make their products appealing and easy to use. In this context, they come up with the idea of providing a mobile app that allows users to quickly apply some standard filters, upload the photos and automatically tag them given their content.
Dave would really like to focus on the core app logic instead of thinking of launching servers, maintaining and managing them. So Dave is looking into serverless platforms, specially OpenWhisk.
Let’s stop and think what an OpenWhisk solution really means. Each component of the app can be written in a different language, the best language for the task at hand. Some of the building blocks can be used directly as off-the-shelf functions either offered in the OpenWhisk catalog or in the opensource community. The computational tasks are outsourced to the cloud, which makes the mobile app more energy-efficient and it won’t drain your battery when using it. Plus, there are no servers to worry about, the scaling of the app is done automatically depending to the current demand. And fault-tolerance comes for free, while you’re paying only for resources you’re using. Sounds like a great solution!
As you can probably guess at this point, there are various scenarios that fit the OW model of programming. OW can power your IoT application or any mobile application. You can use OW to coordinate tasks in a big data/analytics pipeline. You can even automate certain DevOps tasks using events and actions. In general, any application that is deployed following a microservices-based architecture, in which microservices can be individually developed and deployed can be moved to a FaaS platform by moving the microservices to a function-based model of execution.
So, how does OW work? Each function that is submitted to the system gets associated with a rest endpoint, so you can invoke a function directly by performing an http request. Such a request can be emitted by a mobile device, a browser, a web app.
Alternatively, the system allows to configure events to trigger the invocation of an OW action. For example, an update to a Cloudant database can trigger the invocation of an action/function. Or every time someone commits something to a Git repository, an action gets executed.
Let’s talk in a bit more detail about the programming model. There are three main entities in OW: triggers, actions and rules.
A trigger is associated with a class of events that can happen. We’ve seen some examples before: updates to databases, twets, messages, IoT signals, etc.
Functions in OW are called Actions and they represent the code that runs in response to events. You can think of functions as event handlers.
A very simple hello world example is on this slide, written in JS. We support several languages in OW, such as JS, Python, Java and Swift.
In addition, you can package any application written in your favorite language in a docker image, and as long as it follows a certain api, our system can run that too. So you’re only limited by your imagination
Actions can be chained and executed in a sequence, such that you can reuse pieces of code and combine them according to the needs of your application.
Rules are associations between triggers and actions. Given the right set of rules you can have same trigger triggering multiple actions or the same action being triggered by multiple events.
Finally, actions and triggers can be bundled up in packages that can be shared using the OW catalog. You can decide access control features at the package level. Also packages have parameters that can be bound to default values and sent to each action in the package.
I’d like to briefly show a simplified version of how the OpenWhisk guts look like. We have an edge machine that received incoming requests either to a proxy from the cli or from the UI. These requests are forwarded to the master mind in OW, which is the controller. The controller is responsible with ensuring the user is a valid OW user and has the right to perform the requested operation. This is done using a separate service, called the entitlement service. In addition, the controller is responsible with dispatching the actions to be executed to the execution engines. There are several such slaves. Each of them contains a component called the invoker which is responsible with managing resources for in-flight actions. There are several optimizations that the invoker applies to make sure the activation time (the time between an event triggering and the start of the execution of the user code) is as low as possible. But this is an entirely different talk in its own right.
Are there any questions now? If not, I’d like to show a simple demo. This demo integrates a slack slash command with whisk.