There no theoretical difference between service over the network and API. Mostly the exchange format used tend to change. But carefully crafted API can be resiliant and backward compatible.
The amount of work to communicate with an API is several order of magnitude easier to code and faster to run. The last point mean that a whole set of programs where performance is a factor may not be able to benefit for some components to be spread over the network.
In particular services spread across farms and network can't afford to be too "chatty". The number of requests must be kept to a reasonable number and not slow down too much the overall process.
API on the contrary can be chatty. Hundred millions of calls literaly can be made in a second and the amount of data exchanged in a second can be in the gigabytes. If it fit the CPU cache, dozens gigabytes.
Services or micro services are tools. As you explained they are not silver bullet. On top of adding yet another level of complexity with exchange format, network errors, making deployment of a new feature spread accross many services much more complex, there are simply not a fit for all problems.
It may be easy to think you can always make smaller lighter services. But when you have already a few thousand ones, a typical cases in many big companies, the best solution to fight complexity isn't necessarilly to make them one or 2 level of magnitude smaller to have one or two level of magnitude more services. It is not easier to manage dozen or hundred thousand services than a few thousands. It may just make your network infrastructure explode and make it nearly impossible to understand how all theses micro services interreact.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There no theoretical difference between service over the network and API. Mostly the exchange format used tend to change. But carefully crafted API can be resiliant and backward compatible.
The amount of work to communicate with an API is several order of magnitude easier to code and faster to run. The last point mean that a whole set of programs where performance is a factor may not be able to benefit for some components to be spread over the network.
In particular services spread across farms and network can't afford to be too "chatty". The number of requests must be kept to a reasonable number and not slow down too much the overall process.
API on the contrary can be chatty. Hundred millions of calls literaly can be made in a second and the amount of data exchanged in a second can be in the gigabytes. If it fit the CPU cache, dozens gigabytes.
Services or micro services are tools. As you explained they are not silver bullet. On top of adding yet another level of complexity with exchange format, network errors, making deployment of a new feature spread accross many services much more complex, there are simply not a fit for all problems.
It may be easy to think you can always make smaller lighter services. But when you have already a few thousand ones, a typical cases in many big companies, the best solution to fight complexity isn't necessarilly to make them one or 2 level of magnitude smaller to have one or two level of magnitude more services. It is not easier to manage dozen or hundred thousand services than a few thousands. It may just make your network infrastructure explode and make it nearly impossible to understand how all theses micro services interreact.