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 Management with Qubell (and Docker)

1,488 views

Published on

Overview of Qubell's autonomic application management platform, presented at East Bay Containers, Docker and CloudFoundry Meetup on March 5, 2015.

Published in: Software

Autonomic Application Management with Qubell (and Docker)

  1. 1. Autonomic Application Management with Qubell (and Docker) Docker, Containers & Cloud Foundry East Bay Meetup Victoria Livschitz Qubell, Founder and CTO March 5, 2015
  2. 2. Logistics Twitter: please, do! Questions: please, ask them during the talk Me: @vlivschitz Qubell: @qubellinc I don’t want you to forget them. I’ll write them on the board and address at the end. email: victoria@qubell.com Audience participation: get your laptops ready Instant resume builder: “hands on experience with Hadoop”. Even managers can do this.
  3. 3. Talk Flow 1 Continuous delivery & devops: the challenge of managing change at high velocities 2 Autonomic: when humans are not involved 3 Emerging “control stack” for cloud applications 4 Self-service: when humans are involved 5 Follow-along: let’s play with Hadoop Qubell demo: with Docker and AWS How Qubell works: key use cases in configuration and change management
  4. 4. Industry in transition towards greater agility 44 Big, long releases Black box applications All or nothing upgrades Manual change requests Manual testing Disjoint dev & ops Continuous delivery Connected services Partial zero-downtime upgrades Automated, self-service Automated testing Devops: seamless, collaborative
  5. 5. New challenge: speed vs. stability 55 Speed of Innovation Stability & Reliability All components are changing all the time All systems are working all the time Continuous Delivery Continuous Availability
  6. 6. Emerging Control Stack 66 vm vm vm vm vm IaaS Container management Containers vms PaaS Stacks Micro-services Big Web Big Data Big CommercePatterns Pipeline Configuration & orchestration Self-service Policy-drivenCommand & control New & legacy Changes Infrastructure management Autonomic
  7. 7. Qubell: application delivery, re-imagined Policy-based centralized control Self-service, decentralized execution Developers Operations Qubell’s autonomic, policy-driven application management
  8. 8. 88 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:
  9. 9. 99 Management Portal Control Fabric How Qubell works Controller Controller Controller Managed by qubell.com as SaaS Runs in customer infrastructure
  10. 10. Use case 1 Launch new environments on-demand, as developer self- service
  11. 11. 1111 Portal WISB (what it should be) WIRI (what it really is) Controller Live environment 1. Launch new (A) {A, x, A->x, ….}
  12. 12. 1212 Portal WISB (what it should be) WIRI (what it really is) Controller Live environment 1. Launch new (A) {A, x, A->x, ….} {A1, ….} 2. Authorized?
  13. 13. 1313 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?
  14. 14. 1414 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?
  15. 15. 1515 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.
  16. 16. 1616 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.
  17. 17. Use case 2 Publish new version of a component… … new environments are configured correctly with new blueprint
  18. 18. 1818 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?
  19. 19. 1919 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.
  20. 20. Use case 3 Self-service upgrades
  21. 21. 2121 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
  22. 22. 2222 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
  23. 23. Use case 4 Autonomic patches, upgrades with Docker
  24. 24. 2424 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
  25. 25. 2525 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
  26. 26. Use case 5 Policy-based configuration management
  27. 27. 2727 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
  28. 28. 2828 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?
  29. 29. Qubell is reactive Changes propagate as signals to connected services who can (a) respond to that change, and (b) relay signals further
  30. 30. 3030 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
  31. 31. Demo: Setup Application catalog: - Broadleaf commerce (Open source Java-based eCom platform) - Spring’s PetClinic - Big Data stack from Cloudera Environments: - Dev, test, Big Data, production-East, production-West - Different by policies, properties, access rights
  32. 32. Demo: Use cases Self-service - Browse catalog - Launch, destroy, scale, upgrade - with BRAC Configuration management - Browse live instances - Compare their configurations - Audit configurations of old, destroyed instances - Make revisions - Reconfigure from one revision to another Autonomic self-healing - Change Docker image ID, see all affected clusters upgrade themselves
  33. 33. Getting Started: Qubell for Hadoop Developers We’ll play around with Hadoop tools - Sign up for free Qubell Express - Launch your Hadoop cluster on AWS in a few clicks - No prior experience with Qubell or Big Data necessary Audience participation - Get your laptops out - Get on wifi - Follow me
  34. 34. Questions?
  35. 35. Thank you! Victoria Livschitz, Founder and CTO March 5, 2015

×