3 ms·

Is there a valid reason for using microservice unless you have 1000+ engineers working on a product? The microservice argument is compelling to begin with but

Is there a valid reason for using microservice unless you have 1000+ engineers working on a product? The microservice argument is compelling to begin with but shifts the separation of concern to the extreme, to the point that you now have intra service level delegation bubbling up with complexity. Suddenly, fetching a blog post now involves multiple context switching than something written in RoR deployed on beantstalk. If I was forced to use microservice architecture I would not try to deploy it myself instead using Azure Fabric because breaking a monolithic framework codebase itself is such a monumental task especially when you are dealing with legacy code. I feel as if microservice is the "blockchain" of backend architecture space where it's actively solving problems that isn't there. Much like moving to a cryptographic linked-list with decentralized consensus creates ton of drama, splitting services into as many pieces as possible seems like asking for trouble.

daenney 10y ago
> Much like moving to a cryptographic linked-list with decentralized consensus creates ton of drama, splitting services into as many pieces as possible seems like asking for trouble. But it's not about splitting it in as many services as possible. There's also nothing saying you can't live in a hybrid state, you don't need to go 100%. There's plenty of orgs that run a monolith and little by little break out components they need to. Or sometimes build something new as a microservice for other reasons (like the framework/language of the monolith is limiting them to solve a use case) and hook that up to their monolith.
SmurfJuggler 10y ago
For developers yes, I'm working on a similar platform just now - you wouldn't be developing a 3D game on these kinds of things, but containerised development environments are definitely The Sane Way To Do It, for various shades of 'it.'
stevekemp 10y ago
There are cases where it makes sense. In my own case I've splitup several parts of a "simple web application" into services. For example if a new user joins my site I want to send them a welcome email. The traditional way to do that would be to have the back-end send the mail directly. But of course sending email can block and take a while, so you really want to do it in a different process, not inside your Rails/PHP/Perl CGI process. So in this case I submit a "new.user.joined" event to a work queue. I then have a micro-service which pretty much sits idle, until it sees such an event, and then it sends the mail. I have a bunch of these little services that just listen for events that they care about, and do one specific job. If I were in ruby they could be sidekiq workers, but since I'm not I'll just call them "microservices". They can be started/stopped independently, and though they do have application knowledge (e.g. where to load email templates from) they're pretty decoupled. Perhaps I could have picked a better example, but I think it still counts!
sjellis 10y ago
I agree that microservices appear to move the complexity around (and add to it), rather than necessarily making things simpler. My feeling is that they make a lot of sense for addressing the organizational problems of having multiple sets of developers working on different parts of the same product, so it's valuable for larger organizations. They have already paid for a lot of operations infrastructure, so breaking a multi-team monolith into a service per team is viable and useful for getting things done. People problems are the hardest problems in tech. The organization that I work for almost never has more than a "two-pizza team" (eight people) on any one project, so monoliths are a more efficient way for us to build and ship products. We do use external services of course.

daenney 10y ago

> Much like moving to a cryptographic linked-list with decentralized consensus creates ton of drama, splitting services into as many pieces as possible seems like asking for trouble. But it's not about splitting it in as many services as possible. There's also nothing saying you can't live in a hybrid state, you don't need to go 100%. There's plenty of orgs that run a monolith and little by little break out components they need to. Or sometimes build something new as a microservice for other reasons (like the framework/language of the monolith is limiting them to solve a use case) and hook that up to their monolith.

SmurfJuggler 10y ago

For developers yes, I'm working on a similar platform just now - you wouldn't be developing a 3D game on these kinds of things, but containerised development environments are definitely The Sane Way To Do It, for various shades of 'it.'

stevekemp 10y ago

There are cases where it makes sense. In my own case I've splitup several parts of a "simple web application" into services. For example if a new user joins my site I want to send them a welcome email. The traditional way to do that would be to have the back-end send the mail directly. But of course sending email can block and take a while, so you really want to do it in a different process, not inside your Rails/PHP/Perl CGI process. So in this case I submit a "new.user.joined" event to a work queue. I then have a micro-service which pretty much sits idle, until it sees such an event, and then it sends the mail. I have a bunch of these little services that just listen for events that they care about, and do one specific job. If I were in ruby they could be sidekiq workers, but since I'm not I'll just call them "microservices". They can be started/stopped independently, and though they do have application knowledge (e.g. where to load email templates from) they're pretty decoupled. Perhaps I could have picked a better example, but I think it still counts!

sjellis 10y ago

I agree that microservices appear to move the complexity around (and add to it), rather than necessarily making things simpler. My feeling is that they make a lot of sense for addressing the organizational problems of having multiple sets of developers working on different parts of the same product, so it's valuable for larger organizations. They have already paid for a lot of operations infrastructure, so breaking a multi-team monolith into a service per team is viable and useful for getting things done. People problems are the hardest problems in tech. The organization that I work for almost never has more than a "two-pizza team" (eight people) on any one project, so monoliths are a more efficient way for us to build and ship products. We do use external services of course.