One of the biggest benefits of Google Cloud is networking. By default GCE instances in VPC's can communicate with all instances across zones and regions. This is a huge plus.
On AWS, multi region involves setting up VPN and NAT instances. Not rocket science, but wasted brain cycles.
Generally, with GCP setting up clusters that span three regions should provide ample high availability and most users don't need to deal with the multi cloud headaches. KISS. You can even get pretty good latency between regions if you setup North Carolina, South Carolina, and Iowa. Soon West Coast clusters will be possible between Oregon and Los Angels (region coming soon).
This is one of the biggest features that you appreciate a lot when you dont have it, and makes global apps incredibly easy. Softlayer has a similar network with default region peering but not as advanced.
Of course anything can be setup using custom VPN but this is a lot more work and will never be as easy, reliable, automated or cost effective.
That being said, AWS is rolling out automatic VPC peering, running on their own private backbones between regions so there should be functional parity soon, although with different price and performance compared to GCP.
It's a feature they have. It might not make up for other parts of their platform that don't fit what you need but we've found their servers to be efficient and their support is quick and helpful.
They're overshadowed now by the scale, efficiency and managed services of the major clouds but can still be useful if you're running on their dedicated machines. Last I checked, Keen.IO runs on softlayer.
Digital Ocean is a far better alternative if you don't want to use the other bigger cloud providers, quite frankly. AWS dedicated servers are also far less expensive and you get more bang for the buck. m4.2xlarge, for example, is the most comparable hourly offering based on memory and CPU cores to SL base dedicated server and outperforms the hell out of it. See here:
I may be completely off here, but isn't this due to their underlying architecture decisions? That is, AWS from the start has kept all regions completely separate, so that problems in one region do not influence another. But GCP has has issues with failure across regions IIRC.
Having a software defined networking spanning across regions and failure cascades across regions are two different things. There's nothing preventing a vendor from presenting to you a single network, while they are actually distinct networks.
It is also potentially due to Google owing their private fiber backbone that connects all regions and as well as their software Defined Network that allow high bandwidth and low latency routing of packets across regions.
Regardless they both cost money to run. Looks like the cheapest NAT gateway[1] is currently $0.045/hr which is about $32.76 per month. Then you also get charged $0.045 per gigabyte transferred as a "data processing charge" in addition to standard AWS data transfer charges.
AWS needs to release a more affordable and simpler feature for inter region connectivity. Even MS Azure has a Vnet to Vnet connectivity option in which traffic flows through the Azure backbone vs the internet and it doesn't cost much.
That Vnet to Vnet is unreliable when you start using it at scale.
We had issues as soon as we started launching instances ( after connecting vnets ) , and azure supports response was to give them the ids so they can manually add them to routing between vnets.
Also BGP routing, was impossible to do beyond their tutorial level setup.
Comments
One of the biggest benefits of Google Cloud is networking. By default GCE instances in VPC's can communicate with all instances across zones and regions. This is a huge plus.
On AWS, multi region involves setting up VPN and NAT instances. Not rocket science, but wasted brain cycles.
Generally, with GCP setting up clusters that span three regions should provide ample high availability and most users don't need to deal with the multi cloud headaches. KISS. You can even get pretty good latency between regions if you setup North Carolina, South Carolina, and Iowa. Soon West Coast clusters will be possible between Oregon and Los Angels (region coming soon).
This is one of the biggest features that you appreciate a lot when you dont have it, and makes global apps incredibly easy. Softlayer has a similar network with default region peering but not as advanced.
Of course anything can be setup using custom VPN but this is a lot more work and will never be as easy, reliable, automated or cost effective.
That being said, AWS is rolling out automatic VPC peering, running on their own private backbones between regions so there should be functional parity soon, although with different price and performance compared to GCP.
Having used SoftLayer and experienced their API, support, and GUI, I would not consider that a redeeming feature.
It's a feature they have. It might not make up for other parts of their platform that don't fit what you need but we've found their servers to be efficient and their support is quick and helpful.
They're overshadowed now by the scale, efficiency and managed services of the major clouds but can still be useful if you're running on their dedicated machines. Last I checked, Keen.IO runs on softlayer.
Digital Ocean is a far better alternative if you don't want to use the other bigger cloud providers, quite frankly. AWS dedicated servers are also far less expensive and you get more bang for the buck. m4.2xlarge, for example, is the most comparable hourly offering based on memory and CPU cores to SL base dedicated server and outperforms the hell out of it. See here:
https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...
http://www.softlayer.com/bare-metal-servers%20
One success story is not enough compared to thousands elsewhere.
I may be completely off here, but isn't this due to their underlying architecture decisions? That is, AWS from the start has kept all regions completely separate, so that problems in one region do not influence another. But GCP has has issues with failure across regions IIRC.
Having a software defined networking spanning across regions and failure cascades across regions are two different things. There's nothing preventing a vendor from presenting to you a single network, while they are actually distinct networks.
Having distinct networks in different regions encourages you to architect your application in a fault tolerant way.
Or the contrary. In most cases there is something to synchronize between regions, like a replica of the data.
With difficult interconnection of regions, it makes it somewhat harder to do, and it can easily end-up with "meh, AZs are good enough".
It is also potentially due to Google owing their private fiber backbone that connects all regions and as well as their software Defined Network that allow high bandwidth and low latency routing of packets across regions.
AWS also has a private backbones and offers (or will soon) VPC peering run on top of this.
I work for AWS.
Just as an FYI you don't have to use a NAT instance there are also NAT gateways which I find easier to manage: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-na...
Regardless they both cost money to run. Looks like the cheapest NAT gateway[1] is currently $0.045/hr which is about $32.76 per month. Then you also get charged $0.045 per gigabyte transferred as a "data processing charge" in addition to standard AWS data transfer charges.
[1]: https://aws.amazon.com/vpc/pricing/
AWS needs to release a more affordable and simpler feature for inter region connectivity. Even MS Azure has a Vnet to Vnet connectivity option in which traffic flows through the Azure backbone vs the internet and it doesn't cost much.
That Vnet to Vnet is unreliable when you start using it at scale.
We had issues as soon as we started launching instances ( after connecting vnets ) , and azure supports response was to give them the ids so they can manually add them to routing between vnets.
Also BGP routing, was impossible to do beyond their tutorial level setup.