IMO, DevOps should not be afraid of reinventing their own wheels. The closer you are to the service layer you don't actually manage, the better. i.e. if you use

IMO, DevOps should not be afraid of reinventing their own wheels. The closer you are to the service layer you don't actually manage, the better. i.e. if you use public cloud you should really make use of the APIs and build your own wheels. But of course, use existing tools to do your job first, and slowly create your new wheels. Overtime, the new wheels will function better because they can fit your ever-changing requirements. That's my two cents. Sometimes as I am working with boto (Python SDK for AWS), I wish I have the time to write some of the boto modules myself, because they were inconsistent and harder to use than other modules. I can easily create many AWS services with Ansible modules, but I find it easier to hack and integrate more tightly with my environment by writing my own Python code using boto directly. What's inside the machine remains to be Ansible because it does a really good job. Another classic example is logstash and AWS logs like cloudtrail, flow log and alarams. I can easily write a parser in Python or in C and get my job done, and overtime the code can be reusable. But with logstash I can't guarantee that existing filters and plugins will always work and they get really really messy no matter how good you are with logstash. And that's a layer I have to reinvent because of simplicity and total control. I'd rather pipe to Elasticsearch myself than relying on logstash in cases like that.