3 ms·
I'm not sure I understand this. SOA == microservices, basically. Arguably one could say that Microservices = SOA minus ESBs, which is what necessitated the n
by parasubvert 12y ago
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?
- matthewmacleod 12y agoI'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.
- parasubvert 12y agoI 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.