4 ms·

I don't agree with everything you've said, but I do feel like otto is in danger of being another teetering piece on top of the base-os/virtualbox-os/vagrant(+an

I don't agree with everything you've said, but I do feel like otto is in danger of being another teetering piece on top of the base-os/virtualbox-os/vagrant(+ansible/chef/puppet)/guest-application tower, which are all leaky abstractions and all cause problems in practice and make debugging complicated. "Accidental complexity" is the right phrase. I can't help but think that what the DevOps world really needs isn't another thin layer of magic trying to shellac over the issues of everything below it, but rather to have a hard think and rebuild everything from the ground up with more appropriate primitives. Sort of like what NixOS is trying to do (haven't used it, so can't attest to how successful it has been).

corndoge 11y ago
Replace DevOps with "web technologies" in general and your statement rings even more true.
- PaulHoule 11y ago
  I think the difference is that in the case of web technologies there are a huge number of competing products: we've had everything from CGI to ColdFusion to PHP to Ruby on Rails to Node.js and we are always learning from what people got right and wrong in the past.
- stephenr 11y ago
  By "web technologies" do you mean all the abstractions away from pages using HTML, CSS and JavaScript if requried?
yeukhon 11y ago
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.
- collyw 11y ago
  I played with logstash for a day or two, and it looked quite neat, but again, nothing that couldn't be accomplished in a small Perl script.
  - yeukhon 11y ago
    It is nice to the point you have really sit down sweat through the filters and plugins. The documentation is really horrible. A lot of Internet digging and GitHub source code digging...

corndoge 11y ago

Replace DevOps with "web technologies" in general and your statement rings even more true.

PaulHoule 11y ago
I think the difference is that in the case of web technologies there are a huge number of competing products: we've had everything from CGI to ColdFusion to PHP to Ruby on Rails to Node.js and we are always learning from what people got right and wrong in the past.
stephenr 11y ago
By "web technologies" do you mean all the abstractions away from pages using HTML, CSS and JavaScript if requried?

yeukhon 11y ago

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.

collyw 11y ago
I played with logstash for a day or two, and it looked quite neat, but again, nothing that couldn't be accomplished in a small Perl script.
- yeukhon 11y ago
  It is nice to the point you have really sit down sweat through the filters and plugins. The documentation is really horrible. A lot of Internet digging and GitHub source code digging...