Chapter 2. An Introduction to Service-Oriented Design

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 serviceoriented 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 serviceoriented 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.”¹ 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.

Service-Oriented Design Versus Service-Oriented Architecture Versus RESTful-Oriented Architecture

There are many approaches to designing a service-oriented application. This book takes an approach slightly different than those espoused in Java books on serviceoriented architecture (SOA) or even other books that focus on REST. Within the community of professionals building service-based systems there is a bit of debate about the proper use of terminology and what qualifies as best practices.

SOA has become a loaded term. To many people, it implies the use of tools such as SOAP, WSDL, WS-*, or XML-RPC. This implication is why the title of this book uses the word design as opposed to architecture. Even so, this book does focus on architecture. The real goal of service-oriented design is to create simple and agile services layers that can be consumed without the use of generators or strict schemas. In this regard, the style in this book is more in line with REST-based web services than with SOA.

In the book RESTful Web Services,² Leonard Richardson and Sam Ruby discuss the details for a concept they call resource-oriented architecture (ROA). ROA represents their approach for HTTP-based RESTful design and architecture. Richardson and Ruby lay out the concepts of resources, URIs, representations, and links. They also state that ROA has properties of addressability, statelessness, and connectedness, as well as a uniform interface. When it comes to the design of specific services, this book follows Richardson and Ruby’s guidelines. (The appendix, “RESTful Primer,” provides an overview of REST.)

The real difference between the focus of this book and that of RESTful Web Services lies in the interaction points—that is, how services interact with each other to create a complete working application. The focus of this book is on internal services instead of external ones. While some of an application’s services can be exposed to external consumers, their real purpose is to serve other developers working within a single organization. In this regard, this book has more similarity to what one would commonly refer to as SOA. This book also includes a more specific focus on deploying and developing with Rails, Sinatra, and other Ruby libraries and tools.

Of course, SOA, ROA, and RESTful are all meant as guidelines. In the real world, it makes sense to flex a design with the needs of the application rather than adhere to the dogma of a prescribed approach such as REST or SOA. This book takes a pragmatist’s view and focuses on what these things mean for a Ruby environment that uses services as part of the core infrastructure for delivering an application or a web page to a user.

Making the Case for Service-Oriented Design

Service-oriented design can appear daunting and complex. It requires more thought up front and decisions about how to separate logic and data in an application. For Rails developers, the idea of designing a complex system ahead of development may seem like heresy. One of the biggest advantages of Rails is the ability to quickly add a few models to an application and see results immediately. The Rails development style is all about quick iterations.

However, there’s more to the story. Up-front design and services give developers the ability to build apps that support greater complexity and larger team sizes. Service-oriented systems sacrifice iteration speed for stability, reuse, and robustness. The key to pairing Rails applications with services is to use Rails for its strengths and switch over to services when a more stable approach is required. A perfect example of this involves creating a new application. Most new applications have many unknowns in terms of exactly what features will be supported and how popular portions of the application will be (thus informing their need for scale). In the early stages, it is best to use the normal Rails tool set. However, as parts of an application mature, their interfaces and requirements become more concrete. These are the sections that can gain the most from services. Utilizing services is best for sections of an application that have stable, well-defined, and well-understood requirements. The following sections discuss the advantages of using services rather than using a typical monolithic application.

Isolation

Many of the benefits of a service-oriented design stem from the concept of isolation. Isolation makes a service much easier to manage and optimize. Isolated components can be tested separately from other parts of an application. Using isolated components provides an easy way of organizing larger teams. Developers can focus on isolated components. Optimally, this refers to a service running on its own systems, with self-contained business logic and a self-contained data store. The separation of a service from other areas of an application enables increased testability and code reuse. There are multiple levels of isolation, including business logic, shared system, and full isolation.

Business Logic Isolation

