An Introduction to Service-Oriented Design with Ruby and Rails
- Use of Service-Oriented Design in the Wild
- Service-Oriented Design Versus Service-Oriented Architecture Versus RESTful-Oriented Architecture
- Making the Case for Service-Oriented Design
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Service-oriented design is about creating systems that group functionality around logical function and business practices. Services should be designed to be interoperable and reusable. The goal of service-oriented design is to split up the parts of an application or system into components that can be iterated on, improved, and fixed without having to test and verify all the other components when an individual is updated. Achieving these goals usually entails a trade-off between complexity and iteration speed. However, large and mature applications are ill-served when built in Rails monolithic style. It is necessary to segment complex or large applications into parts that can be tested and deployed separately. This chapter explores the basic goals of service-oriented design and design guidelines for splitting applications into separate services.
Use of Service-Oriented Design in the Wild
Organizations such as eBay, Amazon, LinkedIn, and other large web-based companies use layers of services to bring their applications together. While many of these environments are based in Java, the advantages that come from their approaches to architecture design can be applied to web applications and systems written in Ruby.
The architecture of Amazon most exemplifies the advantages of good service-oriented design. In May 2006 the Association for Computing Machinery (ACM) published an interview between Jim Gray and Amazon CTO Werner Vogels titled "A Conversation with Werner Vogels."1 In the interview Mr. Vogels states that when a user goes to the Amazon.com home page, the application calls out to more than 100 services to construct the page.
Mr. Vogels goes on to say that the move from a monolithic two-tier (database and web application) architecture to a service-oriented approach provides many advantages. These include improvements such as scalability, isolation, and developer ownership of production systems. Further, Vogels states that this has led to improved processes and increased organizational agility to develop new services and features. Amazon's service-oriented architecture has enabled the introduction of new applications and services without requiring reconfiguration of the entire system.
Amazon's approach to its internal systems has driven and informed the development of the Amazon Web Services (AWS) platforms. Every piece of the AWS architecture is exposed as a web service. Here's a breakdown of Amazon's current services:
- S3 (Simple Storage Service)—A service for storing files.
- SQS (Simple Queue Service)—A service-based messaging queue.
- SimpleDB—A scalable service-based database.
- CloudFront—A service-based content delivery network.
- EC2 (Elastic Compute Cloud)—A service for provisioning virtual private servers.
The AWS platform represents an example of low-level system components exposed through a services layer. A service-oriented design can take advantage of these types of lower-level components as well as services that operate a little further up the stack that provide functionality for a specific application. Higher-level services might include a user system, a comments service, a video transcoding service, and many others.