
Why We Moved from Amazon Web Services to Google Cloud Platform - jganetsk
https://lugassy.net/why-we-moved-from-amazon-web-services-to-google-cloud-platform-726c412fd667#.lst7lyful
======
scrollaway
Saw this article the other day, it didn't get upvoted much - I'm not sure why
it's getting to the frontpage _now_ , it really isn't saying anything at all.
I agree with the sentiment though.

I haven't been dealing with AWS very long but I keep hitting limitations.
_Stupid_ limitations.

Sometimes they're a big deal (IPv6 is not available natively. WTF, doesn't AWS
run half the web?). Sometimes they're not a big deal, but still annoying
(DNSSEC isn't supported by Route53). Sometimes, they're unbelievable (AWS
Lambda is Python 2.7 only, no Python 3, in 2016).

Sometimes it's probably something that would be fixed with a single line of
code (Ed25519 is not supported as a keypair). Sometimes, the product itself
just sucks (Cloudformation), requires a Ph.D (IAM) or has ridiculous
limitations (certificate manager). And sometimes, it's just the aws cli that,
in between its million subcommands available, cannot do basic things like
creating S3 redirect rules or update ACM certs.

But _all the time_ , it's the web UI that sucks the most - I have to use a
separate browser for cloudwatch logs and S3 because the native UI is just that
bad. And god forbid you enable 2FA, you'll have to get your phone out twice a
day.

These are all the limitations I hit in a few months using AWS. I wonder how
many more I'll hit within the next year. Is Google actually any better? Seems
to me it's just different kinds of limitations.

~~~
nicobn
Don't get me wrong, I love AWS. I use ~15 products almost everyday. I actually
like how powerful IAM is.

But yeah, CloudFormation just sucks. It does. It's painful because it's a
really good idea but the configuration format is inadequate for the task.

CF should have been implemented using a declarative DSL similar to Puppet from
the start. I've been tinkering with the idea of creating a DSL with a JSON
translation layer but I always assumed AWS would eventually move away from
JSON anyway, making the effort futile. Four years later and still no
improvements. Definitely my biggest disappointment with their platform.

~~~
010a
Am I insane, or are you and the commentators below unknowingly describing
Terraform?

[https://www.terraform.io/](https://www.terraform.io/)

~~~
DigitalJack
I'm glad I'm not the only one who thought cloudformation was difficult.

Terraform is great so far. I am running into some duct-tape issues with
resources shared between two terraformations, though.

------
brechin
As someone who worked at a company that used almost all of the GCP products, I
agree with just about everything in this article. GCP is pretty amazing (and
simple) to deal with. They offer so many features that work very well within
their platform. They have a similar 99.95% SLA on most of their services, and
they often automatically apply credits for missed SLAs (YMMV, this may only
apply when you have account reps paying attention).

The major downsides that I've noticed are: 1) Documentation is lacking (but
improving!) 2) Issues that aren't affecting a lot of customers can sometimes
take a long time to resolve. 3) Many services (including App Engine Flexible
Environments) are still in beta, meaning no SLA, and they recommend against
using them in prod. Unless you have a big paid support contract you'll have no
clue how soon (if ever) things will reach GA.

~~~
jazoom
And they have very few locations of datacentre

~~~
ktta
I think they have more than AWS.

[https://cloud.google.com/compute/docs/regions-
zones/regions-...](https://cloud.google.com/compute/docs/regions-
zones/regions-zones)

~~~
cjg_
Oregon, Iowa, South Carolina, Belgium, Taiwan definitely is fewer than the 11
AWS regions.

------
avitzurel
This article is very hand-wavy (I agree with some of the comments here), but
as a heavy AWS user here are things that bother me

1\. Networking -> I completely agree with the OP here, The networking on AWS
needs to be better. I don't want the strongest machine just to have a better
transfer rate. It makes complete sense to have a micro machine for some
services, but if those services are accessed or access other HTTP/s services,
it will be unnecessarily slow

2\. Pricing -> I have the privilege of working at a company that can afford to
pay 3 year in advance. Even if you do that though Amazon will keep you on the
machine types you purchased and not on the newest parallel machine types. In
which case if you paid 3 year in advance you are often "stuck" on previous
generation instance types.

