Should my service be separated into multiple microservices?

Question

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.

Answer 1

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.