Losing Sight of DevOps in an Automation Forest - devopsdays Atlanta 2013

T.j.
Randall,
Director
of
Sales
Engineering,
XebiaLabs

Losing
Sight
of
DevOps
in
an
Automa5on
Forest

© Copyright 2013 XebiaLabs Inc. Proprietary & Confidential.
o  Original speaker for this topic
was Andrew Phillips, VP
Products at XebiaLabs.
o  Unfortunately, Andrew was
unable to be here for DevOps
Days Atlanta 2013.
Let’s Lower those Expectations!
The B Team

Many "DevOps discussions ", both at technical and at manager level, quickly turn
to automation and tooling. But DevOps is about much more than technology!
Are we losing track of the people and practices components that are critical,
and often much harder to implement, than putting some new tech in place?
Or have we learned that smart tech makes people and process changes
unnecessary?
We'll talk about whether we're really losing track of The Big Picture here, and, if
so, discuss suggestions and approaches to tackle this issue.
Abstract

o  Really hot area right now
o  Analyst predictions are that 80% of Fortune 500
companies will go through a “DevOps refresh”
in the next 5 years
o  We’re part of the cool crowd!
It’s a great time to be involved in DevOps!
http://colt-rane.com/eiknarf-cool-crowd/
Before we get too carried away,
though, let’s take a step back and ask
ourselves: what does it actually mean
to “do DevOps or be DevOps”?

Why do we need DevOps?
http://www.projectcartoon.com/create/

Let’s go back to the roots a bit
o  Applying Agile principles to post-development
phases
o  Breaking down the wall between Dev and Ops
o  Getting everyone to think about the entire
lifecycle of an app
o  One team to deliver the service with visibility into
the end-to-end process
http://thehacktory.org/wp-content/uploads/2011/03/office-space-employees-smashing-printer.jpeg
http://devops.com/2013/02/11/defining-the-dev-and-the-ops-roles-in-devops/

When we speak to prospects, when looking at “DevOps job profiles” etc.,
what we very often hear instead is:
•  “We want to implement automated deployment and provisioning
using Deployit / Puppet / Chef / Salt / Rundeck /…”
•  “We want to do some cloud stuff, have more monitoring etc. etc.”
Don’t get us wrong – we love these tools (especially Deployit!)
But in truth, “Delivery Acceleration” is actually a much better term for what
companies evidently are looking to achieve when they say “DevOps”
How are folks talking about DevOps?

There’s no denying that tools help
avoid error-prone, slow processes
and make service delivery better
Tools are good!
But let’s be careful to avoid falling into the trap of believing that
“having automated tooling = doing DevOps”
Of course, vendors are highly motivated to promote, “Just put our
magic box/platform and….tadaaaa, you’ve done DevOps!”
Automation is a means, it’s not the goal of DevOps!

There are plenty of shops that use these tools expertly and where still:
•  Devs don’t know the architecture of the environment where their
application will end up running
•  Ops don’t have any input into the design and architecture of the
application
•  QA is brought in late in the Dev cycle, giving them little opportunity to
understand & build testing for scope of changes
•  Business views the Dev process as a black box, with little insight into the
actual functionality being delivered
•  Responsibilities are split, with devs providing code, Ops providing an
(automated) “platform”, and everyone else just “getting what you get”
But tools aren’t everything…..

Of course, there is a good reason why
people focus on automation first:
•  It can deliver demonstrable value
quickly
•  Compared to changing your
processes and, perhaps even, your
culture, introducing automation is
the easy option
•  And sometimes you may indeed
get enough value out of
automation to say “we’re done”
Why do we focus on tools?
Because we’re geeks!! We love
complexity!
http://goo.gl/ezqr7Z

But don’t kid yourself that you’re automatically “doing DevOps” with tools!
Remember Continuous Integration on a Dollar a Day1 –
CI is not just “install Jenkins and you’re done!”
Keep the end goal in mind:
The Really Big Benefits come from the end-to-end insight,
cooperation, understanding and shared goals
…not just the end-to-end automation
How to really “Do DevOps”?
[1] http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

It’s challenging for larger
organizations to include all
of the various teams
involved in the application
delivery process.
This is hard!

