FWIW, I find the AWS UI much better than the GCP interface. AWS feels much faster to navigate, even though GCP has an SPA-like design, like its other B2B tools.
You know I have to agree with you that AWS UI is more responsive, the UI in GCP is a bit heavy on the JS and sometimes can make the CPU spin. However due to all the reasons stated in the article, I would take that downside any day, twice.
Since all of GCP is available with an API, I'm surprised there aren't third party dashboards. I'd happily pay a percent or two of my bill for an intuitive dashboard at a glance. Especially one that kinda fills the gap between monitoring, alerting, debugging, and manipulating resources.
What you're looking for is datadog. A metrics/monitoring/alerting/debugging/dashboard solution. https://www.datadoghq.com/.
Try a google image search and you will see some examples. There are lots of menus and visualization so you obviously want to try the tool for yourself.
I was once the recipient of a sales pitch for some GCP Apigee products and during the demonstration the control panel glitched at least three different times with loading screens of death and was very slow.
That kind of stuff sticks with you and you know that during an emergency or outage you're going to be battling the UI as well as the underlying problem.
Needless to say we didn't proceed.
AWS might feel a little 2010, but at least I know the control panel is responsive and works. No fluff.
it does not. if you need live migration your software is poorly engineered. the only use case for this is a legacy app that you cannot move away from - but in that case i doubt you’re in the cloud
2. if you want to run your own you’d better know how HA setups work and you can lose at least a machine at ANY point in time (not just when AWS warns you the hardware is failing)
As someone that works solely in a GCP environment for work, I couldn't agree more. GCP products do "just work", but if I had to nitpick, it's that some of their services don't have complete terraform modules (looking at you IAP), but outside of that, their pricing is reasonable, documentation is solid, and we're really happy we ended up going the GCP route.
As someone who just dealt with the questionable state of the gcp docs, I couldn't disagree more, afaics there's really no qa on this stuff. to wit, the official docs for turning on storage bucket uniform access are a missing a parameter, that we only found after turning on http tracing on gsutil. The docs themselves are very spread out, and frequently have errors or inconsistencies (ie use beta v1 of this, v1 of that, and alpha v1 for different resources in the same service). Unlike aws or azure, none of the actual api specs (json data) or even the official cli implementation is in a public repo. For python alone, googlers maintain like 4 different implementations of the api, 'nough said.
I've also had some bad encounters with the GCP docs, particularly around object storage. That was a while ago and may have been fixed. Early on they were not consistent with the actual APIs and poorly organized to boot. It was complicated by the fact that the APIs seem to have shifted.
Amazon overall has done an excellent job on documentation. It's made easier by the fact that they rarely change API behavior once it's deployed.
This article doesn't even mention one of my favorite tools on GCP which is Dataflow. It's really easy to build batch and streaming workflows that can be used for data and machine learning pipelines. It really shows how well the different services within GCP are integrated, since it's trivial to set up PubSub or BigQuery as sources and sinks.
sure. the AWS console has been very hard to use since forever. Some may even go as far as saying that it improved. The UX is not the selling point of a cloud provider.
disagree. I get the sentiment that in the long run an end-user absolutely "shouldn't care", because the infrastructure should be code, if the initial end user onramp sucks (bad UX) then it might give you a negative impression of the system. This impacts other end users, because if adoption has a negative first derivative, you could be in trouble in the long run.
but UX goes beyond just clicky bits on the web. It's also stuff like "does your service take JSON as input and output JSON or XML?". "are critical fields well-named?", "is documentation for your endpoints well-structured and easy to comprehend" which, if the UX is poor, makes your IAC much much harder to reason about when things go wrong.
I think a lot of the issues with AWS mentioned here are mainly the result of 2 factors:
1. AWS having been around longer, and having been vastly bigger and more widely used than GCP for the entire lifespan of both products. AWS is just more expansive/evolved from having piled on more features for more customers over more time.
2. AWS virtually never makes backward-incompatible changes. Every feature of every service and every version of every API since its inception is still functional and presumably will remain that way forever (with a very minimal list of exceptions). So while it's certainly easy to imagine how the entire thing could be streamlined from a blank slate, it's just not how AWS operates.
Meanwhile, Google is absolutely notorious for wantonly EOLing products; see: https://killedbygoogle.com/. Besides the extensive list consumer products (RIP Reader), there are quite a few examples of APIs and cloud services that have been axed. I'm not very familiar with how/if GCP specifically has been impacted by this trigger-happy EOLing, but frankly I think you'd have to have a huge appetite for risk to trust that GCP is not going to pull the rug out from under your business on a whim.
The upside of the never-make-backwards-incompatible-changes approach is that as a customer, I don't have to worry about proactively monitoring for breaking changes to my applications/infrastructure and pre-emptively emergently refactoring/re-architecting them to avoid downtime. I have various little AWS CLI scripts that have been running untouched for years, and they still work. That's a tremendous timesaver and cost-saver whether you're just doing side projects for fun or running enterprise IT.
The downside to this approach is that the product as a whole is an ever-growing spiderweb-snowball of complexity, by design. While some new services/features get added as simplified alternatives to existing offerings (i.e. Amplify, Lightsail), they still exist in an ocean of cruft, and it takes some level of expertise just to be aware of their existence and tease out exactly what aspects they simplify and how they interface with the rest of the ecosystem. If and how AWS resolves this problem dynamic over time remains to be seen; it certainly is a pretty big Catch-22 from a high-level perspective.
So, in short, while GCP is inarguably a more streamlined and user-friendly platform today, it is a bit naïve to make a blanket comparison to AWS on this basis. There are good reasons why AWS is the way it is, and I wouldn't necessarily bet on GCP maintaining its comparative sleekness over time as it may eventually fall prey to the same problems. (Nor would I bet against them avoiding/solving these problems either - there are a lot of very smart people at Google.)
Has Google EOL any Cloud products? I don't remember any being shutdown recently at least. Since these are money-making products (unlike maybe other good customer-facing products), there's a lot less reasons to shut things down IMO
Ah true, although like you said Hire was more a tangent product to G Suite, so not exactly Cloud related, but still business-facing. Thanks for reminding me
Even a small thing like that is a great example of how Google and AWS treat backwards compatibility fundamentally differently. AWS really doesn't EOL things, no matter how 'minor' the impact would be. Look at SimpleDB - it was launched in 2007 and has very clearly been deprecated in favor of DynamoDB[0]. It's not even in the console(!). Yet, it's still operational and usable with the AWS CLI. Everything about it screams "could have been EOL'd years ago", yet AWS dogs on in supporting it and everything else it's ever released until the end of time.
Google's free consumer-facing products with no SLA being shut down... HN loves to complain about this. Any time there's a thread about Google, someone has to complain about the time when they shut down Reader.
There are plenty of APIs and cloud-type products listed in the site I referenced. I don't know what the story with their SLAs or lack thereof was, but it's not like Reader was a one-off thing. (IIRC, there have been some seeming SLA-violation-esque deprecations of Maps APIs...) Google clearly has a culture that is OK with killing off services when it's convenient. Like I said, I don't know if/how this applies or will apply to GCP, but they have enough of a track record that it's perfectly reasonable to be wary.
Both AWS and GCP excel over Azure. Many organizations are strong armed into using Azure as part of their Enterprise Agreements (EA) as part of Microsoft's predatory tactics (they haven't changed one bit) I couldn't imagine someone choosing to use Azure if given a choice.
Agreed, I was forced into using it years ago and still have PTSD from how awful it is. API endpoints randomly return with 500s, block devices hang or just become disconnected, provisioning is extremely slow. The unquantifiable "just works" and general care & polish is missing.
Contrary to the claims of this article I'm very skeptical that the admin UI is much of a success factor when running large applications in public clouds.
Cloud administration is inherently complex. If you are doing anything interesting you'll be managing configuration through tools like Terraform and Ansible. Also, if you don't understand virtual networking on your particular cloud you are going to have problems even there. Any cloud service that gives you good control over networking is by definition going to require effort to configure properly.
39 comments
[ 3.2 ms ] story [ 88.6 ms ] threadTry a google image search and you will see some examples. There are lots of menus and visualization so you obviously want to try the tool for yourself.
That kind of stuff sticks with you and you know that during an emergency or outage you're going to be battling the UI as well as the underlying problem.
Needless to say we didn't proceed.
AWS might feel a little 2010, but at least I know the control panel is responsive and works. No fluff.
Live migration can help you in that case.
2. if you want to run your own you’d better know how HA setups work and you can lose at least a machine at ANY point in time (not just when AWS warns you the hardware is failing)
Amazon overall has done an excellent job on documentation. It's made easier by the fact that they rarely change API behavior once it's deployed.
aws excels at giving you the building blocks and making sure those building blocks work.
unless you’re working at a small scale that’s what you want.
for all the crap aws gets, the documentation is there, the tutorials are there, the services make sense.
gcp is probably going to be around for a while, but i would not bet the farm on it.
in the cloud, today, it’s either aws or azure
but UX goes beyond just clicky bits on the web. It's also stuff like "does your service take JSON as input and output JSON or XML?". "are critical fields well-named?", "is documentation for your endpoints well-structured and easy to comprehend" which, if the UX is poor, makes your IAC much much harder to reason about when things go wrong.
Also I enjoy that GCP has gRPC support.
1. AWS having been around longer, and having been vastly bigger and more widely used than GCP for the entire lifespan of both products. AWS is just more expansive/evolved from having piled on more features for more customers over more time.
2. AWS virtually never makes backward-incompatible changes. Every feature of every service and every version of every API since its inception is still functional and presumably will remain that way forever (with a very minimal list of exceptions). So while it's certainly easy to imagine how the entire thing could be streamlined from a blank slate, it's just not how AWS operates.
Meanwhile, Google is absolutely notorious for wantonly EOLing products; see: https://killedbygoogle.com/. Besides the extensive list consumer products (RIP Reader), there are quite a few examples of APIs and cloud services that have been axed. I'm not very familiar with how/if GCP specifically has been impacted by this trigger-happy EOLing, but frankly I think you'd have to have a huge appetite for risk to trust that GCP is not going to pull the rug out from under your business on a whim.
The upside of the never-make-backwards-incompatible-changes approach is that as a customer, I don't have to worry about proactively monitoring for breaking changes to my applications/infrastructure and pre-emptively emergently refactoring/re-architecting them to avoid downtime. I have various little AWS CLI scripts that have been running untouched for years, and they still work. That's a tremendous timesaver and cost-saver whether you're just doing side projects for fun or running enterprise IT.
The downside to this approach is that the product as a whole is an ever-growing spiderweb-snowball of complexity, by design. While some new services/features get added as simplified alternatives to existing offerings (i.e. Amplify, Lightsail), they still exist in an ocean of cruft, and it takes some level of expertise just to be aware of their existence and tease out exactly what aspects they simplify and how they interface with the rest of the ecosystem. If and how AWS resolves this problem dynamic over time remains to be seen; it certainly is a pretty big Catch-22 from a high-level perspective.
So, in short, while GCP is inarguably a more streamlined and user-friendly platform today, it is a bit naïve to make a blanket comparison to AWS on this basis. There are good reasons why AWS is the way it is, and I wouldn't necessarily bet on GCP maintaining its comparative sleekness over time as it may eventually fall prey to the same problems. (Nor would I bet against them avoiding/solving these problems either - there are a lot of very smart people at Google.)
afaics its called cloud talent in the console now
[0] https://en.wikipedia.org/wiki/Amazon_SimpleDB#Relationship_t...
Azure App Services and SQL database arrives a 1-2 punch for enterprises moving their apps to a PaaS that just works.
Azure is fractally off-kilter.
Cloud administration is inherently complex. If you are doing anything interesting you'll be managing configuration through tools like Terraform and Ansible. Also, if you don't understand virtual networking on your particular cloud you are going to have problems even there. Any cloud service that gives you good control over networking is by definition going to require effort to configure properly.
Just this week I updated an EKS cluster from 1.15 to 1.16 with two clicks.