I spent Tuesday and Wednesday at DevOpsDaysAustin and continue to be impressed with the enthusiasm and collaborative nature of the DOD events. We also managed to have a very robust and engaged twitter backchannel thanks to an impressive pace set by Gene Kim!
DevOpsDays spends a lot of time talking about culture. I’m a huge believer on the importance of culture as the foundation for the type of fundamental changes that we’re making in the IT industry; however, it’s also a sign that we’re still in the minority if we have to talk about culture evangelism.
Process and DevOps are tightly coupled. It’s very clear that Lean/Agile/Kanban are essential for DevOps success (nice job by Dominica DeGrandis). No one even suggested DevOps+Waterfall as a joke (but Patrick Debois had a picture of a xeroxed butt in his preso which is pretty close).
Still need more Devs people to show up! My feeling is that we’ve got a lot of operators who are engaging with developers and fewer developers who are engaging with operators (the “opsdev” people).
Chef Omnibus installer is very compelling. This approach addresses issues with packaging that were created because we did not have configuration management. Now that we have good tooling we separate the concerns between bits, configuration, services and dependencies. This is one thing to watch and something I expect to see in Crowbar.
The old mantra still holds: If something is hard, do it more often.
Not DevOps, but 3D printing is awesome. This is clearly a game changing technology; however, it takes some effort to get right. Dell brought a Solidoodle 3D printer to the event to try and print OpenStack & Crowbar logos (watch for this in the future).
I’d be interested in hearing what other people found interesting! Please comment here and let me know.
Over breakfast with fellow Dell cloud thinker and general deep thinker Michael Cote, he suggested that we two options for something. I was quick to add a third and Cote objected because “having three options is a marketing thing to make you happier with the choices.” He’s right but didn’t have the sources to backup the comment. Since I was looking them up for Cote, I figured they’d be worth posting too:
Personally, I believe that there are always FIVE options. People generally over look the extreme choices like “do nothing” or “all in.” For example, when discussing a product architecture the two options that IMHO should always be on the table include “scrap the project” and “live with the problem.”
We never take the extra options, but they help clarify the three moderate choices. Of course, this makes more sense after you read the above books. So read the books (there are 3), don’t read the books, or setup personal interviews with the authors to get the real story. The choice is yours!
I was part of the Dell contingent at the OpenStack design conference earlier in the month. The conference opened a new chapter for the project because the number of contributing companies reached critical mass. That means that the core committers are no longer employed by just one or two entities; instead, there are more moneyed interests rubbing elbows and figuring out how to collaborate.
From my perspective (from interview with @Cote ), this changed the tone of the conference from more future looking to pragmatic.
That does not mean that everything is sunshine and rainbows for OpenStack clouds, there are real issues to be resolved. IMHO, the top issues for OpenStack are:
Ensuring that we can deploy consistently in multi-node systems
Getting contributions from new members
Figuring out which projects are code, satellite, missing or junk.
Of these issues, I’ve been reconsidering my position favoring API via Implementation over specification (past position). This has been a subject of debate on my team at Dell and I like Greg Althaus’ succinct articulation of the problem with implementation driven API: “it is not fair.” This also ends up being a branding issues for OpenStack because governance needs to figure out which is a “real” OpenStack cloud deployment that can use the brand. Does it have to be 100% of the source? What about extensions? What if it uses the API with an alternate implementation?
Of the other issues, most are related to maturity. I think #2 needs pressure by and commitment from the larger players (Dell very much included). Crowbar and the deployment blueprint is our answer #3. Shouting the “don’t fork it up” chorus from the roof tops addresses contributions while #5 will require some strong governance and inevitably create some hurt feelings.
I’m working on a larger post about the OpenStack Summit around API Implementation vs. Specification. You can have a preview of that AND A LOT OF OTHER STUFF (OpenStack, Crowbar, lunch) in this 40 minute interview w/ Michael Cote.