Microservices - An API-Led Adaptability

The "micro" modifier was added to the term to indicate that these components only offer services to other components of the same application—if they offered services to multiple applications, they would just be regular services.

Many people have mistaken the term "micro" to mean an indication of size rather than scope, which has led to a lot of discussion about what the ideal size of a microservice is. This is equivalent to discussing the ideal size of a component in general, which is about as useful as discussing the ideal length of a piece of string. By definition, microservices are smaller than the larger application of which they are a component, but other than that their size is not very relevant.

In principle, any network protocol can be used for communication between microservices, but the vast majority use HTTP. Because of this, it is usually correct to mentally substitute "HTTP component" for "microservices" in discussions. If you do this, you’re likely to get better insight into the uses, benefits, and challenges of microservices.

So, at last  I would say that replace microservices with "HTTP component" which is led by the API management. API-led connectivity leads to deal with legacy services as well as collaborate the many microservices via HTTP protocol. So why did we end up with the word microservices? Because these components—like all components—expose some sort of API to one another, they can be viewed as offering services to each other, and so they can be called services. While this is true, it is not their most important characteristic. The fact that they are implementation components is more illuminating and hence it is more than the connectivity and usually will be suitable named as API-led adaptability.

Thanks for the reading my post and your valuable feedback, question, comment or any concern is awaited.

Regards,
Vijay