1

We have two services. However, in the past, these two services were one service, but have been split due to differing traffic requirements.

The services are consumed by two kinds of clients; other services and UI clients (web, desktop and mobile).

Consumers of service 1: Services,

  1. Use a very limited number of exposed endpoints (addInput, removeInput).
  2. Generates high traffic.

Consumers of service 2: UI clients,

  1. Using a large number of exposed endpoints
  2. Generating less traffic.

Currently, they are sharing code but as far as I can figure out micro-services should not share base code. Therefore we believe something is wrong using this approach.

what are the key issues to understand in order to solve this kind of micro-services architecture issues?

tom redfern
  • 30,562
  • 14
  • 91
  • 126
Jordi
  • 20,868
  • 39
  • 149
  • 333
  • How is the code shared? Are you using something like npm or maven? Or are you just sharing binaries manually? – tom redfern Jul 24 '17 at 09:28
  • Currently, we're mainting a domain-like library in order to get access (read-write) to a shared database. Both services should (or not) share this library – Jordi Jul 24 '17 at 09:33
  • This may very well be a duplicate question of https://stackoverflow.com/questions/35465175/microservice-architecture-questions-about-code-resue-security-and-database-shar or https://stackoverflow.com/questions/25600580/sharing-code-and-schema-between-microservices – tom redfern Jul 24 '17 at 09:36
  • 1
    Personally, I don't think it's a problem to share domain libraries as long as both services belong to the same business domain. You definitely want to avoid sharing outside the domain, however. – tom redfern Jul 24 '17 at 09:39
  • Yes, services belong to the same business domain, however, this shared domain library contains persistence code currently, should this code be replaced? – Jordi Jul 24 '17 at 09:52
  • Yes, if anything needs to be split out, it's the code which deals with the actual storage mechanism, which is an infrastructure concern. – tom redfern Jul 24 '17 at 09:56
  • Mmm... if storage concerns should be split out, I don't quite figure out why should I mantain a domain-lib only with domain entity definitions... – Jordi Jul 24 '17 at 09:59
  • Sorry I don't mean splitting the storage concern by service, but into a library separate from the domain library. – tom redfern Jul 24 '17 at 10:10

1 Answers1

1

What do you mean Microservices shouldn't share code. Will you deliberately go and search for 2 different TCP stacks ? If you wrote one in Java do you have to write the other in Go?

Services can share code and it doesn't matter if that is 3rd party code or 1st party code. What you don't want to do, as you do in other aspects of the services, is ensure autonomy. Autonomy is what gives you flexibility to change. In terms of shared code, autonomy means that if you updated a shared component, say the bit that handles authorization you don't automatically need to update that in the other service(s) .

Also as time passes and needs change- the services will evolve. As need change they may diverge in the code they use and maybe you'd be able to still reuse bits. Just note that reuse and shared code is not an end in itself and you'd be fine

Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68