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.
Following this reasoning a similar observation can be made when it comes to the JavaScript front end frameworks. With hundreds or thousands of engineers at hand, it appears again as a natural progression to split the systems into separate components (in this case, front ends and back ends), each of which can be supported by dedicated teams and frameworks. When the resources are restricted, however, a monolithic architecture is often easier to build upon and operate than a combined UI framework and an API framework only if for the fact that there are two separate frameworks to reason about instead of one.
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.
For smaller organizations, choosing SOA or client-side JavaScript framework can be a mistake, leading to longer and costlier development cycles, as compared to a traditional Model View Controller (MVC) architecture, if the business complexity is such that a small team of full-stack (or even semi-specialized) developers can handle the development and maintenance directly. Choosing to employ SOA or JavaScript front end framework is a decision that should not be made lightly. Sometimes traditional MVC is still the right approach.
