1. Exploring Devops Amanda Crawford
Cs2610 multimedia software engineering
University of pittsburgh
This Photo by Unknown Author is licensed under CC BY-SA

2. Paper 1: Modern devops: optimizing software development through effective system interactions
Constantine cois, joseph yankel, anne Connell
Carnegie mellon university, software engineering institute
2014

3. The Communication problem in sdlc
Challenge of accurately recording and communicating changes to fundamental requirements and constraints
Vast amounts of information relating to source code, testing, etc
Lack of “focus time” for developers to complete tasks
Lack of proper and timely communication
Automating the communication tasks in the process:
1. record data from the complex system of running software project
2. data into information and knowledge
3. Communicate knowledge in real time to all actors who rely on it to perform properly
Data Driven Approach + DevOps Approach
Data-Driven
Information extraction
Branches off of DIKW Pyramid, Information Science
Data is distilled ino information, knowledge
2. DevOPs-
provides automated to enable efficient collection and organization of data and communicate the data to appropriate actors without humans
Challenge of accurately recording and communicating changes to fundamental requirements and constraints
Information changes and new information comes available,
Existing information repositories and artifacts must be update
Want to avoid injecting defects into the software
Want to avoid wasted effort spent working with incorrect information
Vast amounts of information relating to source code, testing, etc
Must be maintained and updated immediately
Dissemination of information is needed in real time
This need can take a toll on project resources, in which continuous meetings, document creation/congestion and
Reduces productivity

4. Waterfall Sequential Downward Completion
Each output is an input for the following stage
Change Resistant
Has difficulty adapting to change
Changes anytime in the life cycle has a high risk of leading to project failures

5. Agile Practices iterative and incremental development Emphasizes:
direct and constant communication
Adaptive planning
Requires highly effective and efficient communication and tools

6. Data driven development and communication
Addresses the requirements of SDLC:
Detects degrading progress
Collection of accurate and up to date information
Identifying needs for adjustments
Constantly collects large amounts of data and metrics
Data is used to maintain maximal project team performance
Still, if human actors are collecting the data, there is still a lapse in performance
Data Driven Development
Promotes the continual collection of data throughout the SDLC to inform
Prioritization
Tasking
Adaptions
Of the process and ensures success within constraints
Temporal
Budget
Automated Devops
Brings together software developers and operations staff

7. DevOPs
Provides interoperability of software and operations to ensure the maximal data access, knowledge dissemination, and automation
Bridges the siloed operations and development teams
Leverages semi autonomous technologies to facilitate data driven development and communication
Complex tasks are handed off to the machine automation to mitigate the burden of distraction and context switching
Addresses the challenge of managing and maintaining the software development process and tools
Constant communication is between project team members, managers, and clients through project life cycle
Communication is critical to the success of the projects
Constantly changing information Need accurate , readily available, easily found, real time

8. Marriage of humans and systems
Find a balance in maximizing the productivity and quality levels by dividing task between system and human actors
Marriage of humans and systems
System Actors
Offload information and management tasks to system actors
Improves the processes
Maximize the human actors by performing automatable tasks autonomously and seamlessly
Human Actors
Use human actors to focus on specialized tasks
Highly skilled specialists
Specialist knowledge works
Structures the systems actors to handle communication and generic tasks

9. Generalized model for devops
Relevant data and information is contained within both the human and system actors. Communication between the two are defined via software interfaces.
The efficiency is defined in the respect that human actors do not perform the message passing tasks. System actors must be designed to:
pass data between themselves
extract data as needed
Present insights to human actors ONLY when necessary
Links between each category represent a necessary communication between system actors
This can help via an interface
Implies that information can be passed between systems

10. System actors categories
Source Control - Storing and manage versions of source code and artifacts
Issue/Task Tracking – manage projects tasks and status
Build (CI) System – compile, build, and test software source code to produce a functioning application. Continously builds and test the application when changes are pushed

11. System actors categories
Documentation Systems – systems that are used to create, store, transfer, and display software project documentation.
Often human actors manually use text editors and s to transfer documents
Code Review Systems – systems that reviews software source code for correctness and quality
Monitoring System – monitors the state and functionality of all other systems, ensuring that they are operational and notifying the correct actors

