Adopting Microservices at Netflix: Lessons for Architectural Design
1–10 of 76 posts
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#2My comment, slightly edited, from the previous posting of this, at https://news.ycombinator.com/item?id=9106813
> One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.
That sounds like a decision you wouldn't want to take lightly; the kind of thing you might do once your company is already big. I wouldn't want to start out that way though, it sounds like a recipe for a mess.
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#3My comment, slightly edited, from the previous posting of this, at https://news.ycombinator.com/item?id=9106813 > One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it. That sounds like a decision you wo…
Yes I just came in here to write a comment along those lines. I mean surely you're opening a whole can of worms in terms of consistency etc. I get the feeling Netflix happens not to have use cases where strong consistency is a requirement. I'd be interested to get more detail about how they went about the transition - even just pointers to more on the meta-data management tools they use.
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#4My comment, slightly edited, from the previous posting of this, at https://news.ycombinator.com/item?id=9106813 > One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it. That sounds like a decision you wo…
If the two (the database schema and the microservices API) are designed and maintained separately, this assertion (that "updating a service means changing the schema") is not necessarily true. They have separate responsibilities -- the database is persisting the data, and the services provide some business logic, and while they might need to change together this is not always the case.
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#5My comment, slightly edited, from the previous posting of this, at https://news.ycombinator.com/item?id=9106813 > One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it. That sounds like a decision you wo…
Yes I just came in here to write a comment along those lines. I mean surely you're opening a whole can of worms in terms of consistency etc. I get the feeling Netflix happens not to have use cases where strong consistency is a requirement. I'd be interested to get more detail about how they went about the transition - even just pointers to more on the meta-data management tools they use.
The consistency problem is an open question in my mind. I definitely don't like the idea of having some data synchronization tool to fix the inconsistent data across services problem. I wonder what the best practice is for maintaining data consistency across services.
Does anyone know?
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#6If your app depends on lots of of them, it's only going to run as fast as the slowest dependency. 1% chance of poor performance isn't to bad, the joint distribution of 20 microservices each with a 1% chance, well that gets pretty ugly. In the normal case, everything is great, but the failure modes of each service become a much bigger deal.
It's a great architecture, but fan out of dependencies is a real risk.
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#7Earlier quoted context omitted.
Yes I just came in here to write a comment along those lines. I mean surely you're opening a whole can of worms in terms of consistency etc. I get the feeling Netflix happens not to have use cases where strong consistency is a requirement. I'd be interested to get more detail about how they went about the transition - even just pointers to more on the meta-data management tools they use.
The consistency problem is an open question in my mind. I definitely don't like the idea of having some data synchronization tool to fix the inconsistent data across services problem. I wonder what the best practice is for maintaining data consistency across services. Does anyone know?
Ideally you don't have to sync the data because one service owns that data. Other services request that data via api. In a RESTful world those api requests are cacheable.
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#8Earlier quoted context omitted.
The consistency problem is an open question in my mind. I definitely don't like the idea of having some data synchronization tool to fix the inconsistent data across services problem. I wonder what the best practice is for maintaining data consistency across services. Does anyone know?
Ideally you don't have to sync the data because one service owns that data. Other services request that data via api. In a RESTful world those api requests are cacheable.
But what about the situation where you have an entity service that owns the data for one piece of the domain, for example a People service, and then other services, like the Address service and the Billing service, reference a particular person. In that scenario, I can imagine the Address service and the Billing service would have a foreign key referencing a person in the People service. Then, what happens if the Person gets deleted? In that case, we've got a consistency problem, even though each service owned its data.
Is the best practice to not use entity services?
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#9If your app depends on lots of of them, it's only going to run as fast as the slowest dependency. 1% chance of poor performance isn't to bad, the joint distribution of 20 microservices each with a 1% chance, well that gets pretty ugly. In the normal case, everything is great, but the failure modes of each service become a much bigger deal. It's a great architecture, but fan out of dependencies is a real risk.
[deleted]
Re: Adopting Microservices at Netflix: Lessons for Architectural Design
#10Earlier quoted context omitted.
Ideally you don't have to sync the data because one service owns that data. Other services request that data via api. In a RESTful world those api requests are cacheable.
But what about the situation where you have an entity service that owns the data for one piece of the domain, for example a People service, and then other services, like the Address service and the Billing service, reference a particular person. In that scenario, I can imagine the Address service and the Billing service would have a foreign key referencing a person in the People service. Then, what happens if the Per…
The "each service owns its data" scenario shouldn't take precedence over cases like this, where consistency is aligned with obvious business rules. If Person gets deleted, then "on delete cascade" should take care of that Person's Address and Billing records.
For updates and maybe reads, it's a different story.