DevOps:Introducing Infrastructure5as5Codewp.doc.ic.ac.uk/dice-h2020/wp-content/uploads/... ·...

DevOps: Introducing Infrastructure-‐as-‐Code

Elisabetta Di Nitto, Damian A. Tamburri*,Michele Guerriero*, Matej Artac+, Tadej Borovsak+

*Politecnico di Milano+XLAB Corp.

Roadmap

o Session 1: DevOps In a Nutshell

o Break! (5 mins)

o Session 2: Infrastructure-‐as-‐code Explainedthrough TOSCA

o Session 3: Our proposal to connect Dev and Ops:the DICER tool

Session 1

DevOps In a Nutshell

Dev focuses ono Developing featureso Changing requirementso Releasing products

Ops focuses ono Offering serviceso Providing guarantees and stability

Dev & Ops: the classical roles

Dev vs. Ops

“The system works correctly in the development machine but it does not on the operation machine”

“10 days after successful deployment of last release, the system is overloaded”

Who is guilty? Dev– team, or –Ops team?

• Dev works to apply releases• Dev does not pay attention

to QoS guarantees

The problem: two disconnected groups

• Ops resists to releases• Ops is aiming at

guaranteering QoS

• Changes are fundamental for the business!• QoS guarantees are needed too!

• What is it: “Practices or tools that bridge the gap betweendevelopment and operations”

• Goal: Creates a collaborative mindset where a single teamperforms Dev and Opsàthe team must contain differentiated competences, background, etc.

• Requires:• Culture management;• Automation tools;• Organisational as much as technical metrics• Continuous sharing artifacts, procedures, languages, approaches…

DevOps

-‐ Unified Processes

-‐ Unified tooling

DevOps Need 1: Process Alignment!

Development Production

Tools

Development

Tools

IT Operations

Test

BeforeDevOps

«Devs have to walk in Ops shoes and viceversa»

Development Production

Tools

Development & IT Operations

Test

DevOps

Collaborative Development Continuous Testing Continuous Monitoring

QA – Quality Assurance

Development and test on production-‐like

environment

Accelerated deploy using proper

processes and tools

Continuous validation of operation quality

Continuous collaboration and

feedback

1

4

2

3

The four DevOps values

Main IT performance metrics

o Throughputo Deployment frequencyo Lead time for release

o Stability & Qualityo Mean time to recover from failure

IT performance and DevOps (1)

Examples of DevOps practices that improve IT performance

Throughput Stability & Quality

Deployment frequency• Continuous delivery• Version control

Mean time to recover• Version control• Monitoring system and

application health

Lead time for release• Version control• Continuous architecting• Continuous integration• Continuous testing

IT performance and DevOps (2)

Waterfall vs. Agile vs. DevOps

Concerns Waterfall Agile DevOpsMain Focus Design and

developmentDesign and development

Whole application life-‐cycle

Attention to Operation

Minimal or none Minimal or none Main concern

Role of Maintenance Maintenance seen as a redevelopment phase

Maintenance seen as a redevelopment phase

Replaces a running system with a running system

Process Outcome A packaged system ready to be deployed

Various intermediate demo versions of the system

A continuously updated running system

Quality Assurance Testing typically performed toward the end of the process

Test-‐driven development

Test-‐driven development and monitoring-‐driven operation with feedback to Dev

10,3%10,5%

31,3%5,2%

23,4%8,3%

4,8%0,9%5,2%

ArchitectAutomation

DevOps EngineerBuild Engineer

System EngineerManagerDirector

VPOther

DevOps Roles2014 State of DevOps Report, Puppet Labs

(9200+ respondents)

Who focuses on DevOps (in some way)?

22,7%10,9%

7,5%7,4%6,8%5,9%5,7%4,5%3,7%3,0%

21,9%

TechnologyWeb Software

EducationFinance/BankingENTMT/Media

ConsultingTelecommunicati…

GovernmentRetail

Health-‐careAll Others

Industry

5,8%3,6%5,8%

17,1%21,8%

26,8%15,8%

2,1%1,3%

1-‐45-‐9

10-‐1920-‐99

100-‐499500-‐9,99910,000+I don't …

Not …

Company Size by # of Employees

28,3%23,0%

16,9%8,4%

4,9%8,5%8,0%

2,0%

<100100-‐499

500-‐…2,000-‐…5,000-‐…

10,000 >I don't …

NA

Size of IT infrastructure by # of servers

30,4%28,8%

16,0%5,6%

2,3%1,9%1,4%1,3%1,2%

