This document discusses why Ruby is a good programming language for operations staff. It notes that operations involves tasks like building servers, packaging, monitoring, and provisioning that can be programmed. While shell scripts and Perl are commonly used today, Ruby has advantages like allowing multiple versions of the same library, being beginner friendly due to tutorials and syntax, and its use of blocks for iteration, cleanup and separating concerns. Ruby also has good tooling for devops tasks like configuration management, logging and packaging that operations staff can benefit from due to the ability to write plugins for these tools.

1. Ruby
The Language of Devops

2. Who am I?
● Rob Kinyon
o @rkinyon
o rob.kinyon@gmail.com
● Devops lead for many years

3. What is Devops?
● The Cloud?
● Jenkins Automation?
● Continuous integration & deployment?
● A new title?
o with no extra pay . . .
● Developers doing Operations??
o And fire all the sysadmins? (NO-OPS!)
● Automating away your coworkers??!

4. The
Programming
of
Operations

5. The Programming of Operations
● Operations is:
o Build servers
o Packaging
o Monitoring
o Provisioning
o Virtualization
o Environment/Stack Management
o Many many many more things

6. The Programming of Operations

7. The Programming of Operations
● Lots of helpers
o Build this
o Package that
o Move things from here to there

8. The Programming of Operations
● Lots of helpers
o Build this
o Package that
o Move things from here to there
● Templating
o Homegrown templates for Nagios

9. The Programming of Operations
● Lots of helpers
o Build this
o Package that
o Move things from here to there
● Templating
o Homegrown templates for Nagios
● Lots of manual activities

10. The Programming of Operations
Manual
===
Broken

