Rails services in the walled garden

The talk "Rails Services in the Walled Garden" presented by Niranjan Paranjape and Sidu Ponnappa at RubyConf 2011 explores the implementation of service-oriented architecture (SOA) using Ruby on Rails. It addresses the intricacies and challenges faced when building multiple services within a business environment, referred to as a 'walled garden'. This approach focuses on creating independent, evolving services rather than relying on monolithic applications. The speakers draw on their experience working with a large-scale project consisting of more than nine Rails-based services for a major hosting provider, detailing various problems encountered and solutions implemented. Key points discussed include:

Advantages of SOA: Services allow for independent development and deployment, better scalability, and facilitate integration across business verticals while maintaining localized control over API design. These benefits streamline workflows and reduce complexity across teams.
Challenges of SOA: The talk emphasizes some challenges, such as increased chatter between services leading to performance bottlenecks, difficulties in implementing authentication and authorization across services, and complications with database transactions in distributed environments.
Authentication and Authorization: The importance of a centralized authentication system to enable users to access multiple services without re-authenticating is discussed, alongside the implementation of OAuth2 as a robust solution. Centralized roles versus federated rules for service authorization are examined.
Performance Optimization: The speakers encourage implementing performance builds to monitor HTTP request times and improve service communication efficiency. Caching strategies, like server-side, client-side, and intermediary caching, are proposed as methods to improve response times.
Pagination in APIs: Efficient pagination is discussed, highlighting the need for presenting manageable data chunks in API responses. The ‘box paginate’ solution was introduced to make pagination easier when using Active Resource.
Event-Driven Architecture: The benefits of using event systems and message queues (e.g., RabbitMQ) for decoupling services and enabling asynchronous processing of events are explored, showcasing how these can replace problematic direct database integrations.
API Versioning and Transactions: Suggestions for handling API versioning and maintaining backward compatibility are provided alongside discussions on the complexities of managing distributed transactions.

The presenters conclude with considerations for standardizing coding practices across services, advocating for the use of tooling such as Chef or Puppet for configuration management. The overall takeaway from the presentation stresses the importance of designing robust, maintainable, and efficient API-driven services while navigating the unique challenges posed by service-oriented architectures in a corporate setting.

Rails services in the walled garden
Niranjan Paranjape and Sidu Ponnappa • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

In typical service oriented architectures, monolithic applications are sliced along domain verticals to create several independently evolving 'services' that can be used in combination to achieve various outcomes. Rails applications lend themselves to this architecture beautifully and are slowly making inroads in big organisations for this reason. One of the big problems with this approach is that analyzing and managing large quantities of data from multiple services to produce a result becomes very hard. What was originally a relatively simple task when all data sat in the same database as part of a monolithic application, becomes, when split into multiple services, a whole different beast. This talk will focus on our experiences building a system involving about a dozen rails based services integrated over HTTP and XML and the issues we had to deal with when working with large data sets. We will talk about: * Various problems we faced while building RESTful APIs which demanded asynchronous communication between two services * Places where this asynchronous communication was needed to be initiated by the server, essentially a push mechanism instead of pull * Different approaches to this solution ** Sharing a database using read-only 'remote models' ** Creating read only local caches at each consumer *** Propagating updates by having the producer explicitly update each consumer *** Propagating updates using a message queue and the pros and cons of integrating with them in Ruby

RubyConf 2011