| Speakers | |
|---|---|
| Mitchell Hashimoto | |
| Schedule | |
| Day | Sunday |
| Room | K.3.601 |
| Capacity | 85 |
| Start time | 14:00 |
| End time | 14:45 |
| Duration | 00:45 |
| Info | |
| Track | Configuration and Systems Management Devroom |
DevOps is not an absolute. It's a range.
In this talk, I'll use my unique experience from both the standpoint of a system administrator in a small company as well as a reasonably successful DevOps tool writer to explain how modern tools can be used gradually to transition a business to welcome more DevOps practices without sacrificing stability or productivity and in fact increasing both!
Many still consider and talk about DevOps as an absolute thing: developers and operations are the same thing. Of course, this is not the case. DevOps is a range, where on the far left we have old-style ops (very exclusive) and on the far right we have developers doing all the ops (very inclusive).
The idea of DevOps itself is only possible due to wide variety of tools which have become available: Chef, Puppet, MCollective, Vagrant, Cucumber-Chef etc. Prior to these tools, developers simply couldn't be expected or trusted to hook up a terminal to a production machine and run scripts. But with these tools in hand, the ops team can now setup an environment where we slowly push the bar from extreme exclusivity towards more inclusivity.
In this talk, I'll use my unique experience from both the standpoint of a system administrator in a small company as well as a reasonably successful DevOps tool writer to explain how modern tools can be used gradually to transition a business to welcome more DevOps practices without sacrificing stability or productivity and in fact increasing both!
Specifically I'll talk about:
How metrics and monitoring can make the Ops world more transparent, starting the process of bringing in developers. How development environments provisioned with production scripts and the ability to test new scripts can allow developers to experiment with Ops. How building a test infrastructure for testing automation scripts can maintain stability in your organization while allowing people unfamiliar with the ops world to get involved. The importance of dedicating "office hours" as an ops engineer to teaching developers. "Who wears the pager?" or transitioning pager duty to other engineers safely by leveraging the above tools. This talk is based on my experience as:
Engineer on Vagrant which powers many large companies and has helped many companies move towards a more DevOps-friendly attitide. I've seen first-hand how tools can assist this transition. System administrator and software engineer at Kiip, a small company with around 20 employees. I'm the only engineer with any Ops experience, and I've had to very slowly transition our company towards being more Ops friendly.