3\. Someone mentioned CloudFormation here. I completely ditched it in favor of
terraform, CloudFormation looks like a tool from the 90s after using Terraform
(which itself isn't clear of flaws as well)

4\. In terms of VPC and networking I completely disagree with the OP, the
networking and security settings on Amazon are great (if you understand them).
You can define instances that have absolutely no access to/from the outside
world. If you build a secure service, some of your services living in a
"sandbox" makes total sense

5\. App Engine -> The amount of complaints I heard about this service over the
last couple of years are just insane. I heard from multiple users of the
platform that it sucks. While I have absolutely zero experience with it
myself, I tend to listen to people that suffer from it daily.

~~~
scrollaway
App Engine is a joke. It was an interesting and novel idea at the time but it
is _not_ something you want to pick up today (or last year, or the year before
that, or the one before that either).

GAE is a _massive_ lock-in with outdated software in a world where there's so
many better, cheaper, non-lock-in alternatives, even within Google itself.

~~~
boulos
Do you feel the same way about App Engine Flexible Environment (neé Managed
VMs)? That is, is your complaint that GAE Standard _offers_ you all these
services (like Memcache, Task Queues, Datastore) or that you hate the sandbox
it's in?

The GAE team has been (admittedly slowly) pushing the services that were GAE
only into being fully-consumable "Cloud Platform" services (e.g., Cloud
Datastore is the same Datastore that's been "part of" App Engine forever, but
now accessible from anywhere).

It's your choice to use Datastore, and I respect that you would chose to avoid
it, but the _basic_ PaaS idea of "here's some code, run it for me as a web
endpoint" is still compelling even today.

Disclosure: I work on Google Cloud.

~~~
scrollaway
My impression of GAE is that on top of the core issues of the platform's (lock
in by design, outdated by design), it is also very much unloved by Google and
has received very few updates. I stayed away from it so I could be wrong.

But to answer your question, I don't know anything about that Amazon service
but I would feel the same way about similarly-designed competing product.
IMHO, no informed person would ever pick proprietary, lock-in-heavy PAAS
solutions.

~~~
manigandham
> IMHO, no informed person would ever pick proprietary, lock-in-heavy PAAS
> solutions.

This sounds like your personal bias and is clearly not true. Business doesn't
work like this and you would be surprised if you looked at just how much
proprietary software runs the world.

Lock-in isn't a thing to fear, it's a natural spectrum of using any service.
The more specialized that service, the more work will be involved if you need
to move away.

The real question is if the risk is worth it. Do you really need to switch?
Are you worried that Google or AWS will somehow disappear before your business
does? If not, what is the big deal?

~~~
scrollaway
I did preface with "IMHO" (in my humble opinion). I'll give you it's not very
humble, but it's an opinion.

You're conflating two things though: Lock-in as a whole, and _unnecessary_
lock-in like GAE's. Yes, lock-in is a choice to make and not always an
incorrect one. But I can safely say no informed business should/would pick
Adobe Flash over HTML _today_ for, say, internal web apps. Adobe Flash is
fairly old and legacy technology, deprecated in all but name for that scenario
and includes a fairly significant amount of lock in due to its proprietary
nature requiring you to rework your entire application were you to change to
an alternatire. Sounds familiar?

~~~
manigandham
There is no such thing as "unnecessary" lock-in, it's just how the service is.
Take it or leave it. Just because you think it's unnecessary doesn't change
how that service is offered. And so what if there is work to do? Again, that
is what "lock-in" is by definition = the work involved to move away.

You weigh the risks and see if the potential work (that might not ever need to
be done) is worth the benefits offered today by that service. That's what an
informed business does.

------
jread
Word of caution - we've observed 2 global (all regions down concurrently)
networking outages on GCE this year. 18 minutes on April 11 and 1.5-1.7 hours
last night (except for us-west1 - down only 10 minutes):

