Woooo! Last day of a week of conferencing. DevOpsDays Day 1 was good and I have even more openspace topics I plan to propose next time. As usual this is being livestreamed and will be viewable later as well at bmc.com/devops.
Sponsor Watch… Got to talk to our friends at PagerDuty (alert management) and Datadog (monitoring/dashboarding), we use them and love them. And I got to see Stormpath again, they first showed up at last DevOpsDays with a SaaS hosted auth solution (not like PingIdentity and Okta, they actually store the usernames/passwords for you, Les Hazlewood the Apache Shiro guy started it) and they’re growing quickly. Also talked to SaltStack which does salt, a remote command execution framework. 10gen was here with a MongoDB SaaS backup solution (nice!) and monitoring solution.
Leading the Horses to Drink
By Damon Edwards (@damonedwards) from DTO and now #SimplifyOps.
How to spread DevOps in enterprises. There’s silos you know. The term DevOps may work against you – it’s evangelical and being overused/washed already.
There is no ‘why’ other than the why of the business. Read your Deming/Collins/Four Steps to the Epiphany/etc.
Go ask people… Something.
Develop a common DevOps vision. Not a process because they’ll get blinders on. [Ed: I believe this is a false dichotomy – you should teach both. Vision without process lacks focus and process without vision lacks direction. It’s like accuracy and precision.]
- See the system
- Focus on flow
- Recognize feedback loops
Do a value stream mapping – read Learning to See. OK, this is the meat of the preso – very hard to read though.
Take your information flow and turn it into an artifact flow
Do a timeline analysis, find waste
Metrics. Establish the metric chain of what matters to the business, driven down to a capability which influences what matters to the business, and driven down to an activity over which an infividual can cause/influence outcomes.
Doesn’t require saying “devops.”
- Teach concepts
- Analysis
- Metrics chains
- Do something
- Iterate
Only takes like 3 days to bootcamp it. Then put in continuous improvement loops.
You can only break silos by brute-force being the boss, but misalignment will reassert itself. Have to change the alignment.
Q&A: Do it with everyone in the same room with whiteboards/postits, it works better than getting fancy
Beyond the Pretty Charts
Toufic Boubez from Metafor. Cofounded Layer 7 and escaped when CA acquired them.
Came from a popular DOD Austin Openspace – see the blog post!
- We’ve moved beyond static thresholds – or, at least, everyone thinks they suck. Need more dynamic analytics.
- Context is important – planned and known (or should be known) events cause deviation. Correlate events with metric gathering.
- Don’t just look at timelines. Check the thinking round Etsy’s Kale and Skyline, many eval methods assume normal metric distribution and that’s uncommon. Look at a histogram of any given data – like latency is usually gamma not gaussian.
- Is all data important to collect? There’s argument over that. Get it all and analyze vs figure out what’s important to not waste time.
- We all want to automate. Need detection before it’s critical. Can’t always have a human in the loop. Whipping out the control theory – open loop control systems, closed loop – to get self healing systems we need current state/desired state diffing from our monitoring systems and taking action. [Ed. We experimented with this back at NI, we had Sitescope going to a homegrown system called “monolith” that would take actions. Hard to account for all factors though and eventually was discontinued.] Also supervised vs unsupervised loops [Ed: – we might have kept monolith around if it SMSed us and said “memory is high on this server I believe I should restart the java process, is that OK” and we could PagerDuty-like say yea or nay.]
How much data do you need? No more res that twice your highest frequency (Nyquist-Shanon). Most algorithms will smooth/average/etc.
Q&A: Are control systems more appropriate for small not large systems? No – just like in industry, as long as you design for that then it’s not just for toys.
And now I step in for the vendor pitch for Riverbed. Agile Admin Peco left yesterday and the other Riverbed booth guys made themselves scarce, so I did their shout-out for them. They have Zeus EC2 LBs, Aptimize web front end optimizer, and Opnet Appinternals Xpert APM tool! Very cool.
Identifying Waste in your Build Pipeline
Scott Turnquest from Thoughtworks
Tools: Value stream mappings, fishbone analysis, “5 Whys”
So how do we do that value stream mapping? Here we go! [Ed: Oh, this is nice, I was sad that in the DTO presentation they mentioned them and threw some up but didn’t really dive down into one.]
A day of analysis of one small feature – a day of wait, 4 days of dev, 2 mins of wait, 1 hour of acceptance tests, 4 hours of deploy, 1 day in staging, 4 hours to deploy to prod. Note the waste areas – “4 days in dev? Really?” and the long ass deploy windows [Ed: Our value stream looks depressingly like this.] Process cycle efficiency of 75% (value creation time/total time)
So to determine the source of those waste areas, use the fishbone diagram. Had long feedback cycles from structure of code and build/deploy pipelines. Couldn’t test w/o AWS and can’t test individual components, provisioning was serial and repos were flaky.
Fix underlying cause (most impact first) – deploy pipelines. Reduce failure rate of deployments. Half were failing, and failing slow. Moved to AMI baking for reliability. [Ed: They said I was crazy a couple years ago when I said this, “no it’s a foil ball…” Bake when you can!] So this got them from 4 hours to 2 hours, and then parallelized and got down to 25 minutes. This cut down the staging and prod deploys but also the dev time. Process cycle efficiency up to 83%.
5 Whys root cause analysis method. Figured out manual hard to automate deployments were at the root, automated them – don’t be afraid to restructure/redesign when complexity gets in the ways.
Analysis techniques are not just for analysts!
Read Jez Humble’s “Continuous Delivery”, Poppendieck’s “Lean Soft Dev”/”Implementing Lean Soft Dev” , Derby/Larsen “Agile Retrospectives”
Clusters, developers, and the complexity in Infrastructure Automation
Antoni Batchelli of PalletOps. Complexity, essential and accidental. Building a system is simple but the systems are complex at runtime, and “complexity of a system is the degree of difficulty in predicting the properties of the system given the properties of the system’s parts.”
In DevOps we see infrastructure-aware software and concepts moving up into dev processes.
Devs want to run “their own” cluster with all the setups they need – productionlike, but with specific versions/timings/data/code/etc. Don’t care about infra details but want consistent envs/code.
Software has to be infrastructure aware now to autoscale, self-heal, etc. The app is the best informed actor to make/orchestrate infra decisions.
[Ed: This late into a conference week, I get a little irritated about presentations that are not really clear *why* they are telling you what they’re telling you.]
He hates incidental complexity. Me too.
OK, maybe we’re getting to a thesis. Let people solve problems where they are less complex: at the right level of abstraction. Build layers of abstraction – infrastructure, OS, services, actions. Make them into modules, make them functional and polymorphic.
Ignites!
James Wickett (@wickett) on Rugged DevOps and gauntlt for security + DevOps. gauntlt is a gem for continuous security testing as part of your build cycle. BDD your app’s security! Knock Out!!! go to gauntlt.org to get started.
Karthik Gaekwad (@iteration1) on DevOps Culture in the CIA. Devops is culture/automation/measurement/sharing. Seen Zero Dark Thirty? Well, the true story behind that details the COA’s transformation from a split between analysts and operatives especially using Sisterhood, a group of female analysis tracking Bin Laden since 1980. Post 9/11 there was a mass reorg to become more tactical – analysts became Targeters and worked with Operatives hand in hand. Same kind of silo busting. The Phoenix Project is Zero Dark Thirty for DevOps!
Dave Mangot (@davemengot) for DevOps Do’s and Don’ts from Salesforce. Do give everyone the tools they need to do their jobs. Don’t make ops the constraint, Do lots of communicating. Don’t forget to include everyone. Do get ops involved early. Don’t create a front door (loaded) process. Do have integration environments, Don’t forget config management. Do have blameless post-mortems. Don’t use the Phoenix Project as a bludgeon. Do use Agile as a cultural tool. Don’t rely on tools to change culture. Do get executive sponsorship. Don’t do shadow IT. Do use Damon Edward’s levers. Don’t just lecture, it’s a participation sport. Do structure the org around delivery. Don’t make separate DevOps teams or jackets. Do get the whole company involved, DevOps is for everyone.
Jonathan Thorpe – Preventing DevOps success. Not planning for scale. Not having unit tests. Not designing automated tests to scale. Not managing your capacity. Not using your resources effectively. Not using same deployment process for all environments. Not knowing what/where/when/who (activity tracking). Getting covered in ants.
DevOps is the future – John Esser from ancestry.com. What keeps CIOs up at night? Besides ants? IT. Need time to value. Transform mindset/processes/tools/etc. Strangler pattern.
DevOps productivity survey by Oliver White from ZeroTurnaround. DevOps oriented teams spend more time on infrastructure improvements and less on firefighting and support. Problem recoveries are shorter. Release software faster. use more custom tools. Make love for longer time. @rebel_labs
Nathan Harvey on leveling up your skills. Quit! Go to a conference. Try new things. Do a project somewhere. Always be interviewing.
the agile admin 