EOS vs. Public Cloud
At Cypherglass we have assembled a team that has a long history of building out IT infrastructure. Along with many others in the industry, we have become concerned that computing has become too centralized over the last decade. According to Gartner, 47.1% of the public cloud business is owned by Amazon AWS, 10% for Microsoft Azure, and 5% owned by Google/IBM. We aren’t big fans of monopolies or oligopolies, if you are reading this and into crypto, you probably aren’t either. They call them “public clouds” but to us they seem to be privately held company clouds, and not public at all.
Having built out infrastructure for Intel, Microsoft, Amazon, IBM, Hewlett Packard, and CenturyLink (yes some of those same “public cloud” companies) our team created a detailed roadmap for a seriously kick-ass decentralized infrastructure. EOS deserves this level of infrastructure. Nowhere in that roadmap is there one piece of EOS Block Producer software that resides with a big cloud company. EOS promises to change the way we use compute and storage, and create a truly decentralized model for the world. We as Block Producers need to be true to the decentralized model that Dan Larimer and the rest of Block.one envisioned. In many ways our EOS network will compete directly with Amazon AWS, Microsoft Azure and Google Cloud. I doubt Jeff Bezos, Sundar Pichai and Satya Nadella are laying awake nights worrying about EOS, but perhaps they should.
As we launch EOS, we have become concerned that many Block Producer candidates are building nodes on public cloud. Hosting the EOS Network on AWS, Azure or Google is the antithesis of building a decentralized network. In fact, It’s dangerous for the EOS community. As the community, we need to be adamant about insuring that we are independent and decentralized. We at Cypherglass believe that it’s critical for Block Producers to run their own physical infrastructure, and that there are three primary reasons why hosting nodes on a cloud provider exposes EOS to significant risk.
Outages/Redundancy
As a distributed network, with a large number of independent Block Producers, EOS has been designed for redundancy. Let’s say over 50% of those Block Producer nodes are hosted in AWS and they all take an outage like this one? or this one just the other day? That built-in redundancy is suddenly diminished, and application outages would follow. Sure AWS is a good product, but should thousands of EOS DApps be running on one provider?
Competition
What if Jeff Bezos wakes up one morning and decides that in addition to having a bad hair day, he’s also tired of hosting servers that are threatening to garner market share from AWS? What if Microsoft and AWS have their own competing blockchain efforts like this... or this… ? If Costco was renting out space in their warehouses to a hot dog vendor, how long would it be before they shut it down and started selling their own tasty dogs?
Centralization
Let’s not give de facto control of our EOS network to a few powerful corporations. By running Block Producing nodes on AWS, Azure, Google Cloud or any other public provider we are actually centralizing our EOS Network.
For these major reasons, we feel EOS Block Producers need to be on their own hardware in their own data centers. We recommend a design that includes diverse internet circuits, load balancing, hardware firewalls, redundant switching, DDoS mitigation, redundant storage and compute, and multiple geographic locations. To this end, we have invested significant capital and thousands of man hours to build out what we are confident is the most robust and bulletproof infrastructure of any Block Producer candidate. We encourage other BPs to maintain their independence, and not be controlled by major cloud providers. Remember what Spock said in Star Trek II: The Wrath of Khan… “The needs of the many outweigh the needs of the few, or the one.” Please don’t put our network in the hands of big corporations, whether it is a few, or the one.