The support pricing is a very sore point for me too. I can see why when GAE 
becomes perfect and all the "support calls" are because of user errors this 
might make sense. This is not the case as of yet. For instance, both last 
Saturday and tonight I am hitting "customer embarrassing and confidence 
loosing” hurdles because of GAE (see issues 10399 and 10503). Asking me, or any 
other paying user, to pay extra, so that I can timely report these issues and 
then GAE can timely repair them, and restore the service where is should have 
been in the first place, is adding insult to injury…

PK
http://www.gae123.com

On January 22, 2014 at 6:04:21 PM, Coto Augosto C. (c...@me.com) wrote:

Absolutely agree.
I used to rely on app engine services more than heroku or other PaaS but now I 
am disappointed after see that I have been billed for pagespeed while it was 
disabled and I was billed 3 months for back-end instances type B2 while we had 
B1.

Other issue I had was when our application was down for 2 days and we didn't 
have a door to report it. We had to paid for gold support ($400) for gold 
support, I called and they fixed the issue in 3 minutes by restarting the 
instance. Do we have to pay to fix issues in Google end?

I am pretty disappointed now :(

On Jan 22, 2014 10:11 PM, "Doug Anderson" <d...@claystreet.com> wrote:
I think GAE is trying to remain competitive with Amazon Web Services etc... and 
not with CDNs.  App Engine and Google Cloud Storage *is* competitive with 
Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) 
for high volume clients... to my knowledge App Engine doesn't offer that (at 
least not publicly advertised).  App Engine isn't much of a CDN as far as I can 
tell (I don't think that's a prime objective).  It would be hard to argue 
against augmenting with an actual CDN where appropriate.

Certainly technologies like Docker and OpenStack go a long way toward helping a 
lone wolf build a maintainable stack but I think you'll find that if you run 
that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive.  
So I would contend that your pricing argument is more of a generic Anyone's 
Cloud vs Custom Hardware argument.  I can certainly save a ton of money by 
storing data on local hard drives vs the cloud but then I have to worry about 
redundancy, drive and fan failures, rebuilds, backups etc.  If you want 
multi-site redundancy and/or need rapid scaling/growth costs go up and the 
cloud starts to look intriguing again.  Each (cloud and custom hardware) still 
has its place imo... 


On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote:
Hi Doug, 

Just correcting your phrase a little bit: 
"that must be significant bandwidth even for YOU"

We've cut thousands of dollars out of our total bill by serving the images 
ourselves, through a real cdn. 

Appengine output bandwidth is much more expensive than almost any other cdn out 
there. 

Again, keeping this thread on topic, my advices only make sense if you have 
your server bills are in the thousands and are struggling with server costs. 
If you're an early stage startup with < $100 bill or an overfunded startup or a 
big corporation, who cares? :)

thanks
rafa


On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson <do...@claystreet.com> wrote:
Yes, the tests I conducted were on the production server.  I'd even be content 
if the resized images used the same default (quality=85) as the Images service. 
 A switch to a more reasonable default would instantly cut all dynamically 
served images to nearly 1/2 the size...  that must be significant bandwidth 
even for Google.  It's either an oversight on Google's part OR they 
deliberately chose not to utilize the extra CPU bandwidth required for 
additional compression (???).

Serving yourself allows additional flexibility (such as in your gist) but you 
don't get the cost benefits of the dynamic image service (no CPU charges)


On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote:
Doug,

Does that behaviour also happens in production? Compare prod vs dev. 

That's another reason why I prefered to run my own image serving, I control all 
the parameters and can also add things like watermarking, vertical cropping and 
WEBP formatting.  

thanks
rafa


On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson <do...@claystreet.com> wrote:
Rafael & Kaan... since you both utilize dynamic image serving, do either of you 
have an issue concerning the size of dynamically served images?  I filed the 
issue below a while ago and it has seemingly been ignored by Google.  In short 
my grievance is that dynamically served images are effectively sized with JPEG 
quality = 100 (or very close to it).  Thus, the dynamic images are typically 3x 
larger than a comparable image scaled statically via the the Images service 
with quality=65 and 2x larger than quality=85.  My app saves a large reference 
image (1440x1080) and I use dynamic image serving for a variety of smaller 
sizes.  For image heavy apps the difference really adds up... especially for 
mobile.  My issue is below if you have an interest in this topic (your 
thoughts/feedback is much appreciated):
https://code.google.com/p/googleappengine/issues/detail?id=9979


On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote:
Jim, 

In 2014 a good engineer can create your own cloud infrastructure with 10 
machines like the ones I suggested.

Again, I am not saying that I don't like appengine. In fact, I love it and 
that's why I stick with it. 
I am saying it's over priced to run a service like Snapchat. I don't think 
there's any argument there. 


Kaan,

This is my gift to you: https://gist.github.com/mufumbo/8547036

It extends all of the appengine image features: "=s/-c" and includes the most 
useful one: "=h"

Depending on appengine's image serving is a limitation, since "vertical 
cropping" is extremely useful on many elegant websites. 

For example, play around with: http://c1.picmix.net/61757192=s682=h300 or 
http://c1.picmix.net/61757192=s300=h600

By the way, another way to reduce server costs is to pay the $400 or $200 a 
month in support. 
That way you get access to discounted instance hours. It decreased our bill a 
bit and give access to a place to get feedback when appengine is having 
problems or when you need to tweak your scheduling and performance parameters 
that you don't have access from XML config.

