Compiling Abstract Specifica4ons into Concrete Systems – Bringing Order to the Cloud
Ian Unruh, Alexandru G. Bardas, Rui Zhuang, Xinming Ou, Sco4 DeLoach
ANCOR -‐ Automated eNterprise network COmpileR -‐
Cloud Users -‐ Desired Features • Flexibility – access to the raw resources e.g., compute, storage
• Reliable automa4on capabiliCes – Non-‐scenario-‐dependent – AutomaCc deployment and maintenance – Dynamic cluster expansion and contracCon
• Migra4on between different could providers – Capturing infrastructure and applicaCon requirements in a specificaCon
2
Current Cloud CompuCng Offerings
• Allow customers to decide how much management they want: o Infrastructure as a Service (IaaS)
• e.g., Amazon Web Services, OpenStack
o PlaSorm as a Service (PaaS) • e.g., Heroku, MicrosoV Azure
o SoVware as a Service (SaaS) • e.g., SalesForce, Google Apps
3
Current Cloud CompuCng Offerings
• Allow customers to decide how much management they want: o Infrastructure as a Service (IaaS)
• e.g., Amazon Web Services, OpenStack
o PlaSorm as a Service (PaaS) • e.g., Heroku, MicrosoV Azure
o SoVware as a Service (SaaS) • e.g., SalesForce, Google Apps
4
✔ Flexibility (access to the raw resources)
✖ Automa4on (non-‐scenario-‐dependent)
✖ Migra4on (capturing requirements in a specificaCon)
Current Cloud CompuCng Offerings
• Allow customers to decide how much management they want: o SoVware as a Service (SaaS)
• e.g., SalesForce, Google Apps
o PlaSorm as a Service (PaaS) • e.g., Heroku, MicrosoV Azure
o SoVware as a Service (SaaS) • e.g., SalesForce, Google Apps
5
✖ Flexibility (access to the raw resources)
✔ Automa4on (non-‐scenario-‐dependent)
✖ Migra4on (capturing requirements in a specificaCon)
Current Cloud CompuCng Offerings
• Allow customers to decide how much management they want: o PlaSorm as a Service (PaaS)
• e.g., Heroku, MicrosoV Azure
o PlaSorm as a Service (PaaS) • e.g., Heroku, MicrosoV Azure
o SoVware as a Service (SaaS) • e.g., SalesForce, Google Apps
6
✖ Flexibility (access to the raw resources)
✔ Automa4on (non-‐scenario-‐dependent)
✖ Migra4on (capturing requirements in a specificaCon)
Proposed SoluCon
• An abstrac4on that captures what a cloud user needs instead of low-‐level details on how to implement those needs
• There must be a process to automa4cally compile the abstrac4on into a valid concrete system
7
Proposed SoluCon
• An abstrac4on that captures what a cloud user needs instead of low-‐level details on how to implement those needs
• There must be a process to automa4cally compile the abstrac4on into a valid concrete system
8
COMPILATION PROCESS
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations ModelANCOR
9
COMPILATION PROCESS
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations ModelANCOR
10
COMPILATION PROCESS
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations ModelANCOR
11
COMPILATION PROCESS
Configura4on Management Tools (CMTs)
Deploying an eCommerce Website
12
Scalable and highly available eCommerce website architecture
ANCOR Requirement Modeling Language (ARML)
eCommerce Website Requirements SpecificaCon 13
Ancor Requirement Modeling Language (ARML)
eCommerce Website Requirements SpecificaCon 14
Ancor Requirement Modeling Language (ARML)
eCommerce Website Requirements SpecificaCon 15
goals: ecommerce: name: eCommerce frontend roles: - weblb - webapp - worker - work_queue - db_master - db_slave
Ancor Requirement Modeling Language (ARML)
eCommerce Website Requirements SpecificaCon 16
Ancor Requirement Modeling Language (ARML)
eCommerce Website Requirements SpecificaCon 17
roles: weblb: name: Web application load balancer min: 2 is_public: true implementations: default:{ profile: "role::ecommerce:: weblb::default" }
exports: http: { type: single_port, protocol: tcp, number: 80 }
imports: webapp: http
ANCOR Workflow
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations Model
1.
1. Passing the IT system specifica4on to ANCOR
18
ANCOR Workflow
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations Model
1.
1. Passing the IT system specificaCon to ANCOR
2. Specifica4on is stored in the Requirements Model
2.
19
ANCOR Workflow
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations Model
1.
1. Passing the IT system specificaCon to ANCOR
2. SpecificaCon is stored in the Requirements Model
3. Compute low-‐level details of the system and store
them in the System Model
3. 2.
20
ANCOR Workflow
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations Model
1.
1. Passing the IT system specificaCon to ANCOR
2. SpecificaCon is stored in the Requirements Model
3. Compute low-‐level details of the system and store
them in the System Model
4. Start deploying the system on the cloud
infrastructure using cloud plaTorm and CMT APIs
3. 2.
4.
21
ANCOR Workflow
Compiler
Cloud Platform (OpenStack)
Configuring Provisioning
OpenStack API Library (Fog)
Orchestrator (Mcollective)
CMT (Puppet)
Conductor
Requirements Model System Model
Operations Model
1.
1. Passing the IT system specificaCon to ANCOR
2. SpecificaCon is stored in the Requirements Model
3. Compute low-‐level details of the system and store
them in the System Model
4. Start deploying the system on the cloud
infrastructure using cloud plaSorm and CMT APIs
5. Update the System Model so it is always consistent
with the deployed system
3. 2.
4.
5.
22
ANCOR Benefits
ü Infrastructure and applicaCon “portability” ü Up-‐to-‐date applicaCon dependencies
ü Building highly dynamic systems
ü Automated fine-‐grained firewall configuraCon ü Security assessments ü Performance evaluaCons ü CreaCng customized PaaS
23
ANCOR
• Current implementaCon and more informaCon:
hWp://arguslab.github.io/ancor/
24
Conclusion
• SeparaCng user requirements from the implementaCon details has the potenCal of changing the way IT systems are deployed and managed in the cloud
• ANCOR – framework that captures the high-‐level requirements and translates them into a working IT system on a cloud infrastructure
25
hWp://arguslab.github.io/ancor/
LISA Labs
Today 4:00PM – 5:30PM
26 Image Source: h4p://Cnyurl.com/pr5n8gz
Alex Bardas: [email protected]
Related Work • Automa.on Solu.ons – AutomaCng instance management e.g., AWS OpsWorks – Deploying/migraCng applicaCons on different cloud providers e.g., Cliqr, Cloud Velocity, CloudSwitch
– Managing and automaCng instances deployment e.g., Right-‐Scale, Service-‐Now
• Abstrac.on Approaches (PaaS specific) – Windows Azure Service DefiniCon Schema (.csdef), Google AppEngine YAML-‐based specificaCon
• Managing Infrastructure (support CMT integraCon) – OpenStack Heat, AWS CloudFormaCon, Terraform
27
Addi)onal Slide
More Related Work
• Docker container-‐based soluCons: – Maestro-‐NG, Flynn, Deis, OpenShiV, etc.
• Ubuntu Juju: – Works at a similar abstracCon level
28
Addi)onal Slide
ANCOR vs. • SimilariCes: • Work at a similar abstracCon level • Have a way of capturing the dependencies between soVware applicaCons (services)
• Differences: – Using existent CMT modules and workflow:
• ANCOR: minimal changes • Juju: usually, significant changes (integraCon with Juju Tools)
– Dependent services • ANCOR: more “centralized” management scheme • Juju: negoCaCon scheme
– Current feature sets e.g, OS support
29
Addi)onal Slide