4 ms·

The same reason you want to put stuff in to multiple processes: clear boundaries forcing separation and isolation, allowing you to use different technology stac

The same reason you want to put stuff in to multiple processes: clear boundaries forcing separation and isolation, allowing you to use different technology stacks for different things, letting you limit access/allocate resources to specific parts of the app, etc. I agree with regards to HTTP not being the only IPC layer but it's also the most commonly used and there is so much tooling built around it, everything speaks it - so I would say unless you have a good reason not to you should default to it.

mikeryan 10y ago
We do both. We have domain based services based on nodejs which tend to be smaller for example a content management service is separate from our notification service which is separate from our user authentication service which is actually provided by a third party (Auth0). In fact being able to use third party services in place of homegrown is one of the big benefits we've found of a microservice architecture. Particularly when creating prototypes and trial apps for clients. The goal is in initial launch we leverage third parties as much as we can then pull back and replace with internal services as we need. But we also have a suite of npm modules which can be shared across the services for common tasks (our ORM models being a primary use case). Maintaining the libs can be a bit of a pain point and making sure we have solid tests is crucial to making sure we don't break other services but it works pretty well.
danudey 10y ago
Not to mention that if you have hard, effectively physical boundaries between services (i.e. completely separate processes in completely separate projects) it makes it easier to scale them independently. For example, when we started out we had a few servers running all of our stuff. When one service grew more, we scaled it out to its own services. Because we used Django's ORM, all of a given service's tables are restricted to a given prefixed schema (e.g. 'systemname_servicename'), which is easy to migrate separately to a new service without risking breaking interconnections ('oh, we have this one query that uses that one table') etc.

mikeryan 10y ago

We do both. We have domain based services based on nodejs which tend to be smaller for example a content management service is separate from our notification service which is separate from our user authentication service which is actually provided by a third party (Auth0). In fact being able to use third party services in place of homegrown is one of the big benefits we've found of a microservice architecture. Particularly when creating prototypes and trial apps for clients. The goal is in initial launch we leverage third parties as much as we can then pull back and replace with internal services as we need. But we also have a suite of npm modules which can be shared across the services for common tasks (our ORM models being a primary use case). Maintaining the libs can be a bit of a pain point and making sure we have solid tests is crucial to making sure we don't break other services but it works pretty well.

danudey 10y ago

Not to mention that if you have hard, effectively physical boundaries between services (i.e. completely separate processes in completely separate projects) it makes it easier to scale them independently. For example, when we started out we had a few servers running all of our stuff. When one service grew more, we scaled it out to its own services. Because we used Django's ORM, all of a given service's tables are restricted to a given prefixed schema (e.g. 'systemname_servicename'), which is easy to migrate separately to a new service without risking breaking interconnections ('oh, we have this one query that uses that one table') etc.