Quickly and easily build feature-rich apps that automatically trigger responses to events
NOTE: OpenWhisk is now an Apache Incubator project. For current information, see the Apache OpenWhisk website.
WEBCAST REPLAY: Watch the replay of the OpenWhisk Update Tech Talk, recorded on Jan 25, 2017. Representatives from Adobe and IBM provide the latest on OpenWhisk collaboration, developments, and directions.
Microservice architectures have emerged as the preferred way to engineer robust, scalable cloud-native solutions. Microservices hold application logic in small, loosely coupled distributed services, communicating through language-agnostic APIs.
Despite the benefits, microservice-based solutions are hard to build using mainstream cloud technologies, which often require you to control a complex toolchain and build/operations pipeline.
As a result, developers spend too much time dealing with infrastructure and operational complexities like fault-tolerance, load balancing, auto-scaling, and logging features. And that’s where OpenWhisk shines.
The OpenWhisk model consists of three concepts:
- trigger: a class of events that can happen
- action: an event handler — some code that runs in response to an event
- rule: an association between a trigger and an action
Services define the events they emit as triggers, and developers define the actions to handle the events. The developer only needs to be concerned with implementing the desired app logic — the system handles the rest.
Out of the box, OpenWhisk supports Cloudant and Github as event sources, as well as the execution of scheduled actions. Packages to invoke the Watson Translation and Weather services are being provided, as well as an open API, giving any party the ability to contribute a package of actions and triggers back to OpenWhisk.
Why should I contribute?
Are you an app developer who’s already built a cool solution with OpenWhisk? Share your solution with the community and get feedback on your work. Show off your rules, actions, and triggers; show others the way and help them avoid the same issues you encountered. At the same time, you might pick up some ideas from people who’ve done similar work.
Are you a service owner or provider? Consider enabling it for OpenWhisk and let your service start playing the OpenWhisk game. It’ll make the service more attractive to other developers — it’ll be ready to use for building OpenWhisk-based event-driven solutions.
Are you a potential runtime contributor? Do you want to help add more cool features like support for more runtimes? Join us! We’re looking forward to hearing about your ideas and improving OpenWhisk with your help.
What technology problem will I help solve?
Developers need to produce code quickly, and they need to focus on core competencies. OpenWhisk provides the means to accomplish that through:
- A rich set of building blocks that they can easily glue/stitch together.
- The ability to focus more on value-add business logic and less on low-level infrastructural and operational details.
- The ability to easily chain together microservices to form workflows through composition.
OpenWhisk also transparently handles exposing services from cloud providers. The OpenWhisk system
- Supports an open ecosystem that allows sharing microservices via OpenWhisk packages
- Enables developers to compose solutions using modern abstractions and chaining
- Supports multiple runtimes, including NodeJS, Swift, and arbitrary binary programs encapsulated in Docker containers.
How will OpenWhisk help my business?
OpenWhisk can help to power various mobile, web and IoT use-cases; for example, it can enable mobile developers to interface with backend logic running in a cloud without installing server-side middleware or infrastructure.
Since it’s available on IBM Cloud, OpenWhisk provides web developers with access to cognitive and other services. It provides IoT developers with access to analytical services to help them properly react to sensor data, and can even be used to automate DevOps tasks such as kicking off an appropriate action when a build system indicates a successful failed build through an event.