Google App Engine offers free quotas of 1 GB outbound traffic per day and 6.5 CPU-hours (based on a 1.2 GHz Intel x86 processor) per day.
How do those free quotas compare to web hosting plans? For example, the traffic supported by the free quotas -- is that generally higher or less than the traffic supported by a typical $5/mo shared hosting account?
Above the free quotas, Google charges $0.12 per GB outgoing traffic, $0.10 per GB incoming traffic, $0.10 per CPU-hour, $0.15 per GB storage per month.
How do those numbers translate to normal web hosting plans? For example, the traffic that can be supported by a $40/mo VPS plan and $200/mo dedicated server plan, what would they cost on Google App Engine?
I know it depends on a lot of factors, but if anyone has any ballpark estimates or experiences they're willing to share I'd really appreciate it.
I'm trying to decide between App Engine and standard web hosting for a DB-backed Python site. The site will start small, but if the traffic grows I want to see which would be a better option long term.
As you say, it depends on a lot. Not just the site you want to host, but who, specifically, you're comparing it to. To give you a rough idea, I host a site that gets from 20k to 30k pageviews a day on App Engine, and it costs me 17c a week. That's for extra storage over the default quota - all other quotas are well within the free zone.
As far as specific comparisons go, if we look at Linode, for example, their base plan is $20 for 12GB of storage and 120GB transfer per month. At App Engine prices, that would cost you at most $16.20 per month - assuming it was all outgoing traffic. If you do less than that in a month, it costs you less. Obviously, you don't have all the versatility on App Engine that you have with a VPS, but you also have better scalability and reliability.
The comparison is fairly easy to other hosting services. I think App Engine will generally come out ahead, so mostly the decision comes down to if your app is suitable for App Engine.
Man if your app is already in python go with app engine! You could not ask for a more reliable, scalable, efficient platform to host with. As far as the $ goes you cannot beat it. I am working on porting all the applications I have written to python now to take advantage of google app engine. Imagine, no more vps worries about server issues. Take advantage of it!
Try this free diagnostic. It compares Azure / AWS / Appengine and tells you exactly which platform you should use and for how much: http://www.whitestratus.com/cloud-platform-diagnostic-tool
Related
I am in a project to make a web app and we want to host in Google cloud but we can't specify the price because we don't know which services to choose, it's a big app with 18 microservices and a lot of requests per day(let's say 70000 users) can someone explain to me how to get the pricing for the app engine? Or In any other cloud service?
It's difficult to predict the price you are asking for in a detailed way. It depends on several factors:
Availability: If you want 24x7 service or not.
Traffic: Egress traffic, related to requests number.
Resources: CPU, memory etc.
If those requests aren't using much CPU or memory the price is going to be cheaper.
A good idea would be to make a prototype in App Engine standard, using "always free usage limits" and see how it performs {1}.
You also can use Google Cloud Platform Pricing Calculator to get a better idea {2}.
{1}: https://cloud.google.com/free/docs/always-free-usage-limits
{2}: https://cloud.google.com/products/calculator/
I am aware that Google cloud has an IaaS offering which allows point click installation of drupal sites using Bitnami. But I am wondering how this compares with using App Engine or container engine (instead of IaaS).
Per OP--
Large is defined as: "upto 1 million daily users visits to the website and growing"
App Engine, Kubernetes Engine (formerly Container Engine), and Compute Engine are tools that solve different problems.
From what you have shared about your use case, you have the following requirements:
Migrate a large (single) Drupal website
Ensure that it scales beyond 1 million user visits per day
All 3 products will support these requirements.
The important factors that you will need to consider when evaluating these products are:
Cost
Maintenance Effort
When evaluating the products against these two factors in the context of your requirements, you might reach a clearer winner.
For the cost ratings below, it is a best guess using you high level requirements.
Google App Engine - allows you to easily deploy, scale, and update your application. It takes care of all of the "system administration" tasks for you. Rolling out updates to deployed services is also done quite easily via the command line.
Cost is "medium" when compared to running a small single Compute Engine VM but App Engine only provisions what it believes you need to serve the traffic you are receiving, as Drupal requires a DB (can be managed by Google Cloud SQL), this will need to be provisioned separately and will add to the total cost.
Maintenance Effort is "low" because App Engine handles all of the operations tasks.
Google Kubernetes Engine - is a managed Kubernetes providing "Container Infrastructure as a Service". Great for when you have various sized services and you want to bin pack and utilize a cluster of machines for different services. Given you are running a single sized application - a Drupal website, you won't really be taking advantage of this. Scaling and administration is also a little bit more complicated as you will need to scale your Pod as well as the Kubernetes Engine cluster.
Cost is "low" as Kubernetes Engine zonal masters are free and you are only charged for the compute resources of the nodes.
Maintenance Effort is "high" as you will have to configure scaling of your cluster and pods. Operate the Kubernetes Engine cluster and manage your application through the Kubernetes API. A lot more moving parts, when compared to App Engine.
Google Compute Engine - as mentioned, there are Cloud Launcher options to run Drupal. However, once the instance is deployed, you will need to take care of updating. Also, that particular Cloud Launcher version deploys to a single VM. You will probably want to setup Load Balancing, a Managed Instance Group, and Cloud SQL to ensure it is highly available and will scale.
Cost is "low" as you could run your Drupal application and DB on a single small VM, however it may not scale.
Maintenance Effort is "high" as at a minimum, you will have to apply OS patches. To have High Availability and scaling you will have to configure a managed instance group, load balancer, and a startup script/VM image.
In conclusion, if you are an experienced System Administrator, you might prefer to deploy to Compute Engine and manage the system yourself for a potentially lower cost.
If you don't want any operational overhead, App Engine is the way to go.
Kubernetes Engine is too sophisticated a tool for the problem you are solving.
I'm very new to using Google cloud services. As I can see Google App Engine has two way of deployment. The first one is using App Engine sandbox and the second is managed VM.
So I'm interested in pricing. Is there any difference in price? For example if I choose managed VM instead sandbox.
Pricing for the Sandbox can be found on the App Engine Pricing page.
Pricing for the Managed VM's can be found on the Compute Engine Pricing page:
While in beta, pricing is based on Compute Engine Pricing for each VM. Pricing will change in the future.
Based on the linked Price pages:
The Minimum cost for a Sandboxed instance: $0.05 / hour (F1 class, 128MB RAM, 600MHz CPU)
The Minimum cost for a Managed VM: $0.063 (n1-standard-1, 3.75GB RAM, 2.75GCEU CPU)
For other classes of sandbox instances see this page: Adjusting Application Performance
Before jumping to the conclusion that Managed VMs are cheaper: each app gets 28 free instance-hours per day for Sandbox, so chances are good you won't even have to pay for any. Also with further configuration you can achieve to only pay for further "used" instance hours (e.g. you can play with min_idle_instances and max_idle_instances in your module config so additional instances only count toward instance hour billing when they are active (serving requests)).
Notes:
Price shouldn't be the only (or most important) reason to chose one over the other. They are for different things with quite different characteristics.
Sandbox instances are primarily for your application front-end: they can automatically scale as your traffic changes/grows. Many restrictions are enforced.
Managed VMs are good for background operations which can be long or CPU consuming, most of the restrictions are not applied.
In a nutshell: MVMs are for the same price about 10x more powerful.
Default GAE instances are F1: 600Mhz, 128MB, $0.05/h
Comparable MVM: 2500Mhz, 3.75GB, $0.05/h (typical use)
It's not about price, it's about environment. You would not have SQL or root FS on GAE, you can't open ports. Your code base would be hard to migrate to another VPS. As a trade-off you get zero cost maintenance and effortless instant scaling.
I'm doing a prototype backend and in the near future I expect little traffic but while testing I consumed all my 300$ free trail.
How can I configure my app to consume the least possible resources? I need things like limiting the number of instances to 1, using a cheap machine, sleep whenever possible, I've read something about Client vs Backend intances.
With time I'll learn the config that best suits me, but now I need the CHEAPEST config to get going.
BTW: I am using managed-vms with Dart.
EDIT
I've been recommended to configure my app.yaml file, what options would you recommend to confront this issue?
There are two train of thought for your issue.
1) Optimization of code: This is very difficult for us as we are not privy to your App's usage and client-base and architecture. In general, it depends on what Google App Engine product you use the most, for example: Datastore API call (fetch, write, delete... etc...), BigQuery and Cloud SQL. Even after optimization, you can still incur a lot of cost depending on traffic.
2) Enforcing cheap operation: This is easier and I think this is what you want. You can manually enforce a daily budget (in your billing setup page) so the App never cost more than a certain amount per day. You can also artificially lower the maximum amount of idling instances to 0 and use the smallest instance possible (F1 for frontend).
For pricing details see this article - https://cloud.google.com/appengine/pricing#Billable_Resource_Unit_Costs
If you use managed VM -- you'll be billed for Compute Engine Instance prices, not for App Engine Instances, and, as I know, the minimum possible instance to use as Managed VM is "g1-small" which costs you $0.023 per hour full sustained usage (if it will be turned on all month), so you minimum bill will be 0.023 * 24 * 30 = $16.56 only for instance hours. Excluding disk and traffic. With minimum amount of datastore operations you may stay on free quota.
Every application consumes resources differently. To minimize your cost, you need to know what resources used the majority of your expenses and go from there.
If it is spent on extra instances that were just sitting there - then trim the number of instances to the minimum required and use a lower class instance. If you are seeing a lot of expense on datastore calls - then look at optimizing your entities and take advantage of memcache.
Lowest Cost for a simple app:
Use App Engine Standard. It scales to zero instances, so will not cost anything if there is no traffic. With App Engine Flex you will pay for the instance hours and the Flex (GCE) instances are bigger.
Use autoscaling with max instances, F1 instance class:
With autoscaling you do not need to guess how many instances you need. F1 are the smallest instances. Set the max instances in case you get DoS'd or more traffic than you can afford.
Stop Instances:
You can stop the App Engine versions when you do not expect the app to be used. The will be no charge for instance hours for either Standard or Flex. For Flex there will be disk charges. The app will be ready to go when you need it again.
App Engine Version Cleanup:
Versions are easy to create and harder to remove. Here is a post on project cleanup. See this post on App Engine cleanup
https://medium.com/google-cloud/app-engine-project-cleanup-9647296e796a
What do you see as the advantages and disadvantages of Amazon Web Services S3 compared with Google Application Engine? The cost per gigabyte for the two is, at the time I ask, roughly similar; I have not seen any widespread complaints about the quality of service; so I think the decision of which one to use may depend on the API (of all things).
Google's API breaks your content into what they call static content, such as your CSS files, favicons, images, etc and non-static dynamically-generated HTTP responses. Requests for static stuff will be served to whoever requests it until your bandwidth limit is reached; non-static requests will be fulfilled until your bandwidth or CPU limit is reached. With respect to your non-static requests, you can provide any logic you are able to express in Python, so you can be choosy about who you serve.
Amazon's API treats all your content as blobs in a bucket, and provides an access protocol that lets you distinguish between a variety of fulfillable requests ranging from world-readable to owner-only. If you want to something that's not in the kit, though, I don't know what you do beyond being thoughtful about distributing your URIs.
What differences do you see between the two? Are there other cloud storage services you like? Zetta had a press release today, but they're looking for a minimum of ten terabytes on the beta application, and none of my clients are there (yet); and Joyent will probably do something in the near future.
The way I see it is the Google App Engine basically provides a sandbox for you to deploy your app as long as it is written with their requirements (Python etc). Amazon gives you a virtual machine with a lot more flexibility in what can be done but probably more work on your side needed. MS new Azure seems to be going down the GAE route, but replace Python with .NET.
GAE has a limit of 10MB each on static files uploaded through appcfg.py (look right at the bottom of http://code.google.com/appengine/docs/python/tools/uploadinganapp.html). Obviously you can write code to slice large files into bits and reassemble at download time, but it suggests to me that Google doesn't expect App Engine to be used just as a simple CDN, and that if you want to use it as one you'll have to do some work. S3 does the job out of the box, all you have to do is grab a third-party interface app.
If you want to do something non-standard with file access on S3, then probably Amazon expects you to spring for a server instance on EC2. Once this is done, you have much more flexibility than GAE's environment, but you pay more (in cash and probably in maintenance).
The plus point for GAE is that it has "cheap" on its side for small apps (up to 1GB storage, 1GB bandwidth and 1.3 million hits a day are free: http://code.google.com/appengine/docs/quotas.html). Depending on your use, this might be significant, or it might be irrelevant on the scale of your total bandwidth costs.
Coincidentally, I have just this last couple of days looked at GAE for the first time. I took an old Perl CGI script and turned it into a GAE app, which is up and running. About 10 hours total, including reading the GAE introductory docs and remembering how Python is supposed to work enough to write a couple of hundred lines. I'd speculate that's more effort than loading a bunch of files onto S3, but less effort than maintaining EC2 server(s). However, I haven't used Amazon.
[Edited to add: this sounds like the advantages are all with Amazon for commercial purposes. This may well be true, but then GAE is not yet mature and presumably will get better from here fairly rapidly. They only let people start paying in December or so, before that it was free-quota-only except by special arrangement with Google. While Google sometimes takes flack for its claims of "perpetual beta", I think GAE genuinely is still starting up. If your app is a good fit for the BigTable data paradigm, then it might scale better on GAE than EC2. For storage I assume that S3 is already good enough for all reasonable purposes, and Google's clever architecture gives GAE no advantages to compensate when all you're doing is serving files.]
* Except that Google has just offered me a preview of GAE's Java support.
** Just noticed that you can set up chron jobs, but they're limited by the same rules as any other request (30 second runtime, can't modify files, etc).