The Service Pattern is a strategy for allowing a single microapp installation to provide its service to more than one client application.
Eg, using Tasty (a tagging engine) as our example microapp, you can imagine that an organization wishes to deploy several different applications: a blog, an image gallery, and a wiki, all of which they'd like to support tagging via Tasty but still have all the tag/item/user data separate from each other (ie tags from the blog should not bleed into the image gallery or wiki or vice versa). Instead of installing (and maintaining) three separate instances of Tasty, one for each application, they can have a single instance of Tasty running and each of the applications just accesses independent named services off that instance.
The Service Pattern is implemented with a simple URL prefix. Either of the form '/service/<service name>/' or just '/<service name>/'. All resources that the microapp provides are accessed below a service and all data is segmented by service. Each client application (or cluster of microapps that are forming an application) just uses the same service name each time a request is made to the microapp.
So, the blog, image gallery, and wiki might then access tasty via http://tasty.example.com/service/blog/, http://tasty.example.com/service/gallery/, and http://tasty.example.com/service/wiki/ respectively.
Services are also convenient during the development of a client application. A developer working on a new version of the image gallery application could configure their development version access http://tasty.example.com/service/gallery_dev/ so it doesn't mess up the data in the production service. This is why the Service Pattern is recommended even if you have no need for multiple client applications to use the same microapp.
The Service Pattern is directly analogous to table spaces in the database world and serves the same purpose.
The Service Pattern is unnecessary (and thus not recommended) for microapps that do not persist any state. Eg, Gild or Image Resizer would not benefit from implementing the Service Pattern.