Return to Answer

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 (WCP, 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.

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.

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).

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 (WCP, 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.

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 (WCP, 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.

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 it has to have a release process that is orderly and results in high quality builds.

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 (WCP, 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.

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).

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 (WCP, 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.