Coming from an AWS shop, I guess I don't understand the use case(s) for this. What this enable me to do that I couldn't accomplish by ssh'ing to any of the boxes in my environment?
a. It just works. No need to download and configure the right version of the SDK.
b. Does not timeout when you close your laptop [I hope!].
c. I works on a Chromebook. Possibly not something you care about, but a historical pain point for the consistency of Google offerings.
I guess I still don't see the point but maybe I'm assuming that one is already running a *nix and can either jump into the terminal there or connect a VM in the cloud very easily. The convenience doesn't seem that large.
Ultimately what AWSClassic does is give you a lot of baremetal boxes to drop AMIs on. Google's changing that to the containerized model by offering direct services that are scheduled on hardware. As Kubernetes becomes more and more the primary method for deploying apps on Google's managed services, this approach will pay off more.
But it's worth nothing that for many people this is what Amazon needs to do as well. As VPCs become the mandatory methodology for AWS, it's increasingly annoying just to set up the bare minimum you need to get a capable shell inside your environment. Even experienced AWS users have trouble getting VPCs right given the state of the current documentation.
No, no we don't. It's quite easy, and usually it only takes us a few minutes.
If you use AWS services besides S3 it can get very tricky to not overwhelm your egress and not suffer performance issues. Scaling this configuration in an elastic way is certainly not turnkey in the current VPC environment, and probably won't be until Amazon finishes something like the S3 gateway for them.
And the documentation is in a sorry state.
Please. Even for an advanced VPC configuration, you're looking at 1-2 hours tops for setup. If you want point and click, go to Digital Ocean. Complex tools are always going to have a learning curve.
Also, it's not clear to me why I should have to do that part on my own. The fact I need to engineer a solution for high volume access to AWS Services (besides S3) in a VPC is stupid. Especially when I can just keep using EC2C and honestly have an easier time of it, while also not having to migrate and rewrite existing infrastructure to become VPC-aware.
For someone with 'toomuchtodo' it seems like a very questionable use of time.
We use DynamoDB. A lot of it. It is a non-trivial setup to get a dynamic, scaling solution to route traffic efficiently to the DynamoDB endpoints. Our SQS traffic sometimes also experienced extreme latency when we would send large groups of messages.
So forgive me if I greet your derisive tone and silverbacking with skepticism; I've got a product in the market already. I have correspondence from the AWS support explaining that it is in fact very difficult to operate at the scale we want to with some AWS Services that aren't supported, and the S3 connection was also not trivial. This is especially so if you're managing multiple discrete apps that don't coordinate usage or bandwidth spikes, as is common in large enterprise settings. Which is, ultimately, what we're doing.
> Complex tools are always going to have a learning curve.
There is no justification for the current mess that is Amazon's documentation for the VPC feature set. The only reason they get away with it is that AWSClassic is a giant band-aid which will be grandfathered onto customers with scaled products.
Arguing that things like Heroku or Digital Ocean or managed Kubernetes are bad and EC2 is good simply because it uses a hypervisor model instead of a container model is grandstanding and nonsensical, plain and simple.
The startup world has 0 use for this kind of thinking. What matters is how quickly you can deploy, and how efficiently and inexpensively you can scale if you get a hit. Everything else is ego, and useless in this environment.
There are systems that need AWS's model, but they're for specialist products. The vast majority of products can and do deploy in DO or Heroku just fine. And if they're sustaining people and serving customers, who are we to judge?
> There are systems that need AWS's model, but they're for specialist products.
Netflix. Tinder. Reddit. Yelp. Slack. Foursquare.
AWS' model works absolutely fine if you have systems knowledge. If you're looking for a PaaS, its of course not the solution for you. It feels like your comment is "Why doesn't AWS do what it wasn't designed for?"
The nice part about Google's approach, it gives you both worlds in an interoperable package. But I suppose you're more interested in the silverbacking than the specific technical arguments.
Like a lot of "cloud services", this is indeed nothing you can't do on your own box, and I imagine tens of thousands of people have done it before and will do it again on AWS. Google has now done it in a way that generalizes for everyone. Aside from what it lists on the page (installing the GC SDK and setting up authentication), Google handles all of the opsy stuff you would need to do on your own.
Running a Linux server and installing / authenticating an SDK is not really that hard, of course, but it's one less thing to worry about when developing an app. That's almost always always a good thing.
Maybe if you own the servers.
Since they're Google's or Amazon's servers you have to be able to administer them with some set of Google or Amazon credentials. Otherwise what would you do if sshd crashed?
Kill that instance, and spin up a new one.
A wise BOFH gave a preso that stuck with me "Treat EC2 instances like cattle. When one strays off the farm, put a bullet in it's head."
Don't treat your cloud machines as special snowflakes. Build infrastructure via script.
For grins, I wonder how many root AWS creds are tied to Gmail (read: Google) accounts.