0

I am having trouble understanding if a microservice can contain multiple applications.

Looking at Microsoft's example, the Ordering Microservice contains 2 applications.

  1. The API
  2. Background tasks Example

Looking at blog posts and other posts on this site, it seems that having multiple applications interacting with the same database is incorrect, however, I can understand that it can be useful.

Let's take an example I am thinking of implementing for my work where we read emails and each attachment needs to be processed differently:

  1. Read emails from an inbox
  2. Save email attachments to a database for processing
  3. Publish "X" attachment received event
  4. "X" attachment service process the attachment and marks the attachment as processed. This would violate the single per service because all of the "Attachment Services" would be interacting with the same database. Is this ok because its working within the same domain? MyImage
1
  • If they are using the same database then they are the same microservice
    – user253751
    Jun 30, 2020 at 17:56

2 Answers 2

3

To answer your question, "can microservices contain multiple apps", I think it would be better to explain some concepts here. First, there really is no agreement on how "micro" a microservice is, or even on the best way to break down an app into separate domains that work well together. Also what is often glossed over is the complexity of managing a microservices architecture.

All that said, Microservices enable the following:

  • Pushing out updates for different areas of the app on independent schedules.
  • Scaling the application in smaller groups, potentially allowing for less compute resources to serve surge traffic
  • Isolation between domains so they can evolve independently

What you see in Microsoft diagram:

  • Far left: applications. Phone apps, Single Page Apps, etc.
  • Middle: gateways. They provide load-balancing and direct traffic to the different services
  • Right: microservices. Here is where things don't necessarily align with most people's understanding:
    • The services include their own data stores (this is definitely preferred, but usually not where most people start)
    • Microsoft is calling the whole domain the microservice, where most people would call each little box the microserivce.
  • Far right: messaging. Many times the services need to keep certain information in sync, but having a chain of REST calls doesn't scale well. The message bus allows that synchronization to happen in the background.

In many microservice based infrastructures, there will be some variation on this approach. Although you may find that the tools and techniques are a bit different, the pieces that make up the whole are similar enough.

The major point of confusion is around how we count the microservices. It seems that Microsoft is counting teams, while most people count deployable units. That's where the confusion lies.

  • Counting Microsoft's way, there are 6 microservices that contain all the deployable units for those services.
  • Counting the layman's way, there are 4 gateways, 7 microservices, and 7 data stores

Both views are correct, but emphasize different things

Microservices work best when you have full automation, so that any commit to your repository will end with a deployment to a live area (most likely a staging or testing aria). Once the changes are vetted, it can be pushed live. It also works best if you can have a whole team around each functional area (domain, etc). That maps well with how Microsoft is counting their microservices. However, the operational overhead increases with each deployable unit. So when considering the impact of managing the whole infrastructure, your Ordering team has more to worry about than the other teams.

I wish life matched ideals, as you'll find that small teams will have to work on multiple microservices. That is until you can bring in enough revenue to support the ideal.

1

I don't specifically know what Micrisoft intented but here is a reasonable guess of mine.

The goal of a microservices is not to be as small as technically possible. It is to be cut down a classic monolitic architecture in smaller set or microservices. If possible one functionnality = one microservices. This make the maintenance and upgrade of the said functionnality easier (provided you have retro compatibility if you can't afford downtime on your whole system).

Here you have one functionnality : ordering. This microservice is split into not two but three "technical" part :

  • one that receive orders.
  • another that will do some jobs in background. This is probably based on what the first wrote in the database in previous operations.
  • The database which is also an "app" on his own.

The both of them constitute the full fonctionnality to manage orders.

On some documents i once saw the word service defined for each possible operation :

  • service create
  • service delete ....

This kind of stuff if put in different microservice will basically bloat the number of microservices you have to manage. And this will make upgrading without interruption harder. This is why you always need to be wary of how people use the word "Service" when talking to you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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