Could anyone suggest, is it possible to deploy application that consume RAM more than 2 GB. As per the web link provided by Google Cloud Platform documentation its looks not feasible. Web link https://cloud.google.com/appengine/docs/standard
The maximum instance size for App Engine Standard is B8 which provides 2 GB memory.
Related
I want to deploy containerized code using one of Google's serverless options. From what I understand Google has two options for this:
Google App Engine Flexible Environment
Google Cloud Run (in beta)
I've watched the 2019 Google Next talk Where Should I Run My Code? Choosing From 5+ Compute Options. And I read Jerry101's answer to the general question "What is the difference between Google App Engine and Google Cloud Run?".
To me it basically sounds like Cloud Run is the answer to the limitations of using Google App Engine Flexible Environment.
The reasons I can think of to choose App Engine Flexible Environment over Cloud Run are:
Legacy - if your code currently relies on App Engine Flex you might not want to deal with moving it
Track record - App Engine Flex has been around for a while in general availability and in that sense has a track record, whereas Cloud Run is just in Beta
But those are both operation type considerations. Neither is a concern for me. Is there a technical advantage to choosing App Engine Flex over Cloud Run?
Thanks
Note: The beta Serverless VPC Access for App Engine is only available for the standard environment as of this question posting April 2019, not for Flex, so that's not a consideration in the question of App Engine Flex vs Cloud Run
Pricing/Autoscaling: The pricing model between GAE Flexible Environment and Cloud Run are a bit different.
In GAE Flexible, you are always running at least 1 instance at any time. So even if your app is not getting any requests, you’re paying for that instance. Billing granularity is 1 minute.
In Cloud Run, you are only paying when you are processing requests, and the billing granularity is 0.1 second. See here for an explanation of the Cloud Run billing model.
Underlying infrastructure: Since GAE Flexible is running on VMs, it is a bit slower than Cloud Run to deploy a new revision of your app, and scale up. Cloud Run deployments are faster.
Portability: Cloud Run uses the open source Knative API and its container contract. This gives you flexibility and freedom to a greater extent. If you wanted to run the same workload on an infra you manage (such as GKE), you could do it with "Cloud Run on GKE".
I'd actually suggest that you seriously consider Cloud Run over App Engine.
Over time, I've seen a few comments of a "new" App Engine in the works, and it really seems that Cloud Run is that answer. It is in beta, and that can be an issue. I've seen some companies use beta services in production and others wait. However, if I am going to start a new app today - it's going to be Cloud Run over App Engine Flex for sure.
Google is very deep into Kubernetes as a business function. As Cloud Run is sitting on GKE - this means that it is indirectly receiving development via other teams (The general GKE infrastructure).
Conversely, App Engine is on some older tech. Although it's not bad - it is "yesterday's" technology. Google, to me, seems to be a company that gets really excited about what is new and what is being highly adopted in the industry.
All this said - when you wrap your services in a container, you should be able to run them anywhere? Well, anywhere there is a container platform. You can front your services with something like Cloud Endpoints and you can deploy on both App Engine and Cloud Run - swap back and forth. Then, at that point, the limitations might be the services that are offered. For instance, Cloud Run currently doesn't support some items, like Cloud Load Balancing or Cloud Memorystore. That might be a blocker today.
Short story: Appengine is something real, relatively stable. Cloud Run is pretty much just a draft/idea, very unstable.
Long story:
Being in alpha/beta Google Cloud Run may suffer many changes. If you are old enough you might remember how dramatically Appengine pricing has changed. It promised a CPU/RAM based pricing, then it decided that's not "possible" or at least not very profitable and moved to a VM based pricing, then they shipped a decent appengine release(Appengine Flex or whatever name it had at that time) but also increased the price again by adding a minimum instance model. Not to mention the countless APIs/breaking changes or the limits changes.
Cloud Run is based on gVisor which has some limitations so depending on the language/library you use and what you do, it may break(or just Google's implementation may break) at some point and there is nothing you can do (i.e. patch the system) and it will ruin your productivity and potentially your business. You may have a look on its current issues.
Free advice: Even if you choose Appengine or Cloud Run avoid proprietary APIs/services such Google Datastore. They may ruin your business. Pricing, APIs and limits will change. There is no real open source or paid alternative so your code is not portable. Your code is pretty worthless outside of Google cloud.
Disclaimer: I've been burned by appengine changes and datastore lock-in so my opinion may be biased.
I have a ML model with REST API interface as a micro service. When I tried to run with Cloud Run, it deploys but just does not work. I had to switch back to App Engine Flexible Env.
Cloud Run (fully managed) currently (Jul 2020) has RAM limitation of 2GB. For better hardware I should go for Anthose with GKE infra. But this has min instance needs of at least 4 instances to properly work.
Mine being a tiny application I settled for App engine Flexible environment. Though autoscale settings required min 2 instances, in early days it could be managed with manual scaling and 1 instance as limit.
EDIT:
As on Aug 22 2020, the RAM limit is 4GB and number of cores is 2, for fully managed GCP cloud Run.
Main difference is background tasks.
In cloud run, everything kicks off by a request, and once that request completes, the instance won't be up up any longer.
App Engine also gave you some built in freebies like memory caching, but I don't think that's true of App Engine flex.
For a straightforward HTTP API, the differences are negligible, and you can get some of the things that App Engine gives you with other GCP products (Cloud Scheduler, Cloud Task).
You can check this video out for a comparison and demo on cloud run:
https://www.youtube.com/watch?v=rVWopvGE74c
App Engine Flexible, focus on "Code first", developer-focused, App Engine app was made up of multiple services, you really didn't have to do any kind of naming when deploying your applications.
Characteristics of the GAE flexible environment :
It is not possible to downscale to ZERO
Source code that is written in a version of any of the supported
programming languages: Python, Java, Node.js, Go, Ruby, PHP, or .NET
Runs in a Docker container that includes a custom runtime or source
code written in other programming languages.
Uses or depends on frameworks that include native code.
Accesses the resources or services of your Google Cloud project that
reside in the Compute Engine network.
Maximum request timeout: 60 minutes
Cloud Run is a managed compute platform that enables you to run containers that are invocable via requests or events, everything is a service, whether it's an actual service or an application with a web interface, so consider its use as the deployment of a service rather than an appplication.
Characteristics of Cloud Run :
It is serverless: it abstracts away all infrastructure management
It depends on the fact that your application should be stateless.
GCP will spin up multiple instances of your app to scale it dynamically
Downscale to ZERO
You can use below url to get difference between Cloud Run and App Engine.
Hosting Options
Some times many reason to use App Engine over the Cloud Run is, Cloud Run doesn’t Background processes. It response time also 15 mins only.
When making a contents-file based bulletin with Java, why it is needed to use Google Storage, a separate storage service rather than just creating a folder within Java project itself?
Is there any file size limit that a Java project can become?
Is there any file size limit of a Java project to be uploaded for Google-App-Engine?
In App Engine, the local filesystem that your application is deployed to is not writeable. The flexible environment does allow you to write to a directory on a local disk, but written files are ephemeral, due to the fact that the disk gets initialized on each VM startup, so your files will get deleted on this occasion. You can read more related detail on the "Choosing an App Engine Environment" online documentation page.
You can profit from the facilities offered by Compute Engine, if writing to disc is a must. By default, each Compute Engine instance has a single root persistent disk that contains the operating system, as stated on the "Storage Options" page. For more insight, you may implement the proposed example from the "Running the Java Bookshelf on Compute Engine" page.
The Compute Engine does not handle scaling up of your applications automatically, so you'll have to take care of it yourself, as suggested in the "Autoscaling Groups of Instances" document.
There is a maximum size limit of 5 TB for individual objects stored in Cloud Storage. An application is limited to 10,000 uploaded files per version. Each file is limited to a maximum size of 32 megabytes. You may find related details on the "Quotas | App Engine Documentation | Google Cloud" page.
I believe that the Google Kubernetes Engine (GKE) is running on Google Compute Engine (GCE). So, what is the real advantage of using Google Kubernetes Engine in terms of server management?
I am referring to updates to the OS and security patches just like Google App Engine handles this for us. Does the SRE handle the update and security patches?
I know that Google App Engine already does this for us (updating the OS etc.), but on GAE, we are not able to attach a persistent disk.
My plan is to host a flat file CMS, which in this case, does not need for cloud SQL, cloud datastore, etc. Also, cloud memory store is way too expensive.
A big difference between the two is that a normal GCE VM instance is completely unmanaged. Once you've used the GCP-provided image, all updates are up to you. Whereas with GKE, the Master and node versions can be set to upgrade automatically and you only choose which OS you want, not the specific OS version.
This means that if there are security patches or updates to a node OS, it will get pushed to your cluster. When there are improvements or patches to GKE (as long as you enable automatic upgrades) your nodes will receive the new versions.
GKE may cost you a little more than a stand-alone GCE VM, but it comes with more automation and management baked in.
Google App Engine has some information about Memcache limits:
http://code.google.com/appengine/docs/quotas.html#Memcache
http://code.google.com/appengine/docs/python/memcache/overview.html#Quotas_and_Limits
However, total allowed size of RAM/memory store for a single application is not specified. It's known that no objects above 1MB is allowed. Do you have information?
The amount of memcache capacity your app has isn't fixed, and may vary depending on the traffic to your app and how it uses memcache.
As of November 2013, App Engine offers dedicated memcache which guarantees a specific amount of memcache RAM. You can purchase between 1 and 20 GB of dedicated cache. More than 20 GB is available upon request.
The shared memcache RAM available to an application still varies based on multiple factors.
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