I have the following application:
This application receives an API call (HTTP), does some internal work that usually includes reading or writing to a database that has 5 different tables, generates an XML file and then sends it to another system via a REST interface. This has around 5K lines of codes.
I'm now studying the microservice architecture and see how my application would/should look like if I was using it. After reading a lot of stuff, I came to two different solutions:
In the first one, each microservice only serve one or a very few HTTP requests. This is good because if one microsevice is down, only a small part of my previous big app is down, but the rest is still working. However, there is a lot of code duplication between each microservice. For example, each of them has more or less the same code to generate an XML template or send request to the southbound system. I know it can be overcome by using a shared library, but then each microservice needs to use the same programming language.
Splitting the part of my app to smaller services. Here, I avoid code duplication and each service can use a different programming language, but if a single microservice is down, everything stops working. Moreover, this looks like a monolithic architecture, because I'm just separating the layer with HTTP request instead of a class/functions interface. It seems maybe a bit easier to understand and maintain, but not really giving anything more.
I would like to have your opinion on my personal use case as I really struggle to understand how an application in a microservice world should be designed without a concrete example.