Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not a fan of microservices myself - IME it pushes the complexity that exists in any application into implicit interfaces and dependencies between microservices. The difference is that we have better tools for managing this complexity at the application level than we do at the operation level.

Still a big proponent of SOA generally, though. I think the granularity when defining "service" is ultimately going to vary from application to application, however, leaving the sweet spot slightly larger than e.g. Amazon's microservices.



I'm not sure I understand this.

SOA == microservices, basically. Arguably one could say that Microservices = SOA minus ESBs, which is what necessitated the new term. IOW, don't hide your mess of dependencies in a black box, expose and manage them where they're needed.

The granularity of the service is generally determined by the size and responsibility of the maintaining team, and will vary from company to company.

With regards to tooling, I'm curious what you're referring to. Some selection of tools like Splunk, AppDynamics, New Relic, or Boundary certainly can handle both applications and microservice chains, no?


I've reconsidered what I wrote above – you're right. I'd built a mental model of what "microservice" and "SOA" meant that apparently isn't entirely in line with what others are commonly using.

I maintain that it's not a panacea, and that complexity is pulled into other places (operations) where we perhaps don't have equally effective tools at this point. I'd also argue that it's difficult to understand the correct level of granularity (and potentially expensive to fix errors in this decision). But it's not the problem I made it out to be.


I agree with the above. It's not a panacea but it seems to be worth exploring further as a way (not THE way) to manage (not cure) scale/complexity in multi-team environments.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: