DevOps tools in a nutshell(devup.co)
devup.co
DevOps tools in a nutshell
https://devup.co/a-look-at-devops-tools-landscape-7220099c6b81#.wqbzixgow
11 comments
Of the monitoring solutions, which is the "easiest" to deploy and optionally simplest? My impression of Nagios is that it's a pain in the behind.
They also neglected to mention metrics, which I think is the twin sibling to logging. Metrics tell you what is happening, logs tell you what happened. Monitoring can be built off metrics as well, or by an external source pinging in (or both, realistically).
I've never read soo many "DevOps" buzzwords on one place.
I'm quite disappointed by the "Continuous Delivery" section.
I expected tools that let you model a Continuous Delivery pipeline, like http://concourse.ci/, https://go.cd/, or Jenkins with the Pipelines plugin (directly included in Jenkins 2.0+, iirc).
Tools like Maven and Ant would be only a step in such a pipeline.
I guess this reinforces the OPs point that the whole devops nomenclature is very fractured, and folks use terms from this field as they please.
I expected tools that let you model a Continuous Delivery pipeline, like http://concourse.ci/, https://go.cd/, or Jenkins with the Pipelines plugin (directly included in Jenkins 2.0+, iirc).
Tools like Maven and Ant would be only a step in such a pipeline.
I guess this reinforces the OPs point that the whole devops nomenclature is very fractured, and folks use terms from this field as they please.
I completely agree. That section was a gross misunderstanding of what Continuous Delivery actually is. It should have actually been called "Packaging". The "Continuous Delivery" section was more about versioned packaging (and vendoring dependencies into packages), while the automation section was about configuration management of servers (which included deploying versioned packages).
If someone wants to understand what Continuous Delivery actually is (which is pretty well understood), there's a great book on the topic called... oddly enough... "Continuous Delivery" by Jez Humble. It covers CD pipelines like you mentioned, while also covering a bunch of the other listed topics at a high level in a much better way. Granted it's an actual book, but it's worth it's place on an DevOps/Release/Software Engineer's desk when implemented appropriately.
If someone wants to understand what Continuous Delivery actually is (which is pretty well understood), there's a great book on the topic called... oddly enough... "Continuous Delivery" by Jez Humble. It covers CD pipelines like you mentioned, while also covering a bunch of the other listed topics at a high level in a much better way. Granted it's an actual book, but it's worth it's place on an DevOps/Release/Software Engineer's desk when implemented appropriately.
It's an excellent book that I highly recommend. A lot to get through but it never gets difficult to read, and they (David Farley co-authored) include many anecdotes of when things have gone both right and wrong to demonstrate the points they make.
[deleted]
[deleted]
> There is no single definition, rather people use the term ‘DevOps’ as it suits them. And I don’t see harm in doing that as long as the basic concept is clear.
That's the thing, though - the basic concept very obviously isn't clear.
I've seen it go from "developers automating what operators do" to "developers and operators working together" to "operators using automation" to "operators doing things manually" to, in this article, "developers or operators doing things however".
There isn't really much point in using a term with such loose and varying meaning.
That's the thing, though - the basic concept very obviously isn't clear.
I've seen it go from "developers automating what operators do" to "developers and operators working together" to "operators using automation" to "operators doing things manually" to, in this article, "developers or operators doing things however".
There isn't really much point in using a term with such loose and varying meaning.
How about "developers taking responsibility of their own code in live environment"?
This highly depends on the nature of your organization and how many developers you're dealing with. I've seen it quickly break down once you reach more than 3 products and more than 15 devs.
Otherwise, at some point, you need a group of people (devs or otherwise) to sit down, define how these things are done for everyone, get group buy-in, then build the thing that puts their things in live environment.
Otherwise, at some point, you need a group of people (devs or otherwise) to sit down, define how these things are done for everyone, get group buy-in, then build the thing that puts their things in live environment.
I forgot that one! I guess that was an alternative branch from "developers automating what operators do", which implies a degree of that. Only instead of automating, they just do what the operators do now.
I've even seen it used to describe the support team who really just fix the bugs and get the changes into prod by some means... Not my Definition but something I've seen.
This might be better titled as a random list of tools that you may know about or be curious about.
Sure there is some overlap with the already loosely defined 'devops' but this doesn't really make any headway on defining it.
Where is bash, awk and sed in this list?
Sure there is some overlap with the already loosely defined 'devops' but this doesn't really make any headway on defining it.
Where is bash, awk and sed in this list?
So Nagios is a log management tool but Graylog is missing.
Wow, this author is clueless. This is a mishmash list of tools with several misunderstandings about what they do.
http://www.devopsbookmarks.com/
irc channel on freenode has this information compiled
irc channel on freenode has this information compiled
Quoting from http://devup.io/about/
Talking about DevOps, I would have expected a mention of Phabricator [2].
[0] https://prometheus.io/
[1] http://grafana.org/
[2] https://github.com/phacility/phabricator
DevUp is a platform where you can connect different tools from your
workspace and get all the information on a single dashboard.
Talking about DevOps, I would have expected a mention of Phabricator [2].
[0] https://prometheus.io/
[1] http://grafana.org/
[2] https://github.com/phacility/phabricator
https://github.com/phacility/phabricator
wow. Why is this not more famous?
wow. Why is this not more famous?
Quoting from https://en.wikipedia.org/wiki/Phabricator
[1] http://techcrunch.com/2011/08/07/oh-what-noble-scribe-hath-p...
[2] http://readwrite.com/2011/09/28/a-look-at-phabricator-facebo...
[3] https://www.phacility.com/
Phabricator was originally developed as an internal tool at
Facebook. [0][1][2]
- Stripe
- Pinterest
- Khan Academy
- Asana
- Wikimedia Foundation
- KDE
- Dropbox
- Uber
- Bloomberg
- Deviant Art
- Haskell.org
- Babel JS
- Facebook
- Instagram
- MemSQL
- Disqus
- FreeBSD
- Blender
[1] http://techcrunch.com/2011/08/07/oh-what-noble-scribe-hath-p...
[2] http://readwrite.com/2011/09/28/a-look-at-phabricator-facebo...
[3] https://www.phacility.com/
It's quite big in the free software world. Trac used to be the dominant system, but many are looking for even more integrated solutions and some of the biggest (Wikipedia, KDE) migrated to Phrabricator. It's mostly excellent, but know that it's all PHP and it's got a naming convention going that might be considered strange which you can turn off with the config setting serious-business (and that may be the only funny thing about it).
Maybe because in 2016 they should have a live demo that doesn't require an account. With all the virtualization tools around, it's so easy to set up and there's no excuse not to have it. When I see a project/software management tool that doesn't offer a public demo, it looks to me like they don't really want to sell a product.
Oddly enough, the author mentions Nagios under the Logging heading. Nagios does offer a log server product, but it's not commonly used and when someone says Nagios, they almost always mean the monitoring solution.