12. System actors categories
Integration Environment – the environment in which all systems and artifacts operate.
Virtual infrastructure such as VM
Communication Systems – responsible for communication knowledge to the human actors.
This communication can be from both system and human actors

13. Information flow between human and system actors
Communication Phases
Initial Human Actor  System Actor (Input)
System Actor  System Actor ( Communication)
System  Human (Output)

14. Information flow between human and system actors
Shifts majority of the communication requirements to the system actors
Allows human actors to focus on specialized creative task
Ensure immediate and accurate updates of all knowledge across the platform

15. Standards-based DevOps Automation and Integration Using TOSCA Johannes Wettinger, Uwe Breitenb¨ucher, Frank Leymann Institute of Architecture of Application Systems (IAAS) University of Stuttgart 2014
This Photo by Unknown Author is licensed under CC BY-SA
This Photo by Unknown Author is licensed under CC BY-SA
This Photo by Unknown Author is licensed under CC BY-NC-ND

16. Devops Traditional Approach DevOps Approach
Development and operations team have two separate goals
Collaboration is based on a slow and manual process
Deployment process is often manual
Traditional Approach
Development and operations team have the same goal
Collaboration is faster* and seeks to be automated
Automation is used to handle deployment
Uses reusable tools and components
DevOps Approach
For instance, developers want to push changes into production as fast as possible, whereas the operations personnel’s main goal is to keep production environments stable [1]

17. Challenges of automating the deployment
Topology is composed of multiple infrastructures
HTTP Server DB
Master/Slave
There are no out of the box DevOps tools to handle a complete process.
The challenge is combining differing artifacts to model the deployment
form exisiting artifacts to make them reusable and composable in a seamless and interoperable manner
TOSCA standard to modeling of artifacts
The application itself is hosted on an Apache HTTP server and depends on the PHP module; the database of the application is hosted on a MySQL master/slave environment to improve the application’s scalability and to enable high availability of the database: data that are written to the master instance are consistently replicated to the slave instances, so reading requests can be load-balanced between slave instances. In case the master instance breaks, a slave instance can be selected to be the new master instance. The underlying infrastructures and/or platforms could be chosen depending on certain requirements or preferences. For instance, the Apache and MySQL servers could be hosted on virtual machines provided by Amazon Web Services3. To implement deployment automation for this application we want to reuse existing DevOps artifacts, especially to deploy the middleware components.
no Chef cookbook to deploy a complete MySQL master/slave environment out of the box. Consequently, we may better use the MySQL charm4 shared by the Juju community to deploy and dynamically scale such a MySQL setup

