Introducing OpenWhisk - Cloud Native, Event Driven, Serverless Micrsoservices Framework

1. Cloud Native, Event Driven,
Serverless
Micrsoservices Framework
OpenWhisk
@AnimeshSingh

2. 2
Agenda!
• What does it mean to be Cloud Native?!
• Twelve Factor Apps!
• What are Microservices?!
• Developing and Deploying Microservices using OpenWhisk!

3. 3
What does it mean to be Cloud Native?!
• Clean contract with underlying OS to ensure maximum portability!
• Scale elastically without significant changes to tooling, architecture or
development practices!
• Resilient to inevitable failures in the infrastructure and application!
• Instrumented to provide both technical and business insight!
• Utilize cloud services e.g. storage, queuing, caching, …!
• Rapid and repeatable deployments to maximise agility!
• Automated setup to minimize time and cost for new developers!

4. Twelve Factor Apps!
4!

5. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• One codebase tracked in revision
control, many deploys

6. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Explicitly declare and isolate
dependencies
• Typically platform dependent e.g.
npm, bundler or Liberty feature
manager
• Never rely on system-wide
dependencies

7. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Store config in the environment
• Separate config from source
• Avoid ‘config groups’

8. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Treat backing services as attached
resources
• Local and remote resources should
be treated identically

9. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Strictly separate build and run
stages

10. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Execute the app as one or more
stateless processes
• Never rely on sticky sessions

11. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Export services via port binding

12. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Scale out via the process model
• Individual VMs can only scale
vertically so far
• Stateless nature makes scaling
simple

13. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Maximize robustness with fast
startup and graceful shutdown
• Application instances are disposable
• Crash-only design is logical
conclusion

14. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Keep development, staging, and
production as similar as possible
• Use the same backing services in
each environment

15. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Treat logs as event streams
• Don’t write to log files

16. Twelve Factors
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
• Run admin/management tasks as
one-off processes
• E.g. database migrations or for
debugging

17. What are
Microservices?
17

18. Monolithic
Application

19. Monolithic
Application
Modularity

20. Monolithic
Application
Scaling

21. Monolithic
Application
Failing
û

22. Monolithic
Application
Failing
û

23. Monolithic
Application
Failed
û û
û û

24. Monolithic
Application
Update

25. Monolithic
Application
Revolution

26. Monolithic
Application
Develop

27. Microservices
Application

28. Microservices
Application
Interactions

29. Microservices
Application
Scaled

30. Microservices
Application
Evolution

31. Monolithic versus Microservices
Monolithic Microservice
Architecture Built as a single logical executable (typically the server-side
part of a three tier client-server-database architecture)
Built as a suite of small services, each running separately and
communicating with lightweight mechanisms
Modularity Based on language features Based on business capabilities
Agility Changes to the system involve building and deploying a new
version of the entire application
Changes can be applied to each service independently
Scaling Entire application scaled horizontally behind a load-balancer Each service scaled independently when needed
Implementation Typically written in one language Each service implemented in the language that best fits the need
Maintainability Large code base intimidating to new developers Smaller code base easier to manage
Transaction ACID BASE
31

32. • Challenges with today’s models:!
• Complex to construct applications driven
by events!
• Lots of idle time — need to pay for
resources even if no request is being
handled (most APIs / apps don’t receive
super-high load)!
• Scaling capacity is coarse granular,
relatively slow & complex!
Motivation and Introduction – Today!
Handles request,
returns results,
and goes into idle mode, waiting
for next request
2!
App!
CF/Container/VM!
Receives request,!
e.g. HTTP request against API!
1b!
Polls for change,!
e.g. whether new data arrived, record
changed, new data record, temp above
60 degrees, etc.!
1a!

33. Motivation and Introduction!
OpenWhisk!
Actions
(Swift, Node, Java, … code)
Trigger, invoking whisk action!
e.g. HTTP request against API, event about new data record,
temp above 60 degrees, etc.!
1!
…
Deploys action within millisecs,
runs it,
returns results and
frees up resources
2!
… …

