Perhaps it is easier to understand when you remember that service is not a technical term? People provide service.
In the macro economy, service comes from other companies. If you integrate an LLM into your application, you may use the services of OpenAI. If you integrate payment processing into your application, you may use the services of Stripe. Microservices are just like services, except offered within a micro economy (think a single business).
In other words, it's a team separation technique. You let teams within a business organize as if they were separate businesses and let them offer services to each other as if they were operating different businesses.
How those teams design their software is ultimately irrelevant. The key aspect is keeping active communication between teams to a minimum, using published documentation and API contracts as the mode of communication between teams, just as we do on the macro scale. Getting another team on the phone should be as hard as getting Google on the phone – i.e. basically impossible, but also basically unnecessary.
This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to overcome that. Of course, it serves no purpose in a small company where an economy can't reasonably grow anyway.
With no or minimal communication how is it possible to build anything new? In real world if you need to build something new and it requires 10 different companies to do that, it would be virtually impossible.
A lot of customer value comes from companies that assemble ideas that have existed in isolation. Customers think they hate that, but the numbers say they are wrong.
Foods are an early example. Most are rearranging the same dozen ingredients in different quantities and orders of operation.
Vertical integration is not an all or nothing proposition. Companies can make pretty unique solutions by specializing a couple of pieces.
I think the confusion is because "something new" isn't necessarily a completely new, disconnected product. It could be something like adding multi-lingual support to an existing product. In that case, you often do need to coordinate across many teams to get the new feature implemented, which can be a huge pain in a micro-service architecture.
No more than it is a pain in a service architecture – being the exactly same thing, just in a different economy. As always, if a service doesn't do what you need, you build your own in-house. Just because there is a product on the market is that is kind of, sort of, but not really, what you need doesn't mean you must use it.
> You let teams within a business organize as if they were separate businesses and let them offer services to each other as if they were operating different businesses.
> This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to overcome that.
Microservices do work better in large organisations, but I don't think the boundary should be defined by teams, because large orgs perform re-orgs more often than you'd expect.
It really should be defined by product. When a company is reorganised, then you'd be passing around products and product groups and not individual microservices, to the new teams.
I'm not sure a team is defined by individuals who may come and go. Look at professional sports teams that have been around for a long time. None of the people involved in the team today are the same people who were there in the beginning. The people don't define the team.
I expect you will find that service, product, and team all mean approximately the same thing in this context.
In the macro economy, service comes from other companies. If you integrate an LLM into your application, you may use the services of OpenAI. If you integrate payment processing into your application, you may use the services of Stripe. Microservices are just like services, except offered within a micro economy (think a single business).
In other words, it's a team separation technique. You let teams within a business organize as if they were separate businesses and let them offer services to each other as if they were operating different businesses.
How those teams design their software is ultimately irrelevant. The key aspect is keeping active communication between teams to a minimum, using published documentation and API contracts as the mode of communication between teams, just as we do on the macro scale. Getting another team on the phone should be as hard as getting Google on the phone – i.e. basically impossible, but also basically unnecessary.
This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to overcome that. Of course, it serves no purpose in a small company where an economy can't reasonably grow anyway.