The era of the monolithic multi-million line application is over and service-oriented architecture (SOA) killed it, argues Tom Mornini, CTO of Engine Yard, a Ruby and Rails hosting service.
"It's my belief that the days of the huge application are behind us," he said in a recent interview. "There will be applications that appear huge, but at the end of the day they will be a collection of smaller applications."
That composability of the SOA approach is changing the application development game by providing agility for businesses operating in global markets where business opportunities are a moving target.
"I can't see any other way of meeting the continuous demand for data access and the need for fluid change to keep up with the pace of change in the world, inside and outside the enterprise," Mornini said. "That's why the idea of the multi-million line application that was going to solve every problem is just a relic at this point."
According to Mornini, it isn't so much a case any more of SOA being an alternative to traditional application development, there is no alternative but SOA.
"Those big applications are so difficult to manage and maintain it's hard to imagine that monolithic applications is the way forward," he said.
The Engine Yard CTO sees Ruby on Rails with REST as the way to build the new generation of services and applications for SOA. Unlike Java, which was developed in the pre-SOA application development era of the '90s, he noted that Ruby on Rails and REST offer a millennial approach created with SOA in mind.
"It's almost a little secret of Rails that it has a really substantial and deep service-oriented architecture bent to the framework," Mornini said. "The developers of that framework see that (its SOA capabilities) as a very significant strength of the platform."
While he always viewed Ruby on Rails as well suited for SOA development, the release of Rail 2.0 made the framework friendlier to SOA applications, including those requiring legacy data access, he said. While he acknowledges that the original Rails framework was not terribly friendly to legacy data access, this year's model has evolved past that.
For example, code contributions from the Rails community have added capabilities that make it easier to access legacy data in SOA applications by making it possible to expose legacy data as services, he said.
Rails makes RESTful data access easy for developers for following procedures documented in after-market books and Web videos, the Engine Yard CTO said.
"If you write an application with Rails today out of the box and follow standard procedures documented for RESTful Rails, you will automatically get an XML-over-HTTP-based API into all of the data models that your application presents," he said.
But to get this to work it is important to "stay on the Rails," which Mornini said is the Rails mantra for following the established procedures.