11,1%

IT OpsDev/EngDevOps

ConsultantC-‐level Executive

Network OperationsInformation Security

Quality AssuranceRelease Engineering

All Others

Departments

Puppet Labs Findings and Survey recommendations

Practitioners Managers

Cross-‐functional collaboration

• Work with other teams• Find ways to build empathy• Make invisible work visible

• Build trust• Encourage practitioners to move

between departments• Facilitate collaboration

Climate of learning • Learn by sharing knowledge• Always bring back what you learned• Prepare for postmortems

• Create and acquire training budget• Create a climate of learning and

sharing• Make it safe to fail

Tools • Automate the things that are painful • Make sure your team chooses thetools

• Make monitoring a priority

o Clear correlation between high IT performance andstrong business performance

o Suggestions for improvement:

• Shorten time-‐to-‐value• Quick and regular release of softwarefeatures

• Improve quality• Mitigate risks• Increase collaboration in the team

DevOps general advantages

DevOps Organisational Changes

Dev Ops Dev OpsDevOps

Dev OpsDevOps

Separate Silos Separate DevOps Silo

We don’t need Ops

What to avoid: anti-‐patterns

From M. Skelton. What Team Structure is Right for DevOps to Flourish? 2013http://blog.matthewskelton.net/2013/10/22/what-‐team-‐structure-‐is-‐right-‐for-‐devops-‐to-‐flourish/http://web.devopstopologies.com

DevOps Organisational Changes

Dev OpsDevOpsDev Ops DevOps

Infrastructure as a Service

Dev OpsDevOps

DevOps as a Service

Dev OpsDevOps

Temporary DevOps Team

Fully EmbeddedSmooth collaboration

From M. Skelton. What Team Structure is Right for DevOps to Flourish? 2013http://blog.matthewskelton.net/2013/10/22/what-‐team-‐structure-‐is-‐right-‐for-‐devops-‐to-‐flourish/http://web.devopstopologies.com

What to do: adoption patterns

DevOps processes and toolchain

