Serverless Apps with Open Whisk

Editor's Notes

1. Good afternoon. I’m Daniel Krook, a Senior Software Engineer in the IBM Cloud organization. Today I’m going to tell you about OpenWhisk, a new open source project from IBM for building the next generation of cloud native applications.
2. My goals today are to explain how a new approach is enabling developers to write cloud native applications better, faster, and cheaper using serverless technology. I’ll then give you an introduction to OpenWhisk and show you some examples of how it provides that environment for developers. What the audience will learn How cloud computing has evolved to empower developers to write cloud native applications better, faster, and cheaper using serverless technology. Cloud native applications should be written with the 12 factors in mind. However, serverless computing means that they can get some of those principles for free, while focusing instead on business logic rather than operational concerns. The audience will learn how OpenWhisk provides a serverless fabric and framework for creating cutting edge cloud native applications for a variety of workloads. We’re in the early days of an evolution that is empowering developers to write cloud native applications better, faster, and cheaper OpenWhisk provides an open source platform to enable cloud native, event driven, serverless applications
3. Over the past ten years we’ve seen a steady improvement how fast developers can create and deploy applications to production. Starting with the moment that service providers matched virtualized resources with self service APIs, speed has been accelerating. Recently we’ve seen the shift from IaaS to PaaS, where developers concern themselves only with their apps and data. And now, we’ve seen the rise of Functions as a Service programming. Thoughout this shift the developer has narrowed his focus purely on business value, and lost site of more and more operational concerns, hence the term serverless.
4. Another trend driving new models of cloud native application development has been the trend towards less web application focused services as cloud computing matches more and more types of workloads. With them come a need for event driven programming models.
5. In this transition to cloud native application development, the management of decomposed containerized applications has brought new operational concerns.
6. Beyond those deployment problems, this new model improves cloud native development as it promises to address many if not most of the good design patterns provided in the 12 Factors. In fact, what is not directly related to code is now covered by serverless platforms like OpenWhisk.
7. The cost model for cloud computing has always been a draw, but there is room for the reduction of waste.
8. Serverless billing models promises an even closer match between business value gained and computing resources used.
9. So, to summarize these technology improvements and solutions combined an efficient pricing model are driving interest in severless, event driven computing.
10. OpenWhisk provides a similar set of functionality to hosted services from Amazon, Google, and Microsoft, but it also adds unique features in a simple to extend polyglot model, open source nature, and ability to be deployed into many types of environments.
11. 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.
12. Let’s talk in a bit more detail about the programming model. There are three main entities in OW: triggers, actions and rules.
13. A trigger is associated with a class of events that can happen. We’ve seen some examples before: updates to databases, tweets, messages, IoT signals, etc.
14. 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.
15. 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.
16. 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 
17. 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.
18. 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.
19. 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.
20. 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.
21. 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.
22. Docker is used to setup a new self-encapsulated environment (called container) for each action that we invoke in a fast, isolated and controlled way. In a nutshell, for each action invocation a Docker container is spawned, the action code gets injected, it gets executed using the parameters passed to it, the result is obtained, the container gets destroyed.
23. 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! Monitoring, debugging, developer tooling, workflows, and visibility require more work.  Best practices, common message formats, and familiar programming model need to be refined. Flexibility in open source serverless platforms must be balanced with developer responsibility.