34. Execute code on demand in a
highly scalable serverless
environment
Bluemix OpenWhisk
Open Source & Open Ecosystem
Take advantage of easily integrating
with an ever growing list of event
providers and consumers
Action Chaining
Develop independent pieces of code
and quickly connect them and
ecosystem services together
Scale on demand, no administration
Upload your code and let it run. There is
no need to think about infrastructure or
worry about peak projections.
Integrated Container Support
Run custom code put in a Docker
container and never worry about
vendor lock-in
3
Meet
OpenWhisk

35. OpenWhisk: Another way to build
apps…!
Build your apps, your way.!
Use a combination of the most prominent open-source compute technologies to
power your apps. Then, let Bluemix handle the rest.!
Ease of getting started Full stack Control
OpenWhisk
Event-driven apps, !
deployed in a serverless en
vironment.!
Instant Runtimes
App-centric runtime !
environments based on !
Cloud Foundry.!
IBM Containers
Portable and consistent !
delivery of your app !
without having to manage a
n OS.!
Virtual Machines
Get the most flexibility !
and control over your !
environment with VMs.!

36. 36
Bluemix Compute Models!
Cloud Foundry
application!
Docker Container! Virtual Machine!
Consistent experience:!
• Common service binding & consumption model!
• Common user ID & permissions model!
• Ability to hook into common routing layer!
expanding
Level of
abstraction
Flexibility
Event Driven!
application!

37. High-level
architecture
Triggers: A class of events emitted by
event sources."
Actions: Encapsulate the actual code to
be executed which support multiple
language bindings. Actions invoke any
part of an open ecosystem.
Rules: An association between a trigger
and an action."
Packages: Describe external services in
a uniform manner."
"
Combined these allow developers to
compose solutions using modern
abstraction and chaining which can be
created, accessed, updated and
deleted via the CLI
OpenWhisk provides a distributed compute
service to execute application logic in response to
events. !

38. OpenWhisk: How does it work?
}
1
Event Providers
OpenWhisk
Cloudant
Git
Weather
…
…
Data event occurs, e.g.
- Commit on a Git Repository
- CRUD operation on Cloudant
- ….
Trigger execution of
associated
OpenWhisk action
2
…
JS Swift! Docker …

39. OpenWhisk: How does it work?
OpenWhisk
JS Swift! Docker …
Incoming HTTP request, e.g.
HTTP GET mynewcoolapp.com/customers
1 2 Invoke associated
OpenWhisk action
„getCustomers“
Browser
Mobile App
Web App
Variety of
languages

40. 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

41. Programming model
• Services define the events they emit as triggers, and developers
associate the actions to handle the events via rules
• The developer only needs to care about implementing the desired
application logic - the system handles the rest
T A R

42. Programming model
Trigger: „A class of events that can happen“
T

43. Programming model
Actions: „An event-handler, i.e. code that runs in response to an event“
A

44. Programming model
Actions: Multi-runtime support, e.g. JavaScript!A
function main(msg) {
return { message: 'Hello, ' + msg.name + ' from ' + msg.place };
};

45. Programming model
Actions: Multi-runtime support, e.g. Swift!A
func main(params:[String:Any]) -> [String:Any] {
var reply = [String:Any] ()
if let name = params[“name”] as? String {
print(“Hello (name)”)
reply[“msg”] = “Goodbye (name)”
}
return reply
}

46. Programming model
Actions: Multi-runtime support, e.g. Docker containers!A

47. Programming model
Rules: „An association of a trigger and an action“
R
R := T A

48. Programming model
Actions: Can be chained to create sequences to increase flexibility and
foster reuse!
A
AA
:= A1
+ A2
+ A3
AB
:= A2
+ A1
+ A3
AC
:= A3
+ A1
+ A2

49. Programming model
Packages: „A shared collection of triggers and actions“P
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

50. Abstract away infrastructure so
that you can focus on business
logic and innovating
4
OpenWhisk to usher in new era of extreme
simplification in application development
• You can innovate faster through an open ecosystem including
powerful services from IBM like Watson.
• You can quickly build apps and microservices quickly without
having to worry about infrastructure, scalability, or resiliency.
• You can easily work in teams through uniquely powerful chaining
and choice of programming language including Swift.
• Easily extend functionality with Docker.
IBM Bluemix
OpenWhisk

51. Questions?