Image by Kharnagy (Own work) [CC BY-‐SA 4.0 (http://creativecommons.org/licenses/by-‐sa/4.0)], via Wikimedia Commons

-‐ Continuous Architecting

Def. “architect for test, build and deploy, take quality attributes into account, take advantage of feedback from runtime” [1]

-‐ Continuous IntegrationDef. “merge all developer work-‐copies to a shared mainline frequently” [4]Examples. Apache Jenkins, Hudson, etc.

-‐ Continuous TestingDef. “run tests as part the build pipeline so that every check-‐in and deployment is validated” [3]Examples. Selenium+GitHub+LI-‐API, etc.

DevOps process and toolchain

1.Configuration Management

2. ServerProvisioning

3. ApplicationDeployment4. Monitoring

5. Self-‐Adaptation

Our focus

Infrastructure

Middleware

Application

Host Host Network

Apache Tomcat MySQL

Mod_proxy WAR Schema

A large number of tools

One common characteristic

o Code! Example 1To define what a web node should do [Chef]{

“name”: “web”,“description”: “Role used for the web tier”,“chef_type”: “role”,“json_class”: “Chef::Role”,“run_list”: [

“recipe[timezone]”,“recipe[apt]”,“recipe[nginx]”

],“default_attributes”: {},“override_attributes”: {}

}

One common characteristic

o Code! Example 2To run a VM on OpenStack and to install a mongo shell on it [Terraform]resource "openstack_compute_instance_v2" "mongod_host" {

count = "3"region = ""name = "mongod_host"image_name = "${var.image_name}"flavor_name = "${var.flavor_name}"key_pair = "tf-‐keypair-‐1"security_groups = ["mongo_security_group"]network {

uuid = "${openstack_networking_network_v2.tf_network.id}"}...provisioner "remote-‐exec" {

scripts = ["scripts/install_mongo.sh""start_mongod.sh"]

}}

From computation-‐specific machines

By Alessandro Nassiri -‐ Museo della Scienza e della Tecnologia "Leonardo da Vinci", CC BY-‐SA 4.0, https://commons.wikimedia.org/w/index.php?curid=47910919

To programmable machines

To programmable management of machines

To run a VM on OpenStack and to install a mongo shell on it [Terraform]resource "openstack_compute_instance_v2" "mongod_host" {

count = "3"region = ""name = "mongod_host"image_name = "${var.image_name}"flavor_name = "${var.flavor_name}"key_pair = "tf-‐keypair-‐1"security_groups = ["mongo_security_group"]network {

uuid = "${openstack_networking_network_v2.tf_network.id}"}...provisioner "remote-‐exec" {

scripts = ["scripts/install_mongo.sh""start_mongod.sh"]

}} Infrastructure as a Code

Becomes another subject of this same lifecycle

Session 2

Infrastructure-‐as-‐code Explained through TOSCA

Towards standard Infrastructure-‐as-‐Code

Infrastructure

Middleware

Application

Host Host Network

Apache Tomcat MySQL


è An Application Deployment Topology, i.e., “a graph of physical artefacts that need support for several lifecycle phases (e.g., procurement, installation, configuration, deployment, undeployment, teardown, etc.)” [6]

Towards standard Infrastructure-‐as-‐Code

Infrastructure

Middleware

Application

Host Host Network

Apache Tomcat MySQL


è Infrastructure-‐as-‐code, i.e., “a blueprint detailing physical artefacts, all scripts for all lifecycle phases and all artefacts needed for deployment” [6]

IasCBlueprint

IasC MiddlewareScripts (e.g., Chef,Puppet, etc.)

Deployartefacts (e.g., JARs, etc.)

Referenced in

Included in

Where Does TOSCA fit into?TOSCA: Here’s What We’ve Seen there…

o An application topologyo 3 layers

o Infrastructure (Cloud or DC objects)o Platform or Middleware (App containers)o Application modules, schemas and

configurations

o Relationships betweencomponents:o What’s hosted on what or installed on whato What’s connected to what

Infrastructure

Middleware

Application

Host Host Network

Apache Tomcat MySQL


What’s in a TOSCA Topology?o component in the topology are

called Nodeso Each Node has a Type (e.g.

Host, BD, Web server).o The Type is abstract and hence

portableo The Type defines Properties and

Interfaces

o An Interface is a set of hooks(named Operations)

o Nodes are connected to oneanother using Relationships

TOSCA, IasC StandardTOSCA Service Template [7]

TOSCA Core IngredientsTOSCA Service Template

Node Type

o Describes a Cloud or Software type (e.g. Serveror Apache)

oMaps the type to the actual impl. of the lifecycleinterface

Node Type (cont.)

o Defines properties as YAML mapsoMight define capabilities (What it can provide toother nodes)

Node Type (cont.)

oMight define requirements (what it needs fromother nodes)

TOSCA Core IngredientsTOSCA Service Template

Relationship Type

o Requirements and Capabilities are an implicitway to describe relationships

o Usually you need the explicit wayo You need hooks to configure the source or targetnode or both

o So relationships have types and interfaces as well

Relationships (cont.)

o The basic relationship types are:o dependsOn – abstract type and its sub types:o hostedOn – a node is contained within anothero connectsTo – a node has a connection configured toanother

o The basic interface is configureo preconfigure_source, preconfigure_targeto postconfigure_source, postconfigure_targeto add_target, remove_target

Node Templates

o An instance of a type (like Object to Class)o Has specific propertieso Has artifacts:

oWhat to installo How to install (mapped to interface hooks)

o Has requirements and capabilities (orrelationships)

Node Template (Examples)

Translated to TOSCA

Node

Node

Node

“Connects_to” relationship

“Hosted_on”relationship

Workflowso Imperative flow algorithmo Using a workflow engineo Timing the invocation of operations on differentnode

o Examples? Any BPMN specification!

o But… Considered out of scope for the standard(but currently debated, two factions formed inthe TOSCA TC)

Policieso Brings monitoring to the orchestration as inputo Ongoing evaluation of Ruleso Enforce SLA, Health, and anything elseo Can invoke more processeso Standard Structure: <Event><Condition><Action>o Standard Types:

o Access-‐Control;o Placement;o QoS (Quality) or (Continuity) CoS;

o Example?

Event Type<event_type_name>:

derived_from: <parent_event_type>version: <version_number>description: <policy_description>

Policy Definition<policy_name>:

type: <policy_type_name>description: <policy_description>properties: <property_definitions> # allowed targets for policy associationtargets: [ <list_of_valid_target_templates> ] * triggers:

<trigger_symbolic_name_1>:event: <event_type_name># TODO: Allow a TOSCA node filter here# required node (resource) to monitortarget_filter:

node: <node_template_name> <node_type># Used to reference another node related to# the node above via a relationshiprequirement: <requirement_name># optional capability within node to monitorcapability: <capability_name>

# required clause that compares an attribute# with the identified node or capability # for some conditioncondition: <constraint_clause> action:

# a) Define new TOSCA normative strategies# per-‐policy type and use here OR# b) allow domain-‐specific names<operation_name>: # (no lifecycle)

# TBD: Do we care about validation of types?# If so, we should use a TOSCA Lifecycle type description: <optional description>inputs: <list of property assignments >implementation: <script> | <service_name>

<trigger_symbolic_name_2>:...<trigger_symbolic_name_n>:

Eventname of a normativeTOSCA Event Type

Conditiondescribed as a constraint of an

attribute of the node (or capability)

identified by the filter.

ActionDescribes either: a)a well-‐known strategyb)an implementationartifact (e.g., scripts,service) to invoke

