0

I am currently working on redesigning a microservice application. Our application is supposed to serve multiple clients and due to compliance we have to persist the data in separate datastores.

We have isolated the services to be deployed for each client. there are some functionalities that are common for all the clients and some more specific to each one.

How would i go about deciding how to design this behaviour,

  • have separate services based on functionality for all the clients, so if there are 5 services, they will be replicated for each client.
  • Or for the common functionalities among them, have a common service, which have access to all the datasources of the client, and just replicate the custom behaviours for each client, e.g 2 out of 5 are common, so only the 3 services will be replicated for each client.

How can i decide on such a decision, if anybody can give his input or point in a direction where i can reach my answer, it would be greatly appreciated.

2
  • What's the situation on per-tenant scalability? (or, in a similar vein, per-tenant rate limiting)
    – Flater
    Feb 4, 2022 at 15:03
  • Please clarify your isolation requirements. It seems to apply to data at rest. What about compute? Are you allowed to use the same compute node for multiple clients? Network? Mar 7, 2022 at 0:50

2 Answers 2

1

If you have requirements to keep data separate there are no common services. Common services are just great targets for exploit, they just increase risk and don't actually make thing easier for you. With a common service any compromised client now can potentially compromise all your clients (or you can accidentally expose one client to another's data). In addition to the security risk, any downtime on a common service affects all clients, so no you have more angry people calling or insane scheduling hurdles for planned maintenance. It's also likely that all clients will want different upgrade tempos, so it's possible you need to run multiple versions of common clients anyway because some are 2.0 and some are 1.0 and you now have tons of complexity.

If you have requirements to isolate something than everything that uses it needs to be isolated. It's better to think of however many microservices an app needs as a single unit in these cases. With cloud or virtual machines it's really not that different to deploy 15 services or 11 based on your examples. Cost shouldn't be dramatically different either as you should be able to downsize common services as they would get 1/3 of the traffic, and the expense of a potential breach of contract will absolutely exceed hosting costs.

4
  • So, if there's a common operation for all clients, such as a crud operation which is common for all the clients(does exactly the same thing but on different datasource), its better to have an independent service for each of the client ?
    – Imran
    Feb 4, 2022 at 14:10
  • yes because if something can create or read to any database, you are a hack or bug away from company 1 getting company 2 data. the only acceptable exception would probably be an identity management platform.
    – Ryathal
    Feb 4, 2022 at 14:58
  • just to understand further, if there are security mechanisms in place, such as restricting the user input of a client and further validations before actual operation is performed on the data, still this would be a something that leads to problem down the line ?
    – Imran
    Feb 4, 2022 at 16:49
  • 1
    Ryathal is explaining that software is made of bugs. There's some correct code in there, as well, but also bugs. And the software you're going to make? That's right, you're going to make it out of bugs, plus some correct code. There will be an exploitable hole in it. Not a matter of if but of when. So plan for that. Use the isolation tools at your disposal.
    – J_H
    Mar 2, 2023 at 0:41
0

It all depends.

The datastore is by itself an infrastructure property. So in case the only difference is a datastore than you can spin off many replicas of your application and connect them accordingly to the proper datastore.

When there are particular differences per customer, what you want to in reality, is to define the service's capability.

Microservices are not about building small apps but to encapsulate capabilities. The common service is definately antipattern in microservice world. What you actually want is to define what is the responsibility of your service.

But the same service can serve many microservices. So if the service's responsibility is to e.g calculate proper tax for the product than both billing service can use it as well as the service to prapere the offer of a product.

It is also really common to create facade services which orchestrate communication between all low level services and act more use case centric rather than capability oriented.

So you end up with the facade which serves e.g. as a shop and calls underneath all the microservices to serve its use case. It stores the data related to its use case on its own.

On the other hand if the facade service is not the only service which stores the data than you need to confront this requirement with the customer - in most cases not all the data needs to be separate (but it depends).

The key here is to understand your context and scenario:

  • if the same functionality is copied in the code of many applications with tiny changes per customer you may end up with very hard to maintain environment
  • if you share capabilities by encapsulating them in separate service than it allows you to limit the changes in one context to that service and build knowledge and the team around this service
  • if you can share environment but need separate storage you can parametrize your applications (infrastructure complexity grows)
  • if you want total separation you may think about separate environments (infrastructure complexity doubled)

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.