[https://status.cloud.google.com/incident/compute/16015](https://status.cloud.google.com/incident/compute/16015)
[https://status.cloud.google.com/incident/compute/16007](https://status.cloud.google.com/incident/compute/16007)
[https://cloudharmony.com/status-for-google](https://cloudharmony.com/status-
for-google)

~~~
snewman
Wait: seriously, a 1.5 hour multi-region GCE outage just last night? That
would be huge, how is it that we haven't heard about this? The linked /16015
status report doesn't have much information.

~~~
boulos
The incident report isn't done yet, so please be patient as the team finalizes
the root cause and next steps. However, it didn't affect all routes, VMs, etc.
and you'll see that when they publish the IR next week.

~~~
jread
FYI - we verified outages from hundreds of last mile routes using Ripe Atlas
probes with failure rates in the range of 86-96%.

------
mrharrison
Yes, yes, yes, I am also a GCP cheerleader. It's so easy and intuitive to use.
A load balancer is called a load balancer, an instance is called a compute
instance, SQL is called SQL etc.., no AWS name deciphering. GCP's sidebar UI
navigation is a dream compared to AWS's mind numbing grid of features. I had a
fault tolerant highly scalable system up in hours, and I'm not a dev ops guy,
I mostly do frontend.

------
rpedela
For me, it is primarily about Postgres. If Google Cloud had an equivalent
offering to Postgres RDS then I would seriously consider it. I think RDS is
one area where AWS is significantly better than many of their competitors. You
can use any of the major relational databases and they handle backup,
failover, read slaves, encryption at rest, etc.

~~~
matrix
Ditto. If Google offered an equivalent of RDS PostgreSQL, I'd switch tomorrow.

~~~
boulos
Even if it were in Alpha / Beta? What if it didn't have point-in-time
recovery, etc.? Just looking for when we can pencil you in ;)

------
rigocalin
GCE has some major limitations. They just introduced static IP addresses 2
months ago..and I had to re-create all my servers to make use of the static
IP.

Then, you either assign a public IP to each machine, or build yourself a
solution...luke a NAT gateway. Google does not offer a service like this.

The machine that are part of the same subnet cannot talk to each other
directly.. they have to go via the google gateway. This reduces the posibility
of implementing High Avalability solutions that are based on broadcast or
Virtual IP (MS SQL, Windows failover, vrrp...etc).

Labels that you apply to VM's or firewall rules are free text without the
possibility to select from a labels list/cloud or type a new one...accidents
can happen.

The MySQL solution is only reachable via INTERNET!!!. They seems to have a
beta for using a local socket if you install a sql proxy on each server where
you need sql db access...but not in production.

No support for MS SQL.

~~~
lobster_johnson
Another odd limitation: No support for internal load balancers; all LBs must
be public. They have it as an alpha release available on request, so it's
coming, but it's a serious deficiency right now.

The lack of a hosted VPN solution is also weird.

~~~
boulos
You don't have to tell us, internal LB was a long time coming. As for hosted
VPN, do you mean something different than our Cloud VPN offering? (
[https://cloud.google.com/compute/docs/vpn/overview](https://cloud.google.com/compute/docs/vpn/overview))

~~~
lobster_johnson
By VPN I mean something that can be used individually by developers from their
own machine (is there a proper technical term for this type?), not static
point to point from a site such as an office (which is what CloudVPN seems
made for).

We ended up setting up OpenVPN, which shouldn't be necessary. SSH is great and
all, but when you add Kubernetes and other sensitive things like dashboards,
you really want to virtualize everything and hide every internal service
behind a proper, solid VPN gateway.

~~~
MustardTiger
>is there a proper technical term for this type?

Generally individual users connecting to a VPN are called road warriors, even
if they're not on the road and always connect from the same place.

~~~
lobster_johnson
Not type of developer, I mean type of VPN. :-)

~~~
MustardTiger
Yes, that's what I mean. It is called a roadwarrior VPN. As opposed to a point
to point VPN.

~~~
lobster_johnson
Ah, okay. I've never heard that term before, except about people.

------
1_2__3
That was so much handwaving in an article that if you put your palm in front
of the screen you'd hear clapping.

------
oellegaard
"Moreover, people you invite to projects must be Gmail or Google App users"

Potentially a deal-breaker for us. We had a LOT of issues accessing various
Google services after switching from Google Apps to Office 365, which is
cheaper and includes the office suite which the rest of the world use.

~~~
pmontra
Just create accounts for logging in into GCP? They don't have to really use
gmail or be logged in into Google all the time. They could use a separate
browser for GCP. I'm doing that when I have to use Google Drive.

~~~
fulafel
Just the linkage into a Google account is still a liability: last time I tried
to register with an employer email address, the process failed and further
registration attempts with that email address were blocked. And there was no
number to call.

------
meddlepal
I'm slowly moving over some my companies stuff from AWS to GCE/GKE. The
platform may not be as mature but it feels a whole hell of a lot more well
thought out and put together. Also hosted Kubernetes is a big deal for us
since we really don't want to manage that ourselves but would prefer to use an
open source offering for containers compared to ECS.

~~~
boulos
Glad to hear it!

------
danellis
I've tried both AWS and GCP (as well as several smaller VPS providers), and I
definitely preferred working with GCP. AWS has plenty of features, but it all
gets bewildering at times, whereas GCP seems to have a much more nicely
presented UI.

But I have $15,000 in AWS credits from Stripe's Atlas program, and that was
enough to make me reluctantly migrate from GCP to AWS. It means I can do
things the "right way" instead of the "cheap way".

It's unfortunate Google couldn't offer something similar.

~~~
rstupek
I thought the opposite. Google's UI is bewildering, nothing makes logical
sense with how its put together. Disjointed pieces. Poor documentation.
Incomplete API samples that didn't compile even for its own language (golang)

~~~
eeeeeeeeeeeee
Agreed. And this isn't the first Google interface that I find completely
unintuitive. My first foray into the Google docs was trying to get oauth
working. The developer console is confusing and not laid out well.
Documentation can sometimes point you in one direction, only to realize you're
about to implement something that will be end-of-life in months.

AWS Console is not perfect, but IMO, it's much more clear where I need to go
to find things, even without reading a single piece of documentation. And I've
rarely had issues with AWS documentation not being clear and correct.

~~~
vacri
I only use the Google Apps for Business from Teh Goog, and while it's nice,
the documentation is hard to navigate and not so hot. I expect a little bit of
bitrot from such large product lines in the documentation so I understand a
bit of staleness, but finding the right documentation and then trying to skim
through it... it's frustrating and poorly laid-out in Google, in my opinion.

Maybe GCE docs are better, though.

------
omegaworks
Reads more like an advert for a buffet than a reasoned take on the
architectural and business tradeoffs. Detailed price breakdowns are difficult
to read? That's your argument? Really? "By developers, for developers!" so
original. [0]

I expect more effort to go into this from a technical perspective. Give me
some workload / price differentials. Examples of architectures that are
simpler on GCP then AWS.

My app relies on a hybrid of Firebase and AWS for the heavy assets. Still
trying to justify the move to Google Firebase for the full stack. I'm the only
dev so it's time and energy I can't spend on frontend iteration helping real
users.

0\. [http://pbskids.org/zoom/](http://pbskids.org/zoom/)

~~~
boulos
In a side thread, the quizlet folks mention their real-world experience and
reasoning for coming to GCP. In your case, as a Firebase customer, the
integration is already there and you could start adding pieces over time. As
the integration between Cloud and Firebase improves, I'm guessing you'll find
more reason to "just do it on Google Cloud". Ping the Firebase people about
their current Alpha programs ;).

Disclosure: I work on Google Cloud.

------
user5994461
Good. We're finally seeing people migrating to the better platform =)

This article is addressing that most of the GCE services are simpler and a lot
easier to use and manage than the AWS counterpartS. (That final S being
important, having many small and unpolished pieces just contribute to the
complexity.)

It goes hand in hand with what I had already written about the platform.
Expect GCE to be 20-50% cheaper and 1-3x faster:

[https://thehftguy.wordpress.com/2016/06/15/gce-vs-aws-
in-201...](https://thehftguy.wordpress.com/2016/06/15/gce-vs-aws-in-2016-why-
you-should-never-use-amazon/)

[https://thehftguy.wordpress.com/2016/06/22/a-simple-cost-
com...](https://thehftguy.wordpress.com/2016/06/22/a-simple-cost-comparison-
between-gce-an-aws/)

When you see that GCE has less market revenues, you should keep in mind that
GCE could be half the price of AWS in average (yep, no kidding). That means
the actual gap in customers is way smaller than it appears at first sight ;)

With that being said. Both platforms are relatively new and spinning services
like mad, they both have important features missing (albeit not the same
ones.)

------
rajathagasthya
> Amazon’s awesome, but Google Cloud is built by developers, for developers,
> and you see it right away.

Isn't that what AWS was also built for initially? For internal use by
developers? I see this statement from time to time in articles like this.

~~~
crucifiction
It is a marketing material, not an article. Very thin on details with every
point somehow being in GCE's favor? There is nothing AWS does better or they
liked better?

------
godisdad
so triggering. but mainly my fear in using GCP is this: Google is a product
psycho, this is not their core business, I get the feeling that anything about
GCP could change or disappear at any time for any reason and I as the customer
is left to react to these changes.

~~~
melvinmt
> Google is a product psycho, this is not their core business

So you're advocating we should trust the book vendor?

~~~
placeybordeaux
AWS is the cash cow of amazon for now. They get their safest margins there and
revenue to match.

~~~
melvinmt
Yes, exactly.

That's why GCE should be as important to Google as AWS is to Amazon while
arguably both have a different "core business".

------
pdq
The same way TodoMVC [1] has standardized Javascript framework 'Hello World'
comparisons, someone should make an up-to-date CloudApp matrix which shows a
basic cloud benchmark app in a matrix comparison for Amazon, Google,
DigitalOcean, Vultr, etc. so users can see basic price/bandwidth/performance.

There's so much Enterprise Buzzword Bingo that Amazon and Google try to
confuse you on as to why there service is magically better, but IMO the
biggest selling points for startups are price/bandwidth/performance. And the
prices and machine configurations change all the time.

[1] [http://todomvc.com/](http://todomvc.com/)

------
dkopi
"Amazon’s awesome, but Google Cloud is built by developers, for developers,
and you see it right away."

AWS is built by developers for developers as well.

Most of the complaints here about AWS aren't actually about AWS not being "for
developers", but about AWS requiring a certain learning curve.

It's a perfect trade-off between power and flexibility vs agility.

~~~
sjellis
I think that it's fairer to say that it's built by enterprise technical people
for enterprise technical people. Things like the fine-grained control over
networking and resource permissions are hallmarks of enterprise tech.

That's not to say that these things don't solve real problems, but they are
the problems of big organizations. Smaller teams building pure-cloud products
don't have the same problems, and may not even have people with Big Corp
experience.

AWS is the Java of cloud platforms.

------
ocdtrekkie
"Moreover, people you invite to projects must be Gmail or Google App users" \-
I'm trying to figure out why walled garden lock-in is being treated as a
feature.

It sounds like a lot of his reason for switching is simplicity. From this
article, it sounds like AWS has a lot more options and control, and GAE just
does what it wants or thinks is best. I suppose to some, the latter may be
appealing, but at least the author is honest with a "your mileage may vary".
Willing to bet this simplicity costs a lot of options other companies may wish
to use.

------
cagataygurturk
You moved because you did not understand how to run AWS wisely.

~~~
tbrock
Most people don't have time for that. Just give me kubernetes or GAE.

I'm convinced Google's infrastructure play will ultimately win the hearts and
minds of developers because they understand this.

------
cyberferret
We've been using AWS since nearly the day it was released. Overall I really
like it, but I haven't dived deep into the GC platform so I cannot really give
a definitive comparison.

A couple of things that baffle me about AWS though -

* You can purchase reserved instances from anywhere in the world in a few seconds, but WHY when I want to on sell an unused reserved instance in the marketplace, do I HAVE to have a US bank account for Amazon to pay my revenues into?? Why can they just not credit my existing account which I pay thousands per month to them?

* We still battle with occasional high latency spikes for EC2 instances talking to RDS instances within the same VPC! Continuous "MySQL server has gone away" log messages. Ironically, we have absolutely no trouble with Non-VPC EC2 instances that use classic bridging to talk to the same RDS server within the VPC!

We thought to simplify our architecture by putting everything in one VPC for
better security and ease of maintenance, but had to go back to a cobbled half
and half solution to maintain performance. Hence why we now have a few
reserved 'VPC only' instances which we cannot recoup costs by onselling in the
marketplace... :(

~~~
dc_gregory
Raise a ticket; I see no issues VPC => RDS endpoint at all. Might be something
gone sideways in a layer you can't see.

------
sandstrom
I use AWS extensively and it has many benefits. That said, I think they need
to rethink some thing if they want to stay ahead of Google, Digital Ocean,
etc.

Some thoughts:

## More focus on core products

\- Still no IPv6, it's 2016.

\- EC2/VPC (compute) didn't have a simple NAT-instance until a few months ago.

\- S3 (storage) still has nothing like Nearline (GCE) and Glacier is so
confusing and complicated that few bother using it.

\- ELB (Load Balancer) still has scaling problems (with bursts).

\- Still only a single public key per instance, why?

\- Can only use ACM certificates for CloudFront if they are in us-east-1
(despite ACM being available in other geographies and CloudFront is global).
Nothing major but weird.

\- S3 has like a handful of different ways of setting permissions (per file,
per bucket, iam, and some weird old xml-format). Why not simplify this?

## Interfaces are terrible

\- Basically the entire console UI is low quality.

\- Same with APIs, they could use a lot more polish.

\- This is the API call to create a CloudFront (CDN) distribution:
[http://pastie.org/10931494](http://pastie.org/10931494) (no offence, but it
looks like a group of schizophrenic monkeys designed that API).

## Think less about press-releases

\- Apparently AWS force everyone to write the press-release for every product
before designing[1].

\- While it's good to keep the end-goal in mind I think many important details
are lost.

\- The press-release-thinking focus too much on features and too little on
quality and (even more important) refinements to existing things.

## Release fewer features

\- Every year on ReInvent [AWS conference] they tout how many hundreds of new
features they've released[2]. I wish they'd release far fewer features and
make them great instead (+ refine existing stuff).

[1]
[http://www.allthingsdistributed.com/2006/11/working_backward...](http://www.allthingsdistributed.com/2006/11/working_backwards.html)

[2] [https://s3-eu-west-1.amazonaws.com/vpblogimg/2015/04/Aws-
Sum...](https://s3-eu-west-1.amazonaws.com/vpblogimg/2015/04/Aws-
Summit-2015-London-innovation.jpg)

~~~
cthalupa
>\- EC2/VPC (compute) didn't have a simple NAT-instance until a few months
ago.

Managed NAT is new, but the nat instances that previously existing could be
spun up without any configuration outside of disabling src/dst check and
configuring a route to point to them, and they've existed for many years.
[http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NA...](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html)

>\- S3 (storage) still has nothing like Nearline (GCE) and Glacier is so
confusing and complicated that few bother using it.

S3 Infrequently Accessed? [https://aws.amazon.com/s3/storage-
classes/](https://aws.amazon.com/s3/storage-classes/)

~~~
mullen
What gets me is that S3 is probably the easiest thing to learn about in AWS. I
would understand if he complained about the million things you can do in EC2,
but in S3 there is not much choice; S3, S3-IA, S3-RR. Throw in Glacier and
there still are not much to get confused on.

~~~
sandstrom
I'm using S3 extensively and know the product pretty well.

Still, I think Nearline easily beats Glacier on simplicity and clarity. With
Nearline it's super-obvious how long time retrievals take and what the costs
are.

\--------------

## Nearline

Q: How much does it cost?

1 cent per GB & month in storage. Plus 1 cent / gb of transfer (retrieval).

Q: How fast can I retrieve data?

Access times sub 1 second.

SOURCE: [https://cloud.google.com/storage-
nearline/](https://cloud.google.com/storage-nearline/)

\--------------

## AWS Glacier

Q: How will I be charged when retrieving large amounts of data from Amazon
Glacier?

You can retrieve up to 5% of your average monthly storage, pro-rated daily,
for free each month. For example, if on a given day you have 75 TB of data
stored in Amazon Glacier, you can retrieve up to 128 GB of data for free that
day (75 terabytes x 5% / 30 days = 128 GB, assuming it is a 30 day month). In
this example, 128 GB is your daily free retrieval allowance. Each month, you
are only charged a Retrieval Fee if you exceed your daily retrieval allowance.
Let's now look at how this Retrieval Fee - which is based on your monthly peak
billable retrieval rate - is calculated.

Let’s assume you are storing 75 TB of data and you would like to retrieve 140
GB. The amount you pay is determined by how fast you retrieve the data. For
example, you can request all the data at once and pay $21.60, or retrieve it
evenly over eight hours, and pay $10.80. If you further spread your retrievals
evenly over 28 hours, your retrievals would be free because you would be
retrieving less than 128 GB per day. You can lower your billable retrieval
rate and therefore reduce or eliminate your retrieval fees by spreading out
your retrievals over longer periods of time.

Below we review how to calculate Retrieval Fees if you stored 75 TB and
retrieved 140 GB in 4 hours, 8 hours, and 28 hours respectively.

First we calculate your peak retrieval rate. Your peak hourly retrieval rate
each month is equal to the greatest amount of data you retrieve in any hour
over the course of the month. If you initiate several retrieval jobs in the
same hour, these are added together to determine your hourly retrieval rate.
We always assume that a retrieval job completes in 4 hours for the purpose of
calculating your peak retrieval rate. In this case your peak rate is 140 GB/4
hours, which equals 35 GB per hour.

Then we calculate your peak billable retrieval rate by subtracting the amount
of data you get for free from your peak rate. To calculate your free data we
look at your daily allowance and divide it by the number of hours in the day
that you retrieved data. So in this case your free data is 128 GB /4 hours or
32 GB free per hour. This makes your billable retrieval rate 35 GB/hour – 32
GB per hour which equals 3 GB per hour.

To calculate how much you pay for the month we multiply your peak billable
retrieval rate (3 GB per hour) by the retrieval fee ($0.01/GB) by the number
of hours in a month (720). So in this instance you pay 3 GB/Hour * $0.01 * 720
hours, which equals $21.60 to retrieve 140 GB in 3-5 hours.

First we calculate your peak retrieval rate. Again, for the purpose of
calculating your retrieval fee, we always assume retrievals complete in 4
hours. If you request 70GB of data at a time with an interval of at least 4
hours, your peak retrieval rate would then be 70GB / 4 hours = 17.50 GB per
hour. (This assumes that your retrievals start and end in the same day).

Then we calculate your peak billable retrieval rate by subtracting the amount
of data you get for free from your peak rate. To calculate your free data we
look at your daily allowance and divide it by the number of hours in the day
that you retrieved data. So in this case your free data is 128 GB /8 hours or
16 GB free per hour. This makes your billable retrieval rate 17.5 GB/hour – 16
GB per hour which equals 1.5 GB/hour. To calculate how much you pay for the
month we multiply your peak hourly billable retrieval rate (1.5 GB/hour) by
the retrieval fee ($0.01/GB) by the number of hours in a month (720). So in
this instance you pay 1.5 GB/hour x $0.01 x 720 hours, which equals $10.80 to
retrieve 40 GB.

If you spread your retrievals over 28 hours, you would no longer exceed your
daily free retrieval allowance and would therefore not be charged a Retrieval
Fee.

Q: How is my storage charge calculated?

The volume of storage billed in a month is based on the average storage used
throughout the month, measured in gigabyte-months (GB-Months). The size of
each of your archives is calculated as the amount of data you upload plus an
additional 32 kilobytes of data for indexing and metadata (e.g. your archive
description). This extra data is necessary to identify and retrieve your
archive. Here is an example of how to calculate your storage costs using US
East (Northern Virginia) Region pricing:

Your storage is measured in “TimedStorage-ByteHrs,” which are added up at the
end of the month to generate your monthly charges.

Q: How long does it take for jobs to complete?

Most jobs will take between 3 to 5 hours to complete.

SOURCE:
[https://aws.amazon.com/glacier/faqs/](https://aws.amazon.com/glacier/faqs/)

~~~
boulos
Ha! This is a great "write up". I'll pass it along to our heads of storage to
put on slides ;).

I'd like to add one piece I always forget: with S3-IA, you pay for a minimum
of 128 KB, which for apps with tons of small objects really adds up!

Disclosure: I work on Google Cloud.

------
jstepka
related industry review;

* [http://siliconangle.com/blog/2016/08/05/aws-microsoft-azure-...](http://siliconangle.com/blog/2016/08/05/aws-microsoft-azure-clear-leaders-in-gartners-iaas-magic-quadrant/)

day to day i work with AWS, Azure, and Google quite a bit -- from what, in
terms of investment, i would say gartner is accurate.

i'm not sure why digital ocean wasn't taken as serious.

------
mluggy
Hi guys, I'm the original poster. Sorry for joining so late. I read each and
every feedback and also updated the medium article. In no particular order:

1) Didn't mean to hand-wave. For the last few months GCP was the new shiny toy
for me. I got over excited and plan to do deeper post, battling 2 or more
products (i.e Kinesis vs. Pubsub)

2) Not anti-AWS at all. I still find it wonderful:
[https://lugassy.net/search?q=aws](https://lugassy.net/search?q=aws). what
really flipped me was this:
[https://twitter.com/mluggy/status/727764607176159232](https://twitter.com/mluggy/status/727764607176159232)
and other small anonyances

3) Downsides to GCP. Certainly! added to the article

4) For developers, by developers. I realize this was tacky. Let me try again
with 4 examples: a) Trace/breakpoints in production b) Connecting through
virtual socket files instead of tcp c) writing and collecting logs centrally
with console.log and specifically d) DATAFLOW which is architecturally
brilliant (AWS add "Streams" to every new product where GCP simply treat every
product as source and/or sink)

5) Yes I favor GCP for simplicity and dev-friendliness. I don't want to train
people for AWS devops/gotchas. I don't need sophisticated IAM and VPC to feel
smart. GCP ui/quickbar is nicer. For example networking is all on one page.
Most products are properly named (CDN instead of CloudFront, DNS instead of
Route53, Pub/Sub instead of Kinesis)

