Re:CoreOS (YC S13) Raises $12M to Bring Kubernetes to the En...
by chubot on Monday April 06, 2015 @04:09PM
(#9330426)
About disk locality -- I've read that paper and know that Google increasingly has the philosophy of disk locality being irrelevant.
However, I don't buy it for 2 reasons:
1. Highly available distributed services need to have geographical diversity, i.e. they should be "multihomed". This is true on AWS or in Google's internal data centers. That means you have WAN latency, in which case locality becomes again the primary design concern for performance.
Pre-Spanner, Google's solution was to use application-specific logic to be multihomed -- i.e. nearly rewrite your application, depending on how stateful it is. Spanner isn't a silver bullet either. You still have to solve latency problems, just within the ontology of Spanner rather than the application.
It's bad for your code to ignore latency within the data center, and then later add (incorrect) hacks to work around latency between data centers. If you pay attention to network boundaries from the beginning, it will be easier to multi-home.
2. A single machine is still your domain of failure. Even if it doesn't matter for performance, you still have think about machines to handle failures.
The interfaces between machines should be idempotent to handle failures gracefully. And many distributed storage services have complicated performance vs. durability knobs for how many machines/processes have accepted writes.
So I think Google does have a "single system image" bias, and you are right that Kubernetes has these Google-isms in its architecture.
However, I don't buy it for 2 reasons:
1. Highly available distributed services need to have geographical diversity, i.e. they should be "multihomed". This is true on AWS or in Google's internal data centers. That means you have WAN latency, in which case locality becomes again the primary design concern for performance.
Pre-Spanner, Google's solution was to use application-specific logic to be multihomed -- i.e. nearly rewrite your application, depending on how stateful it is. Spanner isn't a silver bullet either. You still have to solve latency problems, just within the ontology of Spanner rather than the application.
It's bad for your code to ignore latency within the data center, and then later add (incorrect) hacks to work around latency between data centers. If you pay attention to network boundaries from the beginning, it will be easier to multi-home.
2. A single machine is still your domain of failure. Even if it doesn't matter for performance, you still have think about machines to handle failures.
The interfaces between machines should be idempotent to handle failures gracefully. And many distributed storage services have complicated performance vs. durability knobs for how many machines/processes have accepted writes.
So I think Google does have a "single system image" bias, and you are right that Kubernetes has these Google-isms in its architecture.