eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Ruby scripting language has drawn its share of both proponents and critics. However, Coupa Software, a spend management company that offers a cloud-based suite of financial applications, has standardized on Ruby as its development language of choice. In an interview with eWEEK Senior Editor Darryl K. Taft, David Williams, vice president of technology at Coupa, spells out why Ruby is a good fit for Coupa’s enterprise offerings.
Why is Coupa primarily a Ruby and Rails shop?
Rails was the best functional and philosophical fit for what we were aiming to do when we started out in 2006, and it has scaled well with the company. Functionally, we fit the mold of a three-tier model-view-controller (MVC) Web application backed by a normalized relational database, and all of our integration with legacy systems is arms-length rather than at the database level. Given that, we fit the assumptions inherent in Rails’ design, and, like any framework, Rails works best when the problem you’re trying to solve with it matches what it’s designed for. Rails wasn’t the only MVC Web framework around at the time, however, so other factors came into play, particularly the philosophy around it and how well the tradeoffs matched what we needed. For us, the choice was mainly between Ruby on Rails and a couple of different frameworks written in Java. Rails’ principles of “convention over configuration” and “don’t repeat yourself,” combined with the “magic” made possible by Ruby’s dynamism, meant that with Rails we could build more features faster with fewer developers and less code. Since our whole tech stack was open source, and there weren’t that many layers, if there was a problem that cropped up anywhere we could debug it quickly and fix it ourselves. We found that we were writing about one-tenth of the code that we’d need to write to do something similar in Java, and having less code to start with, meant that it was inherently easier to maintain.
I’ve heard you say that Ruby makes you happy as developers. Why is that? What is it about Ruby that makes you happy as compared to other languages.
Although Randall Munroe may have compared LISP to a light saber in one of my favorite xkcd comics (http://xkcd.com/297/), I feel like Ruby also fits. It’s versatile; besides using it for our applications, I use it for shell scripts and one-liners that I might’ve used Perl for in the past. It’s elegant—for example, blocks of code are first-class objects, and there’s none of the primitive type vs. object and auto boxing/unboxing of Java. It’s concise and expressive, in that it tends to read like English and isn’t weighed down with excessive punctuation. It’s extendable, both in that it’s open source and in that it’s easy to dynamically generate your own code or modify pretty much anything. Less concretely, when it surprises you, it tends to be for the better, meaning that as a developer you spend more time and energy on the problems you care about and less on catering to the language’s own needs.
You also noted that your Ruby project is fairly large. What is considered large for a Ruby project? If you continue to grow, will that tax the system? What can you do to account for scale?
I haven’t found any reliable statistics, so I can’t be specific in terms of percentiles, but anecdotally, we’re among the larger fairly monolithic Rails apps out there in terms of lines of code (more than 100,000) and number of instances (more than 1,000). The Rails framework popularized the Ruby language here in the US, so while I’m sure there are some large non-Web applications, most of the Ruby applications I’m familiar with are Web apps using the Rails or Sinatra frameworks.
Why Ruby is a Good Fit for the Enterprise
As far as scaling, that’s a complicated question with a number of different answers, and it’s one that varies significantly with the type of traffic you get. The short, generic answer is (1) throw hardware at it, (2) aggressively tune your most common and costly flows, (3) selectively degrade/limit particularly expensive features and (4) break things up into smaller chunks. As an enterprise SaaS app, our load tends to come not from simultaneous usage spikes as much as from power users manipulating large quantities of data at once. Also, since everything is dynamic and subject to encryption, customization and fine-grained security, typical consumer-facing scaling mechanics like CDNs and edge-caching aren’t as relevant. If you look at a use case like Groupon’s or Living Social’s, for example, it’s a lot different than ours. In aggregate, there’s a lot of data, and they need to deal with a large number of simultaneous users, but each individual user is dealing with a fairly small amount that’s common to many other people.
As we scale our business, we certainly, and fortunately, have some technical scaling to get ahead of as well, and we’re taking a multi-tiered approach. We already shared instances and databases by customer, because there is pretty much no shared data between our customers, and we don’t want there to be any possibility of comingling. Rails tends toward very minimal user sessions as a best practice, and we adhere to that, which helps make it possible to scale the front ends fairly linearly with additional hardware. In the short to medium term, a lot of what we are doing is tactical work on database queries and moving to newer versions of Ruby, Rails, and our database to take advantage of various performance and efficiency improvements. What may eventually drive moving to a more service-oriented and less monolithic architecture is wanting more separation internally to support a larger and more naturally segmented development team, but there’s nothing inherent in even that big a change that would preclude using Ruby or Rails.
Does Ruby present any particular challenges for your team?
One challenge comes with Ruby’s power and flexibility: It’s possible to redefine and/or extend existing functionality easily, transparently, and in a number of different ways. Given that, individual developers have great power, and must exhibit concomitant responsibility. Just because you can do something doesn’t mean it’s necessarily a good idea. Code reviews and established coding standards can help alleviate the concern and prevent problems.
In moving to Ruby 2.0, what features are you most interested in taking advantage of?
One particular feature, refinements, will further help narrow down the scope of a dynamic extension. This will make it easier for developers to ensure that their “local” changes to a shared piece of code aren’t accidentally shared with other places in the code that don’t need to take advantage of them. It’s a bit obscure, but the end result should be fewer bugs and more freedom to upgrade components.
I’m also looking forward to the updates to memory management and the garbage collector in 2.0 and 2.1. The performance of a particular Ruby process depends on how often it has to stop to clean up discarded objects, and how long it takes to do that. After upgrading, we’ll be using less memory for the Rails framework itself, and instances of our own objects should be collected more efficiently. This should mean better performance and higher throughput on a per-process basis.
Why Ruby is a Good Fit for the Enterprise
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.