What is the difference between Google App Engine and Google Compute Engine?

Asked 27/3, 2014 at 19:13 Answered 2/8, 2022 at 15:52

Solved google-app-engine google-compute-engine google-cloud-platform

540

I was wondering what the difference between App Engine & Compute Engine are. Can anyone explain the difference to me?

Ulane answered 27/3, 2014 at 19:13 Comment(1)

It wasn't clear for me on their homepages. It's nice to just have it plain like it is here. This StackOverflow page did it's job for me. To each his/her own. :) – Author 14/6, 2014 at 7:16

573

App Engine is a Platform-as-a-Service. It means that you simply deploy your code, and the platform does everything else for you. For example, if your app becomes very successful, App Engine will automatically create more instances to handle the increased volume.

Read more about Cloud Functions

Bipolar answered 27/3, 2014 at 19:19 Comment(11)

If I want to deploy via Docker, what are the differences (besides pricing) between using GAE and GCE? – Expansile 9/5, 2015 at 12:24

Hi, Volgin, can you elaborate the reason why "Compute Engine" is costs much less than App Engine. Thanks – Literal 27/10, 2015 at 2:6

App Engine offers a level of automation (i.e. convenience) that you don't get on GCE. In 5 years of using GAE I never had to install, patch or configure any software, copy disks, etc. It also offers relatively robust load and capacity management - automatically spinning up and shutting down instances as required. Overall, these features allow Google to charge more for instance hours, and many companies and individual developers are happy to pay this premium because GAE saves a lot of time that can be better spent improving your own apps or otherwise making money. – Bipolar 27/10, 2015 at 2:42

Google also offers another service called: Container Engine which focuses on docker and container management (kubernetes). – Hereupon 31/3, 2016 at 7:55

Many thx for your words here. In your last edit you said projects running on App Engine can scale down to zero instances if no requests are coming in . I'm learning gcloud, but it always looks like TWO instances is the minimum when no requests are coming in. Which is right? Zero or two minimum? Is there a special trick? – Kori 18/2, 2017 at 21:4

@zipzit: There is no two instances minimum in any environment. – Bipolar 20/2, 2017 at 5:46

What is the difference between Google Cloud Functions and AWS Lambda. If the answer is nothing or very little then I would vote to strike it form this, as it's a completly different use case. – Ushijima 12/8, 2017 at 8:39

@Erich: It's a different computing model. Often the same use case can be satisfied by a monolithic app or a bundle of micro-services, or a combination of the two. Obviously, some use cases favor one computing model over the other (e.g. if an app needs to support authenticated users, it's more difficult with GCF than with GCE or GAE), but many apps can move their entire backend to GCF if they want to, and there are very good economic and engineering reasons to do that. – Bipolar 12/8, 2017 at 23:37

@Kori it's possible that you've enabled auto-scaling on your instance, in this case I'm not sure if Google will scale to zero as it's implied that you're in production with this setting. During development, they recommend setting manual scaling to 1 which means there'll either be 0 or 1 instance running at a given point in time. It's just a matter of fiddling with the configs till you find what works for you. – Razid 1/5, 2018 at 2:9

@Kori in case of GAE flexible environment, by default your app will initiate two instances but you can change that to one as described here: #47126161 – Elapse 20/5, 2018 at 15:49

Quick comment on "Another advantage is that Cloud Functions execute immediately". From real-life experience they have the same drawback of cold-starts which could make a simple sum(a,b) {return a+b} take minutes with cold-starts – Nitramine 17/1, 2019 at 22:30

116

Basic difference is that Google App Engine (GAE) is a Platform as a Service (PaaS) whereas Google Compute Engine (GCE) is an Infrastructure as a Service (IaaS).

To run your application in GAE you just need to write your code and deploy it into GAE, no other headache. Since GAE is fully scalable, it will automatically acquire more instances in case the traffic goes higher and decrease the instances when traffic decreases. You will be charged for the resources you really use, I mean, you will be billed for the Instance-Hours, Transferred Data, Storage etc your app really used. But the restriction is, you can create your application in only Python, PHP, Java, NodeJS, .NET, Ruby and **Go.

On the other hand, GCE provides you full infrastructure in the form of Virtual Machine. You have complete control over those VMs' environment and runtime as you can write or install any program there. Actually GCE is the way to use Google Data Centers virtually. In GCE you have to manually configure your infrastructure to handle scalability by using Load Balancer.

Both GAE and GCE are part of Google Cloud Platform.

Update: In March 2014 Google announced a new service under App Engine named Managed Virtual Machine. Managed VMs offers app engine applications a bit more flexibility over app platform, CPU and memory options. Like GCE you can create a custom runtime environment in these VMs for app engine application. Actually Managed VMs of App Engine blurs the frontier between IAAS and PAAS to some extent.

Jainism answered 11/9, 2014 at 8:34 Comment(6)

From their docs, you can deploy a VM to GAE via Docker. cloud.google.com/appengine/docs/managed-vms – Expansile 9/5, 2015 at 12:15

It seems that you can use Node.js and Ruby as well now on GAE. – Mansized 24/8, 2016 at 19:52

Managed VMs are now called App Engine Flexible Environment – Widera 1/9, 2016 at 15:32

I deployed my code into App engine, when I check my console I see a Compute Engine VM instance also when checking App engine console I see traces of HTTP servlet requests. so am I using app engine or compute engine? – Indolence 21/11, 2016 at 1:18

I think the part about storage in "...you will be billed for the Instance-Hours, Transferred Data, Storage etc your app really used..." about GAE is wrong. GAE instances are (mostly) volatile. Hence when an instance gets shutdown (e.g. if the instance was created in response to traffic surge, and now is being removed when traffic has dropped), you lose all stored data. Therefore, I do not think it is correct to state that you get "charged" for "storage" in GAE, although you can connect your app in GAE to another GCP product that provides storage and get charged for the later, not as GAE – Screeching 17/5, 2020 at 7:29

@DamilolaOlowookere What I meant is you can add Persistent storage which will be additionally charged(same thing happens if you provision external IPs etc) – Jainism 17/5, 2020 at 10:6

To put it simply: compute engine gives you a server which you have full control/responsibility for. You have direct access to the operating system, and you install all the software that you want, which is usually a web server, database, etc...

In app engine you don't manage the operating system of any of the underlying software. You only upload code (Java, PHP, Python, or Go) and voila - it just runs...

