|
|
|
|
|
|
by kodama-lens
759 days ago
|
|
|
While I don't agree with quite some assumptions and comparisons the author makes I tend to agree that microservices are often not the right answer for your problem. They can be great when: * You need just one function that is not directly related to your core application logic and might be needed by other service. Great usecase for a microservice or lambda * You need to separate statefull and stateless components * Have async workflows * Scaling to infinity and beyond But most don't application problems don't have these requirements for it's core logic. Microservices have a huge cost. Code and dependency dublication, complex deployments, latency, harder debugging and tracing and the cognitive load is much higher. A lot of read blogs and new form netflix and google and want to do the same. The management of my current project is asking for microservices because it is the new hot sh*t, so teams are doing it just like SAFe and AI - even when it does not help to solve the problem. |
|
|