Over a million developers have joined DZone.

Interview: Switching from Java to Ruby

DZone's Guide to

Interview: Switching from Java to Ruby

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

When eSpace moved from mobile salesforce automation to web development, their confrontation with enterprise scalability had just begun. Their unique solution, and their decision to move from Java to Ruby, is the focus of the following discussion with two key players, Mohammed Ali (CTO) and Ehab ElBadry (Services Manager).

Firstly, what is eSpace?

Mohammed: "eSpace is a software company established in Alexandria, Egypt. It was founded in 2000 when eight graduates (pictured below) from the Computer Science Department at Alexandria University decided that, instead of taking the well trodden path of seeking job opportunities in multinationals, they would start their own company.

Inspired by the startup fever sweeping Silicon Valley at the time, they started their own company which has over time become a leader in the field of Web Scalability Solutions."

Ehab: "Over time, we increasingly wanted to catch the Web 2.0 wave, and we enjoyed playing with the new toys that this wave brought. In fact, we ended up finding those toys more interesting than enterprise Java, especially since they were created to support an agile model, benefiting both oursevlves and our clients. Web 2.0 further enabled us to move away from focusing mainly on work outsourced to us from the US and Europe and, instead of being the slaves of multinationals, gradually became the manager of our own projects."

The process must have been incremental. Can you describe how it unfolded?

Ehab: "Initially, we had approximately 20% Ruby projects and 80% Java projects. The 20% were mainly prototypes, not production code. It really took time and commitment for people to make the switch. The real turning point came in 2006 when http://alsaha.com, which is the largest Arabic on-line forum, became our client. (It is so large that it was even mentioned in the movie "The Kingdom", starring Jamie Foxx and others.)

The task was "simple": to renovate their forum."

What were the problems that they saddled you with?

Ehab: "Though they were the largest Arabic on-line forum, they had a very old system that broke easily. A central problem was scalaeability. In fact, they had to close membership subscriptions completely because their system  was, at some point, completely unable to grow further. That's obviously the worst thing that can happen to an on-line forum. So they not only wanted a really attractive website, but also one that would be scaleable."

Mohammed: "And all you would hear at the time was: 'Ruby doesn't scale.' That was the central challenge that we faced."

Ehab: "Not to mention the Distributed Denial of Service (DDoS) attacks."

Aside from the newness of Ruby, does it have other specific features you found attractive?

Mohammed: "Well, at the time that Ruby on Rails came out, someone out there used it to build a website for Tsunami Relief... in a matter of 10 hours. That was a very compelling situation. The Tsunami Relief site had to be scaleable, so this site ticked the right boxes for us. We also looked at the available languages at the time and at the extent to which they supported flexibility, via features such as closures and functional abilities. We needed a balance between object orientation and the power of functional features."

Ehab: "The short learning curve was a crucial factor as well."

Mohammed: "Yes, indeed. There have been huge productivity improvements for some. We had a big team on Java, working for big clients. There was a very steep curve for newbies on our team to enter our workflow. They had to learn a full Java stack, which included Hibernate and Spring. It was simply too complicated, with new employees struggling for weeks just setting up their environment. Senior colleagues had to help them with this, that, and the other, which decreased their productivity too, of course. The conceptual complexity of the full stack really weighed us down, combined with technical problems such as the stateful nature of JSF, the nightmare of configuration files, and so on."

Ehab: "Here's one concrete example: recently we were working on a web crawling project. A new developer came on board who had had a crash course in Ruby. His assignment was to redo everything the Java team had done, but in Ruby. He was done within a week, with less code, more compact, than the original.Yes, there was a performance hit, but the hit was fairly small and insignificant in the greater scheme of things."

Mohammed: "Yes, it is the bandwidth that sets you back, not the processor. Going back to a comparison between Ruby and Java, Ruby has no deep hierarchies, nor interfaces, and the dynamic creation of methods at runtime makes it extremely flexible. Today, we find ourselves making changes to libraries much more often and more easily (no recompilation!) than we did in our Java days. And introducing new libraries to old code is now simply a question of creating a new wrapper between the new library and the old code. While it is true that Java is continually evolving, with increasingly less configuration files, for example, it really belongs to the backend, as far as we are concerned."

