I have a service which is composed of various independent small "blocks" of logical code. A block stands for a class which implements an interface "IBlock" which includes an "Execute" function that gets a BlockRequest parameter and returns a BlockResponse parameter. Each logical block usually does the following: Get some data from a DB, Make an API call, Any specific simple logic over the data, Return a normalized response.

The purpose of this service is to serve an external orchestrator (different service) by executing blocks dynamically according to request. The service is unaware of any business flow, and only knows to execute a specific block on demand. Basically the service is some kind of repository of independent logical blocks.

The service receives request messages via queue, runs some logic according to the request (a specific block) and return an answer by publishing a response message to a different queue.

Outside of executing blocks, the service itself is quite lean and holds little logic - mostly validating the request, logging, writing to DB and publishing back a response. However, there are many "logical blocks" and the number will only increase as we keep using this service.

I will eventually have too many logical blocks which will be hard to maintain and every time a small piece of logic in the form of a new block will be added - Meaning adding another class to the solution -
I will need to test the entire service and deploy all of it again to support the new block or a minor change

Separating the blocks into different services could help as it would allow us to deploy and maintain each block separately, but eventually this would mean a lot of services which would also be tough to maintain and keep track of - making this a lacking solution.

Is there any middle ground pattern\technology\design that could help me build this service properly?

  • 7
    How to do good and reasonable decomposition and abstraction is core question of whole Software Engineering discipline. It is such a huge topic that I cannot see anyone answering this question without writing few books in the process. – Euphoric Dec 5 '19 at 7:54
  • Can your blocks be separated by any logical criteria with minimal overlap? – ZektorH Dec 5 '19 at 8:50
  • 2
    "A block of code that takes a request and returns a response" describes pretty much every computer program, and doesn't seem like a particularly useful interface. Is there a reason you are trying to bundle all of these into a single service? Could they be embedded directly in the external orchestrator? – casablanca Dec 5 '19 at 9:09
  • Basically the external orchestrator is designed to manage the execution of an entire business flow which is composed of various blocks. It knows the order in which they should be executed, whether they should run sequentially or parallelly and if a block is mandatory for a flow completion. It's purpose is to execute these blocks and know when the entire flow is completed. We separated the logical blocks to a different service as they are quite small (but plenty) and this way we could also scale the service to improve performance of the logical blocks – Nir Mochiach Dec 5 '19 at 9:31

Let’s kill a myth: the fact that a block is independent does not justify by itself a microservice.

There is a balance to be found:

  • between the advantage of having independently deployable microservices and the inconvenience of the increased complexity;
  • between the maintenance benefit and the performance overhead of inter-service communication.

The second point is not of your concern, because your orchestration architecture requires the inter-service communication anyway.

The first point remains open for discussion. In view of the many misunderstandings about the desirable granularity of microservices, Chris Richardson, the microservice guru in chief just released a new rule of thumb:

A team should ideally own just one service since that’s sufficient to ensure team autonomy and loose coupling and each additional service adds complexity and overhead. A team should only deploy its code as multiple services if it solves a tangible problem (...)

I do not have sufficient elements to advise, but ask yourself what your goal is, and if releasing each “block” independently would really be a benefit.

For example would your independent block rely on some shared code ? How often does that code change and how will you cope with such changes in the future ? Or could there be some hidden coupling because of expectations about the data exchanged in the requests ?

As an alternative, have you considered a service that offers all the blocks ? You could still achieve the horizontal scalability by having several running occurrences of your coarser grained service.

Now, if after having challenged your own ideas you conclude that microservices would be the right solution, go for it :-)

  • Thanks for the answer! What we currently have is a service that offers all of the blocks. As stated in my question, this situation means that every time we add a new block or change an existing block - we need to test the entire service and deploy all of it. We want the option to deploy blocks independently, however there is no justification to create a service for each block. Is there any option in between that is possible? I've heard of serverless functions. It sounds like it might fit this scenario and I could explore it further. Are there any other options available? Pattern or technology – Nir Mochiach Dec 5 '19 at 13:45
  • @NirMochiach serverless could be an option if each of your block is self standing and is not relying on user-input or other sources as the request transferred by the orchestrator. I you want to deploy independently because of operational reasons, ms may be the answer. But if it’s for testing reasons, can’t you just rely on a battery of automated tests ? In so-far more that your different services are independent (i.e. change on one should not affect the others, in principle) ? – Christophe Dec 5 '19 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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