6) GAE. I was exposed to some horror stories about its and datastore early
days. History aside, I use it today through Flexible VMs which is really
docker under the hood + ability to SSH + easy deployment/versioning + cool
tracer/debugger. My code is Node.js and haven't coded any GAE specific
necessity

Again loved the comments. keep it going!

------
ivarrian
We have several workloads on AWS and we are mostly happy with it in spite of
having several gripes. Google does not have a region in Australia, preventing
us from even considering it. If anyone from the GCE team is on here, are there
any plans to come down under?

------
eeeeeeeeeeeee
"Moreover, people you invite to projects must be Gmail or Google App users
which are secure by default and usually already set up."

Uhh...no. Why would anyone assume some random Gmail account is secure by
default?

~~~
boulos
I wish they wouldn't have called these a "Google Account", but you can use any
email provider now to sign in/up with Google.

Disclosure: I work on Google Cloud, so if you sign up I indirectly ... take
your money?

------
Scarbutt
With google cloud sql and amazon aurora being mysql compatible do any of you
get the temptation of starting your projects with mysql instead postgresql?

~~~
caleblloyd
Google Cloud SQL runs outside of your network (on a public IP). Thus it
doesn't respect your firewall rules and can't use internal network addresses.
I run my own replicated compute engine mysql nodes for this reason. Amazon RDS
and Aurora were superior DBAAS products when I was using AWS. Kubernetes on
Google Container Engine is ultimately what convinced me to switch though.

