Introduction

Happy New Year, everyone! For the first blog in the new year, I am writing a quick overview and tutorial on supporting Python in our platform.

First released over 30 years ago, Python consistently gains momentum to become the most widely used programming language globally. Whether you love or hate them, as a software developer, there’s no denying the impact of Python in the industry. According to StackOverflow survey, for five years in a row, Python remains as the most wanted programming language in the industry:

Python’s popularity makes it the de-facto language for many fields. Businesses like Artificial Intelligence and Data Science are a few of many. And we at Lyrid use it extensively in our development and many crucial parts of our services. 

At Lyrid, we aim to be the platform that provides developers (Python included) with the shortest path to build and scale whatever they make. We do so by leveraging our infrastructure hybrid deployment management. We support Python in the serverless model using our platform’s Web HTTP support. There are two flavors of Python Web Frameworks that we currently use: Django and Flask. You will be able to publish your applications and run them on any cloud in minutes. Our cloud-agnostic approach help users distribute their application and allow them to access multiple cloud deployments.

In this tutorial, I will go through how to get started with a Python Django project. For the first step, and if you haven’t done so already, Register a free account with Lyrid:

‍

Getting Started - Python Django 

Currently, the fastest way to start a Django project in Lyrid Platform is by going through our deployment wizard. First, click on the “Deploy” button at the top:

Select on the “BASIC” templates, and select the “Python v3.9 - Django”, and click Next:

Click on “Deploy” button to start the repository cloning, and build process internally inside our platform, and wait until the deployment is complete:

Once deployment is complete, click Next:

Download the cloned GitHub template and click on Finish:

That’s it! Your first Django application deployed into our platform, and you will be able to access it using our universal distributed HTTP endpoint (*.lyr.id).

Deep Dive

Let’s dive deeper into the Github code. This template is an introductory Python Django application. The application has only one route that simply serves static view of index.html and some static CSS and Javascript that renders this page:

We initialized this project using the default Django project scaffolding 

https://docs.djangoproject.com/en/3.2/intro/tutorial01/#creating-a-project

$ django-admin startproject mysite

And the only modifications we made are as follows:

• Lyrid Definitions

The only file that we added that relates to our platform:

name: py39_django 
description: App Description
ignoreFiles: .git venv
modules:
- name: template
  language: python3.9
  web: django
  description: Module description
  functions:
  - name: entry
    entry: wsgi.py
    description: the entry point for the function

This file will tell our platform how to build, pack and build the application. 

In this example, we let the platform know that this application uses Python 3.9 and Django Web Framework by the values of language and web, respectively. We also have a pointer for the WSGI application that will be used to create our serverless application during the wrapping process.  Please read our documentation for more information about the Lyrid Definition file.

• Additional Libraries

DotEnv: https://pypi.org/project/python-dotenv/

To read into environment variables files.

Whitenoise: http://whitenoise.evans.io/en/stable/

To serve static files without running other infrastructure.

• Routing Static Files and Template
  

This template is serving our simple HTML splash by creating a default path and serving index.html view template as follow:

As you can see, these modifications (apart from the Lyrid definition that is not required to run the Django application) do not need you to install any cloud-specific libraries or contain any public cloud-specific instructions. These Django applications can run on just like any other Django application you have built before and can be hosted on any cloud hosting services that you prefer.

Code Modification and Platform Submission

Next step, we will show you how to update the cloud deployment and publish changes in the platform. But, first, let’s change the code to add a GET /version endpoint that returns a JSON text of a hardcoded version number. First, open the entry/urls.py and add the following lines:

  def get_version(request):
    data = {'version': '1.0'}
    return JsonResponse(data)
    
  urlpatterns = [
      path('', TemplateView.as_view(template_name='index.html')),
      path('version', get_version, name='version')
  ]

Then test it out locally by running:

$ python manage.py runserver

And call into curl:

$ curl http://localhost:8000/version
{"version": "1.0"}

Once you are done with the changes, submit back the code into the platform by calling our Lyrid command-line client:

$ lc code submit

