3 ms·
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
by 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 agoIf 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 agoIt 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.