Amazon is often pointed out as a company that got service oriented architecture (SOA) right. Not only did they implement it internally but also created a highly successful platform – Amazon Web Services (AWS) which provides a multitude of cloud services to mostly business customers.
The scale of this, or similar successes, or just the sheer novelty of trends in technology might be used as the motivation for engineering teams to set the goals for adopting similar architectural solutions. There are, however, situations in which SOA might not be the right choice. What might be missing from the picture is the consideration of organizational structures that support such architectures in existing settings and the costs/benefits associated with SOA.
The first can be explained by the often cited Conway’s law which claims that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Amazon and other large technology companies often employ thousands of engineers which makes their internal structure very different from a company with only a couple or several employees dedicated to software development. These differences propagate to the architectural solutions that are implemented by the engineering teams.
Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality, to architecting it, to building it, and operating it.
This is where the cost argument comes in. Establishing ownership can be essential for reliable and high quality software. Ownership, in turn, comes from the ability to allocate resources. The cost of operating service oriented architecture can be generally higher than that of a monolith application as multiple services may require more dedicated resources to build, maintain, and operate.
It might be beneficial to include the structure of the organization and amount of resources available in the software decision making process. Adopting solutions known to work for large technology organizations might not translate to the same commercial success these companies have achieved.