1.
Victoria Livschitz, CEO of Tonomi
@vlivschitz
Autonomic Management of Cloud
Applications
Autonomic Application Delivery
SVDevOps Meetup
Intuit, May 19 2015

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.
“ ”
Everyday is a battle
to keep up with the pace of innovation

4.
Automation is the Battlefield
Speed and
Self-service
Stability
and Control
VS

5.
Fujitsu Lettuce Farm
(in repurposed micro-chip factory)

6.
Akisai: IoT, Big Data and Cloud in Action

7.
Part of a Greater Vision of Sustaining Farming

8.
Tonomi Vision: Agile Software Factory
Continuously develop,
test, rollout, measure,
analyze, experiment, tune,
scale, patch and upgrade
applications, 24 x 7“ ”

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.
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.
Self-Service

12.
Search eCommerce Personalization
Payment Gateway

13.
Search eCommerce Personalization
Payment Gateway

14.
Search eCommerce Personalization
Update
Index Patch OS Upgrade
Schema
Payment Gateway

15.
Make application configuration
“adaptive” to purpose and
environment

16.
Configuration A
CentOS
CentOS
EC2
20Mb
Data
WebLogic
Stub
API
Blueprint A
Testing
Automation via statically-defined configuration

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.
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.
Facilitate Release Pipeline
Commit UpgradeCI
Regression
Integration
Performance
User
Acceptance
Mobile
Staging
CI
Regression
Integration
Performance
User
Acceptance
Mobile
Staging
Dynamic Environments

20.
Runtime Configuration (t) =
F (Application (t),
Environment (t),
Policy (t))

21.
Adaptive Configuration vs. Deployment Automation

22.
Automation without configuration
and adaptive change management
is not effective in a long run
Adaptive Configuration vs. Deployment Automation

23.
Hadoop
Docker with Pet
Clinic
Broadleaf
Commerce
Oracle ATG
Commerce
Check out Tonomi Starter Kits:

24.
Use Cases
Dynamic test
Environments
Configuration
management
Field installations and
Upgrades
1 2
3
Operational control’s
visibility & enforcement
4

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.
Use case 1
Launch new environments on-demand, as developer self-
service

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.
2828
Portal WISB
(what it should be)
WIRI
(what it really is)
Controller
Live
environment
1. Launch
new (A) {A, x, A->x, ….}

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.
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.
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.
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.
Use case 2
Publish new version of a component…
… new environments are configured correctly with new
blueprint

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.
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.
Use case 3
Self-service upgrades

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.
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.
Use case 4
Autonomic patches, upgrades with Docker

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.
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.
Use case 5
Policy-based configuration management

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.
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.
Qubell is reactive
Changes propagate as signals to connected services who
can (a) respond to that change, and (b) relay signals
further

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.
Innovate Faster!!
Thank you.

48.
Thank you
Victoria Livschitz
@vlivschitz