Is it advisable to have one microservice per tenant?

Question

I have just a few tenants on my application right now, but the number is going to increase over time. The processing logic for each tenant is slightly different from each other and right now the logic for each tenant is residing in the same microservice.

From a best practice viewpoint, is it a good idea to create an individual microservice for each tenant given that each tenant has different processing logic, and over time with increased number of tenants it might become messy to incorporate multiple tenants in the same microservice?

More update on what my application is doing:

I am aggregating data from users, where different tenants are submitting forms that have different schema. Now, what I want to do is have one microservice per tenant that will convert the data into a common schema on which I'm going to do further processing and push to my DB. Right now, I'm finding a bit too many if else cases with my implementation, thinking if there's a better way to do this.

Answer 1

The idea behind multi-tenancy is that you have a single application that is shared by multiple customers. Having separate services is antithetical to this approach. That doesn't mean that would be a bad idea in some cases, but that wouldn't be multi-tenancy.

So, what do do with customers that need different features? The way you handle that in a multi-tenant environment is to implement the feature for ALL tenants, but also include a per-tenant configuration switch that enables or disables the feature. For example, if two of your customers are Bank of America and the Royal Bank of Scotland, you would avoid writing BoA and RBS-specific services. Instead, you'd build in support for both US and UK currency (along with any other necessary features), and add a column to the tenant table that specifies which one to use. The feature configuration is thus agnostic with respect to customer, but still allows for the flexibility you and your customers need. It's more work, but it allows you to maintain a single code base for everyone, and allows you to expand your services to new tenants without having to deploy or write anything new.

Answer 2

There is no one size fits all answer here.

Right now, I'm finding a bit too many if else cases with my implementation, thinking if there's a better way to do this.

On the spectrum of good to bad for your specific needs, tenanted microservices are on the better end of the spectrum than hardcoded if/else chains, but there are many things inbetween that you have skipped over.

It sounds like you're struggling to properly separate your specific tenant logic, and are trying to put the microservice boundary there to strongly enforce it. That's not necessarily wrong, but it is disproportionate overkill. It's the equivalent of enforcing that you wake up on time on the morning, and getting an industrial fog horn to wake you up.
Just like how much more reasonable alarm clocks exist for a lower price, the same kind of code separation can be achieved with self-discipline and clean coding practices in the same codebase, which costs less overhead than taking the microservice route.

Now, what I want to do is have one microservice per tenant that will convert the data into a common schema on which I'm going to do further processing and push to my DB.

The main issue here, as far as I am concerned, is that you're trying to have multiple microservices access the same database (and by the sound of it, the same tables).

That's a big red flag I suggest staying away from. Either you:

• Commit to the microservice architecture and make a "common schema" microservice, which does the "further processing" and db access, and which all the tenanted microservices rely on; or
• Stay away from microservices and properly separate your code a different way.

The processing logic for each tenant is slightly different from each other

A big question here is how sizeable that logic is. Based on your (admittedly vague) description, it sounds like some minor mapping logic rather than a completely redesigned business layer.

The smaller the size of the changed logic, the less justification there is for hosting separate microservices for this logic.

It doesn't sound like microservices are the right way to go about this. You're not really getting the benefit of independent life cycles since you're relying on a shared database, and shared common schema processing logic.

Instead, I suggest you look are restructuring your codebase in order to cleanly separate the interface (common schema) from the implementations (tenanted logic), so that your distinct implementations can be orchestrated by a specific dependency graph as opposed to if/else chains.

Answer 3

Yes. IF the logic is different and not shared. AND you buy into the micro-service philosophy in general.

Leave the word tenant out of the equation for a bit. You have two separate operations to perform. The alternative to two separate applications would be one application with multiple modules.

Sure you can do it that way, but if you believe in microservices, then you think that the benefits of independent deployment and decoupling are worth the downsides of. I dunno more complex deployments? more code?

Put the word tenant back in and you have similar pluses and minuses. Yes you can add more tenants without touching the others. Potentially you MUST write new apps for new tenants, slowing down your on-boarding. But presumably only tenants which use custom processes rather than your standard one.