3 ms·

At Netflix we had both noun and verb services. We had the "play movie" service, which was very much verb, as well as the listing service for example. But we a

At Netflix we had both noun and verb services. We had the "play movie" service, which was very much verb, as well as the listing service for example. But we also had the subscriber service, which was the source of truth for any account data, and the catalog service, which held all the info about the movies. Yes, subscriber was a Tier 0 service and required a strong reliability and scaling story. They had more rigorous deployment setup and were usually over-scaled for traffic. But they also vended a library that services used to connect to them. That library had intelligent caching and fallbacks, so that even if the service was down, in a lot of cases the system could keep running. And the catalog was the same. Microservices is very intertwined with how your engineering teams are built. We had a team that worked on subscriber data, one that worked on catalog data, one that worked on making movies play, one that built listings. So we had services to match.

lifeisstillgood 3y ago
Thank you. I sometimes feel microservices are an evolution of Conways law. How a company sees its internal organisation is how it will want to arrange its microservices and vice versa. I remember trying to build out a "barium bullet" through very complex intertwined systems - following known customer data and looking for their footprints in all linked systems. It gave some insights on how to redesign systems - like someone else said here, removing complexity is ridiculously hard.
wild_egg 3y ago
That seems like a great approach for Netflix and investing in a resilient, redundant Tier 0 service like that was likely worth it there Most orgs don't operate on that scale though and resources would likely be better spent elsewhere > Microservices is very intertwined with how your engineering teams are built. I wish more people understood this. Microservices are much more about scaling your organization than about scaling technology. At a certain size, teams can't collaborate effectively enough and splitting out different services for each team makes a lot of sense

lifeisstillgood 3y ago

Thank you. I sometimes feel microservices are an evolution of Conways law. How a company sees its internal organisation is how it will want to arrange its microservices and vice versa. I remember trying to build out a "barium bullet" through very complex intertwined systems - following known customer data and looking for their footprints in all linked systems. It gave some insights on how to redesign systems - like someone else said here, removing complexity is ridiculously hard.

wild_egg 3y ago

That seems like a great approach for Netflix and investing in a resilient, redundant Tier 0 service like that was likely worth it there Most orgs don't operate on that scale though and resources would likely be better spent elsewhere > Microservices is very intertwined with how your engineering teams are built. I wish more people understood this. Microservices are much more about scaling your organization than about scaling technology. At a certain size, teams can't collaborate effectively enough and splitting out different services for each team makes a lot of sense