Google not Amazon. Make fantastic savings in a server-less world | Hacker News Reader

Google not Amazon. Make fantastic savings in a server-less world

in.3wks.com.au

25 pointsvgt23 comments

Excuse me for being so stubborn, but this article reads like a paid for piece by Google. There is not enough information about who Andrew Walker is, and last time I checked, you needed to have some real professional help to create those kind of infographics.

Oh, and I have just checked, and I really hate when people do this without a disclaimer: "3wks has been a Google Cloud Services Partner since 2012, building digital solutions for enterprise customers and public sector organisations specialising in web and mobile solutions on GCP."

My suspicion as well, how do they get the color palette so on point. Did a google image search, seems like this blog post are the very first one to use those images, so they must have talked with Google's PR team, otherwise they must have an excessive budget to spend their designers' time to advocate other people's products.

I doubt it is for free.

EDIT: they even get AWS's color palette right:

https://cdn-images-1.medium.com/max/1600/1*ypBcvVoRIWfirQTBq...

The person on the left.

https://cdn-images-1.medium.com/max/1600/1*YrtTkA-xV_eincZV6...

See the machine on the right, it resembles the yellowish color for AWS.

OK, it is in this this guy's interests to "sell" Appengine, but he's absolutely right. And I have no skin in the game except as a very satisfied user.

Our startup happened to get in on Appengine early on, and we went with it for exactly the reasons he puts forward. At the end of the day we spend all our time building our apps, instead of being diverted every time the mail server crashes, or a package needs a security upgrade, or our OS needs updating, or a hard drive dies, or a routing table gets corrupted, or replication fails between databases, or the load balancer is doing something strange. When any of those things does happen, I know the best sysadmins on the planet are jumping to fix it.

Having said that, there are a couple of provisos you need to bear in mind:

1. If you need to do anything outside the Appengine ecosystem (using unusual protocols or ports for instance), you're going to have to do it outside Appengine.

2. You have to write to Appengine's datastore. There are alternatives (MySQL for instance) but none of them give you automatic concurrency, scaling and redundancy. This is more painful, but it means if you ever hit the big time, you're covered.

I always imagined what would happen if Oprah mentioned our service on her show. If we had built on AWS (or Azure, GCS or other IaaS), I'd be tearing my hair out provisioning load balancers, web servers and sharding databases. With Appengine, all I'd need to provision would be a crate of champagne.

The article mentioned the Royal Wedding website. This was a great example of Appengine's strength, going from zero to thousands of hits a second and then back to zero. If you'd done it with AWS (or even worse, real hardware), imagine the difficulty of estimating the number of machines you'd need, and the cost of provisioning them. If you have a "bursty" service, Appengine just works and you pay for what you actually use.

And that's the other thing - what you pay is minimal. The Appengine user group is full of people complaining that it is more expensive than $CHEAP_HOSTING_PROVIDER, but as soon as you factor in any sysadmin time - or lost app development time - you come out ahead. We run three services with up to 2 million users, and the monthly cost is in two digits.

The article makes some good points though:

That’s like getting a turkey to vote for Christmas right? In fact IT is the department least accustomed to being automated. "We’re the guys who automate everyone else aren’t we? What’s this — now our own jobs are at risk? Woah." But it’s happening regardless and IT will resist it like all the other departments did. It’s human nature.

But the conclusion is... Unsettling, to say the least:

Enter the CFO who, in my recent experience, is the voice of reason. Now, more than ever, I see CFOs taking the lead in arbitrating technology decisions. This is the correct approach. IT must relearn the vocabulary of business: money.

Has a good CFO ever been a decisive factor in why a startup succeeds? I'm not saying they're not valuable, but if the CFO is making your technology decisions then it seems like you've already lost.

I thought you were exaggerating until I clicked through to the article.

Every single infographic uses Google's color palette...

he's the guy who gets your product delivered by wednesday after meeting with you on monday. It's right there in the article! Also, all of his delivered "products" are idle most of the 24 hours in a day, so there's also that..

Yeah, I stopped reading about 1/4 of the way down the page after feeling like I was reading an advertisement. But I did the exact same thing, and spent three times as long looking for credentials on the author as I did looking at the article.

Sorry, why do you need professional help from Google to create infographics?

I did not say the help needed to come from Google, but that it had to be paid for, and not exactly with pocket change.

> Why is IT ignoring Google’s server-less cloud infrastructure? They’re playing with their toys on Amazon and it’s costing tens of millions in missed business automation opportunities.

Because serverless at scale is phenomenally expensive compared to instances + ops. Solid for prototyping or where you just need to fire off some functions though.

