Why Ruby is a Good Fit for the Enterprise

By Darryl K. Taft  |  Updated 11-04-2013 | Posted 11-01-2013 Print Email

The head of technology at an enterprise software company, Coupa Software, tells eWEEK why Ruby is enterprise-ready.

How secure is Ruby code?

In general, it's quite secure as long as you trust the code that you're running, which is true for us. Most Ruby implementations are open source, and tend to have a lot of eyes on them. There are standard reporting and patching protocols, and generally the right amount of transparency. It's a dynamic, garbage-collected language without explicit memory management, so it's far less prone to the kind of buffer overflow attacks that sometimes plague lower-level languages although, occasionally, something of the kind crops up in a C extension to a library.

For our purposes, security concerns are more around Rails, our application code, SSL [Secure Sockets Layer] and our hosting infrastructure, though I don't remember the last time we actually felt like we needed a patch to the language runtime itself. Rails, similarly, is open source, has a lot of eyes on it and has well-documented procedures in place for security concerns. We keep an eye on anything that comes up and assess it for relevance very quickly.

Is Ruby useful for big data applications?

Sure, at least in some cases. That's a very broad category. There are plenty of folks using Ruby (and often Rails) against a NoSQL database like MongoDB or Cassandra, and some that interface with frameworks like Hadoop through a RESTful API layer. Ruby as a language lends itself nicely to playing with semi-structured data, as it's quite dynamic and not strongly typed. When the data (or what you're doing with it) is a bit more structured and you need more throughput efficiency, it might make sense to choose something like Scala, but it all depends on what you're trying to do.

Does Ruby provide anything that helps with DevOps? Or is DevOps a language-agnostic issue? With the Coupa dev team removed from the main location, does that add to any DevOps issues?

I'd say it's language-agnostic to a certain extent, but the notion of infrastructure-as-code is strong within the Ruby and Rails communities. There are a number of good tools for handling different parts of deployments: Capistrano, Chef and Puppet are all written in Ruby, and are useful for managing Ruby and Rails applications. Similarly, there are a number of companies (Heroku, Engine Yard, New Relic, to name just a few) that host and monitor Ruby/Rails apps specifically.

Our own operations team may be two blocks away from much of our development team, but we still talk a lot. Like many even more distributed tech companies, we make heavy use of subject-specific chat rooms that let us work asynchronously. Face-to-face communication can make a difference, though, so now we have a small team on the development side that integrates with operations, and a couple of rotating developers that sit with operations day-to-day. I suspect we'll need more office space within 6 months, so who knows what our next configuration will look like, but this is certainly something we'll keep paying attention to. I'm agitating for telepresence robots, but the notion hasn't caught on yet.

 


Originally published on eWeek.
 

Submit a Comment

Loading Comments...