
Ask HN: What granularity are your microservices? - trelliscoded
I&#x27;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&#x27;d also like to hear about any negative consequences anyone had from their decisions on where to draw the lines.<p>I also have some more specific questions:<p>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?<p>2. How do you handle debugging these systems?<p>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?
======
jbugwadia
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...](http://www.nirmata.com/2015/02/microservices-five-
architectural-constraints/)

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

