1

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.

5
  • I feel like I have to calm you down a little bit. Microservices are a complex pattern and it will take a few iterations to get right. We can't go from zero to ideal solution in one iteration. These are all fixable. – Martin K Jan 27 '20 at 20:30
  • What is your motivation ? – Cap Barracudas Jan 27 '20 at 21:01
  • @MartinK i did not say it is easy. I believe there are good ways of doing something but i think we are on the wrong way. – afrikaan Jan 28 '20 at 4:49
  • @CapBaracudas my motivation is to understand if microservices and all kind of stuff (kubernetes etc.) is really needed. If so is this the right way of doing this ? – afrikaan Jan 28 '20 at 4:51
  • ask a question on Reddit, it is better. – danilo Jan 30 '20 at 1:43
8

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.

3
  • +1 agree to most everything here. Great write up! – Caleb Jan 31 '20 at 5:19
  • 1
    Depending on what code actually lives in that "common" project, the benefits of having it pulled out vastly outweigh the risks. Think of all the things you have consumed as NuGet packages before. Imagine the hassle if that code was implemented in every single service instead of a shared package? What I would recommend here is that the "common" project should be used/treated exactly as a "company private" NuGet package. Share it the same way you share 3rd party code, because to your individual services it should be treated as 3rd party library. – Caleb Jan 31 '20 at 5:26
  • 1
    @Caleb Yeah, I think you are right... can't get very far without some kind of library. I think I was spooked by the OP's first bullet. I've revised my answer. – John Wu Jan 31 '20 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.