4 ms·

Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how

Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro services, because you can't possibly fit 600 developers into one standup. You'd never be able to coordinate. There are rare technical reasons to choose micro services and there is value to micro services when they're used correctly but if you don't have those precise problems then you don't need micro services. List would include situations like having a subsystem that utilizes far greater resources then any other sub system and would be more cost effective running on specialized hardware Most importantly tho for going 0 to 1 is context. Context is king and always will be. Start ups should not do enterprise services patterns because their not enterprises and neither is the guy coding alone in his bedroom. Your not Netflix. Your not Google. Those companies are going to be so large that they'll encounter every kind of architectural problem. All a start up needs to do is communicate, release, communicate, iterate, repeat. It's the equivalent of asking yourself what did NASA engineers do to send a rocket to the Moon when you're just a guy trying to start a car and get it down the road. Baby steps, for the love of god, baby steps.

cracell 5y ago
Simple rule of thumb is one backend per team. Things like upgrading the language version should not require coordination between multiple dev teams. Of course there's 100s of permutations that work. Optimize for your situation. And if you have no clue what the right call is, go as simple as possible until it breaks on you.
dastbe 5y ago
> There are rare technical reasons to choose micro services Is this just the difference between working in an infrastructure oriented space vs. product oriented? in infrastructure i find that it is often the case that most logical applications should be decomposed into multiple services given scaling and blast radius concerns where having everything in a single application would increase the impact of outages.
Gigachad 5y ago
It's not just communication issues. Things like framework and library updates become extremely difficult when the app is so large it is beyond comprehension for a single person. Multiple smaller upgrades are easier than one massive one. Especially when you have people working on it at the same time you try to update it.
- nijave 5y ago
  Not only that, extremely risky. It's an "all or nothing" approach versus starting at low risk and moving up. I think this is really important to remember with log4j and other vulnerabilities cropping up. It really sucks updating a single dependency version and having your dependency tree explode in conflict. It sucks even more when that prevents you from updating all your apps since they're all part of the same monolithic codebase
Seb-C 5y ago
Absolutely agree. The point of microservices is to separate the concerns from an organizational point of view, not for technical reasons. Most of the advantages attributed to microservices can also be achieved with a monolith architecture using a sane and rigorous design. I find it frustrating at work when I see teams of 50 people having issues coordinating work because they have a monolith, while we often unnecessarily spread a team of 5 people among 10 microservices.
wruza 5y ago
I’ve heard before that microservices deployment scheme solves one particular task: if you get traction, you’ll be ready for scaling. If you can’t do that you are already dead, cause being unable to get 10x more users with a click (when they come) means your competition will do that instead. Is that still true?
- tpetry 5y ago
  You can just start 10 more instances of your monolith. It‘s not a problem.
- drbojingle 5y ago
  No it isn't and to my knowledge it never was. My previous cto seemed to believe this too but dealing with greater throughput can be handled in several ways and the first would be scaling your infrastructure. If you're using aws you can do this easily with elastic beanstalk, a load balancer and some triggers so that the system knows to create a new ec2 instance. The thing is tho your application would have to be built in such a way to support this. The more stateless your backend service the better for this and that usually comes down to session management. If you're using jwt and your backend doesn't keep any sessions your probs good. If your backend is keeping sessions then you need that centralized otherwise you'll have multiple instances using different session information and if your load balancer is directing traffic to instances on a round Robin or bases on based on throughput or something you'll end up with some confusing results on your client device. So you have to do extra work to make a monolith scale but micro services doesn't have to be that extra work. Much cheaper to spin up redis and have all your backend instances use redis for caching sessions, etc then it is to split your app in to micro services.

cracell 5y ago

Simple rule of thumb is one backend per team. Things like upgrading the language version should not require coordination between multiple dev teams. Of course there's 100s of permutations that work. Optimize for your situation. And if you have no clue what the right call is, go as simple as possible until it breaks on you.

dastbe 5y ago

> There are rare technical reasons to choose micro services Is this just the difference between working in an infrastructure oriented space vs. product oriented? in infrastructure i find that it is often the case that most logical applications should be decomposed into multiple services given scaling and blast radius concerns where having everything in a single application would increase the impact of outages.

Gigachad 5y ago

It's not just communication issues. Things like framework and library updates become extremely difficult when the app is so large it is beyond comprehension for a single person. Multiple smaller upgrades are easier than one massive one. Especially when you have people working on it at the same time you try to update it.

nijave 5y ago
Not only that, extremely risky. It's an "all or nothing" approach versus starting at low risk and moving up. I think this is really important to remember with log4j and other vulnerabilities cropping up. It really sucks updating a single dependency version and having your dependency tree explode in conflict. It sucks even more when that prevents you from updating all your apps since they're all part of the same monolithic codebase

Seb-C 5y ago

Absolutely agree. The point of microservices is to separate the concerns from an organizational point of view, not for technical reasons. Most of the advantages attributed to microservices can also be achieved with a monolith architecture using a sane and rigorous design. I find it frustrating at work when I see teams of 50 people having issues coordinating work because they have a monolith, while we often unnecessarily spread a team of 5 people among 10 microservices.

wruza 5y ago

I’ve heard before that microservices deployment scheme solves one particular task: if you get traction, you’ll be ready for scaling. If you can’t do that you are already dead, cause being unable to get 10x more users with a click (when they come) means your competition will do that instead. Is that still true?

tpetry 5y ago
You can just start 10 more instances of your monolith. It‘s not a problem.
drbojingle 5y ago
No it isn't and to my knowledge it never was. My previous cto seemed to believe this too but dealing with greater throughput can be handled in several ways and the first would be scaling your infrastructure. If you're using aws you can do this easily with elastic beanstalk, a load balancer and some triggers so that the system knows to create a new ec2 instance. The thing is tho your application would have to be built in such a way to support this. The more stateless your backend service the better for this and that usually comes down to session management. If you're using jwt and your backend doesn't keep any sessions your probs good. If your backend is keeping sessions then you need that centralized otherwise you'll have multiple instances using different session information and if your load balancer is directing traffic to instances on a round Robin or bases on based on throughput or something you'll end up with some confusing results on your client device. So you have to do extra work to make a monolith scale but micro services doesn't have to be that extra work. Much cheaper to spin up redis and have all your backend instances use redis for caching sessions, etc then it is to split your app in to micro services.