A 15-minute scan read of this - specifically the sections on the stuff I've worked with the most - suggests this is a very, very good addition to the official documentation.
I would as a minimum recommend anybody/everybody considering AWS to read and think about the "When to use AWS" section. Whilst it is an excellent set of tools that have completely changed the economics of deploying software, there are times when you should use Google Cloud, times you should use bare metal, times you should use Heroku. AWS is a complex beast. Heroku is simple, but has limitations.
There are a bunch of apps I'm thinking about building at the moment where I realise a hybrid approach is best: some of GCP's stack, some of AWS', and a small amount of my own bare metal. Knowing when to choose which is not intuitive and comes with time, but there are big, big clues that will help the uninitiated in that section of this open guide.
Also, if you're looking to the future, the AWS Lambda and Google Functions stuff is perhaps the most exciting stuff to start building knowledge up of now if you're a developer, I think.
> There are a bunch of apps I'm thinking about building at the moment where I realise a hybrid approach is best: some of GCP's stack, some of AWS', and a small amount of my own bare metal. Knowing when to choose which is not intuitive and comes with time, but there are big, big clues that will help the uninitiated in that section of this open guide.
unless you have a metric shitton of money to blow, there's never a good reason to start with that.
The most expensive part of any of those cloud providers is networking. If you need to transfer data from bare metal <-> aws, you'll need direct connect which charges basically an arm and a leg.
Transferring between aws <-> gce is expensive for the same reason. Sure, if you're apple scale and need better data redundancy maybe it's okay. maybe. But that's not an app you think about building as an individual or small company.
I also don't think GCPs stack has anything whatsoever that AWS's doesn't have, so it's odd to mention it in that phrase.
If you'd be so kind as to provide an example application you're thinking about, and the reason each of those is needed for some part of it, I'd be happy to hear it!
Personally, I'm not convinced the price will come down low enough for cloud functions/AWS lambda to ever be cost effective. We've looked at it + API gateway, and it would be orders of magnitude more expensive than our current giant amount of webservers.
Kubernetes (and similar technologies) on the other hand, make it possible to get the same economics as cloud functions while still tying your cost directly to the computing resources you use. Also, it gives you the freedom to (with some pain) move your entire platform to a different provider.
This was exactly my reaction. The tips around Amazon Redshift were spot-on including a few obscure-but-critical ones e.g. the one about many small tables taking up a ton of disk space!
I would as a minimum recommend anybody/everybody considering AWS to read and think about the "When to use AWS" section. Whilst it is an excellent set of tools that have completely changed the economics of deploying software, there are times when you should use Google Cloud, times you should use bare metal, times you should use Heroku. AWS is a complex beast. Heroku is simple, but has limitations.
There are a bunch of apps I'm thinking about building at the moment where I realise a hybrid approach is best: some of GCP's stack, some of AWS', and a small amount of my own bare metal. Knowing when to choose which is not intuitive and comes with time, but there are big, big clues that will help the uninitiated in that section of this open guide.
Also, if you're looking to the future, the AWS Lambda and Google Functions stuff is perhaps the most exciting stuff to start building knowledge up of now if you're a developer, I think.