1

I'm reading a lot about microservices but one thing remains a bit unclear to me.

Let's say in my organization, I have 2 abilities:

  1. Extract street names from one or more blocks of text
  2. Given a context of a website, understand what pages in it will most likely contain street names (a.k.a "important page") according to some company-wide heuristic

Now, my business requirement is given a website, return a list of extracted addresses and for each address whether it's from an "important page" or not.

Ability 1 is purely technical, while ability 2 is somewhere in between technical and business.

While thinking about the architecture of this solution (and others), I'm not sure about what ability stands for itself and how to deal with the dependencies.

Option 1 - Separate services, no gateway

enter image description here

Clients that want to have the streets extracted from a website and know whether the street came from an "important page" or not will need to do 2 requests. Clients that only want to extract streets from text will do 1 request.

Pros:

  • Services don't need to know each other

Cons:

  • Some clients need to perform 2 network calls each time
  • Changes to the services cause changes to all clients

Option 2 - Separate services with a gateway

enter image description here

Pros:

  • Clients always perform only 1 call
  • Changes to the services won't cause changes to the clients (for client 2 can be solved by routing it also through the gateway)

Cons:

  • Gateway layer becomes the "chaos" layer, as each new business requirement or client will cause a new endpoint
  • More network calls in total than other solutions

Option 3 - One technical service, one composite service

enter image description here

Pros:

  • Clients always perform only 1 call

Cons:

  • Composite service totally depends on the streets service

I know that I don't want to adopt any extreme approach - I don't want to limit microservices to one endpoint only, but on the other end I don't want to have microservices with 100 responsibilities.

Where should I draw the line?

Things important to consider:

  • client waits for the response (synchronous)
  • ability 2 might get some additional heuristics and some more requirements in the future, while ability 1 will stay the same. That's the main reason I don't think combining the two abilities into one service will be good (the 2 abilities are owned and planned by different teams).
  • ability 2 may be used by itself in the future, does that change the decision?

Eager to hear your opinions!

Improve this question
2
  • It sounds like you have 2 requirements, extract street addresses and rank pages, correct? Is the idea to rank the pages, then extract street addresses? Or to extract the street addresses, and rank only those pages? At any rate, a page rank service, perhaps with tunable algorithm seems very orthogonal from text extraction (also, seems likely to be tunable). I'd begin with two public calls just because the responsibility of each is so different. How the would be composed would be up to the client. If you already have requirements for the composition, perhaps that could be a third call.
    – Kristian H
    Jul 31, 2018 at 19:14
  • @KristianH So you think the client should do 1 call to each service and then a call a service for combining the results? Isn't that an overkill?
    – ronlut
    Aug 1, 2018 at 13:41

2 Answers 2

Reset to default
0

I think of this issue first in terms of supportable API surface. Do you really need to expose the extract street names service to external callers not under your control? You can, of course, but do you need to? And if you don't need to, does this need to be a whole distinct process, with the extra operational considerations, or can it be a library?

Second, the important pages service is likely a front end onto a batch/job process. It takes time to crawl a site and produce a report, and one has to be cognizant of terms of service, etc. So the API surface is different- submit a request to extract important pages, get updates on progress, cancel, get the report, etc. There may be many libraries or other services consumed by this service, of which the extract street is only one.

So I see this as one client facing aggregate service with a batch/job surface that consumes several internal/library functions/services, the deployment of which is dependent on operational factors.

Improve this answer
6
  • What do you mean by "not under your control"? Currently the street names extraction service is used only internally, not exposed to the world, but it is used by multiple clients written in Java, while our street names service is written in Python. So libraries can't really assist in that case. I can control it by placing a gateway to the addresses service, thus hiding the specific implementation. Will that be better? But then again, I'm cresting more layers and network hops.
    – ronlut
    Jul 31, 2018 at 16:20
  • Regarding second paragraph, calls are performed with website content already present, as we serve an already working pipeline that just needs the street names with acknowledgment of the important pages. I would put the important pages logic as part of the pipeline, but it needs to be used by part of the future clients as well
    – ronlut
    Jul 31, 2018 at 16:27
  • Got it, so it does have customers as an independent service. Do you have a solid understanding of who those customers are and what they use it for? e.g. are you going to subsume any of those higher level functions in your subsequent work?
    – Jonah Benton
    Jul 31, 2018 at 16:28
  • Hmm, additional network calls are unfortunate, but are a necessary part of modern applications. Are there operational or performance reasons specifically to optimize for these?
    – Jonah Benton
    Jul 31, 2018 at 16:33
  • Regarding network, don't have specific reasons, just a common thing in our organization to be afraid of network bandwidth as we are new to the microservices world. Regarding clients, I know exactly who they are and we plan the architecture together, but I didn't get your example about what they use it for. Currently the rest of the work will happen at the client. In the future, we may add more logic to the "important page" service and potentially query more than just the street names service
    – ronlut
    Jul 31, 2018 at 17:03
0

While thinking about the architecture of this solution (and others), I'm not sure about what ability stands for itself and how to deal with the dependencies.

I don't think you will find a hard-objective answer to this. It is already falling into context-opinion territory. MS are not a hard coded law. I don't think anyone here can actually answer, this problem as there is not enough context

It does seems like are your options are well though, so ¯\_(ツ)_/¯ go with whatever makes you more confortable

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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