devops introduction
TRANSCRIPT
DevOpsAn Introduction
Robert SellIT Operations ManagerAeroInfo – Boeing Canada
@robertesell
https://ca.linkedin.com/in/robertsell
AgendaDefinitionComparisonPopularityHistoryDifferenceNext StepsThe SecretReferences
Definition
DevOps DefinedA software development method that emphasizes communication, collaboration, integration, automation and cooperation between developers and operations.
This method acknowledges the interdependence of groups and aims to rapidly produce software products through improved operational performance.
Goals of DevOpsThe goals of a DevOps approach span the entire delivery pipeline and include:
• Improved deployment frequency• Lower failure rate of new releases• Shorten lead time between fixes• Maximize predictability, efficiency, security
(rugged) and maintainability
Other DefinitionsMany DevOps leaders refer to DevOps as a “revolution or movement.”
“DevOps is a culture or professional movement.”- Adam Jacob, CTO at Chef
“DevOps is more like a philosophical movement.”- Gene Kim, Founder of TripWire, CTO, Author
CALMS ModelCulture Changing the way we think nd behave in the
organization. Becoming one. Grassroots. Cooperation.
Automation Configuration items. Infrastructure as Code.Lean A focus on value and customer. Reducing
time spent on non-value activities.
Metrics Measure everything all the time. Show improvement.
Sharing Open sharing. Collaboration. Transparency.
My DefinitionI like the definition in the DevOps Cookbook:
We refer to “DevOps” as the outcome of applying Lean principles to the IT value stream.
Understand the goal (customer), common and shared KPIs to support that goal, mapped work steams then improve.
Allows repeatability, consistency and continual improvement.
DefinitionWhat DevOps is NOT:
DevOps is not a product. You can not buy DevOps.
DevOps is not a title or department.
DevOps isn’t compliance. There is no DevOps certification.
DevOps doesn’t just mean you mix Dev and Ops
Side EffectsNow we know what it is, what its goals are and what it is not.
It’s side effects may include:• Higher employee engagement• Improved productivity• Competitive advantage (includes hiring)• Happier customers
Comparison
StagesTraditional Software Delivery Life Cycle (SDLC) treat all stages equally and often spends too much time on risk mitigating activities that don’t create value.
DevOps focuses on software creation and customer feedback while continually seeking to reduce investment in other stages.
Release MethodsTraditional release methods are huge, costly, disruptive, complicated, time consuming, stressful, manual, rare and often don’t work well.
DevOps release methods focus on small, cheap, easy, automated, instant, frequent and perfect.
TeamsTraditional skill based silos benefit from economies of scale but don’t transfer work. “Thrown over the fence.”
DevOps is a dedicated cross functional team focused on one service or application. No handoffs and misunderstandings. Responsibility and ownership for the larger picture.
SchedulingTraditional software development needs to schedule resources across multiple projects. Ops and Dev hardly communicate let alone schedule. Last minute “urgent” requests are the norm.
DevOps allows collaboration and local team scheduling. Small batches and automated process make this much easier.
ExperienceTraditional software releases are terrible experiences full of issues, escalation and fire fighting. War rooms, pizza and all night fiascos.
DevOps turns software releases into non-events. Code is through daily (or more) code integration, automated testing, built in security, and environment synchronization.
FailureTraditionally there is a huge focus on risk aversion. To fail is a bad thing and often results in blame. The fear of failure and blame cause delays and cost.
DevOps are okay with failure. In fact, “fail early” is one of the mandates. Instead of investing in failure elimination, they choose when and how they will fail. Small, early and fast failure allow fast recovery and future prevention. Ie Chaos Monkey
KPIsTraditional measurements have been on uptime, cost and capacity. Unfortunately, organizations often ignore the fact that salary is a top cost and employee time is often spent on non-value work.
DevOps looks at the element of time in the work flow as an additional metric. This forces us to examine the flow of work from start to finish. Decrease areas of waste, increase productive time and focus on value areas.
ResponsibilitiesTraditionally we were all responsible for completing our incoming tasks so we could hand off to the next team.
DevOps changes the “I did my task” concept to “it is ready to deploy” with the introduction of cross functional teams.
AutomationTraditionally there has been a focus on manual task specialization. Unfortunately this often results in errors, bottlenecks and poor documentation.
DevOps automates as much as possible. Time doing routinized behaviors is freed up for creative and innovative tasks. Instead of outdated documentation we do commenting. We never follow documentation to create an environment!
ComparisonDevOps Culture Matrix
Engaged Employees
Popularity
Google TrendsStarted in 2010 and took off from there.
61 points in Jan 2015 and 100 in Sept 2015.
Compared to…
Compared to Star Wars
Compared to iPhone
Compared to ITIL
Compared to The Daily Show
IoT not as Popular“Internet of Things” isn’t even as popular as DevOps.
90 in Jan 2015 and 100 in Sept 2015
Not Just UnicornsUnicorns
Non-Unicorns
http://www.slideshare.net/fullscreen/danapylayeva/xp2015-devops-and-continuous-value-delivery-with-chocolate-and-lego-half-day-workshop/20
Gene Kim
Forecast“DevOps will shift from being a niche approach to application development and deployment
and move into the mainstream over the next 12 months or so.” – Gartner
“So appealing will this grassroots philosophy prove that it will be taken up by a quarter of Global 2000 organizations”
– Computer Weekly
Why so Popular?
Gene Kim
StatsFor people who like stats:
• Traditional Ops are 41% more time-consuming overall• Traditional Ops spends 21% more time putting out fires• DevOps spends 33% more time on infrastructure improvements• DevOps spends 60% less time handling support cases
After DevOps is implemented:• 63% experience improvement in quality of software deployments• 63% release new software more frequently• 55% notice improved cooperation and collaboration• 38% report a higher quality of code productionhttps://www.scriptrock.com/blog/devops-success-stats
History
OpsIT Operations grew up with BOFH (and enjoyed it)Our KPIs are for stability/uptime. Any change is a risk.Our role is to protect developers from themselves.Viewed by Dev as the Evil Empire
DevDevelopers are creative, happy and care free.If an environment breaks they simply put in a ticket. Can’t understand why Ops makes such a big deal.
Ops vs DevPoor release management, out of sync environments, different KPIs and cumbersome processes have caused many years of conflict.
Structure
TraditionalLet’s start with traditional Operations & Development
Chief Information Officer
PMO/BAs Dev DBAs Test InfoSec Release Infra Support
Head of Development Head of Operations
Silos
Empires
Communications
GrassrootsDevOps begins with anyone. Grassroots.
Chief Information Officer
Head of Development Head of Operations
PMO/BAs Dev DBAs Test InfoSec Release Infra SupportWant to
cooperate?
Oh ya!Coffee?
Product FocusSometimes Product Leads are created. Challenging.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support
Embedded OpsOps embedded into Dev teams for DevOps.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support
Operations doing DevOps
Want some DevOps?
Dedicated DevOpsSometimes dedicated DevOps team are created.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support
DevOps
Total DevOpsOne possible DevOps organizational structure:
Chief Information Officer
Management
Product A Product B Product C Product D Product E Product F Product G Product HI’m focused on Product
I’m practicing “Servant
Management”
I’m building leadership for
scalability
Next Steps
Cross FunctionalCreate cross functional teams with representatives from each of the functional areas of the software delivery process.
Map out the flow of work and look for efficiency opportunities. Reduce time for each step (especially non-value steps).
Share the responsibility for building, deploying and maintaining product. Mix Build and Run teams.
CommunicationsDevelop effective communications that promotes collaboration.
Remove blame from Post Mortems and Project Reviews. Fail fast and expect it.
Stop using email in attempt at collaboration.
Treat failure as opportunities. Failure creators own, publish and teach solutions. Continual improvement.
Share RiskCollaboration allows error checking and guidance. Same idea as ITIL CAB.
Quality, availability, reliability, scalability and security is everyone’s responsibility. Traditional InfoSec does not work because it is after the fact and left to IT to enforce. Must be baked in.
Devs responsible for Prod. No “throw over the wall.”
Align GoalsSilos/Empires only exist when leaders are allowed to have different goals.
Share goals and roll up.
Cross functional teams ensure shared goals.
Include Ops in planning throughout the software dev lifecycle.
InnovationWe must demand innovation otherwise it doesn’t occur. Continual improvement now applies to the individual. Training must now occur on a daily basis.
Time must be allocated to on the job training and idea exploration. KPIs to measure it.
Internal hack days, lunch & learns, mini conferences, awards for innovation, collaboration events, etc.
The Secret
The RevolutionI am bias. I see DevOps as a revolution.
Traditional organizations are very inefficient with layers of bureaucracy, silos, empires, red tape, politics and other non-value time wasters.
DevOps forces us to not only fix Dev vs Ops but also fixes the PMO, Quality, Security and others.
EngagementDevOps is employee engagement and is therefore scalable. Autonomous streams.
DevOps corrects the culture. Share. Trust. Learn. Own.
DevOps will revolutionize Operations (not just Dev). Infrastructure as Code is our next evolutionary step. Combined with monitoring and automation, it is scary cool.
Chang(ed)The world has changed. Traditional disciplines are dead, some people just don’t know that yet.
References
SourcesYouTube (full of good videos)Start here:• Docker and DevOps by Gene Kim• DevOps Demystified by Ben Rockwood
SlideSharehttp://www.slideshare.netLoads of good presentations
TrainingIn the name of the DevOps spirit, IT is sharing all our training:
S:\AeroInfo\Training Training materials include: GIT, Docker, etc.
Join my local DevOps MeetUp: http://www.meetup.com/DevOps-Vancouver-BC-Canada
TwitterJohn Allspaw -@allspaw
Jesse Robbins - @jesserobbines
Gene Kim - @realgenekim
Patrick DuBuis - @patrickdubois
Andrew Schafer - @littleidea
Jez Humble - @jezhumble
John Willis - @botchagalupe
Damon Edwards - @damonedwards
BooksThe Phoenix Project: This book by Gene Kim is used by everyone as the modern version of The Goal and is a good starting point for understanding DevOps and the problems it solves. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
BooksContinuous Delivery: This book by Jez Humble is used by Boeing and is the default starting point for understanding Continuous Delivery. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
BooksThe Goal:This book is used to better understand Operations Management and kaizen. It is normally part of an MBA program. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
ReferencesReinventing Organizations: The way we manage organizations seems increasingly out of date. This book was created after 3 years of research and is a key book in DevOps when looking at organizational change.