Put up or shut up


Courtesy:  Jez Humble

DevOps is not…
* A certification
* A role
* A set of tools
* A prescriptive process

DevOps is…
* A philosophy that starts with passion
* A cultural, professional movement with attitude and values
* A reaction to poor communication
* About creating visibility between dev and ops
* About the symbiotic relationship between dev and ops
* Cross-functional teams over organizational silos
* Products, not projects
* Automation over documentation (and more automation… and more…)
* About creating self-service infrastructure for teams
* Knowing that good software doesn’t end with development / release
* Software that doesn’t require support
* Ensuring a continual feedback loop between development and operations
* Cross-functional teams over organizational silos
* Creating products that are owned by the delivery team
* Knowing that a project is only finished when it is retired from production
* Something you can do without doing agile

What we want to achieve

* Operations and development are skills, not roles. Delivery teams are composed of people with all the necessary skills.
* Delivery teams run software products – not projects – that run from inception to retirement



Courtesy:  dev2ops




Related negative posts:

DevOps is DOA

If you use iaas, saas, paas, this will only change the context. It will be another layer of abstraction. Great when it works, hard when it fails. The adagium that your SAAS provider will fix your stuff faster isn’t always true either. There is always a history and a context required to give good support, close constant collaboration can provide that better IMHO.

And because you rely on an external party, you will now have to monitor if it fails, check if you can switch to another paas provider, have a backup ready solution, need testing to avoid performance issues. So here come the operations/sysadmin tasks again, just in a different setting. You might say the developers can do it all themselves now, but in reality they are now taking on the sysadmin roles too.

Don’t get me wrong, I love *aas , but when the **** hits the fan, I’d favor someone I can really talk too, with options for my problem and not a generic problem. If you can get close to that level of collaboration with your SAAS provider, your saas has become another part of your devops team. (bridging collaboration). But my experiences are when things fails, communication often shuts down to a generic information level and isn’t focused on helping my specific issues. This can be done right, but if not, this will just be another silo you will have to bridge again.

DevOps is a Poorly Executed Scam

Since no methodology peddler ever wants to say this, I will: there’s a point where you’re simply fucked. Meaning, you can’t solve the problem with the tools available. Sometimes, you have to fire people who aren’t working out. Sometimes, you’re too deep in technical debt and too pressed for time to do it the “right way”. And sometimes, projects fail. It is what it is. This isn’t defeatist, it’s realist.

I am not trying to sell you a book, I am just being honest about the problems you face. None of this amounts to a methodology, as the Devops people would have you believe. If your developers and your sys admins are so culturally different that they can’t agree on a solution to a simple technical problem, then your organization will not be fixed by some sunshine-up-your-ass methodology you read about in a blog or hear about at a conference. You need to change the culture the hard way, or replace people as necessary until the culture works.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: