CODEWITHSUNDEEP
architecturemicroservices
Russell Durham
Russell Durham

Reputation: 624

Mixing Communication Methods in Microservices

So I'm struggling with a few concepts regarding microservices and communication between then. While I'm not expecting a tech specific answer I am working with asp.net core web api if that helps to answer my question.

Scenario

My resource is a widget. This widget can be updated in one of two ways:

  1. By the user through the UI
  2. Through external event (message published to a bus)

Assumptions

Based on various articles, blogs, etc I'm also working under following assumptions:

  1. Microservices should own their data. So in this case, I should only have one microservice that owns the widget resource
  2. The direct update by the user represents a request/response communication so REST is recommended
  3. The event message suggests that I should also be connecting to a queue and processing messages from the bus
  4. Message consumers are better run as a service than inside something like a web project hosted in IIS

Question(s)

So based on everything mentioned I thought about creating an ASP.NET Core project that runs as a windows service. I know there are some recent changes in .net core 2.1 that make this even easier.

This is in contrast to just creating 2 services one to handle the rest calls and one to consume the bus messages which seems to go against my first assumption as well as just being more difficult to maintain in the long run.

So my questions are

  1. Are my assumptions valid?
  2. Is mixing communication methods within the service like this a good idea or should I create the two services (one for each communication type)?
  3. Is there another way to approach this that is more in line with the ideology behind Microservices?
  4. If I were to do this in node, would the approach be similar as far as having node handle both messages from a bus as well as incoming REST calls?

Upvotes: 1

Views: 436

Answers (1)

usr
usr

Reputation: 171178

Remember why you are using microservices. Using them is not a goal on its own. They are a tool to achieve certain ends such as enforced modularization, independent deployment and more parallel development.

There is no general guidance possible to their size. Making them as small as possible is a non-goal. Rather, find the right size. Not the smallest size possible.

It therefore seems dubious to split the direct and asynchronous data updates into two services. There is simply no driving need.

Since microservices should own their data it is natural to have both these concerns governed by a single microservice operating on that data.

Also, it is a non-goal to avoid mixing communication methods.

Message consumers are better run as a service than inside something like a web project hosted in IIS

That is not technically true. For redundancy you need multiple consumers running on each queue. You can never rely on there being a single consumer or there being always at least one consumer. Therefore, a windows service gains you nothing. Doing this from inside a normal web application is not problematic in my view. It also potentially saves you the need for a windows service. They are hard to work with (deployment is a bit nasty).

It feels to me you are overcomplicating things in order to meet certain abstract guidances. Do not architect based on such blanket guidance. Architect with regard to the specific case.

From what I have heard all you need is a single IIS hosted ASP.NET web application that does all of this including the data processing. But if you feel the need to introduce a service then you could consider splitting the data processing off into another ASP.NET web application which offers a service to the UI application. This service would include methods to retrieve and alter data as well as some kind of notification for asynchronous updates (like an event but across a service boundary).

Upvotes: 2

Related Questions