7

I was wondering - too many microservices usually cause testing and devops overheads + it makes the system more complex.

My service is something that handles a large load (from a data stream). It needs some database data from time to time.

There will be also a seperated process that needs to keep feeding the database with data from external source.

I initially thought of 3 services:

  • The service that manipulates and handles the data
  • Service that feeds the database
  • REST API service that will be used also as internal but also as external (eventually for UI), and internally for requests from the services.

I have several cases i'm considering:

  • I've read that a CRUD service is an anti-pattern - so i'm not sure about #3.
  • The first manipulation service needs a special scale algorithm, and the REST API that will be used externally also, requires totally different scale (much lower)
  • Service #1 and #2 actually share the database (or use the REST API) (though they are in the same domain) - it sounds like it's an anti pattern.

My main question is - Should i combine some of the services above? having mentioned that scale requirements are different.

5
  • Are you sure that the second bullet is really a service? What calls it?
    – JimmyJames
    Sep 10, 2019 at 15:59
  • Actually #1 is questionable too. "Manipulates and handles the data" -> for what purpose?
    – JimmyJames
    Sep 10, 2019 at 16:02
  • The first is part of an ingestion pipeline, there's a large amount of data that comes from various sources and needs to be handled, then we are persisting it. The second bullet is an independent process, that is syncing let's say configurations and data from our monolith
    – ArielB
    Sep 10, 2019 at 17:44
  • Not everything needs to be structured as a service. The way you describing it, I wonder if it is more like a 'job'. Are these sources pushing data to you or are you pulling data from them?
    – JimmyJames
    Sep 10, 2019 at 17:55
  • Data is pushed to a q and the services read from the queues.
    – ArielB
    Sep 10, 2019 at 18:59

1 Answer 1

7

Microservices are not like namespaces. You don't use them to separate logical parts of your architecture as you would with a namespace. So a single dev, looking the business domain and sort of judging what "belongs together"-- that is not an optimum design approach (even though it seems to be rather common with engineers and managers trying to keep up with development trends).

Microservices are units of deployment. The point of a microservice is that it can be versioned, deployed, scaled, and managed independently of the other services. So some reasons to separate things out:

  • Functionality that has unusual load and may need to be scaled differently. For example, you data ingestion service might handle very large files very slowly, and therefore have different hardware requirements to perform at an acceptable level.

  • Functionality is likely to version at a different rate. For example, internal services might be subject to rapid change while services exposed to the public occur on a slower schedule. Separating them into separate deployment units would help keep high uptime while not tying you hands with the internal stuff.

  • Functionality that requires different security. A public service exposed on the internet may have different security mechanisms from a service exposed on your intranet. So they get deployed to different servers that are behind a different sort of firewall.

I suggest reconsidering your division of services based on the above.

The service that manipulates and handles the data

I don't know to respond to this since to my knowledge all computer programs manipulate and handle data.

Service that feeds the database

Sounds like this might need different scaleability from the rest-- separate it into its own service.

REST API service that will be used also as internal but also as external (eventually for UI), and internally for requests from the services.

Sounds like the internal and external services have different security requirements-- separate into their own services.

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.