Hacker News new | past | comments | ask | show | jobs | submit login

This seems like it's just taking the idea of decoupling your service and talking to them via APIs a little further by saying.. decouple them to an even smaller granularity?

This has always been the generally accepted way to scale out software services. Is there a novel idea being discussed here, or just that they've been doing this at Netflix?




Yes, a lot of organizations already design their backends in this way without necessarily thinking to use a brand new term to describe it.

Cockcroft defines a microservices architecture as a service-oriented architecture composed of loosely coupled elements that have bounded contexts.

To me this just reads as "service-oriented architecture in a sensible way".

No one thinks to intentionally build a SOA with tightly coupled components with poor boundaries.


When it comes down to it, n-tier, SOA, and microservices are all expressions of the same basic ideas.


Exactly. Even in the late 90s "3 tier" development pushed the idea of having a separate layer and sticking to APIs. This is just saying that instead of making big layers, make smaller ones. Which isn't bad, it's just that most of the time you don't need this. Add a new service, like "GetRecommendationFromFacebook?" OK, go ahead and deploy, because you haven't changed the rest of the services in your layer, like "LoginUser".

And there was a whole hubbub of discovery what with UDDI and DISCO and all that jazz I never really understood.

It'd be nice if they gave some solid examples of the "micro" part to distinguish it from the general SOA idea.




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

Search: