When not to build a service-oriented architecture

Talk given at NY CTO Summit 2014.

Transcript

1. When not to build an SOA Lee Edwards totally not representing Groupon or SideTour @terronk
2. When to build an SOA • Huge team size or code base • Specific scaling requirements • API-driven business
3. When not to build an SOA • Literally every other time
4. SOA has real benefits •Removal of harmful dependencies •Service reuse •Independent deployability •Independent scalability •Parallelized Development! •Bragging rights
5. SOA has real drawbacks
6. Serialized development
7. Losing engineers to the pan • Architecture • logical • physical • Tooling • deploy • routing • API • Documentation
8. Logical architecture Product Page UI Widgets Inventory API Checkout Orders Redemption Merchandise Fulfillment
9. Communication structure Product Page UI Widgets Inventory API Checkout Orders Redemption Merchandise Fulfillment
10. Jeff Bezos 2002 E-mail 1. All teams will henceforth expose their data and functionality through service interfaces. 2. Teams must communicate with each other through these interfaces. 3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. 5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6. Anyone who doesn’t do this will be fired. 7. Thank you; have a nice day!
11. Conway’s Law “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
12. A Corollary to Conway’s Law Organizations which design systems are fated to copy the communication structure of the system
13. Communication Band-Aids • Architecture teams/committees/boards • Time spent on service documentation • Status updates with other teams • Larger meetings • Project managers
14. Do any of these seem like good ideas in any other environment?
15. Things you need to build a good SOA • Time to build tooling • A large, highly-experienced engineering team • The ability to say no to new features as you develop a robust, well-engineered platform
16. Things you don’t have as an early startup • Time to build tooling • A large, highly-experienced engineering team • The ability to say no to new features as you develop a robust, well-engineered platform
17. SOA is Batman The architecture you deserve, but
 not the one you need right now.