18. Initial devops classification of artifacts
Node Centric Artifacts(NCA) – things that are executed on a single node
VM Images
Config Definitions
Doesn’t handle cross node relations
Examples: Chef cookbooks, Puppet Modules, Docker Images
Environment Artifacts(ECA) – things that are executed in an environment of multiple nodes
Bundles
Templates
Examples: JuJu Charms, OpenStack Heat
Relationshi[
Orchestration
ECAs typically use and orchestrate NCAs
Management
ECA use NCA to provide consistent environment contexts in a multi node environment

19. Aspects of nca’s and eca’s
Level of dependencies
Provider dependent
Tooling dependent
Level of Virtualization
Hypervisor-based virtualization
Container virtualization
Infrastructure Centric vs Application Centric
Resources focus on configuration and orchestration of middle ware (application)
Resources focus on configuration and orchestration of VMs, storage, and network (infrastructure)
Definition vs Image Based
Definition – configuration definition
Declarative vs Imperative
Images – Dockers images
Dependencies
providerdependent such as CloudFormation templates, i.e., they can only be used in combination with a certain provider such as Amazon in this case. Other artifacts are toolingdependent suchasChefcookbooksorJujucharms:they can be used in conjunction with different providers, but require certain tooling such as a Chef runtime or a Juju runtime.
Definition-based artifacts can be created in a declarative, in an imperative, or in a combined manner. For instance, Chef cookbooks typically define the desired state of a resource using a declarative domain-specific language [4], [15]. However, imperative statements can alsobepartofsuchartifacts.Unixshellscriptstypically consist of a set of imperative command statement

20. Chef Classification Node Centric Artifact
Definition Based: Used to define configurations
Both Declarative and Imperative
Tooling Dependent
Supports different levels of virtualization
Application Centric
Infrastructure centric : focuses on the distribution of infrastructure resources
Chef [4], [5] is a configuration management framework that provides a domain-specific language (Chef DSL) based on Ruby.
e Chef server acts as a central management instance for the recipes, run lists, and attributes. Each node has a run list and a set of attributes assigned.
To sum it up: according to our classification aspects presented in Section III-A, Chef is a tooling-dependent but not provider-dependent solution that supports different levels of virtualization: Chef recipes can be executed on physical servers, VMs, and containers. Chef is infrastructure-centric because it focuses on the distribution and execution of recipes on infrastructure resources such as VMs. Because Chef recipes are typically declarative scripts, although they may include imperative statements as well, Chef follows the idea of creating and maintaining definition-based artifacts. Chef recipes are node-centric artifacts because they run in the scope of a single node.

21. JuJu Classification Environment Centric Artifact Tooling Dependent
Hypervisor based virtualization
Environment Centric
Definition Based
Uses imperative language
Expressed in a declarative model
Juju does not prescribe the usage of any domain-specific language to create these scripts. Figure 4 denotes the environment-centric focus of Juju: charm instances and their configurations live in a certain environment such as an interconnected set of VMs hosted at Amazon Web Services. Charminstancescanbelinkedsuchasanapplicationcomponent that is connected to a database. These links are explicitly expressed and can be configured.
These links are explicitly expressed and can be configured. In contrast to Chef, charms and charm instances are the main entities; the underlying nodes and the scripts that are executed on them provide the required infrastructure to host the charm instances. It is important to denote that a charm instance is not limited to the scope of a single node.

22. TOSCA
Goal is to enhance the portability and management of applications
Topology Templates – graphs of nodes and relationships of topological structure
Node Templates/ Types
Relationship Templates / Types
Operations
Requirements
Capabilities
Supports the deployment and management of applications
Imperative processing - management plans
Declarative processing – does not require any plan
TOSCA supports the deployment and management of applications. To enable completely self-contained CSARs, management plans can be stored directly in the corresponding CSAR. Thus, imperative TOSCA runtime engines run these plans to consistently execute management tasks.
the declarative approach does not require any plans: a declarative TOSCA runtime engine derives the corresponding logic automatically by interpreting the topology template.
We ignore the difference

23. Methodical transformation framework
Manual selection of artifacts
Dependencies are resolved
Generate TOSCA application model
Chef Cookbook Transformation
Juju Charms Transformation
Build and deploy TOSCA model
Based on the selection, the artifacts are automatically retrieved, e.g., from the public Juju charm store.

24. Chef: fine grained transformation
Each TOSCA Node represents a chef cookbook
Each cookbook owns a metadata.rb – describes a dependencies on other cookbooks
Attributes – gives the node type properties
Low-level nodes and can become very large and complex to manage
Based on the selection, the artifacts are automatically retrieved, e.g., from the public Juju charm store.

25. CHEF: Course grained transformation
One node may contain multiple cookbooks with dependencies
Skips the creating of low level nodes
Can be hard to separate functionality such as operating systems cookbooks and middle ware cookbooks
Balances out fine – grained transformation

26. Webshop transformation
Lifecycle scripts that need to be executed on the source node are mapped to source operations in the generated relationship type; scripts that are supposed to be executed on the target node result in target operations.
Webshop transformation

27. conclusion Devops is a culture and has many different facets
Communication between systems and human requires deep analysis
Automation and orchestration should be composed using a we defined and systematic fashion
Both scenarios and solutions are derived from the discovery of patterns
Both of these examples can be modeled as IC cards and SIS

28. References
Cois, C. A., Yankel, J., & Connell, A. (2014, October). Modern DevOps: Optimizing software development through effective system interactions. In Professional Communication Conference (IPCC), 2014 IEEE International (pp. 1- 7). IEEE.
Wettinger, J., Breitenbücher, U., & Leymann, F. (2014, December). Standards- based DevOps automation and integration using TOSCA. In Proceedings of the IEEE/ACM 7th International Conference on Utility and Cloud Computing (pp ). IEEE Computer Society.