5 lessons from the service-oriented architecture trenches

SOA is great for large enterprises, but not for small teams -- and four other nuggets of advice from a seasoned SOA veteran.

It's said that 10,000 hours of practice at a chosen activity will make someone an expert at it. Service-oriented architecture has been in force for several years now, so there is a rising class of developers and architects who understand the practice on an intimate level.

So it's good to hear about experiences with SOA projects through a recent post from Will Larson, a software engineer and technical leader who has built out service-oriented architecture for a range of clients, including Digg and SocialCode.

Larson shared what he sees are five things enterprises need to know about SOA:

1) SOA is great for moving mountains, but not molehills: In SOA, bigger is better. SOA doesn't "provide a lot of value for very small teams," Larson relates. It actually tends to complicate architecture, he declares. "My gut feel is that small teams seeing massive performance wins from moving to a SOA could probably have gotten those same wins through any system rewrite/overhaul." For large organizations, however, SOA provides "an abstraction for large teams to work together effectively" through defined interfaces which hide internals.

2) Start simple, with just a couple of services: Don't start out trying to boil the ocean — or even a lake for that matter. "Start by adding simple and uncontroversial services, like a user identity and authentication service," Larson says. "Roll each service out to all your applications before adding another. Then add another, and another until you've reached the desired consistency. (Which might only be a couple of services early on. Don't be afraid to go slowly.)"

3) Protocol matters: Leverage the skills of staff members. "One of the most important decisions we made from Digg to SocialCode was switching from the Thrift protocol to HTTP. This allowed the browser to be a native client which uses the APIs directly, but more than that, it also made debugging and experimentation easier because most software developers are extremely comfortable with HTTP and HTTP servers, whereas relatively few are comfortable with Thrift," says Larson. However, each of the protocols has its strengths and weaknesses.

4) For starter projects, stick with dumb API clients: Whether to use smart or dumb clients depends on several factors, including developer experience. "There is a tradeoff between using sophisticated clients which hide as much complexity as possible (buying ease of use at the loss of control or awareness) versus dumb clients which expose all the ugly details of the underlying API (control and awareness at expense of 'normal case' implementation speed)." Larson adds that he personally is "a strong proponent of dumb API clients.  I believe smart clients encourage engineers to treat a SOA as a monolithic application, and that's a leaky abstraction."

5) Leave well enough alone — even if it is duplicated: In any sizable organization, you're going to find two or more teams working on similar services — fight the urge to merge them, Larson advises. It's more productive to let the duplicated services get developed — as he puts it: "get to the destination faster by avoiding fruitless debate." Once released, then you can focus on single, reusable services. "After the various implementations are stable, then it's a good time to use those as concrete requirements for building a shared service," says Larson.

(Thumbnail photo: IBM Media Relations.)