Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Autonomic Application Delivery with Tonomi

640 views

Published on

This introduction to autonomic application delivery with Tonomi (formerly, Qubell) had been presented at SVDevOps meetup at Intuit on May 19, 2015

  • Be the first to comment

  • Be the first to like this

Autonomic Application Delivery with Tonomi

  1. 1. Victoria Livschitz, CEO of Tonomi @vlivschitz Autonomic Management of Cloud Applications Autonomic Application Delivery SVDevOps Meetup Intuit, May 19 2015
  2. 2. About the speaker Founder & CEO, Tonomi (formerly, Qubell) First autonomic application delivery and management platform for cloud applications Founder & CEO, Grid Dynamics, 2006 - 2013 Pioneer of enterprise clouds; leading provider of open, scalable, next-generation technology solutions for Tier 1 retailers Principal Architect, Sun: 1997 - 20o6 Chief architect of GM; chief architect of financial services; senior scientist in SunLabs; technical lead on SunGrid, world’s first public cloud service.
  3. 3. “ ” Everyday is a battle to keep up with the pace of innovation
  4. 4. Automation is the Battlefield Speed and Self-service Stability 
 and Control VS
  5. 5. Fujitsu Lettuce Farm (in repurposed micro-chip factory)
  6. 6. Akisai: IoT, Big Data and Cloud in Action
  7. 7. Part of a Greater Vision of Sustaining Farming
  8. 8. Tonomi Vision: Agile Software Factory Continuously develop, test, rollout, measure, analyze, experiment, tune, scale, patch and upgrade applications, 24 x 7“ ”
  9. 9. Tonomi Focus: Adaptive Control Externalize configuration of everything affecting application and its environment. Enable centralized control over configurations from a cloud. Continuously monitor health of running applications. Track changes in their environment. Identify triggers that require controlled response. Adaptively change application configuration by applying orchestrated workflows based on policies. Log all changes for analysis and audit. 1. 2. 3.
  10. 10. Emerging Control Stack IaaS Infrastructure management vm Container management Containers vms PaaS Stacks Micro-services Web Big Data CommercePatterns Pipeline Environment management Self-service Release management ConfigurationAutonomic vmvmvm IoTMobile Domains More…
  11. 11. Self-Service
  12. 12. Search eCommerce Personalization Payment Gateway
  13. 13. Search eCommerce Personalization Payment Gateway
  14. 14. Search eCommerce Personalization Update Index Patch OS Upgrade Schema Payment Gateway
  15. 15. Make application configuration “adaptive” to purpose and environment
  16. 16. Configuration A CentOS CentOS EC2 20Mb 
 Data WebLogic Stub API Blueprint A Testing Automation via statically-defined configuration
  17. 17. Configuration A Configuration B CentOS CentOS EC2 20Mb 
 Data WebLogic Stub API Blueprint A Blueprint B Testing Production RedHat 2Tb 
 Data WebLogic API WebLogic RedHat Static configurations, folked
  18. 18. Configuration A Configuration B CentOS CentOS EC2 20Mb 
 Data WebLogic Stub API 2Tb 
 Data WebLogic API Tonomi Way: Adaptive Configuration Environment BEnvironment A WebLogic Testing Production RedHat RedHat
  19. 19. Facilitate Release Pipeline Commit UpgradeCI Regression Integration Performance User Acceptance Mobile Staging CI Regression Integration Performance User Acceptance Mobile Staging Dynamic Environments
  20. 20. Runtime Configuration (t) = F (Application (t), Environment (t), Policy (t))
  21. 21. Adaptive Configuration vs. Deployment Automation
  22. 22. Automation without configuration and adaptive change management is not effective in a long run Adaptive Configuration vs. Deployment Automation
  23. 23. Hadoop Docker with Pet Clinic Broadleaf Commerce Oracle ATG Commerce Check out Tonomi Starter Kits:
  24. 24. Use Cases Dynamic test Environments Configuration management Field installations and Upgrades 1 2 3 Operational control’s visibility & enforcement 4
  25. 25. 2525 Developer (every day): new version of X is ready! • How many live instances of X are affected? Where? • How to deliver the change (Docker, Chef, etc.)? • What related services might be affected? • What to do about them, and their dependents? • How to keep all systems are running while all this is happening? • Also… • How do I know the change made had been authorized? • How do I discover app’s actual configuration? • How do I compare configs of different instances? • Where do I find configuration change logs? Ops:
  26. 26. Use case 1 Launch new environments on-demand, as developer self- service
  27. 27. 2727 Portal WISB (what it should be) WIRI (what it really is) Controller Live environment 1. Launch new (A) {A, x, A->x, ….}
  28. 28. 2828 Portal WISB (what it should be) WIRI (what it really is) Controller Live environment 1. Launch new (A) {A, x, A->x, ….}
  29. 29. 2929 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller Live environment 1. Launch new (A) {A, x, A->x, ….} {A1, ….} 2. Authorized?
  30. 30. 3030 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller 4. Make new application instance, A1 X.1 Live environment A1 1. Launch new (A) 5. Use cloud API, PaaS, chef, docker, etc. {A, x, A->x, ….} {A1, ….} 2. Authorized?
  31. 31. 3131 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller 4. Make new application instance, A1 X.1 Live environment A1 1. Launch new (A) 6. Log existence of A1, and all of it’s components, with their configurations {A, x, A->x, ….} {A1, ….} 2. Authorized? 5. Use cloud API, PaaS, chef, docker, etc.
  32. 32. 3232 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller 4. Make new application instance, A1 X.1 Live environment A1 1. Launch new (A) 6. Log existence of A1, and all of it’s components, with their configurations 7. Update 8. Done! {A, x, A->x, ….} {A1, ….} 2. Authorized? 5. Use cloud API, PaaS, chef, docker, etc.
  33. 33. Use case 2 Publish new version of a component… … new environments are configured correctly with new blueprint
  34. 34. 3434 Portal 1. Publish change X.2 3. Update catalog WISB (what it should be) WIRI (what it really is) Controller 4. Generate new blueprint for A X.1 Live environment A1 {A, x, A->x, ….} {A1, ….} 2. Authorized?
  35. 35. 3535 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller 4. Make new application instance, A2 X.1 Live environment A1 X.2 A2 1. Launch new (A) 6. Log existence of A2, and all of it’s components, with their configurations 7. Update 8. Done! {A, x, A->x, ….} {A1, A2, ….} 2. Authorized? 5. Use cloud API, PaaS, chef, docker, etc.
  36. 36. Use case 3 Self-service upgrades
  37. 37. 3737 Portal WISB (what it should be) WIRI (what it really is) Controller X.1 Live environment A1 X.2 A2 {A, x, A->x, ….} {A1, A2, ….} 1. Upgrade (A) to latest
  38. 38. 3838 Portal 3. Do this! WISB (what it should be) WIRI (what it really is) Controller X.2 Live environment A1 X.2 A2 6. Update state of A1, and all of it’s components 7. Update 8. Done! 4. Reconfigure X.1 to X.2 (application specific: blue- green, canary, with downtime, etc.) Note: Use cloud API, PaaS, chef, puppet, docker, LiveRebel, etc. 5. Check & fix dependencies {A, x, A->x, ….} {A1, A2, ….} 2. Authorized? 1. Upgrade (A) to latest
  39. 39. Use case 4 Autonomic patches, upgrades with Docker
  40. 40. 4040 WISB (what it should be) WIRI (what it really is) Controller X.2 Live environment A1 X.2 A2 {A, x, A->x, ….} {A1, A2, ….} X -—-> image ID x.1 —> image ID 1 x.2 —> image ID 2 x.3 —> image ID 3 Docker Hub 1. New (ID 3) 2. Detect, trigger or push
  41. 41. 4141 WISB (what it should be) WIRI (what it really is) Controller X.3 Live environment A1 X.3 A2 4. Update state of A1, A2, etc. 3. Upgrade all affected instances {A, x, A->x, ….} {A1, A2, ….} X -—-> image ID x.1 —> image ID 1 x.2 —> image ID 2 x.3 —> image ID 3 Docker Hub 1. New (ID 3) 2. Detect, trigger or push X.2 -> X.3 X.2 -> X.3
  42. 42. Use case 5 Policy-based configuration management
  43. 43. 4343 WISB (what it should be) WIRI (what it really is) Controller X.2 Live environment 1: test A1 {A, x, A->x, ….} {A1, A2, ….} Live environment 2: production X.2 A2 Policy 1 Policy 2 Portal
  44. 44. 4444 WISB (what it should be) WIRI (what it really is) Controller X.2 Live environment 1: test A1 {A, x, A->x, ….} {A1, A2, ….} Live environment 2: production X.2 A2 Policy 1 Policy 2 Portal 1. Launch A in “test” 3. Do this! 4. Make new application instance, A1 based on Policy 1 2. Authorized?
  45. 45. Qubell is reactive Changes propagate as signals to connected services who can (a) respond to that change, and (b) relay signals further
  46. 46. 4646 WISB (what it should be) WIRI (what it really is) Controller X.2 Live environment 1: test A1 {A, x, A->x, ….} {A1, A2, ….} Live environment 2: production X.2 A2 Policy 1 Policy 2 Portal Signals propagating through the circuits of connected application fabric Triggers
  47. 47. Innovate Faster!! Thank you.
  48. 48. Thank you Victoria Livschitz @vlivschitz

×