Language Importance for DevOps Engineers(blog.hypergeometric.com)
blog.hypergeometric.com
Language Importance for DevOps Engineers
http://blog.hypergeometric.com/2012/02/05/language-importance-for-devops-engineers/
2 comments
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.
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.
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.
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.
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.
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.
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.
The importance of the Chef DSL is abstracting away common system interactions and most importantly, all the edge cases that come up. Whatever you are automating, you're going to be installing packages, starting services, and creating configuration files. Everyone should not need to re-invent that wheel, nor suffer finding the same Ruby GC bug when running a certain IO method.
By design, Chef fully expects you to leverage Ruby if you are operating in an environment of any complexity. Herein it differs from some other configuration management tools which strive to model everything you would want to manage. We (I am a Chef developer) often refer to our resources as primitives, the building blocks with which you code your infrastructure.
By design, Chef fully expects you to leverage Ruby if you are operating in an environment of any complexity. Herein it differs from some other configuration management tools which strive to model everything you would want to manage. We (I am a Chef developer) often refer to our resources as primitives, the building blocks with which you code your infrastructure.
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.
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.
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.