OpenWhisk Introduction

Editor's Notes

• #4: 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.
• #5: 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.
• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #12: 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!
• #13: 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.
• #14: 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.
• #15: 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.
• #16: Let’s talk in a bit more detail about the programming model. There are three main entities in OW: triggers, actions and rules.
• #17: 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.
• #18: 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.
• #19: 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.
• #20: 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 
• #21: 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.
• #22: 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.
• #23: 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.
• #24: 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.
• #25: Are there any questions now? If not, I’d like to show a simple demo. This demo integrates a slack slash command with whisk.