Service oriented architecture

A service oriented architecture (SOA) is one where we bias our engineering practices around the primitive abstraction where logical components are networked programs. This is an important distinction from a distributed system which is concrete, or at least some tangible code artifact. SOA is a lens of thinking about problems, ideally a simplification of underlying complexity.

Our ability to abstract is very important. We no longer articulate complex business logic using assembly/low-level hardware instructions. We now use a wide spectrum of much higher level languages to express our intent. However some abstractions become too great to bear because what the components they are underpinned by are often too complex to be casually ignored in practice. We call this a "leaky abstraction." The abstraction is a bucket encapsulating its contents but not well enough.

SOA is a tricky way of thinking because fundamentally we must consider the network in addition to solving the problem at hand if all we have to reason with is networked programs. Networks are incredibly complicated in the simplest sense that they can cease to be interconnected for a multitude of reasons. Programs need to account for this complexity, through error handling, redundancy, etc.

The network is an inescapable concern. More nuanced discussion of SOA is more often framed around where we place the handling of this additional complexity, traded in turn for the benefits of SOA. For example, you made adopt a company-wide tech stack & framework in which all new software fits. This enables a smaller portion of "core" developers to solve the network problems for all other developers.

The complexity pervades but it's not everyone's problem, is the claim. In practice, no single organizational unit of any size can take full responsibility for the network. The network is a concern distributed amongst all developers working on a system. It cannot be boiled away such that all engineers need not think about it when designing programs. Failure modes and certainly latency requirements must be accounted for, unless those things don't matter to the software at hand which is fleetingly rare.

The level of abstraction SOA suggests we frame engineering practice is rather troublesome. It is not precise enough for proper system design.