App engine saves tons of headache, especially for inexperienced people but it has 2 significant drawbacks: 1. more expensive (but it does have a free quota which compute engine doesn't) 2. you have less control, thus certain things are just not possible, or only possible in one specific way (for example saving and writing files).

Tantrum answered 27/3, 2014 at 21:29 Comment(4)

You can deploy a VM to GAE via Docker, so you can manage the OS etc. cloud.google.com/appengine/docs/managed-vms – Expansile 9/5, 2015 at 12:16

"it just runs", are you serious? i think i am not the only one who has troubles with adapting the code to GAE, when it comes to file uploads or background processes – Underestimate 21/11, 2017 at 21:49

@Underestimate what kind of troubles? could you give examples? – Appenzell 17/1, 2021 at 10:36

Update: Compute Engine has a free quota – Hysell 5/4, 2021 at 3:59

Or to make it even simpler (since at times we fail to differentiate between GAE Standard and GAE Flex):

Compute Engine is analogous to a virtual PC, where you'd deploy a small website + database, for instance. You manage everything, including control of installed disk drives. If you deploy a website, you're in charge of setting up DNS etc.

Google App Engine (Standard) is like a read-only sandboxed folder where you upload code to execute from and don't worry about the rest (yes: read-only - there are a fixed set of libraries installed for you and you cannot deploy 3rd party libraries at will). DNS / Sub-domains etc are so much easier to map.

Google App Engine (Flexible) is in fact like a whole file system (not just a locked down folder), where you have more power than the Standard engine, e.g. you have read/write permissions, (but less compared to a Compute Engine). In the GAE standard, you have a fixed set of libraries installed for you and you cannot deploy 3rd party libraries at will. In the Flexible environment, you can install whatever library your app depends on, including custom build environments (such as Python 3).

Although GAE Standard is very cumbersome to deal with (although Google makes it sound simple), it scales really well when put under pressure. It's cumbersome because you need to test and ensure compatibility with the locked-down environment and ensure any 3rd party library you use does not use any other 3rd party library you're unaware of which may not work on GAE standard. It takes longer to set it up in practice but can be more rewarding in the long run for simple deployments.

Mihrab answered 28/5, 2017 at 20:4 Comment(3)

do you mean by "read-only", the fact that we can't write to files disk? – Handknit 16/1, 2019 at 3:23

@JohnBalvinArias yes, it's a read-only sandboxed container. You cannot access the 'outside' world, nor can you write to this container / disk. It's there for you to execute your code from. – Mihrab 8/2, 2019 at 12:56

So if I can use docker to install s/w in GAE, does it mean google takes care of creating/allocating a linux instance with basic configurations and then runs docker on tops of it? In essence, compute engine adds additional responsibility of VM configs. Am I right? – Deshawndesi 3/12, 2019 at 1:30

In addition to the App Engine vs Compute Engine notes above the list here also includes a comparison with Google Kubernete Engine and some notes based on experience with a wide range of apps from small to very large. For more points see the Google Cloud Platform documentation high level description of features in App Engine Standard and Flex on the page Choosing an App Engine Environment. For another comparison of deployment of App Engine and Kubernetes see the post by Daz Wilkin App Engine Flex or Kubernetes Engine.

App Engine Standard

Pros

Very economical for low traffic apps in terms of direct costs and also the cost of maintaining the app.
Auto scaling is fast. Autoscaling in App Engine is based on lightweight instance classes F1-F4.
Version management and traffic splitting are fast and convenient. These features are built into App Engine (both Standard and Flex) natively.
Minimal management, developers need focus only on their app. Developers do not need to worry about managing VMs in a reliable, as in GCE, or learning about clusters, as with GKE.
Access to Datastore is fast. When App Engine was first released, the runtime was co-located with Datastore. Later Datastore was split out as the standalone product Cloud Datastore but the co-location of App Engine Standard serving with Datastore remains.
Access to Memcache is supported.
The App Engine sandbox is very secure. Compared with development on GCE or other virtual machines, where you need to do your own diligence to prevent the virtual machine from being taken over at the operating system level, the App Engine Standard sandbox is relatively secure by default.

Cons

Generally more constrained than other environments Instances are smaller. Although this is good for rapid autoscaling, many apps can benefit from larger instances, such as GCE instance sizes up to 96 cores.
Networking is not integrated with GCE
Cannot put App Engine behind a Google Cloud Load Balancer. Limited to supported runtimes: Python 2.7, Java 7 and 8, Go 1.6-1.9, and PHP 5.5. In Java, there is some support for Servlets but not the full J2EE standard.

App Engine Flex

Pros

Can use a custom runtime
Native integration with GCE networking
Version and traffic management is convenient, same as Standard
The larger instance sizes may be more suitable to to large complex applications, especially Java applications that can use a lot of memory

Cons

Network integration is not perfect - no integration with internal load balancers or Shared Virtual Private Clouds
Access to managed Memcache not generally available

Google Kubernetes Engine

Pros

Native integration with containers allows custom runtimes and greater control over cluster configuration.
Embodies many best practices working with virtual machines, such as immutable runtime environments and easy ability to roll back to previous versions
Provides a consistent and repeatable deployment framework
Based on open standards, notably Kubernetes, for portability between clouds and on-premises.
Version management can accomplished with Docker containers and the Google Container Registry

Cons

Traffic splitting and management is do-it-yourself, possibly leveraging Istio and Envoy
Some management overhead
Some time to ramp up on Kubernetes concepts, such as pods, deployments, services, ingress, and namespaces
Need to expose some public IPs unless using Private Clusters, now in beta, eliminate that need but you still need to provide access to locations where kubectl commands will be run from.
Monitoring integration not perfect
While L3 internal load balancing is supported natively on Kubernetes Engine, L7 internal load balancing is do-it-yourself, possibly leveraging Envoy

Compute Engine

Pros

Easy to ramp up - no need to ramp up on Kubernetes or App Engine, just reuse whatever you know from previous experience. This is probably the main reason for using Compute Engine directly.
Complete control - you can leverage many Compute Engine features directly and install the latest of all your favorite stuff to stay on the bleeding edge.
No need for public IPs. Some legacy software may be too hard to lock down if anything is exposed on public IPs.
You can leverage the Container-Optimized OS for running Docker containers

Cons

Mostly do-it-yourself, which can be challenging to do adequately for reliability and security, although you can reuse solutions from various places, including the Cloud Launcher.
More management overhead. There are many management tools for Compute Engine but they will not necessarily understand how you have deployed your application, like the App Engine and Kubernetes Engine monitoring tools do
Autoscaling is based on GCE instances, which can be slower than App Engine
Tendency is to install software on snowflake GCE instances, which can be some effort to maintain

Di answered 20/4, 2018 at 22:56 Comment(0)

As explained already Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS) while Google App Engine (GAE) is Platform as a Service (PaaS). You can check the following diagram to understand the difference in a better way (Taken from and better explained here) -

