December 5, 2012
Kansas City DevOps Meetup
Agenda
• 5:30 – 6:15 – Meet, greet, and eat
• 6:15 – 6:45 – Google Fiberspace Presentation
• 6:45 – 7:00 – Agenda and Introductions
• 7:00 – 7:30 – Meetup group logistics
• 7:30 – 7:45 – Presentation – Aaron (Cerner) and Stathy
(OpsCode)
• 7:45 – 8:00 – Volunteers and next meeting decisions
• 8:00 Q&A and Wrap-up
“We are at our most productive when we share our thinking.
One night of crazy brain-storming over a few beers is more
likely to produce more exciting results than 20 years’
solitary study in the lab.”
–Professor Howard Trevor Jacobs, Descartes Prize Winner
Read more at redmonk.com - http://goo.gl/FEJyI
http://redmonk.com/jgovernor/2004/12/15/the-pub-is-the-place-for-creativity-and-innovation/
Who am I?
Area Director
My agenda
Bootstrap Meetups
Learn more
Share experiences with people from diverse backgrounds
Introductions …
~ 1m round the room brief intro, don’t be too shy 
“Rules of Engagement”
3 Rules of DevOps Meetup
“Rules of Engagement”
1st Rule:
Talk about DevOps
Meetup
“Rules of Engagement”
Collaboration
&
Community
“Rules of Engagement”
2nd Rule:
TALK about
DevOps Meetup
“Rules of Engagement”
3rd Rule:
No Assholes
“Rules of Engagement”
Collaborate and debate
NO disrespect
“Rules of Engagement”
DevOps = Community
Logistics
• Topic coverage? topic focus?
• Lightning talks, 4-5, 5-10m each
• Unmeeting – Larger group
• Presentations – Intro & Advanced
• Demo & Tutorial
• Case studies and experience sharing.
• Monthly? Bi-monthly? Quarterly?
“Infrastructure As Code” 101
Infrastructure is Complex
• Nodes
• Networking
• Files
• Directories
• Symlinks
• Mounts
• Routes
• Users
• Groups
• Packages
• Services
• Filesystems
Items of Manipulation
(resources)
Application
See Node
Application
Application Database
See Nodes
Application
App Databases
See Nodes Grow
App Servers
App Databases
See Nodes Grow
App LB
App Servers
App Databases
See Nodes Grow
App LBs
App Servers
App Databases
See Nodes Grow
App LBs
App Servers
App DB Cache
App DBs
See Nodes Grow
App LBs
App Servers
App DB Cache
App DBs
Infrastructures have topology
Round Robin
DNS
App Servers
App DB Cache
App DBs
Floating IP?
Yours is a snowflake
App LBs
App Servers
NoSQL
DB slaves
Cache
DB Cache
DBs
Complexity increases quickly
USA
EUR
AUS
It increases globally...
Traditional Thinking Won’t Make the Grade …
Before discussing the future,
Let’s review the past.
More importantly why
“traditional” enterprise
technologies will not cut it.
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 20151980 1981 1982 1983 1984 1985 1986 1987 1988 1989
Unprecedented Growth AND Complexity …
1980
Mainframe
1990
Client/Server
2000
Datacenter
2010+
Cloud
Scale x Complexity > Skills
Inflection point forces
disruption.
Inflection Point Inspires …
Mainframe Client/Server Datacenter
Cloudy
-
20
40
60
80
100
120
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Millions
Physcial Hardware Virtual Nodes
Traditional, data
model driven
applications.
Traditional, doma
in model driven
applications.
“Infrastructure As
Code”
“Infrastructure As
Code”
USA
EUR
AUS
How can this be abstracted AND represented?
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Maturity of “Infrastructure As Code”
“In God we Trust, all others bring DATA!!!”
http://radar.oreilly.com/2007/10/operations-is-a-competitive-ad.html
VS
• A configuration management system (DSL)
• A library for configuration management
• A community, contributing to library and expertise
• A systems integration platform (API)
http://www.flickr.com/photos/asten/2159525309/sizes/l/
“Infrastructure As Code”
Some Samples
package { "apache2":
ensure => latest
}
service { "apache2":
ensure => running,
require => Package["apache2"],
subscribe => File[httpdconf],
}
Some Samples
package "apache2" do
package_name node[:apache][:package]
action :install
end
template "/etc/www/configures-apache.conf" do
notifies :restart, "service[apache2]”
end
service “apache2”
The players
Metaphor Attribution – Andrew Shafer, now of Rackspace
Dev Ops&
Meet Dev
• Little bit weird
• Sits closer to the boss
• Thinks too hard
Don’t hate the
player …
Metaphor Attribution – Andrew Shafer, now of Rackspace
Meet Ops
• Pulls levers & turns knobs
• Easily excited
• Yells a lot in emergencies
Why you be hatin
? ! ?
Metaphor Attribution – Andrew Shafer, now of Rackspace
Traditional Process
Dev’s job is to add new
features.
Ops’ job is to keep the site
stable and fast
Load
Balancer
App Server
Database
Dev (shared)
Dev - QA - UAT - Prod
Load Balancer
App Server App Server
Database
Load
Balancer
App Server
Database
QA
Agility - Design vs Manufacturing
How ?
Dev ProdQA
Goal = Increase Velocity
Agility - Design vs Manufacturing
Load
Balancer
App
Server
App
Server
Database
Load
Balancer
App
Server
App
Server
Database
Load
Balancer
App
Server
App
Server
Database
What ?
“Infrastructure As Code” + Continuous Deployment
Value of Continuous Deployment?
• Visibility and Accountability
• Reduce Risk
• Increase Productivity
• Innovate Faster
• Business Agility
Thank You!
Stathy Touloumis
stathy@opscode.com
Twitter | IRC | github: stathyinc
Thank You!
Aaron Blythe
aaron.blythe@gmail.com
Twitter: ablythe
Github: aaronblythe
Topic Brainstorming
• 7:45 – 8:00 – Volunteers and Topics
• Frequency of meeting – 5th of every month?
• Solidify next few topics to cover
• Pick topic(s) and speaker(s) for the next meeting