Notes: If this is the first time you are re-submitting the application into Lyrid after modification, you will likely need to download and configure our command-line client. Please check on how to do so here: https://docs.lyrid.io/installation

We are working on Git integration to support tightly integrated CI/CD pipelines with your Git repository.

Once the submission is completed, test out the new endpoint using the public URL:

$ curl https://$endpoint.lyr.id/version
{"version": "1.0"}

And that’s all; you are now ready to roll to build and deploy using our cloud-agnostic deployment!

How Lyrid Uses Python Django in Production

For the past few years, Lyrid has been running and hosting our own Single-Sign-On Identity Management service that utilizes the following Python Django open-source project: https://django-graphql-auth.readthedocs.io/en/latest/

We would like to thank Pedro (https://github.com/PedroBern) and everyone who contributed to this project. We’ve made this project run as Lyrid serverless applications and built our signup, login, and social media login functionalities based on this:

And, we are extending this open source and will be putting our version of GraphQL based Single-Sign-On Identity service that is deployable into Lyrid Platform and a custom admin UI and views:

As a part of giving back to the community, we will also push this project back to our GitHub as a Free Open-Source solution that you can run on any cloud platform. So check back in a few weeks for more details!

Questions

Here are some of the most common questions I got:

1. How are we running supporting infrastructures like object storage, database, and caching?

At the moment, these application instances are meant to be stateless and built as serverless applications. The application does not (and cannot) hold any data as the underlying containers infrastructure will be automatically deleted and removed from the platform if there are no activities. Therefore, additional infrastructures that have the state of the applications need to run outside of this application. 

We do support interconnecting other supporting cloud services for your application. Example:

• Using AWS S3 (and any S3 compatible services) as your object storage using https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html

• Use Managed SQL compatible databases with services like: https://www.elephantsql.com/

And yes, we are currently working on supporting these infrastructure services natively inside our platform. So let us know if you need help with setting up some infrastructure.

2. How do we publish this to AWS and GCP?

We connect to your public cloud account using the respective public cloud’s API to deploy into your organization account. We require you to submit your cloud IAM credentials into the platform that needs specific permissions for a proper deployment. Please follow our documentation at: https://docs.lyrid.io/pubcloudaccsetup

3. Our Python application requires some third-party libraries to pack in the container. How does that work? And what about long-running background tasks?

We support injecting your libraries into the serverless model container; this is done via a build shell script that you can push together into submission. We are also working on a deployment scenario that allows you to run background tasks in a container mode deployment along with our managed Kafka-based event processing channels. We will publish an update in our documentation on how to do so, but in the meantime, just let us know about this requirement, and we will be happy to show you how to do so.

Closing

As a technical founder, I always have to bet on what technology stack we should use and support. And deciding on Python is almost a no-brainer. They have been around for quite some time, and it’s easy to see why Python has the strongest community— they have the most passionate fans rallying behind them! 

We have always known that Python will play a significant role in our company development from the beginning. Here are some examples of open-source Django projects that we have identified to work inside our platform with little to no code changes:

GitHub: https://github.com/saleor/saleor.git

Description: Saleor is an open-source, GraphQL-first e-commerce platform delivering ultra-fast, dynamic and personalized shopping experiences.

GitHub: https://github.com/netbox-community/netbox.git

Description: NetBox is an infrastructure resource modeling (IRM) application designed to empower network automation.

GitHub: https://github.com/taigaio/taiga-back.git

Description: Taiga is the project management tool for multi-functional agile teams. It has a rich feature set and at the same time it is very simple to start with through its intuitive user interface.

And yes, we use these projects internally hosted in our clusters as our daily driver. 

Our platform will always be free to start and explore. So whether you just started learning about Python and Django, or a sizable project, you can always try out our support by adding our definition file and just pointing to your WSGI application. We are happy to help you build a cloud-agnostic solution for any vertical and horizontal. 

That’s all for the tutorial. Thank you for reading it this far, and stay tuned for more deployment tutorials soon. We always want to hear your feedback,  ideas and experiences using our platform. We’re honored to support you while you build your disruptive idea! So feel free to email us at hello@lyrid.io or join our Slack channel.