The head of technology at an enterprise software company, Coupa Software, tells eWEEK why Ruby is enterprise-ready.
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.
Originally published on eWeek.
This article was last updated on 11-04-2013 |