Devops kc meetup_5_20_2013

Editor's Notes

  • #3 5:30 – 6:15 – Meet, greet, and eat6:15 – 7:00 – Welcome, introductions, and agenda7:00 – 7:30 – Meetup group logisticsExpectations and general thoughtsPotential future topics we'd like to coverDetermine how often we'd like to meet7:30 – 7:45 – Infrastructure as Code, short prezo7:45 – 8:00 – "Picks" and then wrap-up.Solidify next few topics to coverPick topic(s) and speaker(s) for the next meeting8:00 Wrap-up
  • #4 Pre-empt introductions with a simple yet powerful statement.Spirit of community and collaboration.
  • #5 Main – Help bootstrap technology groups around Midwest region.Began tech career diving feet first into co-founding ISP, multiple downturns and upturns, multiple generations of Automation technology, 7 yrs Software Eng, 3 yrs leadingApply learning in different contexts – industries, maturity, organizations, cultures
  • #10 Context around “No Assholes”Have respect for others who may be less experienced, have less exposure or maybe just do not learn as fast.Have respect for those who may have limited time and/or realize some topics are not easily conveyed.Mutual Respect
  • #11 Mutual RespectIt’s not so much about just technology but the complete interaction of people, process and technology used.If you can’t get along with people, you are missing a big part of the equation.
  • #13 DevOps is bigger than Dev and OpsSpans other tech groups, dba’s, QASpans business side tooGet out of the “us” vs “them” mentality
  • #14 Things to decide after prezoTopic Coverage possibilitiesMeeting frequency[Come up with several topics]
  • #15 DevOps is bigger than Dev and OpsSpans other tech groups, dba’s, QASpans business side tooGet out of the “us” vs “them” mentality
  • #30 Automation nothing new but the complexity we just talked about has really proliferated with enabling platforms such as virtualization and cloud.
  • #31 Infrastructure As Code is nothing newIt’s been growing in popularity, was always a consideration with cutting edge Bay Area tech firms.The inflection point has given it escape velocity.
  • #33 CFEngine – Mark BurgessPuppet – Luke KaniesOpscode – Adam Jacob
  • #34 SALES-> “Infrastructure As Code” Opscode positionObvious, several articles on Oreilly discussing studies and data from companies using “secret sauce” tech which is really “Infrastructure As Code” VS traditional methods including enterprise tech.http://radar.oreilly.com/2007/10/operations-is-a-competitive-ad.html
  • #38 How does this apply to DevOps?So how many people recognize these characters? And I’m not just talking about Spock and Scotty, how many people recognize the traditional IT roles embedded in their behaviors.Metaphor Attribution – Andrew Shafer, now of Rackspace
  • #41 And furthermore, we think these two roles have always pinned dev and ops against each other. Developers are measured based on the output of new functionality they churn out. Create a bunch of features, send them over the wall to Q&A/release/ops who are left to deploy and scale that new functionality while keeping the site up. Ops meanwhile, is really only tasked with just that, with keeping everything running as a sole focus. What is the single most common way to make a running site go down, introduce change…