11. TARGET=${1:-"monitor-prod"}
for rule in /nagios/rules/*.tmpl; do
process_template.pl $rule $TARGET
mv ${rule##tmpl#cfg} /nagios/final
done
scp /nagios/final/*.cfg $TARGET.company.com:/var/nagios/
ssh $TARGET.company.com -c "sudo service nagios3 restart”
The Programming of Operations

12. The Programming of Operations
● As a single script, it's okay.
o Concise, clear - what else do you need?

13. The Programming of Operations
● As a single script, it's okay.
o Concise, clear - what else do you need?
● Problems:
o No tests (untestable!)
o No reusability or extensibility
o Inscrutable code

14. The Programming of Operations
● As a single script, it's okay.
o Concise, clear - what else do you need?
● Problems:
o No tests (untestable!)
o No reusability or extensibility
o Inscrutable code
● Bugs:
o Assumes the contents of $PWD and $PATH
o Assumes a human will know if it worked

15. The Programming of Operations
● Operations staff are not developers

16. The Programming of Operations
● Operations staff are not developers
● Operational focus is about maintenance
o Keep it on
o Keep it up
o Keep it responding

17. The Programming of Operations

18. The Programming of Operations
● Operations staff are not developers
● Operational focus is about maintenance
o Keep it on
o Keep it up
o Keep it responding
● Operations has to manage changes by those
pesky developers
o Right now. While something is on fire. (Really!)

19. The Programming of Operations
What is the perfect language?
● Multi-system
● Quick to boot
● Easy to learn
● Easy to maintain
● Large community / Lots of modules
● Easy to find good staff

20. Languages we won't discuss
● C/C++
● .NET (C#, F#, etc)
● JVM languages
● Functional languages
o Especially Erlang
● Node.JS

21. Bash/Shell scripts (Good and Bad)
● Easy to write
● Everyone has written Bash scripts
● Horrible control structures
● Horrible variable structures
● Non-existent code structuring
● “Libraries” don’t exist
● Only really works on *nix
o Git-Bash doesn't count

22. Perl (the Good)
● What most sysadmins use other than Bash
● Great variable structures
● Great control structures
● Excellent reusability
o CPAN is the largest single-language repository
● Works everywhere (literally)
● Good programmers can manage 500kLOC

23. Perl (the Bad)
● Everyone thinks they know Perl
o Bad Perl is really really bad.

24. Perl (the Bad)
● Everyone thinks they know Perl
o Bad Perl is really really bad.
● Standard language facilities require
libraries
o Exceptions, objects, case statements

25. Perl (the Bad)
● Everyone thinks they know Perl
o Bad Perl is really really bad.
● Standard language facilities require
libraries
o Exceptions, objects, case statements
● CPAN is 80%+ useless

26. Perl (the Bad)
● Everyone thinks they know Perl
o Bad Perl is really really bad.
● Standard language facilities require
libraries
o Exceptions, objects, case statements
● CPAN is 80%+ useless
● Really old Perls are installed everywhere
o 5.005_003 (March, 1998)

27. Perl (the Ugly)
● Solving a problem with regular expressions
means you have two problems.

28. Perl (the Ugly)
● Solving a problem with regular expressions
means you have two problems.
● Sigils ($, @, %, etc) make code hard to read
o Ironically, the idea was to make code easier to
read

29. Perl (the Ugly)
● Solving a problem with regular expressions
means you have two problems.
● Sigils ($, @, %, etc) make code hard to read
o Ironically, the idea was to make code easier to
read
● Too many places where hidden globals
make you cry.
o E.g., namespaces aren't namespaced.

30. Python (Strengths)
● Great variable structures

31. Python (Strengths)
● Great variable structures
● Great control structures

32. Python (Strengths)
● Great variable structures
● Great control structures
● All the advanced features
o Exceptions
o Objects
o Case statements

33. Python (Strengths)
● Great variable structures
● Great control structures
● All the advanced features
o Exceptions
o Objects
o Case statements
● Runs everywhere that we care about

34. Python (Weaknesses)
● Significant whitespace is difficult for non-
developers.

35. Python (Weaknesses)
● Significant whitespace is difficult for non-
developers.
● System programming libraries aren't mature

36. Python (Weaknesses)
● Significant whitespace is difficult for non-
developers.
● System programming libraries aren't mature
● Writing libraries isn't self-evident
o Tutorials and scaffolding also immature

37. Ruby (Strengths)
● Great variable structures

38. Ruby (Strengths)
● Great variable structures
● Great control structures

39. Ruby (Strengths)
● Great variable structures
● Great control structures
● All the advanced features
o Exceptions
o Objects
o Case statements

40. Ruby (Strengths)
● Great variable structures
● Great control structures
● All the advanced features
o Exceptions
o Objects
o Case statements
● Runs everywhere that we care about

41. Ruby (Strengths)
● Great variable structures
● Great control structures
● All the advanced features
o Exceptions
o Objects
o Case statements
● Runs everywhere that we care about
● Already used as a sysadmin language

42. Ruby (Weaknesses)
● Minor versions changing syntax
o 1.8.7 vs. 1.9.3 vs 2.x

43. Ruby (Weaknesses)
● Minor versions changing syntax
o 1.8.7 vs. 1.9.3 vs 2.x
● Ruby is not Rails
o Really!

44. Ruby (Superpowers)
1. Install multiple versions of same library
2. Newbies are a way of life
3. Blocks

45. Multiple library versions
● Sysadmins are pessimistic
o Foo-bar 1.3.9 works, so don't change it!!

46. Multiple library versions
● Sysadmins are pessimistic
o Foo-bar 1.3.9 works, so don't change it!!
● Not everyone can use the same version
o Something needs a feature in Foo-bar 2.1.5

47. Multiple library versions
● Sysadmins are pessimistic
o Foo-bar 1.3.9 works, so don't change it!!
● Not everyone can use the same version
o Something needs a feature in Foo-bar 2.1.5
● So install both and specify at runtime
gem 'Foo-bar', '=1.3.9'
require 'foobar'

48. Newbie friendly
● Rails is how many new web-developers start

49. Newbie friendly
● Rails is how many new web-developers start
● Rails is Ruby (plus, but still)

50. Newbie friendly
● Rails is how many new web-developers start
● Rails is Ruby (plus, but still)
● Thousands of great tutorials, skeletons, and
communities.
o Google "ruby tutorial XYZ" for all values of XYZ)

51. Newbie friendly
● Rails is how many new web-developers start
● Rails is Ruby (plus, but still)
● Thousands of great tutorials, skeletons, and
communities.
o Google "ruby tutorial XYZ" for all values of XYZ
● Syntax is very easy to read and write
o Reading code is very hard
o Anything that makes it easier is a "Good Thing"(tm)

52. Blocks (Temporary File)
require 'tempfile'
Tempfile.open('some-prefix') do |tmp|
tmp.write "Some text"
# Do something with tmp here
end

53. Blocks (Reading from a file)
File.foreach('/some/file') do |line|
puts “Line read: #{line}”
do_something(line)
end

54. Blocks (Writing to a file)
File.open('/some/file') do |file|
file.puts 'first line'
file.puts 'second line'
end

55. Blocks (Writing to a file)
File.open '/some/file' { |file|
file.puts 'first line'
file.puts 'second line'
}

56. Blocks (Changing Directory)
Dir.chdir('/some/place') do |dir|
do_something_in_some_place(dir)
end
do_something_in_original_dir()

57. Blocks (Nested blocks)
Dir.chdir('/some/dir') do
%w{sub1 sub2}.each do |subdir|
Dir.chdir(subdir) do
# In /some/dir/sub[12]
end
end
end

58. Why blocks?
● Same construct for iteration and closures
o A logical new lexical scope

59. Why blocks?
● Same construct for iteration and closures
o A logical new lexical scope
● Automatic cleanup
o (Not necessarily guaranteed in all cases)

60. Why blocks?
● Same construct for iteration and closures
o A logical new lexical scope
● Automatic cleanup
o (Not necessarily guaranteed in all cases)
● Clean delination of concerns
o Relevant code is in one place

61. Why blocks? (as a sysadmin)
Because my job isn't where I can faff about
until everything is perfectly just-so and my
HammerFactoryFactoryFactory has 103% test
coverage in Jenkins.
I need to be done yesterday and I need to be
sure it works by looking at it.

62. Why blocks? (as a devops)
Because it's the easiest way to convert a
sysadmin into a developer.

63. Tooling
● Vagrant
● Chef / Puppet
● Logstash
● fpm
● Cucumber
● AWS / Rackspace clients
● Rake / Capistrano

64. Tooling (why do I care it's in Ruby?)
Three reasons:
1. Plugins

65. Tooling (why do I care it's in Ruby?)
Three reasons:
1. Plugins
2. Plugins

66. Tooling (why do I care it's in Ruby?)
Three reasons:
1. Plugins
2. Plugins
3. Plugins

67. Tooling (why do I care it's in Ruby?)
Three reasons:
1. Plugins
2. Plugins
3. Plugins
4. Some of them require Ruby (Vagrant)

68. Questions?