3 ms·
That’s not quite right, SOA as originally defined had no mapping to team structure or deployment runtime, it was mostly about defining discrete service interfac
by parasubvert 7y ago
That’s not quite right, SOA as originally defined had no mapping to team structure or deployment runtime, it was mostly about defining discrete service interfaces and ensuring your clients used that contract rather than back channels to communicate. Most often you had a dozen services running in a single app server cluster. Conway’s law was rarely discussed (with some exceptions).
Microservices tended towards a single runtime per service, ensuring the deployment lifecycle was tied to the build lifecycle and thus allowing for independent evolution.
- deleted 7y ago[deleted]
- Retric 7y agoI am not saying that’s how SOA was defined, just that it was used to refer to such team organization around architecture. EX: Amazon famously uses a Service-oriented architecture where a service often maps 1:1 with a team of 3 to 10 engineers. https://en.wikipedia.org/wiki/Microservices https://en.wikipedia.org/wiki/Microservices At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.
- parasubvert 7y agoThe general view of microservices was largely invented out of thin air ;) when you look at Martin Fowler’s wiki or Adrian Cockcroft’s presentations which were the originating popularizers of the term , it was all a reasonable refinement of SOA. But then you’d get some that would make bizarre claims like a microservices must be under 100 lines of code. :shrug:
- Retric 7y agoPeople where not pulling that from thin air. Cockroft’s Rule of Thumb Can complete a service in two weeks or less Completed = coded, tested, and in production • Fits in “one or two developers’ heads” At that rate you quickly hit hundreds of services.