Escolar Documentos
Profissional Documentos
Cultura Documentos
Serverless
Micrsoservices Framework
OpenWhisk
@AnimeshSingh
Agenda!
What does it mean to be Cloud Native?!
2
What does it mean to be Cloud Native?!
Clean contract with underlying OS to ensure maximum portability!
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
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
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
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.!
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
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.
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
Open Third
Yours
Source A post Party A myAction
4
Questions?