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

Cloud Native, Event Driven,

Serverless Micrsoservices Framework

OpenWhisk

@AnimeshSingh

2

Agenda!

•  What does it mean to be Cloud Native?!

•  Twelve Factor Apps!

•  What are Microservices?!

•  Developing and Deploying Microservices using OpenWhisk!

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!

Twelve Factor Apps!

4!

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


•  Explicitly declare and isolate dependencies

•  Typically platform dependent e.g. npm, bundler or Liberty feature manager

•  Never rely on system-wide dependencies


•  Store config in the environment

•  Separate config from source

•  Avoid ‘config groups’


•  Treat backing services as attached resources

•  Local and remote resources should be treated identically

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

Twelve Factors


•  Execute the app as one or more stateless processes

•  Never rely on sticky sessions

Twelve Factors


•  Export services via port binding

Twelve Factors


•  Scale out via the process model

•  Individual VMs can only scale vertically so far

•  Stateless nature makes scaling simple

Twelve Factors


•  Maximize robustness with fast startup and graceful shutdown

•  Application instances are disposable

•  Crash-only design is logical conclusion

Twelve Factors


•  Keep development, staging, and production as similar as possible

•  Use the same backing services in each environment

Twelve Factors


•  Treat logs as event streams

•  Don’t write to log files

Twelve Factors


•  Run admin/management tasks as one-off processes

•  E.g. database migrations or for debugging

What are Microservices?

17

Monolithic Application

Monolithic Application Modularity


Scaling


Failing

û


Failing û


Failed û û û û


Update

Monolithic Application Revolution


Develop

Microservices Application


Interactions


Scaled


Evolution

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

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

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!

… …

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

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

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

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!

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

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 …

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

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

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

Trigger: „A class of events that can happen“ T

Programming model

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

Programming model Actions: Multi-runtime support, e.g. JavaScript!A

functionmain(msg){return{message:'Hello,'+msg.name+'from'+msg.place};

};

Programming model Actions: Multi-runtime support, e.g. Swift!A

funcmain(params:[String:Any])->[String:Any]{varreply=[String:Any]()ifletname=params[“name”]as?String{ print(“Hello\(name)”) reply[“msg”]=“Goodbye\(name)”}returnreply

}

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

Programming model

Rules: „An association of a trigger and an action“ R

R := T A

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

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

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

Questions?

Technology

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