Another devops thread, another time I end up agreeing with 'toomuchtodo. "Serverless" is sneaky-expensive. It's not a particularly practical model once you've gone past trivial stuff; maybe that'll change, but operations for instances and even your more involved boondoggles like container-fleets-on-cloud-compute are pretty well-understood at this point in ways that serverless stuff still isn't.

But yeah, they're "toys". Risk and cost? Who cares. Let's blog.

Could anyone give a breakdown on why it's more expensive (and where the money goes)? Interesting stuff.

Both Google and Amazon charge based on compute heft per second (Amazon in GB-seconds, Google in a mix of GB-seconds and GHz-seconds). When you multiply that out, it overtakes EC2 pricing at a point; I've done the math out for different types of sites before, and it obviously varies by stack, but you hit those breakpoints a lot sooner than you might otherwise expect. One project's workload was something like 10 req/sec and the Lambda costs were more than three load-balanced m4.larges (edit: load-balanced for fault tolerance more than load) due to RAM usage that was per-request in Lambda but amortized across all requests on instances.

Serverless stuff can make a lot of sense for low-utilization tasks under this model, but for applications with nontrivial load you may be paying for a lot of GB-seconds on an ongoing basis. Couple that with the additional latency inherent to spin-up times when putting Lambda behind an HTTP endpoint, and it also runs the risk of being a kinda-janky experience for the user, too (though this can be mitigated), and I'm very not-a-fan past toy/proof-of-concept problems.

Perfect explanation as usual.

The author's definition of serverless was too vague and under-discussed for me to touch, but I didn't get the sense that the author was comparing the cost profile of Amazon's Lambda to Google's Cloud Functions.

I should've been more clear. I believe the author was comparing AWS instances to Google serverless. Serverless has its place, but moving to it wholesale with no thought to use case or workload profile is insanity.

I'd love to see this backed up with actual cost comparison breakdown on google vs Amazon.

Also, I'm not sure the article 100% clarifies what it means by serverless. Does it mean "functions as a service", or something else? The term serverless is overloaded these days.

I think it means anything that doesn't require you to know or even decide how many servers you are using. It automatically scales by default.

It would include App Engine and Elastic Beanstalk, but also 'functions as a service' like AWS Lambda and Google Cloud Functions.

The author is clearly talking about App Engine, but comparing it to EC2 which is definitely not serverless, and very disingenuous. Even Google has an 'normal' non-serverless EC2-like option now.

Aws has plenty of serverless - s3,dynamo,cloudfront,lamda,sqs, I could say rds and beanstalk are also kind of serverless, in loose way.

And aws is cheap...until it becomes not cheap (usually after you hit some numbers, or start dealing with "compliance").

On google side, Gcp app engine is kinda bleh... kubernetes is probably the best thing they have, but it's useful up to a point. And once you cross the "point" you start spending shit tons of money - and unless you are snapchat/YouTube it's hard to swallow it too.

Bottom line - aws might be marginally more expensive at first, but it has plenty of ways to keep things cheap if you are so inclined and flexible enough to meet all kinds of it needs (at a price of course).

I stopped reading at the first subheader, since it immediately betrayed the author's own ignorance regarding AWS' support for both automation and "serverless" software. Lambda is by no means obscure, nor is CloudFormation.

Calling one's target audience "ignorant" does not make for a good argument, while we're at it.

Surely, this person works for Google. Anybody who has actually dealt with any of this stuff in production knows that Amazon is the industry leader for a reason and that Google is way, way back in third place.

As with all things: you get what you pay for.

> Anybody who has actually dealt with any of this stuff in production knows that Amazon is the industry leader for a reason and that Google is way, way back in third place.

Though I haven't worked with either cloud extensively (I mainly play with them for pet projects), I think that's an overly strong and awfully generalized assertion. There are a number of other, less Google-press-release, experiences around that show a preference for Google.

Instead of saying "anybody knows", could you offer some actual reasons you believe AWS to be superior? That would be much more constructive and appreciated.

I'll start by saying that I find AWS' control panel infuriating to use but complete in functionality while Google's is much nicer to use but often lacks features, annoyingly forcing you to use their command line tools. I also find Google's built in quotas to be too low to actually do much with it and I hate that I had to "apply" for an increase. On the other hand, I like Google's billing much more than AWS; their sustained use discounts are easy to figure out and don't require an upfront commitment, which as an individual I'm not likely to want to pay for.

There is a deeper level of vendor lock-in for serverless vs servers as well.

Reply on news.ycombinator.com