Serverless Apps with Open Whisk
•Download as PPTX, PDF•
4 likes•404 views
Serverless apps can be developed using OpenWhisk, an open source serverless platform. OpenWhisk allows code to execute in response to events, using triggers, actions, and rules. It provides polyglot support and scales dynamically. The document demonstrates how to create a timer triggered action and a Slack bot using OpenWhisk. It also provides an overview of OpenWhisk's architecture and implementation.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Serverless Apps with Open Whisk
Similar to Serverless Apps with Open Whisk (20)
More from Dev_Events
More from Dev_Events (20)
Recently uploaded
Recently uploaded (20)
Serverless Apps with Open Whisk
- 1. Serverless apps with OpenWhisk Cloud native • Event driven • Microservices @DanielKrook • Senior Software Engineer • IBM Cloud OpenWhisk.org
- 2. @DanielKrookOpenWhisk.org What you will learn today • How cloud has evolved to enable developers to write cloud native applications better, faster, and cheaper using serverless technology. • How OpenWhisk provides an open source platform to enable cloud native, serverless, event driven applications. • How to get started developing with OpenWhisk on Bluemix, or find out more about the underlying open source serverless platform.
- 3. OpenWhisk.org @DanielKrook What makes serverless, event driven computing so compelling?
- 4. @DanielKrookOpenWhisk.org Cloud evolution means developers can write apps better, faster, and cheaper Bare metal Virtual machines Containers Functions Decreasing concern (and control) over stack implementation Increasingfocusonbusinesslogic
- 5. @DanielKrookOpenWhisk.org Newer workloads are a better fit for event driven programming 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 in response to scheduled tasks Provide easy server-side backend for mobile app
- 6. @DanielKrookOpenWhisk.org Problem: It’s expensive to scale microservices Explosion in number of containers / processes: 1. Increase of infrastructure cost footprint 2. Increase of operational management cost and complexity Region BRegion A Break-down into microservices Make each micro service HA Protect against regional outages Monolithic application
- 7. @DanielKrookOpenWhisk.org Serverless can handle many cloud native app 12 Factors I Codebase Handled by developer (Manage versioning of functions on their own) II Dependencies Handled by developer, facilitated by serverless platform (Runtimes and packages) III Config Handled by platform (Environment variables or injected event parameters) IV Backing services Handled by platform (Connection information injected as event parameters) V Build, release, run Handled by platform (Deployed resources are immutable and internally versioned) VI Processes Handled by platform (Single stateless containers often used) VII Port binding Handled by platform (Actions or functions are automatically discovered) VIII Concurrency Handled by platform (Process model is hidden and scales in response to demand) IX Disposability Handled by platform (Lifecycle is hidden from the user, fast startup and elastic scale is prioritized) X Dev/prod parity Handled by developer (The developer is the deployer. Scope of what differs is narrower) XI Logs Handled by platform (Developer writes to console.log, platform handles log streaming) XII Admin processes Handled by developer (No distinction between one off processes and long running)
- 8. @DanielKrookOpenWhisk.org Problem: Programming and pricing models aren’t ideal Continuous polling needed in the absence of an event driven programming model Charged for resources, even when idle Worries persist about capacity management Swift Application Container VMCF 2 Polling 1b Request 1a
- 9. @DanielKrookOpenWhisk.org Cost model offers a better match between app and resources Applications charged by compute time (millisecond) rather than reserved memory (GB/hour). While many applications must still be deployed in a daemon model, serverless provides an alternative that can mean substantial cost savings for a variety of event driven workloads. Greater linkage between cloud resources used and business operations executed.
- 10. @DanielKrookOpenWhisk.org Technological and business factors make serverless compelling Serverless platforms and frameworks are gaining traction Cost models getting more granular and efficient Growth of event driven workloads that need automated scale Platforms evolving to facilitate cloud native design for developers
- 12. @DanielKrookOpenWhisk.org OpenWhisk in a nutshell OpenWhisk is a cloud platform that executes code in response to events OpenWhisk
- 13. @DanielKrookOpenWhisk.org OpenWhisk is different than other hosted services Serverless deployment and operations model Optimized utilization, fine grained metering at any scale Flexible programming model with powerful tooling Open source and open ecosystem (moving to Apache) Ability to run in public, private, and hybrid models OpenWhisk
- 14. @DanielKrookOpenWhisk.org OpenWhisk supports many growing workloads OpenWhisk can help power various mobile, web and IoT app use cases by simplifying the programming model of orchestrating various services using events without a dedicated backend. Digital app workloads Big Data/Analytics pipeline Complex data pipelines for Big Data/Analytics tasks can be scripted using changes in data services or streams for near real-time analytics and feedback. DevOps and infrastructure as code OpenWhisk can be used to automate DevOps pipelines based on events triggered from successful builds, or completed staging, or a go-live event. Microservices builder OpenWhisk can be used to easily build microservices given the footprint and programming model desired by microservices
- 16. @DanielKrookOpenWhisk.org Triggers, actions, rules (and packages) Data sources define the events they emit as triggers. Developers associate actions to handle the events via rules. T A R
- 17. @DanielKrookOpenWhisk.org Triggers A class of events that can occurT Social events Data changes Device readings Location updates User input
- 18. @DanielKrookOpenWhisk.org Actions Code that runs in response to an event (that is, an event handler) A
- 19. @DanielKrookOpenWhisk.org Actions Can be written in a variety of languages, such as JavaScript, Python, Java, and Swift A function main(params) { return { message: 'Hello, ' + params.name + ' from ' + params.place }; };
- 20. @DanielKrookOpenWhisk.org Actions Or any other language by packaging with DockerA
- 21. @DanielKrookOpenWhisk.org Actions Can be composed to create sequences that increase flexibility and foster reuse A AA := A1 + A2 + A3 AB := A2 + A1 + A3 AC := A3 + A1 + A2
- 22. @DanielKrookOpenWhisk.org Rules An association of a trigger to an action in a many to many mapping. R R := T A
- 23. @DanielKrookOpenWhisk.org Packages A shared collection of triggers and actionsP A A read write T changes A translate A forecast A post T topic Open Source A myAction T myFeed Yours T commit Third Party
- 25. @DanielKrookOpenWhisk.org The OpenWhisk execution model Pool of actions Swift DockerJS Trigger 1 Running action Running action Running action 3 OpenWhisk Engine 2 A T AAA
- 26. OpenWhisk.org @DanielKrook Demo 1: Create a timer triggered action
- 27. @DanielKrookOpenWhisk.org Demo 1: Timer triggered action Trigger 1 Running action 2 T A Cron syntax alarm Log the current time $ wsk action create handler handler.js $ wsk action invoke --blocking handler $ wsk trigger create every-20-seconds --feed /whisk.system/alarms/alarm --param cron “*/20 * * * * *” $ wsk rule create invoke-periodically every-20-seconds handler $ wsk activation poll bit.ly/ow-demo-1
- 28. @DanielKrookOpenWhisk.org OpenWhisk enables event driven applications Event Providers Cloudant GitHub Weather … Which triggers execution of associated OpenWhisk action 2 Slack JS Swift Docker … An event occurs, for example • Commit pushed to GitHub repository • Data changed in Cloudant 1 OpenWhisk
- 29. @DanielKrookOpenWhisk.org OpenWhisk can implement REST microservices Send HTTP request HTTP GET app.com/customers 1 Invoke OpenWhisk action get-customers Browser Mobile App Web App 2 JS Swift Docker … OpenWhisk API Proxy
- 30. OpenWhisk.org @DanielKrook Demo 2: Create a Slack bot
- 31. @DanielKrookOpenWhisk.org Demo 2: Create a Slack bot bit.ly/ow-demo-2 GET /register POST /command POST /event Register action Event action Command action 2 OpenWhisk Engine 1 AAA API Proxy Register the bot Respond to direct messages Respond to slash commands
- 33. @DanielKrookOpenWhisk.org OpenWhisk design principles 1. Provide an open interface for event providers 2. Offer polyglot support and simple extensibility for new runtimes 3. Support higher level constructs as appropriate (e.g. action sequences) 4. Scale dynamically on a per request basis 5. Enable sharing of actions and event providers 6. Leverage best of breed open source software (Docker, Kafka, Consul, …) 7. Use the Apache 2 License
- 34. OpenWhisk.org @DanielKrook OpenWhisk under the hood: A deeper look bit.ly/ow-int 1. Entering the system: nginx 2. Really entering the system: Controller 3. Authentication and Authorization: CouchDB 4. Getting the action: CouchDB… again 5. Who’s there to invoke the action: Consul 6. Please form a line: Kafka 7. Actually invoking the code already: Invoker 8. Storing the results: Yes… CouchDB again
- 36. @DanielKrookOpenWhisk.org What you learned today • 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, serverless, event driven applications • Bluemix provides a hosted instance of OpenWhisk that you can use to get started (and offers integration with a catalog of services)
- 37. @DanielKrookOpenWhisk.org Experiment with OpenWhisk on Bluemix bit.ly/ow-bm
- 39. @DanielKrookOpenWhisk.org Join us to build a cloud native platform for the future! OpenWhisk.org dwopen.slack.com #openwhisk bluemix.net
- 40. @DanielKrookOpenWhisk.org Watson IOT OpenWhisk Customer registry Shipping system SendGrid Service reports actions IBM Cloud LOB, SoR systems & databases Need a new filter Email: Filter on its way! bit.ly/open-fridge
- 41. @DanielKrookOpenWhisk.org analyze reading OpenWhisk create order alert customer alarm changes changes service order appliance feed Watson IoT A A AT T T T P P P bit.ly/open-fridge
Editor's Notes
- 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.
- 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
- 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.
- 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.
- In this transition to cloud native application development, the management of decomposed containerized applications has brought new operational concerns.
- 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.
- The cost model for cloud computing has always been a draw, but there is room for the reduction of waste.
- Serverless billing models promises an even closer match between business value gained and computing resources used.
- So, to summarize these technology improvements and solutions combined an efficient pricing model are driving interest in severless, event driven computing.
- 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.
- 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.
- 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, tweets, 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.
- 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.
- 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.
- 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.
- 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.