4 ms·

I do not see why a startup would not go with microservices today. It is a nice way of separating concerns. The knowledge on how to do this in a good way is out

I do not see why a startup would not go with microservices today. It is a nice way of separating concerns. The knowledge on how to do this in a good way is out there. It allows for smaller isolated changes, feature focused development and much shorter time to production. Just build services that are not too small, avoid dependency hell between services and never build platforms.

rajin444 4y ago
You introduce a lot of complexity when you change the boundaries. Straight to microservices is almost always premature optimization. You'll know pretty quick when it is needed.
- AtNightWeCode 4y ago
  The boundary complexity is always present. When you want to tackle that problem is another concern. Horizontal dependencies can destroy any system no matter if it within a database or between services. A lot of monoliths reach end-of-life because everything is glued together. I even worked with partners that have systems where each database table is dependent on a single table in the database. It failed. A design doomed to fail from start.
zanellato19 4y ago
It makes everything more complicated. Deployment is more complicated, changes can be more complicated, performance is more complicated. Its a great way of splitting up teams, but when you are a startup and have a single team for a long time, why would they do this? > Just build services that are not too small, avoid dependency hell between services and never build platforms. This is basically "code without bugs and you will be alright". Avoiding dependency hell is difficult, sizing up the services at the perfect size is also difficult as hell. Everything is a lot more difficult. Microservices can be amazing, I'm not saying they aren't, but acting they are just better than monoliths is not seeing difficulties where there are many.
lolinder 4y ago
Microservices are a solution to organizational problems, not to technical ones. They mean accepting increased technical complexity (your system is now distributed) in exchange for decreased organizational complexity (your teams can now deploy independently from each other, can safely make database schema changes, etc). Going with microservices from day 1 will initially mean that you have one team maintaining many services. They have to deploy them separately. If you're doing it "right" you have separate databases per service. None of that is useful for a team that's just starting out. If you want separation of concerns, the language's module system and a bit of discipline will get most teams as far as they need without introducing distributed computing into the equation.
- AtNightWeCode 4y ago
  I think the key is not to make the services too small. If you are a startup with one team, you should probably end up with a handful of services. And do not let the services talk to each other. Individual deployment of services is the single best thing with microservices. If the services are not highly coupled that is. For example. To be able to fix a bug in the search function in a system without affecting anything else speeds up things. Such a deployment can take minutes instead of the hours as some of the monoliths I worked on takes to deploy. It also gives the possibility of rolling forward instead of always having to rollback. EDIT: replied to the wrong comment.
- mbesto 4y ago
  > Microservices are a solution to organizational problems, not to technical ones. Which is exactly what separation of concerns achieves: > It is a nice way of separating concerns. It's also why Uber got to "thousands of microservices" and found it terrible...for the same reason managing thousands of developers is a nightmare. The overhead eventually catches up. I upvoted you both btw.
  - AtNightWeCode 4y ago
    Didn't Uber end up with something like 2000+ microservices. I seriously doubt that their business requires that amount of services. More likely that they have a lot of highly coupled services, services that serves no meaning by themself, services that are just wrappers around database entities and so on.
collyw 4y ago
The way I look at it microservices come together to form a monolith. So you effectively have a monoloith with unreliable network connections between components instead of reliable method calls. Much more effort for little benefit for most startups. My current work has put a load of developer resources into a kubernetes setup. It makes troubleshooting slower and I don't think we have ever scaled beyond the default two pods, except when some bug was playing up.
- AtNightWeCode 4y ago
  If you place things in the right service, the need for service-to-service communication is low. I know companies that straight out banned it. If you treat each service as a database table. Sure, you will be in for a ride. If you then are lenient about breaking changes, then you will have real problems. But microservices is a service architecture. Each service is almost a product. Each service covers an entire problem. Parts of that problem is not in another service. A service is not a task.
- DeathArrow 4y ago
  It doesn't always make sense to use microservices. If the app is big, you will have a hard time using a monolithic architecture. Also, microservices do better if you have a high load, if you have many teams working on the same project, if you have to feed data to many apps or frontends. And microservices are more reliable if done well. Many people have a fear of microservices. They are afraid of dependency hell, they are afraid their app will lock up, they are afraid it will make the app more complex. In my experience, that is not the case if the architecture is done well.
