

Language Importance for DevOps Engineers - gpapilion
http://blog.hypergeometric.com/2012/02/05/language-importance-for-devops-engineers/

======
rachelbythebay
Your mileage will vary. In my life working for "the man" as a sysadmin or
developer type in Mountain View, it broke out like this:

Shell scripts: a little bit here and there. Mostly for my own shortcuts to
save time doing repetitive stuff.

Perl, PHP, Ruby, Chef/Puppet, Haskell: Zero.

Javascript: Only if cargo-culting a "make this table sortable" thing into a
web page counts.

Java: Just that one time, to help out some folks who were on vacation when
their service broke.

SQL: Unfortunately, more than I like to admit. Almost always used in
conjunction with...

Python: Far more than I liked. One service was nothing but Python code written
with a typical scripter mentality. Pain.

C: Rarely, like a one-afternoon tool we used just once.

C++: Constantly. So many things were and are written in it.

I must say that lumping C and C++ together is worrisome. Odds are, you're not
going to use them the same way.

------
artemvv
The article is very biased opinion indeed. PHP, JavaScript, SQL, Java and
Perl? Wow. Party like it's 1999. Honestly, I don't see DevOps doing
JavaScript. I am no aware of any DevOps tools based on JavaScript and server-
side JavaScript movement is only beginning. PHP, Perl, SQL, Java are a dead
waste of time. Major DevOps tools such as Chef, Capistrano, Fog, Puppet, are
based on Ruby. Systems are written in C and system control utilities are all
Shell. A DevOps guy needs to know Ruby or Python (pick one), Shell and C.
Erlang and JavaScript would probably be next on the list.

~~~
gpapilion
You don't need to know chef, its a simple DSL that is quite wasteful resource-
wise.

I'd pick ruby over python, but thats just me. I'd still choose perl over
either, but thats because things like threading and the low memory footprint
are appealing.

DevOps is about running the stack. If you don't understand the stack your,
you're not doing devops.

~~~
artemvv
You are confusing DevOps with full-stack engineering. These are two different
things.

DevOps is about continuous deployment, continuous integration, automation,
infrastructure as code. Your choses to do infrastructure as code are Chef
(Ruby), Puppet (Ruby), CFEngine (C), and BCFG2 (Python). You will not get very
far with DSL-only knowledge of Chef of Puppet only. The case is the same with
CFEngine and BCFG2. All infrastructure as code frameworks assume you are going
to customize.

As for the resources, the most valuable resource these days is engineering
time. Chef specifically and Ruby toolchain overall are hyper-efficient when it
comes to engineering time.

~~~
gpapilion
I disagree.

Infrastructure as code can be implemented any way you want. The DSL portion of
chef should get you very far, if it doesn't you should just be writing ruby,
C, or python code to meet you needs.

Automation is really what devops is about; infrastructure as code, continuous
integration, continuous deployment are all just synonyms for automation. I
think again, what ever get the job done the most reliably, and quickest.

~~~
artemvv
I don't see the disagreement.

I'll give you a Chef example of why DSL is not going to get you far.

Let's say you are running a LAMP stack. Let's say your engineers are good
enough to implement a Service Oriented Architecture. SOA means your
infrastructure needs to be capable of running a variety of disjoint
components. As a DevOps Engineer you need to be able to automate
infrastructure and deployment to support rapid releases of application
services.

From the infrastructure perspective, application services needs are similar.
An application service will probably require a set of Hosts/VMs with specific
roles, Vhost configuration, DNS provisioning, Load Balancer config, Logging
configuration, User configuration, etc.

If you are writing just in DSL you will end up for a unique Chef recipe for
every application service. These recipes are going to be 90% similar, and your
Chef repo will become very difficult to maintain because many changes will
require edits of multiple recipes (copy-pastes mostly).

Now, if you move beyond Chef's DSL, you will be able to extend Chef's DSL with
your own definitions.

My Chef's recipe for a new LAMP application service is php_app "name" do ...
that sets up DNS, Vhosts, logging, users and everything required in one
command. The code is also very maintainable. To change the way logging is done
for all application services, I need to edit only several lines of code in the
Chef definition.

DevOps movement started as idea to adapt developer practices in systems
administration. One of the principles developers use is DRY (Don't Repeat
Yourself). In order to DRY you need to know more than basic Chef DSL.