About three months ago I spent a whole month optimizing my servers to reduce 
the costs from $10k to $5k. Even now, I feel it's too overpriced for the 
performance it's delivering.

thanks
rafa


On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral <kaan...@gmail.com> wrote:
I think he gets it much more than you give him credit for

Hetzner example, as I interpret it, and think about it myself, is about the 
price of computing/ram/bandwith, although it's not comparable 1:1, it's 
important to know how cheap computing and hosting has become over the years, 
especially in this last 5-10 years

It was really interesting to hear about your story Rafael, it was the 
approximate reason why I started this discussion, to learn and speculate about 
major services

The 2000$ to 300$ cdn comparison is interesting, however no other service that 
I know of matches the extreme capabilities of google images service
I use the =s/-c resizing/cropping extensively, that's why I could never easily 
replace appengine, or the cdn

You seem to have lived my worst case scenario, going out of money and having to 
ask others for money.

Anyway if you don't mind it would be great to learn more about your 
product/story, but I'm guessing it's better to keep things as private as 
possible :)


On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote:
1970's?  What on earth about my post made you think of the 1970's?   My 
description of geographically redundant, web based applications?  Please indeed.

The link you provided is for a LAMP hosting service... basically what I 
described in my third scenario about.  That's apples-vs-oranges as compared to 
GAE.  

I suggest you consult with the Application Architects where you work and 
politely ask them to describe the differences to you.  Clearly nobody here is 
getting through to you and I don't have the time or the inclination.




On Tuesday, January 21, 2014 12:35:13 AM UTC-6, Rafael Sanches wrote:
Guys, 

Please, we're not in 1970 anymore. There is no argue that appengine is the most 
expensive hosting on earth and possibly the universe.

My company spend $4000 a month with appengine. We could host the same service 
with $50 in a more powerful environment:
http://www.hetzner.de/en/hosting/produktmatrix/rootserver-produktmatrix-ex

With $300 we could make it redundant and more reliable and faster than 
appengine. 
A dedicated server is also more reliable, because of appengine infamous 
"hicupps" due to its scheduling system and instance boot time. 
In one of my services I rent a rack with 20 spaces and it's filled with only 10 
severs. It means I can scale my servers with 10 more. That configuration costs 
$1000. 
Please, pay attention for 10 dedicated quad-core with 32GB of ram. How much 
would you pay in appengine for that type of throughput? I did the calculations: 
$60k. 

Please, it's incomparable price wise. There's no argue and let's not go there :)

thanks
rafa


On Mon, Jan 20, 2014 at 1:44 PM, Jim <jeb6...@gmail.com> wrote:
I've seen many variations of this statement, "Google App Engine is expensive!", 
and it always strikes me as a bit off.  I supppose it depends on your 
perspective and your requirements.

For the past three years I've been running a small start-up building a SaaS 
analytics application.  For the prior 25 years or so I built enterprise apps 
for some well-known software houses.  The last 12 years I was building 
SaaS-based software products serving top-tier global financial institutions.  
During that time I worked on projects where we built, from the ground up, 2 
different web-based solutions which wound up serving tens-of-thousands of 
end-users and very large volumes of system-to-system (B2B type) transaction 
volumes.

When we created our infrastructure for these systems we needed multiple 
geographically dispersed data centers, high levels of fault-tolerance within 
any given data center, n-tier architecture, secure systems, scalable databases 
and front-end servers, system, security and network monitoring and 
administration, etc.  When you spec that all out from scratch, you will have a 
hard time doing it for less than several hundred thousand dollars capex with 
big ongoing opex expense.  Any growth beyond your initial headroom will require 
additional capex expenditure and incremental ongoing opex.

Depending on the profile of your application and the system load, at some point 
you will pass the threshold of it being cheaper to build and maintain your own 
equivalent infrastructure, but that threshold is very, very high.  So it makes 
me think people who say GAE is 'expensive' are not making a comparison such as 
this.  Maybe they don't really need everything that GAE offers.

Or perhaps they are comparing GAE to other cloud offerings such as AWS?  
Amazon's pricing doesn't seem to be radically different than Google's to me, 
for similar services.  And given that Amazon's PaaS solution is not yet as 
complete at GAE, I think that any complete appliation built on AWS is going to 
require some level of system-engineering.  System engineers are not cheap. One 
of the things we like about GAE is that, at this point in our corporate 
evolution, we can focus entirely on our Customers and our Software and not 
spend money or time configuring hardware, OS and other "low level" stuff that 
we (as application software guys) don't want to mess with.  There are very real 
hard and soft monetary benefits to this. 

Or maybe when people say "expensive" they mean as compared to other "cloud" 
offerings that are more along the lines of rented physical or virtual machines. 
 Yes, some of these can be cheap compared to GAE.  But these are really 
apples-to-oranges comparisons when you consider all the things you need to 
provision a global, "utility-grade" (aspirationally, anyway) SaaS offering.  

So I guess this post is a long-winded way of me saying "GAE Expensive?  Really? 
 What exactly do you mean by that?  Compared to what?"

On Monday, January 20, 2014 4:19:54 AM UTC-6, coto wrote:
We all should be surprised, because Google App Engine is very expensive!!

On Sunday, January 19, 2014 5:23:13 AM UTC-3, alex wrote:
Why were you surprised?
--
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google 
Groups "Google App Engine" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to