- 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
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.