So you are still using Java and mixing it with your Ruby frontend?

Ehab: "Definitely. For example, the Indexer is in Java. Also, the Classifier, which is the part of the code that puts a topic on AlSaha.com into a particular category (such as "Politics" or "Science") is pure Java."

Mohammed: "Running on the same JDK allows this mixing. But, of course, if the JDK would incorporate dynamic method invocation, we'd be really happy, since it would improve the performance of dynamic languages such as Ruby."

But you also created your own unique solution, NeverBlock. Can you say something about that?

Mohammed: "Ruby has some VM performance problems, partly based on its implementation and partly based on immature libraries, in particular those related to concurrency. We have created a solution and now provide an improved I/O concurrency library to the Ruby community, called NeverBlock."

Ehab: "NeverBlock is a set of tools and utilities that allow Ruby developers to write non-blocking, concurrent code in a transparent manner, meaning that they will keep coding in their traditional ways while getting the benefit of non-blocking IO operations."

Mohammed: "Right. This is not a new API. It is a low level library that solves concurrency problems relating to sockets, network operations, and the invocation of external programs. Technically, NeverBlock builds on two main concepts: Ruby 1.9 Fibers (or Coroutines) and evented, non-blocking IO.

(More on fibers here.)

It builds on top of those to provide developers with IO access libraries that can totally hide the complexities of the evented model and add concurrency support to your applications."

So, the basic model is "fibers", rather than "threads"?

Mohammed: "Right. Fibers are "light threads" that are not scheduled by the VM, but are issued manually. They can be paused and resumed at will. Each action in the application takes place within a new fiber. One issues an action and, at I/O, the fiber pauses and then resumes at the end of I/O. There is, as a result, no scheduling overhead. There is no locking and there are no race conditions, because pause and resume both occur on demand. And, again, the user of the library doesn't need to code anything differently, only being required to configure something slightly differently."

Ehab: "It is being used in production already. Read more about our benchmarks here."

Mohammed: "Although it is not that common to have too many connections, e.g., doing I/O during ten thousands of connections, the benefits can be seen by Amazon web services, for example. When connecting to a single database, the benefits will be considerably less, since it mainly applies to scenarios where one is scaling upwards. We want to provide a fullstack solution to the Ruby community, including also something like the Python MultiProcessing library, which is utilized for running applications in multicore environments."

What concrete gains do users of AlSaha.com now benefit from?

Ehab: "Usability. The user friendliness of Web 2.0 is obviously a boon. In addition, we've incorporated several new features, such as a statistics provider: users of the site can see how many people visited a topic. They now can also create and save drafts and there is an aggregator putting related topics into a single place."

What kind of conclusions have you been able to draw from your experiences?

Ehab: "Well, AlSaha.com is one of the top 10 visited Ruby on Rails applications on-line today. From this and other experiences we can conclude that, firstly, we were able to create attractive and performant websites. Secondly, it is possible to create Ruby on Rails applications that scale and that are performant under load."

Mohammed: "We're now moving faster, thanks to these experiences. We're able to focus more strongly on the Gulf market, while maintaining a balance with the US and Europe. For example, we're creating a portal for the Qatar Foundation, which is a governmental entity focusing on the advancement of technology in that part of the world. Also, we're working with VodaFone and Etisalat. Recently we were at the Ruby conference to share our experiences with our migration to Ruby. (Watch it on-line here.)"

And any final comments on Java and Ruby?

Mohammed: "The question turns on the question of being dyanmic. Ruby allows that. It should be possible to have a flexbile application, one that can be changed and maintained easily. We very rarely look at Java anymore. Annotations and generics give me the creeps! They fill a space, sure, but are overused because Java needs their dynamic capabilities. But, in fact, they seem to be bending the language unpleasantly, to make it behave dynamically. When Java came out, it was a big improvement over C/C++. But, for us, Ruby has proven itself a convincing alternative in the enterprise."

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}