Download as PDF, PPTX
![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
}](https://image.slidesharecdn.com/whiskmeetup-160523172915/75/Introducing-Cloud-Native-Event-Driven-Serverless-Micrsoservices-Framework-OpenWhisk-45-2048.jpg)
![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
}](https://crownmelresort.com/image.slidesharecdn.com/whiskmeetup-160523172915/75/Introducing-Cloud-Native-Event-Driven-Serverless-Micrsoservices-Framework-OpenWhisk-45-2048.jpg)
Uploaded byAnimesh Singh
Introducing Cloud Native, Event Driven, Serverless, Micrsoservices Framework - OpenWhisk
This document discusses cloud native, event-driven serverless applications using OpenWhisk microservices framework. It begins with an agenda that covers what it means to be cloud native, Twelve Factor Apps methodology for building apps, an overview of microservices, and developing and deploying microservices using OpenWhisk. The document then provides more details on each topic, including characteristics of cloud native apps, principles of Twelve Factor Apps, benefits and challenges of monolithic vs microservice architectures, and how OpenWhisk works to enable event-driven serverless applications.
More Related Content
Similar to Introducing Cloud Native, Event Driven, Serverless, Micrsoservices Framework - OpenWhisk
![Hybrid Cloud, Kubeflow and Tensorflow Extended [TFX]](https://cdn.slidesharecdn.com/ss_thumbnails/tfx-kfp-191031073013-thumbnail.jpg?width=640&height=640&fit=bounds)
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
Introducing Cloud Native, Event Driven, Serverless, Micrsoservices Framework - OpenWhisk
- 1. Cloud Native, EventDriven, Serverless Micrsoservices Framework OpenWhisk @AnimeshSingh
- 2. 2 Agenda! • What doesit mean to be Cloud Native?! • Twelve Factor Apps! • What are Microservices?! • Developing and Deploying Microservices using OpenWhisk!
- 3. 3 What does itmean 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.
- 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.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31. Monolithic versus Microservices MonolithicMicroservice 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 withtoday’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 ondemand 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 wayto 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! CloudFoundry 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 classof 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 doesit 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 doesit 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 OpenWhiskcan 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 • Servicesdefine 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: „Aclass of events that can happen“ T
- 43. Programming model Actions: „Anevent-handler, i.e. code that runs in response to an event“ A
- 44. Programming model Actions: Multi-runtimesupport, e.g. JavaScript!A function main(msg) { return { message: 'Hello, ' + msg.name + ' from ' + msg.place }; };
- 45. Programming model Actions: Multi-runtimesupport, 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-runtimesupport, e.g. Docker containers!A
- 47. Programming model Rules: „Anassociation of a trigger and an action“ R R := T A
- 48. Programming model Actions: Canbe 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: „Ashared 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 infrastructureso 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.