I have had this itch to investigate the pros and cons of service oriented architecture (SOA) and its derivatives (ROA, WOA, etc) for many years but never really cared enough to do it. Usually because many of the projects I built didn’t use it or the decision had been made a long time ago and it was pretty much irreversible at that point.
My experience with SOA systems has been at medium/large sized companies and generally I found that it worked sufficiently well for them. However SOA didn’t seem like a vastly superior solution relative to the architectural patterns I had been exposed to over time. SOA just had a different set of trade offs that really just made it feel like a different tool in the tool box.
Now, I deliberately try to avoid religious wars with tools and somewhere in my mid 20s I stopped caring about what they did in “theory” as well. I care much more as a technically competent entrepreneur about what actually happens when you implement a solution across all of the business and not just the problem at hand (think hiring, execution risk, business flexibility, time to develop, etc).
Now, with my history and viewpoint clearly established i’ll jump into my analysis.
Given my experience at medium/large companies where SOA is used internally to power the product here are the complaints of SOA that I have heard/experienced:
- Services are only as good as the best architect on that service team.
- Its expensive to move engineers from team to team because each service completely different.
- If a service has a bug you have to wait for the service team to fix it.
- It is incredibly hard to test changes across multiple services.
- With each incremental service you add your client requires more integration code (different payloads, protocols, errors etc).
- When a service introduces breaking changes to an interface it is hard to find who all the clients are and just how big of an impact those changes will have downstream.
- When there are a nontrivial number of services its difficult to find what services exist and what functionality they expose.
Now let’s go over how SOA is meaningfully different from the traditional object oriented architecture (OOA).
- You have the flexibility to use different everything in SOA (languages, libraries, operating systems, protocols, web servers, testing tools, etc) per service where as in traditional OOA you typically stay in one language have a list of common dependencies, on a single stack.
- You usually have stateless communication between components where as in OOA you implicitly have stateful communication with pass by reference mechanics.
- With SOA everything that is exposed publicly is done intentionally and its harder for “client” engineers to break service abstractions although that doesn’t stop the “owner” engineers from doing it on occasion.
- In theory you get to deploy your service independently of others (until you make changes that break other clients, which happens frequently enough in practice for me to mention it here)
- Strict permission control over code bases if you have contractors etc.
With these differences SOA has the following advantages over OOA in my mind:
- You can adopt new technologies independently from the rest of the org.
- Monkey patching, accessing private methods, or otherwise inserting hacks into code you don’t really own is harder to do.
- Prevents code commit conflicts and enforces ownership contracts.
- With stateless communication implementation *can* be simpler, it certainly makes threading easier.
Here is my list of disadvantages of SOA vs OOA:
- Its much more complex and therefore slower to execute initially.
- You typically need more engineers for the same amount of work.
- You need sr engineers and architects proportional to # of services.
- It requires tooling for service discovery, registration and testing.
- Moving engineering resources has larger fixed costs.
- Cross service development requires more coordination.
- Without solid architects there is significant execution risk.
I think SOA is really appropriate for large teams working on complex systems at medium/large profitable “cool tech” companies where the costs can be amortized over a longer time periods with great engineers without threatening the success of the business. I also think SOA is appropriate for communication between companies where each company is a service. At that level you really don’t lose much because few of the OOA benefits are applicable.
If SOA matches your company’s profile then i highly recommend taking a look at this: http://www.infoq.com/presentations/twitter-soa.
If your company doesn’t match the criteria above then I think OOA is probably right for you. It is faster to start, easier to understand, more flexible from an engineering management perspective, and allows you to move much faster with smaller teams. I would also say that even if you are planning on being a huge successful company with 100s of engineers its not worth investing in SOA until you actually feeling the pain of your immense success.
Small aside: SOA’s tradeoffs actually remind me a bit of database sharding but for engineering teams.
(Lead Image source: https://tech.bellycard.com/blog/migrating-to-a-service-oriented-architecture-soa/)