Microservices and 3rd party APIs

Question

I recently joined a team who is trying to use "microservice" pattern for their new application. They've already started to implement API's. In the end it should be an API for both mobile and web UI. I have some issues about their implementation.

Things that doesn't make sense to me:

• Every "microservice" is inside one git repository plus one solution file (.sln they're using dotnet).
• Since all microservice intertwined they can't be deployed independently.
• There is "gateway pattern" but gateways are making http calls to other "microservices".
• There is a "common" project (class library) to all requests and responses. (all projects have reference to that project).
• For every 3rd party API they implemented a "microservice" to consume it. (think it like; mobile is making a request to a gateway then gateway proxies that request to a microservice then that microservice is making "actual" http call to 3rd party) this is same for web UI part.

I don't feel that they are doing things in right way, but I don't know where to start. I tried to trace a request but it did not go well. There are tons of boilerplate code in the solution file. The bad thing is, there is a deadline and they don't want to participate for a big refactor.

What should be the next step?
Any pattern to follow for those things?

Maybe microservices are not good for us.

Answer 1

Every "microservice" is inside one git repository plus one solution file (.sln they're using dotnet).

This is fine. In fact I wouldn't do it any other way.

Since all microservice intertwined they can't be deployed independently.

This is a serious architectural mistake and will impact your project agility and uptime. The whole point of separating services is flexibility in deployment. This is probably the one bullet point I would focus on.

There is "gateway pattern" but gateways are making http calls to other "microservices".

I can see why this would seem troubling but it is actually fairly normal. Even though there is an extra hop, on modern hardware this isn't much of an issue if you are keeping these services lightweight, and depending on your security model could actually be rather valuable.

There is a "common" project (class library) to all requests and responses. (all projects have reference to that project).

This could be either good or bad depending on the code management and release model. It's helpful to have a framework, but your release process better be on fleek (orderly and results in high quality builds, and perhaps published as polished packages, e.g. via Nuget).

For every 3rd party API they implemented a "microservice" to consume it. (think it like; mobile is making a request to a gateway then gateway proxies that request to a microservice then that microservice is making "actual" http call to 3rd party) this is same for web UI part.

Seems a little wasteful, but if the third party services all work in different ways (WCF, SOAP, REST, RPC) then it is actually pretty helpful to make them uniform with this sort of facade. This is not a red flag for me.

I think Martin's comment is spot on: Microservices are a complex pattern and it will take a few iterations to get right. These are all fixable.