4 ms·

Microservices can be useful in medium/large companies where you have many teams of devs and it becomes cumbersome to have them all work on one monolith. As long

by brodie 7y ago

Microservices can be useful in medium/large companies where you have many teams of devs and it becomes cumbersome to have them all work on one monolith. As long as there's good communication and understanding of needs between teams, each team can develop their services how they want, in whatever language/platform, with their own review and QA and deploy processes. For smaller teams or small projects it isn't really super useful. Also, my personal experience is that when you start making microservices, the monolith doesn't go away. It also isn't so cumbersome if each team is in charge of one or a few services and you only split things if there's a clear benefit. I'm probably saying things you already know. My point is that I think for multiple cooperating teams, monoliths and microservices are complementary.

FpUser 7y ago
I myself directed teams of developer up to 35. Do not know beyond that scale. Teams simply worked on modules and main designers made sure they complied to a shared interfaces / state machines in more complex cases. Not a big deal. The law was: I trust developer so here is your module interface and constrains. Now go away and come back with implementation (which would still compile to a single monolith). As I was lucky to work with very good programmers bar couple of bad apples I've never had any real problems with the delivery and its quality
- jzoch 7y ago
  Its clear that you could afford to not use microservices (which is great! You didnt burden yourself with the cool approach since it wasnt necessary). Not everyone has those requirements though and may NEED them
  - FpUser 7y ago
    I completely fail to see what is so "cool" about increasing system complexity beyond of what is actually enough for most of the real life cases. To me: reliably working product is what is "cool" and that is what I've always pursued.
to11mtm 7y ago
My current set of experiences say: Microservices (where it makes sense) + Macrorepos. Microservices are really handy when you're at scale and/or the problem you're solving works well with the paradigm. I'm thinking back to a gig I had where each of our vendor integration points (sending the same data, just formatted for that vendor) was a good use case even for a smaller company. We used Scheduled tasks to launch the application that did what was basically an ETL. Oh, that vendor is down? Great, just have the sysadmin stop the thing. No database muckery required. No need to build a fancy front end. Easy to delegate to/train on helpdesk type folks. But any microservice is part of a larger ecosystem. It's critical to have a workflow that doesn't make refactoring the domain a huge chore/lift. IOW: Keep the related microservices in a single repo. Really, unless you've got a use case like the above (processes that need granular control) or HA/Scaling concerns (since in that case you'll be able to better focus on the parts that need to scale), A Monolith or domain based services are the way to try to go.
acdha 7y ago
I think a lot of this also becomes a question of where you choose accomplish the same root goal: if your team can maintain sound boundaries in either a large codebase or a bunch of microservices, test & tune well, you’re likely to have good results either way. A lot of people tend to see something working or failing and attribute it to the technology rather than the social dynamics behind it.

by brodie 7y ago

FpUser 7y ago

I myself directed teams of developer up to 35. Do not know beyond that scale. Teams simply worked on modules and main designers made sure they complied to a shared interfaces / state machines in more complex cases. Not a big deal. The law was: I trust developer so here is your module interface and constrains. Now go away and come back with implementation (which would still compile to a single monolith). As I was lucky to work with very good programmers bar couple of bad apples I've never had any real problems with the delivery and its quality

jzoch 7y ago
Its clear that you could afford to not use microservices (which is great! You didnt burden yourself with the cool approach since it wasnt necessary). Not everyone has those requirements though and may NEED them
- FpUser 7y ago
  I completely fail to see what is so "cool" about increasing system complexity beyond of what is actually enough for most of the real life cases. To me: reliably working product is what is "cool" and that is what I've always pursued.

to11mtm 7y ago

My current set of experiences say: Microservices (where it makes sense) + Macrorepos. Microservices are really handy when you're at scale and/or the problem you're solving works well with the paradigm. I'm thinking back to a gig I had where each of our vendor integration points (sending the same data, just formatted for that vendor) was a good use case even for a smaller company. We used Scheduled tasks to launch the application that did what was basically an ETL. Oh, that vendor is down? Great, just have the sysadmin stop the thing. No database muckery required. No need to build a fancy front end. Easy to delegate to/train on helpdesk type folks. But any microservice is part of a larger ecosystem. It's critical to have a workflow that doesn't make refactoring the domain a huge chore/lift. IOW: Keep the related microservices in a single repo. Really, unless you've got a use case like the above (processes that need granular control) or HA/Scaling concerns (since in that case you'll be able to better focus on the parts that need to scale), A Monolith or domain based services are the way to try to go.

acdha 7y ago

I think a lot of this also becomes a question of where you choose accomplish the same root goal: if your team can maintain sound boundaries in either a large codebase or a bunch of microservices, test & tune well, you’re likely to have good results either way. A lot of people tend to see something working or failing and attribute it to the technology rather than the social dynamics behind it.