Embed Size (px)
DESCRIPTION
Abstract: Sometimes it seems like It's near impossible to get anything innovative, interesting done in a large company - it's as if BigCos are goaled to prevent just that. While you can't type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps! I'm amazed when I find a skunk-worked project that's blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it's even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You'd never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the "real story," being at Dell now after six years at RedMonk covering tech from the outside, I'll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company. Presented at DevOpsDays Austin: http://devopsdays.org/events/2012-austin/proposals/How%20a%20BigCo%20actually%20got%20some%20innovation%20done/
Citation preview
The Longer Story of Crowbar
How a BigCo actually got some innovation done
Michael Coté @cote
2 2
2 2
The Setup
• We, here, all know what DevOps is, so I won’t talk about that • Most of us would love to work on a product, some of us do • Getting stuff done in the small is well documented, but not in large
companies • Here, I go over lessons learned for getting a DevOps product out the
door and (bonus!) traction in a large company
• P.S.: these are my views after studying and interviewing the team and ecosystem. They’re not not official, sanctioned Dell views (never mind this template).
3 3
3 3
Conclusions • There are two types of people in the world… - those that understand
DevOps, and those who don’t • Always Be Coding, not educating - Be comfortable with people not
understanding, you can’t educate forever • Get Customers/Users ASAP - drives your own process, use to explain
yourself • Work the Iron Triangle - when you’re young being awesome is better than
being on-time • Find the right context - getting pulled to do something is easier than pulling
something along • Hiding Out – things are easier when no one knows they should care • Get by with just enough architecting & abstracting - you probably are
gonna need it, but you can finish it later • Don’t open source a box of junk - bring something to the party • Market the right stuff - top-down marketing & bottom-up marketing
4 4
Crowbar: how does it work?
(As if I could tell you!)
5 5
5 5
What Crowbar is D
ell C
row
bar
O
ps
Man
agem
ent
Core Components & Operating Systems
Cloud Infrastructure & Dell IP Extensions
Physical Resources
APIs, User Access, & Ecosystem Partners
• Includes all the components required to implement an
entire cloud infrastructure including components from
ecosystems partners
• Pluggable components deploy cloud infrastructure
• Allow for expansion by the community services and
customers
• Can integrate with existing products
• Delivers basic data center services and required cloud
infrastructure
• Provision bare-metal servers from box to cloud WITHOUT
user intervention, other than racking/cabling and some
minimal configuration questions
6 6
6 6
It’s got a UI!
7 7
7 7
History of Crowbar
Meat-cloud
• We have Bob do that
March, 2011
• Initial announcement
July, 2011
• OpenStack • Dreamhost Ceph • Open Sourced
August, 2011
• Hadoop (Cloudera)
• Cloud Foundry
Sep, 2001
• Barclamps fully modulerized
November, 2011
• Hadoop barclamp open sourced
Installing private cloud stacks was tedious – we want to do it 2-3 hours
8 8
Lessons Learned
(Once again, all the usual things apply.)
9 9
9 9
There are two types of people in the world…. Those that understand DevOps, and those who don’t
• Many people won’t understand what you’re talking about
• Come up with good metaphors – Soup vs. Sandwich (judgmental,
benefits driven) – “And then what?” - Talk about the 2-3
year strategy
• Speak through your customers
10 10
10 10
Always Be Coding – Not Educating Be comfortable with people not understanding, you can’t educate forever
Image from Chip Holden &co.: http://www.flickr.com/photos/mrchippy/443960682/
Professorial Shiny Object Syndrome: • “What is DevOps?”? • “What is Agile, Lean, etc?” • “What is Big Data?” • “What is cloud?”
11 11
11 11
Get Customers/Users ASAP Drives your own process, use to explain yourself
• “Find 10 customers, no matter what size, segment, geography.” – Once you have traction, you’ll be taken seriously – You can have your customers explain what your doing to yourself – You’ll get excellent direction about what you should be doing
• If you think this is obvious, you don’t work at a BigCo
12 12
12 12
Work the Iron Triangle When you’re young being awesome is better than being on-time
Features
Schedule Quality
• “If I wait a week, I’ll get another feature”
• The older the project, the more schedule matters
• DevOps is young, so schedule is lowest priority of the three
For the wonks
Image from Scott Ambler: http://www.ambysoft.com/essays/brokenTriangle.html#Figure1
13 13
13 13
Find the right context Getting pulled to do something is easier than pulling something along
• Getting pulled to do something is easier than pulling something along
• Opportunistically look for chances to solve problems with your solutions
• Avoid gratuitously selling & pleasing
Image from http://failblog.files.wordpress.com/2009/05/fail-owned-tricycle-fail1.jpg via John Willis
14 14
14 14
Hiding Out Things are easier when no one knows they should care
• Carve out from the organization • Don’t over-hype and promise
– Sets expectations that won’t match process
– Creates pull for you to education – cf. Professorial Shiny Object Syndrome
• Hiding out implies you’ll have something worth-while once you emerge
• Narrow your explanation of what you’re doing as needed, no matter what you’re actually doing
Image from http://www.flickr.com/photos/barretthall/121988215/
15 15
15 15
Get by with just enough architecting & abstracting You probably are gonna need it, but you can finish it later
“I really don’t know what I’ll need in the future” • Build a platform • Plan for the future • But don’t go crazy • You’ll argue this all the time • Creates strong dependency
on organizational knowledge
Image from http://www.flickr.com/photos/neajjean/1596292769/
16 16
16 16
Don’t open source a box of junk Bring something to the party
• Roll up your pre-opening cabal of partners
• If you’re servicing an open source ecosystem, being open yourself is probably easier
• Know how to (internal) market OSS momentum
• Partnerships are much easier – Mechanics of participation – Good enough is often good enough
Image from http://www.flickr.com/photos/cote/7014915367//
17 17
17 17
Market the right stuff Top-down marketing & bottom-up marketing
• “Why aren’t these guys telling me about Crowbar?”
• Marketing & PR from all angles • Practitioner-to-practitioner • BUT! You’d be surprised how
hungry PR people are for genuine stories