with optional property definitions as inputs (to either choice)

TOSCA Policy Example – Entities that compose Policy (Event, Condition, Action) model

TOSCA Policy Definitionmy_scaling_policy:

type: tosca.policies.scalingproperties: # normative TOSCA properties for scaling

min_instances: 1max_instances: 10default_instances: 3increment: 1

# target the policy at the “Pod”targets: [redis-‐master-‐pod ] triggers:

resize_compute: # symbolic nameevent: tosca.events.resource.utilizationtarget_filter:

node: master-‐containerrequirement: host capability: Container

condition: utilization greater_than 80%action:

# map to SENLIN::ACTION::RESIZEscaleup: # logical operation name

inputs: # optional inputs parametersnumber: 1strategy: BEST_EFFORT

Implementation: <script> | <service_name>

...

Example Senlin “scaling_out_policy_ceilometer.yaml”

Target is a Kubernetes Pod of the

tosca.groups.placement type

TODO:Need a % data type

for TOSCA

using the Kubernetes “redis” example

TOSCA normative event type (name) that would map todomain-‐specific names (e.g.,

OpenStack Ceilometer)

Symbolic name for the trigger

(could be used to reference an externalized version; however, this

would violate a Policy’s integrity as a“Security document” Find the attribute via the topology:

a) Navigate to node (directly or via therequirement name) and optionally theCapability name

b) The condition to map & register with thetarget monitoring service (e.g., Ceilometer)

Describe NODE to attach an alarm | alert | event to

i.e., Using the “node”, “req”, “cap” and “condition” keys

would expressed as a descriptive “filter”

Note: we combined the Senlin“Action” of

SENLIN:ACTION:RESIZEwith the strategy: BEST_EFFORT

to have one name

List optional input parms. here

*more info online

Putting it All Togethero TOSCA Template contains:o Application Topology

oNodeso Interfaceso Propertieso Artifacts (Plugins in Cloudify)

oRelationshipso Interfaces

oWorkflowso Policies

tosca_definitions_version: tosca_simple_yaml_1_0_0

description: >This TOSCA simple profile deployes nodejs, mongodb, elasticsearch, logstash and kibanaeach on a separate serverwith monitoring enabled for nodejs server where a sample nodejs application is running. The syslog and collectd areinsatlled on a nodejs server.

imports:-‐ tosca_base_type_definition.yaml-‐ paypalpizzastore_nodejs_app.yaml-‐ elasticsearch.yaml-‐ logstash.yaml-‐ kibana.yaml-‐ collectd.yaml-‐ rsyslog.yaml

dsl_definitions:host_capabilities: &host_capabilities# container properties (flavor)disk_size: 10 GBnum_cpus: { get_input: my_cpus }mem_size: 4096 MBos_capabilities: &os_capabilitiesarchitecture: x86_64type: Linuxdistribution: Ubuntuversion: 14.04

topology_template:inputs:my_cpus:type: integerdescription: Number of CPUs for the server.constraints:-‐ valid_values: [ 1, 2, 4, 8 ]

…

TOSCA YAML IasC Examples

oWordPress+MySQLo NodeJS App+MongoDB

WebServer-‐DBMS-‐1: WordPress -‐ MySQL

name

WebServer

Properties• component_version:• admin_credential:

Requirements

Container

server

Compute

Capabilities

Container

HostedOn

Capabilities

Container

wordpress

WebApplication

Properties• context_root:

Requirements

Container

HostedOn

mysql_dbms

DBMS

Properties• component_version• admin_credential• root_password• port

Requirements

Container

HostedOn

Capabilities

Container

mysql_database

Database

Properties• password• user• port• name

Requirements

Container

HostedOn

Capabilities

ConnectsTo

Endpoint.DB

Endpoint.DB

WebServer-‐DBMS-‐3: Nodejs -‐ MongoDB

nodejs

WebServer

Artifacts• nodejs_sample_app

