Devops kc meetup_5_20_2013


Published on

  • @WilliamMullins2 I certainly hope you can make it to future meetups like the one this Monday. Adam Jabob was very impressed with your diagram at the first meetup. I have heard that he has taken it and is trying to find ways to work it into future presentations. I look forward to future discussions with you if I am lucky enough to have them. You seem to have a very deep way about your thinking.

    I am curious what you think of as forward engineered systems? Is it simply designed and added to as time goes on? (As opposed to the more commonly used reversed engineering of picking apart an existing system?) A lot of parallels are being drawn from software to manufacturing these days (I guess they always have since Ford-ian management is employed so often, despite all of Drucker's writing on knowledge workers). Since many of us no longer ship software, but rather systems that are directly consumed (APIs, websites, etc.) it seems awkward that there is almost never a finished product as there is with manufacturing and or other physical engineering endeavors. Sure we ship an App that lands in an App Store, but it is often useless without the data and services that feed it. Those have these requirements of always being there. If they are done right the first time (which almost never occurs) they still carry with them these costs of continually being up.

    The continuous nature of the server and data side of the equation is something I would love to chat about with you sometime. Hope you make it out to future events!
    Are you sure you want to  Yes  No
    Your message goes here
  • DevOps = Community

    Groups, Teams, and Communities of Practice are typically used somewhat interchangeably - at least in Meet Up type situations where no single established enterprise is directing the activity.

    But as terms of reference in the domain of curating Collaboration, groups are typically work off line-of-sight exchanges that eschew inter-agent complexity in the interest of efficiency. Most of project management can be accomplished by proficient forward-engineering of a PERT architecture into plans, procedures, budgets and schedules.

    In distinction, Teams and Communities embrace inter-agent complexity - it is where the positive returns (i.e. complexity grounded emergent - sum-greater-than-parts outcomes) are to be found. It seems that positive returns reflect a Return on Objective contribution - enterprise sustainment - that is a needed substrate for the conduct of all those specific projects.

    It is said that upwards of 70% of all organizational change management initiatives fail to meet the expectations of sponsors. From the stories of those that do succeed, the importance of nurturing the relationship ground of the technical changes comes across clearly - still doing that upfront work is typically shorted more often than not.

    I'd like to suggest that Community as Complex Architecture may warrant some conversation in parallel with the notion of Architecture as Code. Any experienced Community Organizers in the crowd?

    Cheers, Bill M, Better Choices Consulting
    Are you sure you want to  Yes  No
    Your message goes here
  • DevOps = Community

    Do terms or reference matter? Certainly in 'coding' they do; but what about the 'curating' half of hacking? I use hacking to encompass both the techware (i.e. digitized-coded half of the enterprise) and the sociological (i.e. the part of the enterprise where collaboration, mutual trust and adaption to outcomes of all types occur).

    So is there agreement on the span of 'complexity' as a meme? Is intense mechanical complication (e.g. as appears on slide 29) in the domain of techware or on the socio side of the enterprise.

    From the perspectives of Systems Thinking, Neuroscience, and Complexity Science, biological systems have complexity by virtue of the non-linear interdependence of the agents that comprise the enterprise web.

    History in other CHCC domains suggests there may be an important juncture regarding how the issue of the socio-technological interface is framed for purposes of discussing matters of complexity.

    In 'Behind Human Error' Woods et. al. provide an very thorough survey of the trials and tribulations of those who've worked to understand the 'workings' of the high-technology enterprise in areas like medicine, aerospace, nuclear and chemical energy, and maritime operations.

    Of immediate interest to the DevOps movement might be Chapter 9 on the 'Clumsy Use of Technology' (i.e. here meaning computer supported decision making such are aircraft flight management or automated surgical anesthesia administration).

    As a sample: 'The characteristics of the [defect-generating] systems are problems because of the way they shape practitioner cognition and collaboration in their field of activity. These are not deficiencies in an absolute sense; whether or not they are flaws depends on the context of use.'

    Forward-engineered systems - those that conform to the linear logic of Newtonian systems design - can become enormously complicated in the CAD system or at the Workstation - still they cross a threshold into complexity only when they become part of the system they are intended to support (of course a project developing a complicated software product is a complex-adaptive system context as well but its not the User's system).
    Are you sure you want to  Yes  No
    Your message goes here
  • Bill Mullins will be posting comments on some slides as WPM:

    Although I'm new to the DevOps conversation, I come by way of four decades of experience in Complex, High-Consequence Circumstance enterprises - in 1974 I was the Chief Engineer on a new construction nuclear submarine; Baton Rouge was the second in first class of submarines to have a fully digitized sonar, fire control, and navigation system.

    My interest in the challenges of sustaining performance in CHCC socio-technical enterprises has never flagged. The DevOps conversation is very familiar in form if not in specific details. I look forward to learning more about the on-going effort and regret I had to cancel on the meeting on the 20th do to a last minute family matter.

    In subsequent comments I'm going to offer some perspectives from outside the DevOps emergence trajectory. Everything these days very quickly gets arcane (aka 'stovepiped') particularly among those without any prior relationships. I hope that these comments will prove as useful to you are as they are to me in developing them for communication across a 'cultural boundary.'
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • Pre-empt introductions with a simple yet powerful statement.Spirit of community and collaboration.
  • 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
  • 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
  • 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.
  • DevOps is bigger than Dev and OpsSpans other tech groups, dba’s, QASpans business side tooGet out of the “us” vs “them” mentality
  • Things to decide after prezoTopic Coverage possibilitiesMeeting frequency[Come up with several topics]
  • DevOps is bigger than Dev and OpsSpans other tech groups, dba’s, QASpans business side tooGet out of the “us” vs “them” mentality
  • Automation nothing new but the complexity we just talked about has really proliferated with enabling platforms such as virtualization and cloud.
  • 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.
  • CFEngine – Mark BurgessPuppet – Luke KaniesOpscode – Adam Jacob
  • 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.
  • 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
  • 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…
  • Devops kc meetup_5_20_2013

    1. 1. December 5, 2012Kansas City DevOps Meetup
    2. 2. 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
    3. 3. “We are at our most productive when we share our thinking.One night of crazy brain-storming over a few beers is morelikely to produce more exciting results than 20 years’solitary study in the lab.”–Professor Howard Trevor Jacobs, Descartes Prize WinnerRead more at -
    4. 4. Who am I?Area DirectorMy agendaBootstrap MeetupsLearn moreShare experiences with people from diverse backgroundsIntroductions …~ 1m round the room brief intro, don’t be too shy 
    5. 5. “Rules of Engagement”3 Rules of DevOps Meetup
    6. 6. “Rules of Engagement”1st Rule:Talk about DevOpsMeetup
    7. 7. “Rules of Engagement”Collaboration&Community
    8. 8. “Rules of Engagement”2nd Rule:TALK aboutDevOps Meetup
    9. 9. “Rules of Engagement”3rd Rule:No Assholes
    10. 10. “Rules of Engagement”Collaborate and debateNO disrespect
    11. 11. “Rules of Engagement”DevOps = Community
    12. 12. 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?
    13. 13. “Infrastructure As Code” 101
    14. 14. Infrastructure is Complex
    15. 15. • Nodes• Networking• Files• Directories• Symlinks• Mounts• Routes• Users• Groups• Packages• Services• FilesystemsItems of Manipulation(resources)
    16. 16. ApplicationSee Node
    17. 17. ApplicationApplication DatabaseSee Nodes
    18. 18. ApplicationApp DatabasesSee Nodes Grow
    19. 19. App ServersApp DatabasesSee Nodes Grow
    20. 20. App LBApp ServersApp DatabasesSee Nodes Grow
    21. 21. App LBsApp ServersApp DatabasesSee Nodes Grow
    22. 22. App LBsApp ServersApp DB CacheApp DBsSee Nodes Grow
    23. 23. App LBsApp ServersApp DB CacheApp DBsInfrastructures have topology
    24. 24. Round RobinDNSApp ServersApp DB CacheApp DBsFloating IP?Yours is a snowflake
    25. 25. App LBsApp ServersNoSQLDB slavesCacheDB CacheDBsComplexity increases quickly
    26. 26. USAEURAUSIt increases globally...
    27. 27. Traditional Thinking Won’t Make the Grade …Before discussing the future,Let’s review the past.More importantly why“traditional” enterprisetechnologies will not cut it.
    28. 28. 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 1989Unprecedented Growth AND Complexity …1980Mainframe1990Client/Server2000Datacenter2010+CloudScale x Complexity > SkillsInflection point forcesdisruption.
    29. 29. Inflection Point Inspires …Mainframe Client/Server DatacenterCloudy-204060801001201990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015MillionsPhyscial Hardware Virtual NodesTraditional, datamodel drivenapplications.Traditional, domain model drivenapplications.“Infrastructure AsCode”“Infrastructure AsCode”
    30. 30. USAEURAUSHow can this be abstracted AND represented?
    31. 31. 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 2015Maturity of “Infrastructure As Code”
    32. 32. “In God we Trust, all others bring DATA!!!”
    33. 33. • A configuration management system (DSL)• A library for configuration management• A community, contributing to library and expertise• A systems integration platform (API)“Infrastructure As Code”
    34. 34. Some Samplespackage { "apache2":ensure => latest}service { "apache2":ensure => running,require => Package["apache2"],subscribe => File[httpdconf],}
    35. 35. Some Samplespackage "apache2" dopackage_name node[:apache][:package]action :installendtemplate "/etc/www/configures-apache.conf" donotifies :restart, "service[apache2]”endservice “apache2”
    36. 36. The playersMetaphor Attribution – Andrew Shafer, now of RackspaceDev Ops&
    37. 37. Meet Dev• Little bit weird• Sits closer to the boss• Thinks too hardDon’t hate theplayer …Metaphor Attribution – Andrew Shafer, now of Rackspace
    38. 38. Meet Ops• Pulls levers & turns knobs• Easily excited• Yells a lot in emergenciesWhy you be hatin? ! ?Metaphor Attribution – Andrew Shafer, now of Rackspace
    39. 39. Traditional ProcessDev’s job is to add newfeatures.Ops’ job is to keep the sitestable and fast
    40. 40. LoadBalancerApp ServerDatabaseDev (shared)Dev - QA - UAT - ProdLoad BalancerApp Server App ServerDatabaseLoadBalancerApp ServerDatabaseQAAgility - Design vs ManufacturingHow ?
    41. 41. Dev ProdQAGoal = Increase VelocityAgility - Design vs ManufacturingLoadBalancerAppServerAppServerDatabaseLoadBalancerAppServerAppServerDatabaseLoadBalancerAppServerAppServerDatabaseWhat ?
    42. 42. “Infrastructure As Code” + Continuous DeploymentValue of Continuous Deployment?• Visibility and Accountability• Reduce Risk• Increase Productivity• Innovate Faster• Business Agility
    43. 43. Thank You!Stathy Touloumisstathy@opscode.comTwitter | IRC | github: stathyinc
    44. 44. Thank You!Aaron Blytheaaron.blythe@gmail.comTwitter: ablytheGithub: aaronblythe
    45. 45. 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