DevOps has many different meanings depending on the perspective and experience of anyone you might ask. The tech industry generally aligns on DevOps being a set of practices and culture that an organization adheres to in order to deliver operational excellence. DevOps should not be a team, a set of tools, or something you can bring in a consultant to apply to your organization. Excellent leaders in the DevOps space realize that self-reflection and attempts to correct any issues are the most effective ways to improve.
Thanks to the crew at Lean Agile KC for putting together an exceptional LAKC17 this year. I really enjoyed the interaction with everyone curious about operations practices at VML. It was a pleasure sharing how we fixed our DevOps Culture Anti-patterns by learning on our internal portal. And taking a bit of time to go over some additional learning and practices in an Open Sessions was awesome. Thanks to everyone who continued the discussion. See below for the SlideShare and my notes with some of the things I spoke about not directly in the slides.
I have recently been talking about how various books have helped my career in some unique ways, from helping bring some day to day peace, to changing the way I think about working with other teams. One of the most intriguing books I have ever read that impacted not just myself, but my organization is Lean Enterprise: How High Performance Organizations Innovate at Scale (Lean (O’Reilly)). You can re-read my other posts about the influential books below:
This week I have talked about a couple of books that have impacted my work and career. Please go back and read the following posts about two that have shaped me into the engineer and manager that I am today:
The book that really gave a gut punch to my specific day to day capabilities was Site Reliability Engineering: How Google Runs Production Systems
This week I am going over a few resources that I have run across that have shaped, changed, or completely rocked my career in technology. Today I want to start with the book that started my current career arc in a way that led to some of the best outcomes like working a sane number of hours per week, dealing with fewer panicky late night issues, and having an overall increase in career and personal wellness. I know that is a lot to put on just one book, but it was so impacting in a way that made me realize that I should not just keep doing my job the same way “because that’s the way we’ve always done it”.
What a great group of attendees along with the organizers just knocking it out of the park at this year’s dev up Conference. I’ve got the slides embedded after the jump and below that have a few notes about things I discussed not on the slides. Please feel free to reach out to me on twitter if you have any questions or just want to talk about these topics further.
Thanks for all those who attended my breakout session “Apply Software Development Practice to Application Configuration”. And many thanks again to Amegala. The details and examples in this talk can be found on my original post here: https://tomcudd.com/software-development-practice-application-configuration/
If you have questions or want to continue the conversation, please follow me on Twitter.
A friend shared this link with me and asked if these are good steps to making a transition into a DevOps role form more traditional IT experiences.
I have some issues with these five things that are supposed to help transition someone to a “DevOps” job. Instead of focusing on trying to find a job that fits some key buzzwords, I suggest working towards some general career development goals.
Ops teams should always strive towards implementing the best application configuration strategy and infrastructure as code solution that will work best for each scenario. However, Puppet, Chef, Ansible, and other similar products may not be the right solution for every project and team. Depending on the DevOps maturity of the team, flexible delivery capabilities needed, feature plugin issues, or off-release work cycles, building a custom solution could be the steps needed get a team from manually editing configurations in production to a fully automated continuous integration pipeline. We want to avoid the scenario where “when you’ve got a hammer, every problem looks like a nail”.
Continue reading “Apply Software Development Practice to Application Configuration”