4 ms·

In my experience, microservices grew to prominence not because of their technical merit, but because it allowed engineering "leadership" to not have to make dec

by dpeck 6y ago

In my experience, microservices grew to prominence not because of their technical merit, but because it allowed engineering "leadership" to not have to make decisions. Every developer or group of developers could create their own fiefdoms and management didn't have to worry about fostering consensus or team efforts, all that had to be agreed on was service contracts. We end up with way too many developers on a given product, an explosion of systems that are only the least bit architected, but thankfully the vp of engineering didn't have to worry themselves with actually understanding anything about the technology and could do the bare minimum of people management. Individual minor wins, collectively massive loss. * there are reasons for microservices at big scales, if everyone is still fitting in the same room/auditorium for an all-hands I would seriously doubt that they're needed.

riffraff 6y ago
That is the classic Conway's law that system design follows an organisation's communication structure. I would argue it's not a bad thing per se: reducing coordination can speed up some processes and reduce overhead. But I agree there is a threshold below which it doesn't make much sense.
rowanG077 6y ago
You make it sound like having separate teams is bad. It's the best. The larger the team the slower it moves.
pjmlp 6y ago
And the worse it that it just gets rebooted every couple of years. Anyone doing distributed computing long enough has been at this via SUN RPC, CORBA, DCOM, XML RPC, SOAP, REST, gRPC, <place your favourite on year XYZW>.
- peterwwillis 6y ago
  Some more hits and misses: ONC-RPC, DCE/RPC, JRMI, MSRPC, RPC over HTTP, MAPI over HTTP, JSON-RPC, JSON-WSP, WAMP, M-RPC, MTProto, ICE, Cap'n Proto, PRyC, DRb, AMF, RFC, D-Bus, Thrift, Avro, GWT
  - pjmlp 6y ago
    Yeah, I was being generous by not listing everything. :) Thanks for completing the list.
  - p_l 6y ago
    <pedant>ONC-RPC and DCE/RPC and MSRPC and JRMI are dupes</pedant> ;) That said, I recently ended up looking at the code so far and thinking "I should have used CORBA". And nothing so far managed to dissuade that thought...

by dpeck 6y ago

riffraff 6y ago

That is the classic Conway's law that system design follows an organisation's communication structure. I would argue it's not a bad thing per se: reducing coordination can speed up some processes and reduce overhead. But I agree there is a threshold below which it doesn't make much sense.

rowanG077 6y ago

You make it sound like having separate teams is bad. It's the best. The larger the team the slower it moves.

pjmlp 6y ago

And the worse it that it just gets rebooted every couple of years. Anyone doing distributed computing long enough has been at this via SUN RPC, CORBA, DCOM, XML RPC, SOAP, REST, gRPC, <place your favourite on year XYZW>.

peterwwillis 6y ago
Some more hits and misses: ONC-RPC, DCE/RPC, JRMI, MSRPC, RPC over HTTP, MAPI over HTTP, JSON-RPC, JSON-WSP, WAMP, M-RPC, MTProto, ICE, Cap'n Proto, PRyC, DRb, AMF, RFC, D-Bus, Thrift, Avro, GWT
- pjmlp 6y ago
  Yeah, I was being generous by not listing everything. :) Thanks for completing the list.
- p_l 6y ago
  <pedant>ONC-RPC and DCE/RPC and MSRPC and JRMI are dupes</pedant> ;) That said, I recently ended up looking at the code so far and thinking "I should have used CORBA". And nothing so far managed to dissuade that thought...