7 ms·

I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been c

I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been chosen and the new shiny tech has people entranced. What we do (physics simulation software) doesn’t need all the complexity (in my option as a long time software developer & tester) and software engineering knowledge that splitting stuff into micro services require. Only have as much complexity as you absolutely need, the old saying “Keep it simple, stupid” still has a lot of truth. But the path is set, so I’ll just do my best as an individual contributor for the company and the clients who I work with.

ReclusiveCoder 10mo ago
Try sharing it with them anyway!:D
LtWorf 10mo ago
I thought microservices were old by now, which is why this kind of articles are finally appearing.
- Nextgrid 10mo ago
  It's less about how old microservices are and more that ZIRP being over, there is now finally pressure to improve software development efficiency, and to a certain extent, optimize infrastructure costs. Developers are now riding the new wave.
walt_grata 10mo ago
I started making the case for organizational efficiency rather than a technical argument. Demonstrating where the larger number of people and teams necessary to make a decision and a change and how that impacts the amount of time to ship new features has been more effective IME.
- szundi 10mo ago
  [dead]
echelon 10mo ago
If you have workloads with different shapes, microservices make sense. If not, do the monolith thing as long as you can. But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices. If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith. If your microservice is as thin as leftpad.js and hosts only one RPC call, maybe don't do that. But if you need to carve out a thumbnailing service or authC/authZ service, that's a good boundary. There is no "one size fits all" prescription here.
- soco 10mo ago
  I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.
  - xnx 10mo ago
    Good point. They would not have been as popular if they were called "multi-services" or "team partitioned apps".
  - karmakaze 10mo ago
    The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me. The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.
    - ants_everywhere 10mo ago
      That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.
xnx 10mo ago
I would really like to send this article back in time 11 years
venturecruelty 10mo ago
This article shows up here once in a while, but it's a good read: https://softwarecrisis.dev/letters/tech-is-a-pop-culture/ https://softwarecrisis.dev/letters/tech-is-a-pop-culture/
to11mtm 10mo ago
IMO, Engineering mindset is a huge challenge when it comes to 'do you do microservices' And by that, I mean that I have at times seen and/or perhaps even personally used as a cudgel - "This thing has a specific contract and it is implicitly separate and it forces people to remember that if their change needs to touch other parts well then they have to communicate it". In the real world sometimes you need to partition software enough that engineers don't get too far out of the boundaries one way or another (i.e. changes inadvertently breaking something else because they were not focused enough)
- randall 10mo ago
  but fr at facebook we just had unit tests. if someone else broke your code it’s your fault unless you have tests. there are of course microservices for things like news feed etc, but iirc all of fb.com and mobile app graphql is from the monolith by default.

ReclusiveCoder 10mo ago

Try sharing it with them anyway!:D

LtWorf 10mo ago

I thought microservices were old by now, which is why this kind of articles are finally appearing.

Nextgrid 10mo ago
It's less about how old microservices are and more that ZIRP being over, there is now finally pressure to improve software development efficiency, and to a certain extent, optimize infrastructure costs. Developers are now riding the new wave.

walt_grata 10mo ago

I started making the case for organizational efficiency rather than a technical argument. Demonstrating where the larger number of people and teams necessary to make a decision and a change and how that impacts the amount of time to ship new features has been more effective IME.

szundi 10mo ago
[dead]

echelon 10mo ago

If you have workloads with different shapes, microservices make sense. If not, do the monolith thing as long as you can. But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices. If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith. If your microservice is as thin as leftpad.js and hosts only one RPC call, maybe don't do that. But if you need to carve out a thumbnailing service or authC/authZ service, that's a good boundary. There is no "one size fits all" prescription here.

soco 10mo ago
I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.
- xnx 10mo ago
  Good point. They would not have been as popular if they were called "multi-services" or "team partitioned apps".
- karmakaze 10mo ago
  The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me. The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.
  - ants_everywhere 10mo ago
    That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.

xnx 10mo ago

I would really like to send this article back in time 11 years

venturecruelty 10mo ago

This article shows up here once in a while, but it's a good read: https://softwarecrisis.dev/letters/tech-is-a-pop-culture/ https://softwarecrisis.dev/letters/tech-is-a-pop-culture/

to11mtm 10mo ago

IMO, Engineering mindset is a huge challenge when it comes to 'do you do microservices' And by that, I mean that I have at times seen and/or perhaps even personally used as a cudgel - "This thing has a specific contract and it is implicitly separate and it forces people to remember that if their change needs to touch other parts well then they have to communicate it". In the real world sometimes you need to partition software enough that engineers don't get too far out of the boundaries one way or another (i.e. changes inadvertently breaking something else because they were not focused enough)

randall 10mo ago
but fr at facebook we just had unit tests. if someone else broke your code it’s your fault unless you have tests. there are of course microservices for things like news feed etc, but iirc all of fb.com and mobile app graphql is from the monolith by default.