[irq]: techie interrupted






What is your philosophy on build vs. buy?

In case it isn’t already obvious: for most of my career I was one of those guys who built one of everything and at some level believed that what I built was better than what other people built. As I’ve grown more experienced I’m much more protective of my time, my team’s time and our ability to focus on what differentiates us from other products. My default is buy unless there’s a compelling counter-argument.


CTO to CTO: Werner Vogels and Don Neufeld — Medium



“ What we have seen is that a logically centralized, hierarchical control plane with a peer-to-peer data plane beats full decentralization,” explained Vahdat in his keynote. “All of these flew in the face of conventional wisdom,” he continued, referring to all of those projects above, and added that everyone was shocked back in 2002 that Google would, for instance, build a large-scale storage system like GFS with centralized control. “We are actually pretty confident in the design pattern at this point. We can build a fundamentally more efficient system by prudently leveraging centralization rather than trying to manage things in a peer-to-peer, decentralized manner. „

Google Lifts Veil On “Andromeda” Virtual Networking


“ I think enterprises should care more about full stack independence to manage vertical risk. Why? When a technology is vertically prescriptive (i.e. Pivotal CF One requiring VMware), it hurts an organizations’ ability to manage supply chain risk by ensuring they can source vendors to fulfill needs at other parts in the stack. This means that a customer loses cost control leverage, feature leverage, and can be held hostage in the face of overall stack quality degradation. By optimizing for vertical independence, an enterprise ensures that vendor selection at any tier in the IT stack does not dictate what vendors they use above and below that part of the stack. „

The LIES That Come With Some Flavors of PaaS


“ It used to be that the physical hardware was orders of magnitude more expensive than engineers but this hasn’t been true for decades now - it’s perfectly reasonable to look for ways to reduce yours costs especially if it can be done quickly but obsessing over hardware costs, especially while you’re still growing, is a red herring. Building large systems is tough and the fewer things you have to worry about the better - using AWS reduces the chance that you will run into a scenario where you’re just not able to do something without changing your host and rewriting your architecture. „

AWS is about infrastructure optionality


“ Imagine a cloud in which servers were automatically decommissioned after a week of use. In a sort of DevOps anti-SLA, any VM running for more than 168 hours would be (gracefully) terminated. This would force a constant churn of resources within the infrastructure that enables true cattle-like management. This cloud would be able to very gracefully rebalance load and handle disruptive management operations because the workloads are designed for the churn. „

Mayflies and Dinosaurs (extending Puppies and Cattle) | Rob Hirschfeld


“ The thing you have to get comfortable with is you’re relinquishing a lot of control to this system and allowing it to do the right thing for you, and trusting it – it may take steps you don’t know about," Neil says. "These systems are so large that no one person is keeping track. That’s what the system is designed to do – take care of the details. „

Inside Microsoft’s Autopilot: Nadella’s secret cloud weapon • The Register

blog comments powered by Disqus
page 1 of 99 | next »
Tumblr » powered Sid05 » templated Disquss » commented