You are on page 1of 51

Cloud Native, Event Driven,

Serverless
Micrsoservices Framework

OpenWhisk

@AnimeshSingh
Agenda!
What does it mean to be Cloud Native?!

Twelve Factor Apps!

What are Microservices?!

Developing and Deploying Microservices using OpenWhisk!

2
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!


3
Twelve Factor Apps!

4!
Twelve Factors
I. Codebase
One codebase tracked in revision
II. Dependencies
control, many deploys
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
Twelve Factors
I. Codebase
Explicitly declare and isolate
II. Dependencies
dependencies
III. Config
IV. Backing Services
Typically platform dependent e.g.
V. Build, release, run
npm, bundler or Liberty feature
VI. Processes
manager
VII. Port binding
VIII.Concurrency
Never rely on system-wide
IX. Disposability
dependencies
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Store config in the environment
II. Dependencies
III. Config
Separate config from source
IV. Backing Services
V. Build, release, run
Avoid config groups
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Treat backing services as attached
II. Dependencies
resources
III. Config
IV. Backing Services
Local and remote resources should
V. Build, release, run
be treated identically
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Strictly separate build and run
II. Dependencies
stages
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
Twelve Factors
I. Codebase
Execute the app as one or more
II. Dependencies
stateless processes
III. Config
IV. Backing Services
Never rely on sticky sessions
V. Build, release, run
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Export services via port binding
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
Twelve Factors
I. Codebase
Scale out via the process model
II. Dependencies
III. Config
Individual VMs can only scale
IV. Backing Services
vertically so far
V. Build, release, run
VI. Processes
Stateless nature makes scaling
VII. Port binding
simple
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Maximize robustness with fast
II. Dependencies
startup and graceful shutdown
III. Config
IV. Backing Services
Application instances are disposable
V. Build, release, run
VI. Processes
Crash-only design is logical
VII. Port binding
conclusion
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Keep development, staging, and
II. Dependencies
production as similar as possible
III. Config
IV. Backing Services
Use the same backing services in
V. Build, release, run
each environment
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
Twelve Factors
I. Codebase
Treat logs as event streams
II. Dependencies
III. Config
Dont write to log files
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
Twelve Factors
I. Codebase
Run admin/management tasks as
II. Dependencies
one-off processes
III. Config
IV. Backing Services
E.g. database migrations or for
V. Build, release, run
debugging
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
What are
Microservices?

17
Monolithic
Application
Monolithic
Application
Modularity
Monolithic
Application
Scaling
Monolithic
Application
Failing
Monolithic
Application
Failing

Monolithic
Application
Failed

Monolithic
Application
Update
Monolithic
Application
Revolution
Monolithic
Application
Develop
Microservices
Application
Microservices
Application
Interactions
Microservices
Application
Scaled
Microservices
Application
Evolution
Monolithic versus Microservices

Monolithic Microservice
Architecture Built as a single logical executable (typically the server-side Built as a suite of small services, each running separately and
part of a three tier client-server-database architecture) communicating with lightweight mechanisms

Modularity Based on language features Based on business capabilities

Agility Changes to the system involve building and deploying a new Changes can be applied to each service independently
version of the entire application

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
Motivation and Introduction Today!
1a! 1b!
Challenges with todays models:!
Receives request,! Polls for change,!
Complex to construct applications driven e.g. HTTP request against API! e.g. whether new data arrived, record
by events! changed, new data record, temp above
60 degrees, etc.!
Lots of idle time need to pay for
resources even if no request is being
handled (most APIs / apps dont receive
super-high load)! 2!
Scaling capacity is coarse granular, Handles request, App!
relatively slow & complex! returns results,
and goes into idle mode, waiting
for next request
CF/Container/VM!
Motivation and Introduction!
1!
Trigger, invoking whisk action!
e.g. HTTP request against API, event about new data record,
temp above 60 degrees, etc.!

Actions
OpenWhisk!
(Swift, Node, Java, code)

2!
Deploys action within millisecs,
runs it,
returns results and
frees up resources


Meet Bluemix OpenWhisk
OpenWhisk

Open Source & Open Ecosystem Scale on demand, no administration


Take advantage of easily integrating Upload your code and let it run. There is
with an ever growing list of event no need to think about infrastructure or
providers and consumers worry about peak projections.

Action Chaining Integrated Container Support


Execute code on demand in a Develop independent pieces of code Run custom code put in a Docker
highly scalable serverless and quickly connect them and container and never worry about
environment ecosystem services together vendor lock-in

3
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.!

OpenWhisk Instant Runtimes IBM Containers Virtual Machines


Event-driven apps, ! App-centric runtime ! Portable and consistent ! Get the most flexibility !
deployed in a serverless en environments based on ! delivery of your app ! and control over your !
vironment.! Cloud Foundry.! without having to manage a environment with VMs.!
n OS.!

Ease of getting started Full stack Control


Bluemix Compute Models!
Event Driven! Cloud Foundry
Docker Container! Virtual Machine!
application! application!
expanding

Flexibility
Level of
abstraction

Consistent experience:!
Common service binding & consumption model!
Common user ID & permissions model!
Ability to hook into common routing layer!

36
OpenWhisk provides a distributed compute
High-level service to execute application logic in response to
architecture events. !
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: How does it work?

}
Event Providers

2 Cloudant
Trigger execution of
associated 1
OpenWhisk action
Git
Data event occurs, e.g.
-Commit on a Git Repository
OpenWhisk Weather -CRUD operation on Cloudant
-.

JS Swift! Docker

OpenWhisk: How does it work?

1 2 Invoke associated
OpenWhisk action
Browser
Incoming HTTP request, e.g. getCustomers

Web App HTTP GET mynewcoolapp.com/customers

Mobile App
OpenWhisk
Variety of
languages

JS Swift! Docker
Some usage Scenarios
Digital app workloads Big Data/Analytics pipeline
OpenWhisk can help power Complex data pipeline for Big Data/
various mobile, web and IoT app Analytics tasks can be scripted using
usecases by simplifying the changes in data services or streams
programming model of for near real-time analytics and
orchestrating various services feedback.
using events without a dedicated
backend.

DevOps & infrastructure as code Micro-Services builder


OpenWhisk can be used to Whisk can be used to easily build
automate DevOps pipeline based micro-services given the footprint
on events triggered from and programming model desired by
successful builds or completed micro services
staging or a go-live event.
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
Programming model
T
Trigger: A class of events that can happen
Programming model
A
Actions: An event-handler, i.e. code that runs in response to an event
Programming model
A Actions: Multi-runtime support, e.g. JavaScript!
function main(msg) {
return { message: 'Hello, ' + msg.name + ' from ' + msg.place };
};
Programming model
A Actions: Multi-runtime support, e.g. Swift!
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
}
Programming model
A Actions: Multi-runtime support, e.g. Docker containers!
Programming model
R
Rules: An association of a trigger and an action

R := T A
Programming model
A Actions: Can be chained to create sequences to increase flexibility and
foster reuse!

AA := A1 + A2 + A3

AB := A2 + A1 + A3

AC := A3 + A1 + A2
Programming model
P Packages: A shared collection of triggers and actions

A read

A write

T changes A translate A forecast

Open Third
Yours
Source A post Party A myAction

T topic T commit T myFeed


IBM Bluemix OpenWhisk to usher in new era of extreme
OpenWhisk 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.

Abstract away infrastructure so Easily extend functionality with Docker.


that you can focus on business
logic and innovating

4
Questions?