Google Compute Engine
GCE is an important service provided by Google Cloud Platform (GCP) since most of the GCP services use GCE instances (VMs) beneath the management layer (not sure which ones don't). This includes App Engine, Cloud Functions, Kubernetes Engine (Earlier Container Engine), Cloud SQL, etc. GCE instances are the most customizable unit there and thus should only be used when your application can't run on any other GCP services. People often use GCE to transfer their On-Prem applications to GCP, since it requires minimal changes. Later, they can choose to use other GCP services for separate components of their apps.

Google App Engine
GAE is the first service offered by GCP (Long before Google came to the cloud business). It auto-scales from 0 to unlimited instances (It uses GCE underneath). It comes in 2 flavors Standard Environment and Flexible Environment.

Standard Environment is really fast, scales down to 0 instances when no one is using your app, scales up and down in seconds, and has dedicated Google services and libraries for caching, authentication, etc. The caveat with the Standard environment is that it is very restrictive since it runs in a sandbox. You have to use managed runtimes for specific programming languages only. The recent additions are Node.js (8.x) and Python 3.x. The older runtimes are available for Go, PHP, Python 2.7, Java, etc.

Flexible Environment is more open as it allows you to use custom runtimes as it uses docker containers. Thus if your runtime is not available in the provided runtimes, you can always create your own docker file for the execution environment. The caveat with it is, it requires having at least 1 instance running, even if no one is using your app, plus the scaling up and down requires a few minutes.

Don't confuse GAE flexibility with Kubernetes Engine, as the latter uses actual Kubernetes and provides much more customization and features. GAE Flex is useful when you want stateless containers and your application relies on HTTP or HTTPS protocols only. For other protocols, Kubernetes Engine (GKE) or GCE is your only choice. Check my other answer for a better explanation.

Mosesmosey answered 9/1, 2019 at 9:40 Comment(0)

If you're familiar with other popular services:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku or AWS Elastic Beanstalk

Google Cloud Functions -> AWS Lambda Functions

Azaleeazan answered 23/11, 2019 at 18:53 Comment(0)

I'll explain it in a way that made sense to me:

Compute Engine: If you are do-it-yourself person or have an IT team and you just want to rent a computer on cloud that has specific OS (for example linux), you go for the Compute Engine. You have to do everything by yourself.
App Engine: If you are (for example) a python programmer and you want to rent a pre-configured computer on cloud that has Linux with a running web-server and the latest python 3 with necessary modules and some plug-ins to integrate with other external services, you go for the App Engine.
Serverless Container (Cloud Run): If you would like to deploy the exact image of your local setup environment (for example: python 3.7+flask+sklearn) but you do not want to deal with server, scaling, etc. You create a container on your local machine (through docker) and then deploy it to Google Run.
Serverless Microservice (Cloud Functions): If you want to write bunch of APIs (functions) that do specific job, you go for google Cloud Functions. You just focus on those specific functions, the rest of the job (server, maintenance, scaling, etc.) is done for you in order to expose your functions as microservices.

As you go deeper, you lose some flexibility but you are not worried about unnecessary technical aspects. You also pay a little more but you save time and cost (IT part): someone else (google) is doing it for you.

If you want to not care about load balancing, scaling, etc., it is crucial to split your app to bunch of "stateless" web services that writes anything persistent in a separate storage (database or blob storage). Then you will found how awesome is Cloud Run and Cloud Functions.

Personally, I found Google Cloud Run an awesome solution, absolute freedom in development (as long as stateless), expose it as a web service, docker your solution, deploy it with Cloud Run. Let google be your IT and DevOps, you do not need to care about scaling and maintenance.

I have tried all other options and each one is good for different purpose but Google Run is just awesome. To me, it is the real serverless without losing flexibility in development.

Hermie answered 19/5, 2019 at 9:29 Comment(0)

Google Compute Engine (GCE)

Virtual Machines (VMs) hosted in the cloud. Before the cloud, these were often called Virtual Private Servers (VPS). You'd use these the same way you'd use a physical server, where you install and configure the operating system, install your application, install the database, keep the OS up-to-date, etc. This is known as Infrastructure-as-a-Service (IaaS).

VMs are most useful when you have an existing application running on a VM or server in your datacenter, and want to easily migrate it to GCP.

Google App Engine

App Engine hosts and runs your code, without requiring you to deal with the operating system, networking, and many of the other things you'd have to manage with a physical server or VM. Think of it as a runtime, which can automatically deploy, version, and scale your application. This is called Platform-as-a-Service (PaaS).

App Engine is most useful when you want automated deployment and automated scaling of your application. Unless your application requires custom OS configuration, App Engine is often advantageous over configuring and managing VMs by hand.

Christianity answered 27/10, 2019 at 23:53 Comment(0)

App Engine gives developers the ability to control Google Compute Engine cores, as well as provide a web-facing front end for Google Compute Engine data processing applications.

On the other hand, Compute Engine offers direct and complete operating system management of your virtual machines. To present your App, you're going to need resources, and Google Cloud Storage is ideal for storing your assets and data, whatever they're used for. You get fast data access with hosting around the globe. Reliability is guaranteed at a 99.95% up-time, and Google also provides the ability to back up and restore your data, and believe it or not, storage is unlimited.

You can manage your assets with Google Cloud Storage, storing, retrieving, displaying, and deleting them. You can also quickly read and write to flat datasheets that are kept in Cloud Storage. Next in the Google Cloud lineup is BigQuery. With BigQuery, you can analyze massive amounts of data, we're talking millions of records, within seconds. Access is handled via a straightforward UI, or a Representational State Transfer, or REST interface.

Data storage is, as you might suspect, not a problem, and scales to hundreds of TB. BigQuery is accessible via a host of client libraries, including those for Java, .NET, Python, Go, Ruby, PHP, and Javascript. A SQL-like syntax called NoSQL is available which can be accessed through these client libraries, or through a web user interface. Finally, let's talk about the Google Cloud platform database options, Cloud SQL and Cloud Datastore.

There is a major difference. Cloud SQL is for relational databases, primarily MySQL, whereas Cloud Datastore is for non-relational databases using noSQL. With Cloud SQL, you have the choice of either hosting in the US, Europe, or Asia, with 100 GB of storage, and 16 GB of RAM per database instance.

Cloud Datastore is available at no charge for up to 50 K read/write instructions per month and 1 GB of data stored also per month. There is a fee if you exceed these quotas, however. App Engine can also work with other lesser known, more targeted members of the Google Cloud platform, including the Cloud Endpoints for creating API backends, Google Prediction API for data analysis and trend forecasting, or the Google Translate API, for multilingual output.

While you can do a fair amount with App Engine on its own, It's potential skyrockets when you factor in its ability to work easily and efficiently with its fellow Google Cloud platform services.

Significance answered 9/7, 2015 at 23:27 Comment(0)

The cloud services provides a range of options from fully managed to less managed services. Less managed services gives more control to the developers. The same is the difference in Compute and App engine also. The below image elaborate more on this point

Silverware answered 16/5, 2020 at 14:15 Comment(0)

-1

App Engine is a virtual server. Compute Engine - it's like a full server.

Rupee answered 2/8, 2022 at 15:52 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Google Compute Engine (GCE)

Google App Engine

Recommended topics

Hot tags