javcasas 4y ago
You can separate concerns without microservices too! People in the past were able to do it, they even invented programming language keywords for it, like https://www.tutlane.com/tutorial/csharp/csharp-access-modifiers-public-private-protected-internal https://www.tutlane.com/tutorial/csharp/csharp-access-modifi...

rajin444 4y ago

You introduce a lot of complexity when you change the boundaries. Straight to microservices is almost always premature optimization. You'll know pretty quick when it is needed.

AtNightWeCode 4y ago
The boundary complexity is always present. When you want to tackle that problem is another concern. Horizontal dependencies can destroy any system no matter if it within a database or between services. A lot of monoliths reach end-of-life because everything is glued together. I even worked with partners that have systems where each database table is dependent on a single table in the database. It failed. A design doomed to fail from start.

zanellato19 4y ago

It makes everything more complicated. Deployment is more complicated, changes can be more complicated, performance is more complicated. Its a great way of splitting up teams, but when you are a startup and have a single team for a long time, why would they do this? > Just build services that are not too small, avoid dependency hell between services and never build platforms. This is basically "code without bugs and you will be alright". Avoiding dependency hell is difficult, sizing up the services at the perfect size is also difficult as hell. Everything is a lot more difficult. Microservices can be amazing, I'm not saying they aren't, but acting they are just better than monoliths is not seeing difficulties where there are many.

lolinder 4y ago

Microservices are a solution to organizational problems, not to technical ones. They mean accepting increased technical complexity (your system is now distributed) in exchange for decreased organizational complexity (your teams can now deploy independently from each other, can safely make database schema changes, etc). Going with microservices from day 1 will initially mean that you have one team maintaining many services. They have to deploy them separately. If you're doing it "right" you have separate databases per service. None of that is useful for a team that's just starting out. If you want separation of concerns, the language's module system and a bit of discipline will get most teams as far as they need without introducing distributed computing into the equation.

AtNightWeCode 4y ago
I think the key is not to make the services too small. If you are a startup with one team, you should probably end up with a handful of services. And do not let the services talk to each other. Individual deployment of services is the single best thing with microservices. If the services are not highly coupled that is. For example. To be able to fix a bug in the search function in a system without affecting anything else speeds up things. Such a deployment can take minutes instead of the hours as some of the monoliths I worked on takes to deploy. It also gives the possibility of rolling forward instead of always having to rollback. EDIT: replied to the wrong comment.
mbesto 4y ago
> Microservices are a solution to organizational problems, not to technical ones. Which is exactly what separation of concerns achieves: > It is a nice way of separating concerns. It's also why Uber got to "thousands of microservices" and found it terrible...for the same reason managing thousands of developers is a nightmare. The overhead eventually catches up. I upvoted you both btw.
- AtNightWeCode 4y ago
  Didn't Uber end up with something like 2000+ microservices. I seriously doubt that their business requires that amount of services. More likely that they have a lot of highly coupled services, services that serves no meaning by themself, services that are just wrappers around database entities and so on.

collyw 4y ago

The way I look at it microservices come together to form a monolith. So you effectively have a monoloith with unreliable network connections between components instead of reliable method calls. Much more effort for little benefit for most startups. My current work has put a load of developer resources into a kubernetes setup. It makes troubleshooting slower and I don't think we have ever scaled beyond the default two pods, except when some bug was playing up.

AtNightWeCode 4y ago
If you place things in the right service, the need for service-to-service communication is low. I know companies that straight out banned it. If you treat each service as a database table. Sure, you will be in for a ride. If you then are lenient about breaking changes, then you will have real problems. But microservices is a service architecture. Each service is almost a product. Each service covers an entire problem. Parts of that problem is not in another service. A service is not a task.
DeathArrow 4y ago
It doesn't always make sense to use microservices. If the app is big, you will have a hard time using a monolithic architecture. Also, microservices do better if you have a high load, if you have many teams working on the same project, if you have to feed data to many apps or frontends. And microservices are more reliable if done well. Many people have a fear of microservices. They are afraid of dependency hell, they are afraid their app will lock up, they are afraid it will make the app more complex. In my experience, that is not the case if the architecture is done well.

javcasas 4y ago

You can separate concerns without microservices too! People in the past were able to do it, they even invented programming language keywords for it, like https://www.tutlane.com/tutorial/csharp/csharp-access-modifiers-public-private-protected-internal https://www.tutlane.com/tutorial/csharp/csharp-access-modifi...