Requirements

Container

app_server

Compute

Capabilities

Container

HostedOn

Capabilities

Container

paypal_sample

WebApplication

Properties• context_root:

Requirements

Container

HostedOn

mongo_dbms

DBMS

Properties• port

Requirements

Container

HostedOn

Capabilities

Container

mongo_database

Database

Properties• password• user• port• name

Requirements

Container

HostedOn

Capabilities

ConnectsTo

Endpoint.DB

Endpoint.DB

GitHubRepo.

Artifacts:nodejs_sample_app

mongo_server

Compute

Capabilities

Container

Session 3

Infrastructure-‐as-‐code in action: the DICER tool

DICER: IasC From Architectural Diagrams

o DevOps

oModel-‐Driven Engineering

!

Analysis

Deployment blueprint

DICER, incremental modeling and analysis

DICE Platform Independent Model (DPIM)

DICE Technology Specific Model (DTSM)

DICE Deployment Specific Model (DDSM)

is implemented by

is deployed onto

TOSCAblueprint

Analysis

Analysis

Analysis & Optimization

M2M transformation

M2M transformation

M2T transformation

DICE Methodology

DICER tool quick demo

DICER actual deployment

DICER Delivery Service

LogicalContainer 1

Blueprint A

Platform params

LogicalContainer 2

Blueprint B

Blueprint B.2

Platform params

LogicalContainer 15

Blueprint B.2

DICER TOSCA technology library

o A plug-‐in for Cloudifyo A single import line in the TOSCA blueprinto Node types + Chef cookbooks for Major Big Data serviceso Unified across supported IaaS vendors

Conclusion (1)

o DevOps is concerning all typical dimensions(team, process, tooling)

o Differently from other approaches, it focuses ontwo subjecto The application code (the software)o The code to create, run, control, evolve the machine

o TOSCA: an attempt to create a standard forinfrastructural code

Conclusion (2)

oWhat we misso A better connection between the design of softwareand the design of the infrastructure

o A precise and rigorous comparison between the newlanguages and tools for coding infrastructures

References[1] Erder, Murat and Pureur, Pierre. Continuous Architecture: Sustainable Architecture in an Agile and Cloud-‐Centric World. Amsterdam: Morgan Kaufmann, 2016. [2] Continuous Testing Paperback – January 2, 2014 by W. Ariola, C. Dunlop [3] Part of the Pipeline: Why Continuous Testing Is Essential, by Adam Auerbach, TechWell Insights August 2015[4] M. Fowler Continuous Integration, https://www.thoughtworks.com/continuous-‐integration[5] Chen, Lianping (2015) "Continuous Delivery: Huge Benefits, but Challenges Too” IEEE Software. 32(2): 50. [6] http://docs.oasis-‐open.org/tosca/TOSCA-‐Simple-‐Profile-‐YAML/v1.0/csd03/TOSCA-‐Simple-‐Profile-‐YAML-‐v1.0-‐csd03.html[7] P. Lipton, D. Palma, M. Rutkowski, and D. A. Tamburri, “Tosca solves big problems in the cloud and beyond!” IEEE Cloud, vol. 21, no. 11, pp. 31–39, 2016.[8] Guerriero, Michele, Tajfar, Saeed, Tamburri, Damian Andrew and Di Nitto, Elisabetta "Towards a model-‐driven design tool for big data architectures.." Paper presented at the meeting of the BIGDSE@ICSE, 2016.[9] Gómez, Abel, Merseguer, José, Di Nitto, Elisabetta and Tamburri, Damian Andrew. "Towards a UML profile for data intensive applications.." Paper presented at the meeting of the QUDOS@ISSTA, 2016.[10] Artac, Matej, Borovsak, Tadej, Di Nitto, Elisabetta, Guerriero, Michele and Tamburri, Damian Andrew. "Model-‐driven continuous deployment for quality DevOps.." Paper presented at the meeting of the QUDOS@ISSTA, 2016.

Links

o DICE deployment service:https://github.com/dice-‐project/DICE-‐Deployment-‐Service

o Big Data blueprint examples:https://github.com/dice-‐project/DICE-‐Deployment-‐Examples

o DICER:https://github.com/dice-‐project/DICER

DevOps:Introducing Infrastructure5as5Codewp.doc.ic.ac.uk/dice-h2020/wp-content/uploads/... ·...

Documents

Transcript of DevOps:Introducing Infrastructure5as5Codewp.doc.ic.ac.uk/dice-h2020/wp-content/uploads/... ·...