Services that isolate based on business logic generally have their own application code, with a shared data store and shared systems. From an organizational perspective, this can be advantageous because the business logic for parts of the system is contained in one place, without leaking into other sections of the application code base. Separation of business logic makes it easier to segment a larger group of workers into teams that can work separately. Services isolated on business logic can share data sources with other systems. Generally, this is more common within a legacy system where multiple services must interface with the same database.

Figure 2.1 shows what business logic isolation might look like for the interactions between separate components. The application servers would probably reside on the same physical server, with the database on another. To achieve true business logic isolation, the two services should have separate code bases. Further, they should not communicate with each other through the database. It’s too easy to bleed business logic from the two services together through the shared database. Ideally, using services would achieve better isolation. However, for the purposes of migrating existing Rails applications to services, the shared database approach may be necessary in the early stages.

Figure 2.1 Services with separate business logic and a shared database.

The business logic can be isolated through the use of two services, which share a database. The Rails application can still sit on top of those services. In the Rails MVC view of the world, these services occupy the Model level of the stack. The controllers and views can still be contained within the Rails application.

Shared System Isolation

Shared system isolation refers to separate services running inside their own application instances. This is like multiple Rails applications or Sinatra services running in Passenger or multiple Mongrels on the same system. Each would have its own databases, but they would be running on the same hardware. This type of system provides clean separation of business logic and data layers that is ideal. However, it changes your scaling strategy because of the shared system resources.

Figure 2.2 shows the interaction for two services that implement a shared system level of isolation. The difference between this separation and the business logic isolation just discussed is the separation of the databases. Now, each of the services communicates only with its own database and the external interface of the other service. A typical configuration would have the two databases actually residing on the same database server and the two services running on the same application server. A shared hosting environment is an example of this kind of setup. However, with shared hosting, the two services are actually two different customer applications that have nothing to do with each other.

Figure 2.2 Shared systems with isolated services.

The disadvantage with shared system isolation is that shared system resources can be tricky to manage. Further, shared system isolation adds complexity with upgrading libraries or running other system-level applications. Thus, improvements to shared system services require testing against other services when making system changes.

Full Isolation

Ideally, services should run in full isolation. With full isolation, they have their own server or virtual private server instances, completely separate code bases and repositories, and their own data stores. Over time, a system could phase from one form of isolation to another. Migrating from a typical monolithic Rails application could start with a migration to a shared database and systems, then to isolated databases, and finally to completely isolated systems.

Testing in Isolation

Within the framework of testing, isolation provides the advantage of having a single testable interface. A public service API can be checked and agreed upon. Changes within the service need not affect how the API responds to commands. The testing of a service’s interface is very much like unit or model testing within a Rails application. The only difference is that the callable methods are HTTP methods that can be called by any application. All the details of the business logic and how data is stored or optimized are hidden behind the service interface.

The big advantage isolation provides with regard to testing is in the time required to run the test suite. Rails developers working on mature projects with large code bases routinely have to wait longer than 15 minutes for their test suites to run to completion. In fact, it’s not entirely uncommon for some teams to work with large code bases that take longer than 40 minutes to run their entire suite of tests. This becomes a major problem when you want to change something small. After even a small change, the full suite of tests must be run to ensure that the change didn’t break anything.

With isolated application components, testing to make sure other parts of an application are functioning properly becomes a much smaller problem. For example, consider an application code base that takes 20 minutes to run the full suite of tests. Then break that application into four fairly evenly sized, separate, isolated components. Now the test time for a single change to one of these components is cut down to one-fourth of what was previously needed. If a change is made to one of the new components, it isn’t necessary to run the test suite for everything. Only the tests for the single component need to be run, and in this example, that would take roughly 5 minutes rather than 20. As long as the public-facing interface for the component is well tested, changes can be deployed without concern that the other three-fourths of the application still works. Of course, if the API of a service changes, then each consumer must be tested to ensure proper operation.

Robustness

Services that are well designed provide an application with a robust architecture. That is, the architecture is able to withstand stress on the system and changes in the operating environment without loss of functionality. The underlying environment in which services run can change while a service continues to operate without the service consumers having any knowledge of these changes.

