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