------
Mayzie
Really want Google Cloud to be an option for us - but given that they lack a
Sydney/Australian data centre means they miss out on a lot.

------
tmaly
What would the equivalent of say a $20 node on Digital ocean cost on the
Google Cloud Platform?

~~~
jahewson
Between about $25 and $40 depending on how you configure the machine. GCP
doesn't offer exactly the same configurations as DO.

~~~
boulos
Despite me working on GCE, I have to give a shout out to all the hosts like DO
that include a hefty amount of network egress in the price. The network is
heavily overcommitted (how many of you actually send X GiB/month/droplet?),
less reliable, etc. but for those that use it to serve images for "don't care"
it can't (yet) be beat.

Disclosure: I work on Compute Engine and Cloud and want your business.

------
sandGorgon
The biggest problem with Google Cloud is _data store_ lockin..which is worse
than programming language lockin.

I would move to them in heartbeat if they had anything like postgres RDS ...
But Google seems to love it's own version of MySQL.

Anybody know if this is on the roadmap ?

~~~
hoodoof
Why is it such a big deal, why not just run Postgres yourself?

~~~
sandGorgon
Why can't I run my own servers then ? The whole point of AWS is moot then.

Between everything else, database is the single most critical aspect - and
there's a huge value for a high availability system.

------
jvehent
Does anyone have feedback running app at scale in Google Cloud for more than
one year?