For those familiar with object-oriented design, the robustness advantages of services may sound similar to the advantages of encapsulation. Indeed, with services, the aim is to achieve encapsulation for entire sections of an application. In object-oriented design, encapsulation means that the underlying implementation can be changed without the API consumer’s knowledge. For services, such changes can include code changes and more drastic changes, such as moving to a different type of database.

For example, consider a user management service. To start with, it includes only basic functionality, such as a user model, authentication, profile data, and a lightweight social network (where people can be friend each other). The initial implementation could use ActiveRecord and a MySQL database. As the load on the service picks up, it starts to outgrow the limits of the regular SQL solution. Because there is a clearly defined services interface, this can be modified without a single change to the rest of the application.

Switching underlying data stores could go something like this: After some hand wringing and careful research, you might decide to move the user data to some NoSQL data store, such as CouchDB, Redis, or MongoDB. First, you would update the implementation to use the new data store, along with migration scripts to move the data from MySQL to the new NoSQL database. Once a new server or two or three have been set up, you could migrate the code and data. When this migration is complete, the other sections of the application are still able to access the user management service without ever knowing about the complete change of the underlying data store.

Scalability

Experienced Rails developers tend to roll their eyes when people mention scalability. People outside the Rails community advise against using Rails because they say it isn’t scalable. Meanwhile, Rails developers know that Rails itself isn’t the problem. While it’s true that scalability in general is difficult, the problem usually comes down to the database. A services approach provides more tools and ability to deal with scaling. Specifically, using services makes it easy to scale portions of an application individually. Data can be split across services, and the performance under load can be optimized for each service.

A partitioned data strategy is part of service-oriented system design. When fully isolating services, you need to make decisions about putting data in one service or another. Once data has been partitioned, changes can be made to the individual services based on their scaling needs. While one service may need to optimize for data writes, another may optimize for many reads. The advantage of a good service design is that these needs can be handled on a case-by-case basis instead of requiring optimization of a single database for all cases.

Services also make it easier to scale team size. When a programming team is larger than six people, it gets hard to coordinate changes in an application. One developer’s change may step on another’s. Further, as the code base of the application gets larger, it gets harder to introduce new developers to the system as a whole. When an application is split into services, developers can be assigned to a specific service or two. Thus, they need to be familiar only with their section of the application, and the working groups can remain small.

Finally, using services makes it easier to scale the absolute size of an application in terms of the code base. Larger applications have too much code for anyone to be familiar with it all at any given time. In addition, their tests take longer to run. For example, when developing Rails applications, a developer doesn’t usually have to dig into the Rails code base. Rails provides a layer of abstraction that doesn’t often need to be penetrated. Services can provide this same layer of abstraction for code and for actual production systems.

Agility

When thinking about complex architectures, agility is not the word that comes to mind. However, properly designed services can be far more agile than monolithic applications. Changes to the underlying nature of the services can be made without concern for the rest of the application. The pains of deployment can also be eased because deployments don’t require the entire application to be updated with each change.

The ability to change underlying service implementations without affecting the rest of the application provides implementation agility. Switching databases or changing message queues or even changing languages can be done without worrying about the rest of the system. This kind of agility is often overlooked in the Rails community, but it becomes a huge asset to applications that mature over a period of years. Using services allows for changing or updating underlying libraries without having to dig through every part of the application code base to make sure everything is still working as expected.

In the Ruby community, a good example of an advantage offered by services is the planning for migration to Ruby 1.9. Services provide greater agility in making these kinds of updates. Services can be upgraded to 1.9 as the libraries they use are confirmed to work. Thus, services can take a phased approach to upgrading to use Ruby 1.9 and take advantage of its features.

One of the keys to maintaining agility in a service environment is proper versioning. Each service interface should be versioned when an update includes a breaking change. As long as the design includes the ability to run multiple versions of a service simultaneously, it’s possible to keep somewhat agile with respect to interface changes. If an update to the service API is additive—that is, it doesn’t change existing calls and only adds new functionality—the service can remain at the same version.

