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.
Related
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.
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 currently looking for a Cloud PaaS that will allow me to scale an application to handle anything between 1 user and 10 Million+ users ... I've never worked on anything this big and the big question that I can't seem to get a clear answer for is that if you develop, let's say a standard application with a relational database and soap-webservices, will this application scale automatically when deployed on a Paas solution or do you still need to build the application with fall-over, redundancy and all those things in mind?
Let's say I deploy a Spring Hibernate application to Amazon EC2 and I create single instance of Ubuntu Server with Tomcat installed, will this application just scale indefinitely or do I need more Ubuntu instances? If more than one Ubuntu instance is needed, does Amazon take care of running the application over both instances or is this the developer's responsibility? What about database storage, can I install a database on EC2 that will scale as the database grow or do I need to use one of their APIs instead if I want it to scale indefinitely?
CloudFoundry allows you to build locally and just deploy straight to their PaaS, but since it's in beta, there's a limit on the amount of resources you can use and databases are limited to 128MB if I remember correctly, so this a no-go for now. Some have suggested installing CloudFoundry on Amazon EC2, how does it scale and how is the database layer handled then?
GAE (Google App Engine), will this allow me to just deploy an app and not have to worry about how it scales and implements redundancy? There appears to be some limitations one what you can and can't run on GAE and their price increase recently upset quite a large number of developers, is it really that expensive compared to other providers?
So basically, will it scale and what needs to be done to make it scale?
That's a lot of questions for one post. Anyway:
Amazon EC2 does not scale automatically with load. EC2 is basically just a virtual machine. You can achieve scaling of EC2 instances with Auto Scaling and Elastic Load Balancing.
SQL databases scale poorly. That's why people started using NoSQL databases in the first place. It's best to see which database your cloud provider offers as a managed service: Datastore on GAE and DynamoDB on Amazon.
Installing your own database on EC2 instances is very impractical as EC2 has ephemeral storage (it looses all data on "disk" when it reboots).
GAE Datastore is actually a one big database for all applications running on it. So it's pretty scalable - your million of users should not be a problem for it.
http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html
Yes App Engine scales automatically, both frontend instances and database. There is nothing special you need to do to make it scale, just use their API.
There are limitations what you can do with AppEngine:
A. No local storage (filesystem) - you need to use Datastore or Blobstore.
B. Comet is only supported via their proprietary Channels API
C. Datastore is a NoSQL database: no JOINs, limited queries, limited transactions.
Cost of GAE is not bad. We do 1M requests a day for about 5 dollars a day. The biggest saving comes from the fact that you do not need a system admin on GAE ( but you do need one for EC2). Compared to the cost of manpower GAE is incredibly cheap.
Some hints to save money (an speed up) GAE:
A. Use get instead of query in Datastore (requires carefully crafting natiral keys).
B. Use memcache to cache data you got form datastore. This can be done automatically with objectify and it's #Cached annotation.
C. Denormalize data. Meaning you write data redundantly in various places in order to get to it in as few operations as possible.
D. If you have a lot of REST requests from devices, where you do not use cookies, then switch off session support ( or roll your own as we did). Sessions use datastore under the hood and for every request it does get and put.
E. Read about adjusting app settings. Try different settings (depending how tolerant your app is to request delay and your traffic patterns/spikes). We were able to cut down frontend instances by 70%.
If we had the possibility to run GAE app without any code change on our servlet engine that would be great because:
in case that google changes their billing policy we can just jump to our own server or in case their current policy doesn't fit our app needs
we can do stuff which is not allowed in the GAE, compromising a 1 JVM, 1 DB
We don't actually need a distributed system but more of a realtime system with synchronize, true locking mechanisms, other servers/software installed on the server machine, socket interface etc...
Such a package should include at least:
TomCat (or equivalent)
DataNucleus Access Platform
(Task Queue service)
Any idea if it's easy to get such a thing or if it's already exist somewhere?
Thanks
Good question - GAE is excellent, but it has considerable limitations, so I think it is a good idea to keep your options open. With that in mind here are some options.
http://appscale.cs.ucsb.edu/
"AppScale is a platform that allows users to deploy and host their own Google App Engine applications. It executes automatically over Amazon EC2 and Eucalyptus as well as Xen and KVM. It has been developed and is maintained by the RACELab at UC Santa Barbara.
There is also TyphoonAE but it is Python specific so probably not useful for you.
Also take note of the Siena project...
http://www.sienaproject.com/index.html
This is supposed to provide GAE/J users with a persistence API that is better suited to the GAE Datastore then JDO/JPA, but is still portable to other platforms.
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).