~~~
pbbakkum
We've been running it for about a year to power Quizlet - overall things have
been good and we're happy. AWS and GCP are complicated enough that they're
tough to compare holistically, but on most of the things we care about we find
GCP to be equivalent or better (sometimes significantly) than AWS. It really
does have better networking and disk technology, and the pricing is much
better. Here's the analysis we did: [https://quizlet.com/blog/whats-the-best-
cloud-probably-gcp](https://quizlet.com/blog/whats-the-best-cloud-probably-
gcp).

Rough patches are:

\- Live migration is sometimes not seamless.

\- Pub/sub is missing some core features.

~~~
BrandonY
Can I ask what the Pub/sub features you miss are?

~~~
ryangordon
Mainly Pub/Sub does not let a single subscription subscribe to multiple topics

------
known
Unlike AWS, GAE is very easy to use.

------
pw
Anyone run Ruby on GAE's new "Flexible Environment"?

~~~
matt4077
Thought about it, but I believe it was the pricing model that made it rather
unattractive compared to just running Compute Engines.

------
westoque
Did you also investigate moving to Heroku rather than GAE?

------
hoodoof
IAM is complex because it is powerful. Unfortunately.

------
serge2k
> Want to run a message bus? AWS will make your head spin with SNS, SQS,
> Kinesis, Kinesis Streams and Kinesis Firehose. GCP has only Pub/Sub which
> just works and is insanely scalable.

