Ask HN: What granularity are your microservices? | Hacker News Reader

Ask HN: What granularity are your microservices?

1 pointtrelliscoded1 comment

I'm turning a side project into a production application, and I was wondering how other people split up their apps into different internal services, and what those services are. I'd also like to hear about any negative consequences anyone had from their decisions on where to draw the lines.

I also have some more specific questions:

1. How do the microservices map onto the unix security model? Does each service get its own UID? How do you keep the user databases in sync in production?

2. How do you handle debugging these systems?

3. How do databases integrate with your architecture? Do you use the same communications bus as the rest of the system, or do the services communicate with the database using its native protocols? Do you treat the database server as a microservice too?

Can you elaborate on why you want to split your application into multiple services? This matters, as a 'how' you split may vary based on the 'why'.

My suggestion would be to look at the existing modules in your application, and analyse the coupling and cohesion across them. If you find loosely coupled modules, with minimum dependencies of their own, then these become good candidates for services. Another consideration is to try an split around domain concepts, rather than functional concepts. For additional thoughts, take a look at this post: http://www.nirmata.com/2015/02/microservices-five-architectu...

On your questions:

1. With a microservices-style each service may have multiple instances. And each service instance runs as a separate process, and may be on different hosts. So, you can map each service to its own UID, or may run a group of services with the same UID based on the privileges each service requires.

2. Debugging gets harder! It best to plan for testing each service in isolation (e.g. using mocks), or with minimal dependencies. Troubleshooting is also harder. You will need log aggregation and management. If you are running in containers, you can use services around the container to handle logs.

3. A service should have its own database and only expose an interface to the rest of the world. Hence, you can directly use a database driver in your service.

Hope this helps.

Regards,

Jim

Reply on news.ycombinator.com