I've been reading about the Microservice Architecure and with the limited valuable information available on internet, I believe, I have a fair understanding of it from the theory point of view. I understand that on a high level this architecture suggests to move away from monoliths and have small, independent services. However, all the examples that I see on the internet are suggesting to write loosely coupled windows services (daemons in case of non MS implementations) connected to an ESB. I understand that writing small, loosely coupled web services that adhere to SRP also fits the bill of micro services.
That said, oData.Net services, where all oData controllers (micro services?) are deployed as a monolith, is a clear violation of the Microservices Architecure pattern. Is it a correct statement to make that oData.net is not designed to work as micro services? If your answer is no then please explain with help of a an example. Also, help me understand, how to have the API gateway pattern in the mix.
ODATA do fit micro services. However, micro services are not a good fit for odata. What I mean is that there is really nothing that stops you from exposing OData in a micro service.
However, by doing so you typically expose a large set of the inner data structure in the micro service. That would in turn increase the coupling between different services. By doing so, you make it harder to change a service due to dependencies.
My own personal rule of thumb is to expose as small API as possible from each service. And the data structures that I expose are not the same as the internal ones. They might be flattened or a union between data in different internal entities.
My reasoning is: If you are going to create separate services, try to separate them as much as possible. Else you are just building a monolith that happens to run in a couple of different windows services.