This point is oddly weak in comparison to the others.

> Amazon has one of the most confusing IAM. While it is nice to set up a role
> to only allows usage for a particular resource from a specific device and
> times of day, you end up spending most of your time debugging policies.

Haven't used GCP, but I didn't mind IAM. Missed it when I waas trying to
figure out Azure stuff.

> We moved because we wanted to work on infrastructure that runs YouTube,
> Gmail and Google Analytics. We moved because Google is fair, much more tech-
> savvy and launch products that just works.

ugh. Perfectly fine article now just reeks of google "fanboy-ism".

~~~
cheeseprocedure
> This point is oddly weak in comparison to the others.

Agreed - it was senseless. SNS/SQS aren't particularly complex and they scale
like crazy. Kinesis is something else entirely (N-hour record retention
w/arbitrary consumers and offsets) and doesn't even belong in the comparison.

> ugh. Perfectly fine article now just reeks of google "fanboy-ism".

Do Google's core products actually run on GCP these days? I was under the
impression they do not.

~~~
bdcravens
> Do Google's core products actually run on GCP these days? I was under the
> impression they do not.

Not really. They are influenced by, but the same, code as runs Google. (for
instance, Kubernetes is based on Borg)

------
justinlardinois
I found Google App Engine difficult to work with as recently as two years ago,
just for a small proof-of-concept app. It took a lot of shoehorning to use
third party Python libraries, the file upload API is just weird, and the admin
panel was buggy.

Also, another random oddity: somewhere in one of its built in libraries there
was a function for validating email addresses. It was returning true on a
bunch of very obviously bad address formats, so I looked up the source and
found that all the function did was verify its argument wasn't the empty
string.

I imagine GAE is better now, but my first experience with it left a bad taste
in my mouth.

~~~
jscholes
> Also, another random oddity: somewhere in one of its built in libraries
> there was a function for validating email addresses. It was returning true
> on a bunch of very obviously bad address formats, so I looked up the source
> and found that all the function did was verify its argument wasn't the empty
> string.

My favourite comment of the whole thread.