Here’s a fun sample of answers from a recent survey:
o When was the last time Dev and Ops from your teams went out for a beer?
o Do Dev and Ops have shared incentive structures, do they go on joint
teambuilding exercises etc.?
o When is the first time an Ops team member gets involved in a Dev project?
o How much regular contact is planned between Dev and Ops after the
release goes live?
o How many Ops stories/wishes/requests are incorporated into the Dev
backlog?
What do you mean by “doing DevOps”?

There are three areas of preparation for DevOps that CIOs /
decision-makers / change agents should examine to prioritize action and
gauge readiness:
People
Processes
Technology
People, Processes and Technology for DevOps

People questions to ask include:
o  Do you consistently bring the entire
app team together during a release,
to review all aspects of the release?
(not to focus discussion timelines! ;)
o  Does everyone attend the post
mortem for each application
releases? How does offshore give
their feedback?
o  Do you capture and implement and
track changes to your process based
on feedback of previous releases?
The Peeps in DevOps
DevOps is about getting people to work together better
through shared understanding, goals and responsibilities
Examples:
o  A 15 minute SCRUM for each
team in the release – same rules
apply!
o  Not a session to hammer on
issues / delays – a real meeting to
gather feedback for the next
iteration!
o  Something as simple as a Wiki
page or Excel to track items –
keeps them in front of people.

Process questions to ask include:
o  Is it possible for team members, during the
development phase of a project, to
allocate time to other team areas for
collaboration and discussion?
o  During the planning phases of a new
infrastructure rollout can an operations
project allocate time to developers to
discuss the implications on development?
o  Do development and operations people
regard themselves as working with each
other rather than being “service providers”
for each other?
Who put the PROC in Process?
Due to vast geographical separations, whiteboard scribbles and water-cooler discussions need to be
replaced by collaboration methods that are accessible globally.
Organizations have to include the whole team!
Examples:
o  Ensure you have this time allocated in
your project plans / tasks, and ensure
clear deliverables for these meetings.
o  Operations needs the ability to work
closely with Dev, QA & DBA teams to
understand the impact(s) of
infrastructure changes.
o  Having remote teams is a real challenge
for good collaboration. Organizations
have to work hard to ensure all
employees are part of the team.

Technology questions to ask include:
o  Collaboration tools. Are the Dev and Ops’
activities visible?
o  Status tools. Does the team have access to
a shared console or dashboard that allows
everyone to see the status of various
versions of the applications through
development, test and QA to production?
o  Empowerment/self-service tools. Do you
have the tooling that would enable team
members to carry out each other’s tasks?
Can we finally talk about Technology?
The tools should drive collaboration, not resistance!
Examples:
o  Agree as a project / release team
what methods / tools will be used
to collaborate
o  Make sure that your status tools are
used by every member of the
project / release team.
o  Managers: force your employees
to look for areas of automation,
including all aspects of a product.

Are your DevOps goals more than just getting everything automated?
If so, how are you measuring the additional goals? If not, why not?
How do you define “doing DevOps”?
What are the greatest challenges you’ve come across on that path?
Were they technical, people/process-oriented, lack of management buy-in, ..?
Now over to you!

Next Steps
o  Learn more: xebialabs.com/solutions
o  Article: No Quick Fix for DevOps
http://bit.ly/16htNZp
o  Whitepaper: Preparing for Continuous Delivery
bhttp://bit.ly/1dWjpYO
Products: www.xebialabs.com/products
Blog: http://blog.xebialabs.com
Twitter: @xebialabs
YouTube: http://youtube.com/xebialabs
STAY INFORMED
MORE RESOURCES

Losing Sight of DevOps in an Automation Forest - devopsdays Atlanta 2013

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Losing Sight of DevOps in an Automation Forest - devopsdays Atlanta 2013

Ähnlich wie Losing Sight of DevOps in an Automation Forest - devopsdays Atlanta 2013 (20)

Mehr von XebiaLabs

Mehr von XebiaLabs (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Losing Sight of DevOps in an Automation Forest - devopsdays Atlanta 2013

Hinweis der Redaktion