recentpopularlog in


« earlier   
Postmortem: VSTS 4 September 2018 – Service Blog – Azure DevOps
However, the reality of cross-region synchronous replication is messy. For example, the region paired with South Central US is US North Central. Even at the speed of light, it takes time for the data to reach the other data center and for the original data center to receive the response. The round-trip latency is added to every write. This adds approximately 70ms for each round trip between South Central US and US North Central. For some of our key services, that’s too long. Machines slow down and networks have problems for any number of reasons. Since every write only succeeds when two different sets of services in two different regions can successfully commit the data and respond, there is twice the opportunity for slowdowns and failures. As a result, either availability suffers (halted while waiting for the secondary write to commit) or the system must fall back to asynchronous replication.
cloud  distributedcomputing  database  captheorem  recovery  microsoft  ovum 
18 days ago by yorksranter
Cloudflare goes InterPlanetary - Introducing Cloudflare’s IPFS Gateway
Using Cloudflare’s gateway, you can also build a website that’s hosted entirely on IPFS, but still available to your users at a custom domain name. Plus, we’ll issue any website connected to our gateway a free SSL certificate, ensuring that each website connected to Cloudflare's gateway is secure from snooping and manipulation.
distributedcomputing  p2p  cdn  cloudflare  ipfs  ccn 
23 days ago by yorksranter
DBMS Musings: NewSQL database systems are failing to guarantee consistency, and I blame Spanner
(1) Systems that fail to guarantee consistency result in complex, expensive, and often buggy application code.
(2) The reduction of availability that is caused by the guarantee of consistency is minute, and hardly noticeable for many deployments.
(3) The CAP theorem is fundamentally asymmetrical. CP systems can guarantee consistency. AP systems do not guarantee availability (no system can guarantee 100% availability). Thus only one side of the CAP theorem opens the door for any useful guarantees.
I believe that the above three points is what has caused the amazing renaissance of distributed, transactional database systems
captheorem  distributedcomputing  database  nosql  newsql  hacker  google  spanner  cool 
23 days ago by yorksranter
What do you believe now that you didn't five years ago? Centralized wins. Decentralized loses. - High Scalability -
With cloud based edge computing we've entered a kind of weird mushy mixed centralized/decentralized architecture phase. Amazon let's you put EC2 instances at the edge. Microsoft has Azure IoT Edge. Google has Cloud IoT Edge and GKE On-Prem and Edge TPU. The general idea is you pay cloud providers to put their machines on your premises and let them manage what they can. You aren't paying other people to manage you're own equipment, the equipment isn't even yours. Outsourcing with a twist. Since the prefix de- means "away from" and centr- means "middle", maybe postcentralization, as in after the middle, would be a good term for it?
7 weeks ago by yorksranter
Costs of task allocation with local feedback: Effects of colony size and extra workers in social insects and other multi-agent systems
If more workers are present than needed to complete the work available, some workers will always be idle; despite this, having surplus workers makes redistributing them across the tasks that need work much faster. Thus, unexpectedly, such surplus, idle workers may potentially significantly improve system performance
allocation  ants  distributedcomputing  cybernetics 
june 2018 by yorksranter
Distributed TensorFlow - O'Reilly Media
On the one hand: distributed tensorflow On the other, Android Neural Networks API: Hmm?
tensorflow  distributed  distributedComputing  NN  architecture  platform 
december 2017 by psychemedia
Notes on Distributed Systems for Young Bloods – Something Similar
New systems engineers will find the Fallacies of Distributed Computing and the CAP theorem as part of their self-education. But these are abstract pieces without the direct, actionable advice the inexperienced engineer needs to start moving. It’s surprising how little context new engineers are given when they start out.

Below is a list of some lessons I’ve learned as a distributed systems engineer that are worth being told to a new engineer. Some are subtle, and some are surprising, but none are controversial. This list is for the new distributed systems engineer to guide their thinking about the field they are taking on. It’s not comprehensive, but it’s a good beginning.
programming  distributed  distributedcomputing  fallacies 
september 2017 by stiefkind

Copy this bookmark:

to read