3

I have read through all of Google's documentation on App Engine and various other blog posts but I still do not have a clear idea on the structure of a Django app running on App engine.

As I see things, App engine instances are attached to one SQL database and Google provides auto-scaling and auto load balancing that will replicate your SQL database according to current load.

What does this mean in terms of Django python code? All it seems to take to deploy a Django app is to run glcoud app deploy. If an App Engine instance's SQL database is scaled and replicated automatically in real time, is the Django app replicated along side them? Or will all HTTPS requests go through a single Django app no matter the replications?

In addition, is the Django backend code physically hugging the database it is connected to?

Rage
  • 870
  • 9
  • 27

1 Answers1

1
  1. As I see things, App engine instances are attached to one SQL database.

App Engine instances don’t come attached to anything. You need to also deploy a Cloud SQL instance either with MySQL or with Postgres and then use the Cloud SQL proxy to connect your application to the instance. It is not mandatory to use Cloud SQL, you can also run MySQL on Compute Engine or even on a third party platform but you will need to determine the proper way to connect it to your app.

  1. Google provides auto-scaling and auto load balancing that will replicate your SQL database according to the current load.

As mentioned here You cannot autoscale a database instance, neither in Cloud SQL nor in any other infrastructure support. What Google Cloud SQL provides you is with a fully managed instance, this means that you don't have to worry about backups, patches, and fixes. Also, Cloud SQL provides you with High availability in the case of your instance fails to reduce a lot the downtime of your application, also provides you with an easy way to add read replicas, increasing the performance of your reads operation.

  1. What does this mean in terms of Django python code? Probably you want to take a look at the Github sample and the running Django on App Engine quickstart.

  2. All it seems to take to deploy a Django app is to run glcoud app deploy. That's not precise, you can run the glcoud app deploy to deploy ANY valid application to App Engine, in python a minimal application requires a main.py file, a requirements.txt, and an app.yaml doc. For Django you will need your valid Django application + your app.yaml file (look at git repo in point 3)

  3. If an App Engine instance's SQL database is scaled and replicated automatically in real-time, is the Django app replicated alongside them? Again there is not such an App Engine SQL database. The database instance will run independently of your application in App Engine. When your App Engine application auto-scales your Cloud SQL instance (or compute engine if you decide to go that way) will remain exactly as it was before, it is "agnostic" of App Engine and its behavior and the same for App Engine, your App Engine instances are agnostic of the replication behavior of your Cloud SQL. You will have just a connection between them sending requests back and forth.

  4. Or will all HTTPS requests go through a single Django app no matter the replications? You can have multiple instances in App Engine running your application at the same time, they will send requests back and forth your Cloud SQL database via the Cloud SQL proxy, not HTTP request.

  5. In addition, is the Django backend code physically hugging the database it is connected to? Again, Your Django/App Engine App is one thing and your Cloud SQL database is another different thing, they will talk with each other via the Cloud SQL proxy. So no hugging or physical contact, just "social distancing"

Hope this helps

Chris32
  • 4,716
  • 2
  • 18
  • 30
  • Chris, thank you for your exhaustive answer I understand the premise more now. However, since the Cloud SQL database never does any autoscaling, how does App Engine autoscale in terms of a Django app? Does it replicate the Django app and run it on another computer? Lastly, why are App Engines socially distant to their database? Would it not be faster for them to come in physical pairs? – Rage Jun 11 '20 at 06:27
  • 1
    Well, App Engine autoscale as it would do it for any other app. More traffic>More Instances, Less traffic>Fewer instances(Still a single instance can serve multiple requests). This means App Engine running your application (only the App Side) in more instances the needed time to serve the increase in traffic and then it will kill those instances. Now, what would happen if the database is "physically" attached to these instances? That means that you will be losing data each time an instance is killed. This is why Cloud SQL doesn't autoscale because autoscale means that your will be losing data. – Chris32 Jun 11 '20 at 06:40
  • 1
    In other words, App Engine is oriented to work with [Stateless Oriented Apps](https://whatis.techtarget.com/definition/stateless-app#:~:text=A%20stateless%20app%20is%20an,data%20from%20a%20previous%20session.) and then, you will persist data between session in an [Stateful databse](https://www.bizety.com/2018/08/21/stateful-vs-stateless-architecture-overview/) – Chris32 Jun 11 '20 at 06:40
  • 1
    Also, keep in mind that if you locate your App Engine service and your Cloud SQL service on the same region and zone there would be almost no latency due to data traveling between Data Centers ;-D – Chris32 Jun 11 '20 at 06:42
  • That makes sense. You've been extremely helpful Chris, I wish the best for you. – Rage Jun 11 '20 at 06:45