Interoperability

For large heterogeneous environments, interoperability is an important requirement. When working with multiple languages or interface with legacy databases, legacy systems, or external vendors, using services is a great way to connect with these systems. Web-based interfaces to these systems can provide the ability to flex with changes without breaking sections of an application. The HTTP interface also prevents being tied to a specific messaging implementation that might otherwise be used to communicate with these systems. Services ease interoperation with internal and external systems and with systems written in languages other than Ruby.

Internal interoperability refers to interfacing with systems written in different languages within an environment. Some of these systems already expose their functionality through a web API. Apache Solr, a Java-based indexing and search server, is a great example of a system that provides a service interface. By interacting with this interface, Ruby developers can take advantage of all the work done on this project without having to call into the Java code directly by using something like JRuby. The Solr interface is usually called by other services and applications within an environment.

External interoperability refers to the need to interface with external systems such as those from vendors. Many external services also provide a web-based interface for their customers. Examples include SimpleDB, SQS, SalesForce, Github, Lighthouse, Twitter, Facebook, and countless others. Writing clean, performant Ruby client libraries is key to bringing these services into an application. Writing client libraries is covered in detail in Chapter 6, “Connecting to Services,” and Chapter 7, “Developing Service Client Libraries.”

Environments with multiple languages in use benefit from the use of HTTP-based services. While Ruby is a great programming language, it isn’t always the best tool for every job. If a section of an application would benefit from being implemented in Erlang, Scala, or even Java, HTTP services can provide the message bus for interaction between these disparate setups.

Reuse

After a service has been developed and deployed, it can be reused across the entire system. The argument for reuse is strongest in environments where multiple applications have common shared functionality, such as consultancies and large corporate environments that develop multiple internal applications for different users.

Consultancies that develop and host applications for their clients could reuse services. Currently, the most common model of code reuse across these applications is through the development of plug-ins or gems. Specific examples include user authentication, tagging systems, commenting systems, and searching. However, many of these could be developed and deployed as services. One of the possible gains to taking the service approach is the reuse of system resources across all clients. For example, a user management system could be implemented as a service (as in the example in Chapter 1, “Implementing and Consuming Your First Service”). This system could then be used across all client systems. If this is repeated for other shared functionality, new applications will have to implement and deploy only anything that is custom to their environment.

Providing public-facing APIs is another area where the services used to build a system internally can be reused. If services are created for internal use, they can be exposed later for general use. The popularity of the Twitter API shows that it can be advantageous to expose parts of an application through a RESTful HTTP interface. With the services approach, exposing application functionality to the outside world becomes as easy as simply opening up an already existing internal API to the public.

Conclusion

Hopefully, this introduction has whetted your appetite for exploring the service-oriented approach covered in this book. The extra design work and communication overhead of creating and using multiple services takes a little more effort than creating a typical Rails application. However, the benefits of a service-oriented design can far outweigh the costs associated with inter service communication and more up-front design.

Here’s a quick recap of the benefits of service-oriented design:

• Isolation—Robustness, scalability, and improved testing strategies all stem from the concept of isolation. Isolation gives an application architecture many of the advantages that encapsulation provides in object-oriented design.

• Robustness—Services are robust because their underlying implementation can change with shifting load requirements, libraries, and languages without detriment to the rest of the application.

• Scalability—When using services, you need to think up front about how to separate data and manage interaction. This partitioning of logic and data provides the ability to scale the size of the code base and team in addition to the number of requests to process.

• Agility—Upgrades to underlying system components are easier with services. Further, new versions of existing services and completely new services can be implemented outside the full architecture. This can provide much-needed agility for mature code bases where changes are typically expensive to verify with the rest of an app.

• Interoperability—Using HTTP-based services is a great way to expose the functionality of legacy applications or external vendors.

• Reuse—Service-oriented design enables reuse of components across multiple applications or clients.