Confessions of a Full Stack Devop(ansible.com)
ansible.com
Confessions of a Full Stack Devop
http://www.ansible.com/blog/confessions-of-a-full-stack-devop
3 comments
Tooling is still difficult. I've used Puppet, Chef and Ansible all in production environments and though I like Ansible the best I just think none of them are all that great yet. Chef had some major issues between versions (entire suites of cookbooks made obsolete) and certain operations weren't deterministic. Puppet's DSL is just awful in my opinion though they have probably the best feature set . Ansible is definitely much simpler than the other two and easier to use, but a lot of the gotchas are just frustrating, e.g. jinja2 templating issues, a lot of new features that have unintended side effects when used with certain other features, where you can use conditionals and where you can't use conditionals seem arbitrary, etc.
Most people do need simple. Just having 2 or 3 servers is enough to handle quite a bit traffic and you can always vertically scale up to a certain point.
Once I recover from burn out I'll likely look into an alternative to Chef.
Once I recover from burn out I'll likely look into an alternative to Chef.
Thanks for the proper permalink!
As a former DevOps engineer turned to development, DevOps has been much maligned. The idea is not to get everyone to wear all hats. DevOps makes deployment part of the development cycle rather than the broken practice of throwing code over the wall. Nothing hurts morale like resting soundly each time ops is fighting fires your code created.
DevOps done properly does not require an engineer to deploy her own code, but it does require a sense of ownership over what happens with your code in production. If that means helping someone understand your code changes enough to fix the monitoring tools or tune the database then your product will benefit.
Most importantly, deploying more often means automation gets better. As Martin Fowler keeps saying, "if something hurts, do it more often." (It must hurt him to say that.) http://martinfowler.com/bliki/FrequencyReducesDifficulty.htm...
As a former DevOps engineer turned to development, DevOps has been much maligned. The idea is not to get everyone to wear all hats. DevOps makes deployment part of the development cycle rather than the broken practice of throwing code over the wall. Nothing hurts morale like resting soundly each time ops is fighting fires your code created.
DevOps done properly does not require an engineer to deploy her own code, but it does require a sense of ownership over what happens with your code in production. If that means helping someone understand your code changes enough to fix the monitoring tools or tune the database then your product will benefit.
Most importantly, deploying more often means automation gets better. As Martin Fowler keeps saying, "if something hurts, do it more often." (It must hurt him to say that.) http://martinfowler.com/bliki/FrequencyReducesDifficulty.htm...
For too long Operations and Development have had an adversarial relationship that bordered on belligerent. At a lot of large organizations I've had a working relationship with development didn't really care how efficient their app worked or whether it crashed every half hour, just that it provided the functionality that it was supposed to. This became a nightmare for operations. The same goes the other way around. Operations didn't really care much about how the development environment is setup and don't care how difficult it is for developers to deploy and test their code.
DevOps, as widely debated what the actual meaning is, brings development and operations into a more symbiotic relationship. Whether that means that devs have a more operations minded outlook, or operations looks into how to make development more efficient, or automating operations or any of the other various definitions in the end it's about making sure the entire life cycle of an app is run more efficiently. From initial development and testing through scaling.
DevOps, as widely debated what the actual meaning is, brings development and operations into a more symbiotic relationship. Whether that means that devs have a more operations minded outlook, or operations looks into how to make development more efficient, or automating operations or any of the other various definitions in the end it's about making sure the entire life cycle of an app is run more efficiently. From initial development and testing through scaling.
It actually killed my motivation to program in general so it's not like I'm some ansible fanboy too. I don't use anything now because I haven't deployed a line of code in about 2 months.