Thou shalt have only Autonomous Services

Question

One of the tenets of SOA is: "Services Are Autonomous". I have 2 services. Service A depends on Service B. Service A cannot serve clients unless Service B is up and running. Do I violate the tenet here?

Or if autonomous must mean "decoupled", do I satisfy the tenet if I have a failsafe (say another instance of Service B running elsewhere that's connected to if primary instance is down.)? This may satisfy my availability requirements, but I'm not sure how this can reduce my dependency. Yes, the failsafe could even be Service C from a third party and in this case I do improve my autonomy.

Or does the tenet just mean that the services have to be designed as "fifedoms" with well-defined interfaces for getting the data in & out. However, some gurus seem to think that you need to even store this data you receive internally to reduce dependency and maintain your autonomy...

Is it a mistake if I were to treat services as components with messaging? :)

Thoughts?

Answer 1

Your autonomy is only improved by having a back up service. What if both services B and C go down? Then your service goes down. You can improve your autonomy (and your performance) even further by caching results from the external services. That way, if B and C go down, you can still service some of your clients with cached results. As long as you're relying on 3rd party services, though, you'll never achieve 100% autonomy.

Answer 2

See this post on SOA Tenets. Also see The Fractal Constellation of Autonomous Services.

"Services should be deployed, managed and versioned independently of other services and / or applications that depend upon them. "

Autonomy doesn't mean isolated or utterly stand-alone.

Instead, you may have a "constellation" of two services. Yes, they depend on each other. No, A doesn't break when B is moved or upgraded. Nor does A break when B's non-interface internals are changed.

Similarly -- from B's point of view -- and upgrade to A's internals doesn't ripple through to changes in B's interface and internals.

The API's evolve independently. The schema, messages, and implementations are independent. They just happen to refer to each other.

"Service A cannot serve clients unless Service B is up and running" -- don't worry. Service A cannot serve clients if it's down, either. Service down is a problem. Doesn't matter of it's B (on which A depends) or A. The dependency has nothing to do with A or B being reliable or available.

Yes, services have well-defined and independent interfaces. The implementation of A depends on B, but the interface does not.

---

Edit.

"some gurus seem to think that you need to even store this data you receive internally to reduce dependency and maintain your autonomy..."

Can't see the point. If A depends on B, and B's algorithm changes, A's copy of B's data is -- well -- old. Depends-on usually means a live, working, up-to-the-transaction relationship.

The problem is that B may be slow, which makes A slow, which makes the application that uses A slow. That's a bummer. But that's no call for breaking the autonomy rules and having A keep a secret cache of old data from B.