Hacker News Reader

Comment by stephenr | Hacker News Reader

Isn't this whole approach based on the (imho wrong) idea that "DevOps" means developers [trying] to manage servers/infra?

IMO DevOps is about smarter Ops using "development" (i.e. automation, reproducible system config systems) rather than ad-hoc management of individual servers.

To me this reminds me a lot of some MongoDB fans - they have no real need for Mongo, they just don't want/know how to define a usable schema for a relational DB.

View on HN

Hi Stephen, Very interesting comment here. We do think that DevOps has different definitions, and in our opinion, none is really wrong, as all comes back to the same idea. Let me explain this. DevOps is all about reducing the gap between development and operations. This is done allowing "smarter ops" to use "development", but also helping developers to realise some operations. VisualOps is made for both sides. We hope that VisualOps could help developers who don't want to spend too much time on operations, but also, we created VisualOps to act like a programmable configuration manager (like Chef, Puppet ...).

I understand your point but personally a developer who wants more control over operations, but isn't able/willing to learn to write recipies/config packages/what-have-you and relies on a visual tool like this is going to raise alarm bells for me.

A developer relying on (current) visual tools isn't really a developer to me anyway. But I'm totally willing to give in here; the idea of visual programming has been around longer than me (search wikipedia for a start), and let's not forget that in digital circuitry visual tools are used (and are of use) a lot.

Indeed! Visual tools makes the approach more "human". Simplified tools don't mean dummy tools. It's actually the total opposite: a developer forced to do deal with Ops is less likely to do some mistakes using a simpler tool, than trying to deal that things that he doesn't (and doesn't want to) understand. I understand the other point of view, that we better start by learning the most complicated things (I've started to learn programming with C and ASM, although I'm a 90s guy), and the whole challenge we have with VisualOps is to make the learning and usage easier, without breaking the knowledge.

IMO the idea is about the capability of "automation, reproducible system config systems", not who should do what.

I agree with the first part but the last part (who should do what) is still relevant.

The majority of developers I have met and worked with have a cursory knowledge of infrastructure/server management at best. That is not a criticism against them at all. But I still wouldn't trust most of them to configure infrastructure outside a local/dev/"sandbox" environment.

You wouldn't rely on a HTML template file that your graphic designer created with Photoshop -> Export to Dreamweaver would you?

No. But that's a problem to be solved with how we leverage the tool, not the tool itself.

Right, but as I said in the other thread - if someone wants to work in Ops/Ops-ish, but can't learn a recipe/packaging system, I doubt a GUI tool is going to improve the results.

Hi Stephen. We understand your opinion, as I replied to someone else before, there are different ways to take the problem, and one of our biggest challenge is to make the learning easier without breaking the knowledge. I would just add that VisualOps isn't just a GUI tool. We have spent a lot of time to adapt SaltStack source code to something we think to be the right approach. Also, more features are on the way, and we count on your support to bring them to life! Check out our public roadmap board for more details (you're welcome to vote for your favorite ones): https://trello.com/b/wQdmsmp0/madeira-idea

Reply on news.ycombinator.com