Getting Started With Django

It's easy to get started developing Django apps that run on Google Cloud Platform. And because the apps you create will run on the same infrastructure that powers all of Google's products, you can be confident that they will scale to serve all of your users, whether there are a few or millions of them.

Hosting platforms

There are four main options for deploying Django on Cloud Platform.

Django Deployment Option Use if you want Don't use if you need Get Started
Google App Engine standard environment
  • Minimal configuration
  • No server maintenance
  • Easy scalability
  • Python 3
  • System libraries not available in the App Engine standard Python environment
Django on App Engine standard environment
Google App Engine flexible Environment
  • Most of the advantages of App Engine
  • System libraries and Python libraries that depend on them
  • Custom Docker runtimes
  • SLAs not provided by Beta products
Django on App Engine Flexible Environment
Google Container Engine
  • Django containers in a microservice environment
  • A toolkit to design your own container-based platform
  • A fully-featured platform as a service. For a container-based PaaS, consider flexible environment.
Django on Container Engine
Google Compute Engine
  • Familiar infrastructure as a service using VMs
  • Windows VMs
  • A no-ops environment without the need to configure your own infrastructure
Django in Google Cloud Launcher

Databases

The Django object-relational mapper (ORM) works best with a traditional SQL database. If you are starting a new project, Google Cloud SQL is a good choice. With a few clicks you can create a database that is fully managed and scaled by Google, with no management on your end.

You can also use other SQL databases like PostgreSQL if you're willing to manage them yourself on Compute Engine or another service. For a click-to-deploy enterprise PostgreSQL database on Compute Engine, consider EDB Postgres Enterprise. For a managed PostgreSQL service hosted outside of Google, consider ElephantSQL.

In many situations, there are compelling reasons to use a NoSQL database, for example, scalability or suitability for your data model. Although using the Django ORM with a NoSQL database can be challenging, it is possible with some limitations. For example, many types of database joins can expressed in Django, but are not supported by Cloud Datastore and other NoSQL databases like MongoDB. One possibility is to use a mixed SQL and NoSQL approach that uses different databases for different types of data.

For a managed, massively-scalable NoSQL solution, consider Cloud Datastore , which is a non-relational database that scales better than a SQL solution.

If you choose to use MongoDB, you can deploy it using Cloud Launcher and do your own management, or you can use the managed MongoDB hosting service provided by mLab.

For many years, the most popular approach to making the Django ORM work with NoSQL solutions was Django non-rel, but the project is a fork of Django that has not been kept up to date with the main line. A new project called Djangae has emerged, which provides a Django ORM backend for Cloud Datastore without forking Django. While Djangae looks extremely promising, it is not an officially supported way to run Django on App Engine.

Caches

App Engine comes with a built-in Memcached service. To install Memcached on Compute Engine, you can use Cloud Launcher. To install Memcached on either Compute Engine or Container Engine, you can use the Memcached Docker image. Similarly you can install Redis by using Cloud Launcher or the Redis docker image.

Task queuing

App Engine comes with a built-in task queue feature for long-running background jobs. Outside of App Engine, consider the massively scalable Cloud Pub/Sub service, which can be turned into a task queue using Cloud Pub/Sub Task Queue for Python (psq).

Other popular task queuing options, available in Cloud Launcher, include RabbitMQ and Kafka. There are also Docker images for RabbitMQ and Kafka.

Send feedback about...