4 ms·

I'm not sure I'd call it microservices, since they could be monolithic inside each organization, but I had the same thought. Just spend the time to agree on a s

I'm not sure I'd call it microservices, since they could be monolithic inside each organization, but I had the same thought. Just spend the time to agree on a standardized API that everyone can support, and then the central API just proxies to the appropriate subsidiary. I wonder why they haven't done it that way.

ThePadawan 7y ago
Personal experience from a past job: Coming from a clunky, overused but underdesigned monolithic structure, the work to standardize inter-team/inter-department communication is really hard. In general, the easiest thing is to overspecify those APIs and fight anyone who wants to simplify them. Complicated work looks good on a CV, after all. So now you have hard-to-implement, full-of-cruft API designs. At that point, teams realize that the easiest thing is to work around them. And off you go into splintered components which ignore the standard APIs as much as possible. Turns out that's much easier, and you deliver results with higher velocity! From far enough away, you can just see "more standard APIs => higher velocity", so obviously you keep doing that, right?
- huffmsa 7y ago
  Developers and product people have a hard time apply the idea of only building the simplest, most minimal "thing" the consumer needs first and gradually iterating it when the developers and other internal personnel are the consumer. An internal API is just as much a revenue driving product as an external one.
JamesBarney 7y ago
I'm honestly not sure where mini-services, micro-services, nano-services, and service oriented architecture begin or end relative to each other. So a micro service is 2 pizzas. Maybe for just a plain service you can have up to a a pizza party's worth of people. But you can only have up to 10 nano services per sandwich before they become pico-services?
pjc50 7y ago
What might be easiest is "federated" or "decentralised" - since coordination is prohibitively difficult here, build a set of pieces independently. The truth is that they behave as separate companies in a Coase theory-of-the-firm sense. So treat them that way from an IT perspective.

ThePadawan 7y ago

Personal experience from a past job: Coming from a clunky, overused but underdesigned monolithic structure, the work to standardize inter-team/inter-department communication is really hard. In general, the easiest thing is to overspecify those APIs and fight anyone who wants to simplify them. Complicated work looks good on a CV, after all. So now you have hard-to-implement, full-of-cruft API designs. At that point, teams realize that the easiest thing is to work around them. And off you go into splintered components which ignore the standard APIs as much as possible. Turns out that's much easier, and you deliver results with higher velocity! From far enough away, you can just see "more standard APIs => higher velocity", so obviously you keep doing that, right?

huffmsa 7y ago
Developers and product people have a hard time apply the idea of only building the simplest, most minimal "thing" the consumer needs first and gradually iterating it when the developers and other internal personnel are the consumer. An internal API is just as much a revenue driving product as an external one.

JamesBarney 7y ago

I'm honestly not sure where mini-services, micro-services, nano-services, and service oriented architecture begin or end relative to each other. So a micro service is 2 pizzas. Maybe for just a plain service you can have up to a a pizza party's worth of people. But you can only have up to 10 nano services per sandwich before they become pico-services?

pjc50 7y ago

What might be easiest is "federated" or "decentralised" - since coordination is prohibitively difficult here, build a set of pieces independently. The truth is that they behave as separate companies in a Coase theory-of-the-firm sense. So treat them that way from an IT perspective.