5 ms·

I agree with the bulk of your comment, and want to add one thing you didn't mention. Micro services allow you to scale the size of your engineering team. We sta

by jshen 12y ago

I agree with the bulk of your comment, and want to add one thing you didn't mention. Micro services allow you to scale the size of your engineering team. We started with a monolith at my company and as the engineering team grew from 5 to ~50 we started pulling out independent pieces and making them services that a team of ~5 could own, and it has worked out well.

aantix 12y ago
Why do you have to fully decouple if it's not necessary. Create a gem(s), and call it a day.
- jshen 12y ago
  Yeah, i have asked myself this, and have repeatedly tried it. Somehow it usually doesn't work out as well. With gems it's still a bit too easy to dig into a gem and fiddle with it to get something done quickly when in a hurry breaking the encapsulation. Maybe there are other reasons as well. Also, with a big org I like having the ability to use different languages and technologies in some small services. Is functional programming all the rage? Well we can experiment with it on this little service need to build without much risk. Another thing I like is that other teams can leverage my micro service regardless of the languages we are using. With libraries, everyone has to use the same language.
yummyfajitas 12y ago
You can do the exact same thing with service objects. You can probably also get away with smaller teams, since most teams don't need to worry about devops.
- kyllo 12y ago
  But doesn't that just put you right back into RPC-land, where you don't even know whether a method call is local or over the network, because the interface is the same? And if you take the suggested alternative of wrapping the return values in 'Future', then your interface just changed, so now the code that calls your service all needs to be rewritten. It's pretty well established that service calls are either local or remote, and the service interface should show the difference between the two, but that means means that changing a service from local to remote is always going to break its clients. That's a pain point, but it's probably better than making every service call remote by default which is what a microservices architecture does.
hyp0 12y ago
you can divide a project into modules without using microservices... but microservices can scale in performance terms, and are the future (or something like it) IMHO - including local many-core. they also enable an app-like per usage business model for libraries, which could be interesting...

by jshen 12y ago

aantix 12y ago

Why do you have to fully decouple if it's not necessary. Create a gem(s), and call it a day.

jshen 12y ago
Yeah, i have asked myself this, and have repeatedly tried it. Somehow it usually doesn't work out as well. With gems it's still a bit too easy to dig into a gem and fiddle with it to get something done quickly when in a hurry breaking the encapsulation. Maybe there are other reasons as well. Also, with a big org I like having the ability to use different languages and technologies in some small services. Is functional programming all the rage? Well we can experiment with it on this little service need to build without much risk. Another thing I like is that other teams can leverage my micro service regardless of the languages we are using. With libraries, everyone has to use the same language.

yummyfajitas 12y ago

You can do the exact same thing with service objects. You can probably also get away with smaller teams, since most teams don't need to worry about devops.

kyllo 12y ago
But doesn't that just put you right back into RPC-land, where you don't even know whether a method call is local or over the network, because the interface is the same? And if you take the suggested alternative of wrapping the return values in 'Future', then your interface just changed, so now the code that calls your service all needs to be rewritten. It's pretty well established that service calls are either local or remote, and the service interface should show the difference between the two, but that means means that changing a service from local to remote is always going to break its clients. That's a pain point, but it's probably better than making every service call remote by default which is what a microservices architecture does.

hyp0 12y ago

you can divide a project into modules without using microservices... but microservices can scale in performance terms, and are the future (or something like it) IMHO - including local many-core. they also enable an app-like per usage business model for libraries, which could be interesting...