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

Question

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

User · Answer

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 from Google Cloud Platform (GCP) since most of the GCP services use GCE instances (VMs) beneath the management layer (not sure which one don't). This includes App Engine, Cloud Functions, Kubernetes Engine (Earlier Container Engine), Cloud SQL, etc. GCE instances are the most customisable unit there and thus should only be used when your application can't run on any other GCP services. Most of the time people 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 component of their apps.

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

Standard Environment is really fast, scales down to 0 instance when no-one is using your app, scales up and down in seconds and have dedicated Google services and libraries for caching, authentication etc. The caveat with 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 dockerfile 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 few minutes.

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

User · Answer

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 is 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 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 longer run for simple deployments

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 App Engine  Compute Engine is an Infrastructure-as-a-Service  You have to create and configure your own virtual machine instances  It gives you more flexibility and generally costs much less than App Engine  The drawback is that you have to manage your app and virtual machines yourself   Read more about Compute Engine  You can mix both App Engine and Compute Engine  if necessary  They both work well with the other parts of the Google Cloud Platform   EDIT  May 2016    One more important distinction  projects running on App Engine can scale down to zero instances if no requests are coming in  This is extremely useful at the development stage as you can go for weeks without going over the generous free quota of instance-hours  Flexible runtime  i e   managed VMs   require at least one instance to run constantly   EDIT  April 2017    Cloud Functions  currently in beta  is the next level up from App Engine in terms of abstraction - no instances  It allows developers to deploy bite-size pieces of code that execute in response to different events  which may include HTTP requests  changes in Cloud Storage  etc   The biggest difference with App Engine is that functions are priced per 100 milliseconds  while App Engine s instances shut down only after 15 minutes of inactivity  Another advantage is that Cloud Functions execute immediately  while a call to App Engine may require a new instance - and cold-starting a new instance may take a few seconds or longer  depending on runtime and your code    This makes Cloud Functions ideal for  a  rare calls - no need to keep an instance live just in case something happens   b  rapidly changing loads where instances are often spinning and shutting down  and possibly more use cases   Read more about Cloud Functions

User · Answer

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

[google-app-engine] What is the difference between Google App Engine and Google Compute Engine?

Examples related to google-app-engine

Examples related to google-compute-engine

Examples related to google-cloud-platform