Deploying Python Applications to Azure
As a cloud engineer who’s also a dabbler in building applications at home, I’ve taken a big interest recently in how we can take the local prototypes & applications built by techies and turn them into valuable tools available to other members of an organisation, particularly when looking at enterprise environments. This post shows how easy it can be to get such tools up and running in the cloud!
Why talk about this at all?
It is quite common for some talented programmer or engineer to come across a really useful library, framework, or tool of some sort, build a really good demo, but then it goes nowhere after showing it to their team. Why? It can be a mix of factors — uncertainties over cost implications, lack of knowhow in terms of how to get it up and running, needing more confidence that all the key considerations have been covered, etc. The aim of this article is to highlight it can be very straightforward to pick a framework, build something, and get it delivered to end users. For today, we’ll pick Streamlit, a popular framework for building web apps to visualise data.
The point of this article is that there’s a great way to build applications out there which is underutilised. Realistically, most SaaS/PaaS tools like Power BI or Dynamics will cover you for most use cases whether it be dashboarding, some sort of CRUD application, or something else altogether. However, if you do want to take some of the really cool things people can build and make them available to others, read on!
What is Streamlit, and why should I use it?
Streamlit’s site describes it best; it’s a fantastic library for developing webapps for interacting with data. I personally like Streamlit for two reasons:
· It’s easier to use than many other tools — it’s a very simple library for building data apps, and it’s very ease to include components built in other libraries such as Seaborn or Altair.
· It looks good — most people who use it feel it has a certain je ne sais quoi that screams quality. It’s easy to exploit this thanks to the high quality of available documentation.
One thing to highlight — no one tool/library/framework will always be the silver bullet to every problem you face. What library to choose and when is it’s own conversation, and not one I want to focus on today. What you see here will generalise to other frameworks in other languages.
How do I get my app up and running?
Streamlit’s site has some great content for getting up and running quickly and learning the ropes. Their gallery shows just how creative you can get (and shows some of the polish I mentioned earlier). There’s also great documentation and references on how to build solutions using the library — today, we’ll deploy the multi-page sample app to Azure. There are three steps to go through:
- Building an application
- Preparing your Azure environment
- Deploying your code
Step one — build an app!
So, in this case, the app is already written since we’re just borrowing the sample app I referred to previously. A super important detail for Python development is to always use virtual environments to manage dependencies! This lets us use the pip freeze command to generate the requirements.txt file that will allow Azure to install the application dependencies. This is simply a text file which lists all the Python libraries and versions used by your application, and tends to be commonly used across many cloud providers; this will be important for later. Looking at VS Code, if we were to want to actually run the app, we simply use streamlit run Home.py — Home.py being the entry point file. We can see this running in my browser below.
Step two - prepare your Azure environment!
To host this application in the simplest way possible in Azure, we can just deploy the application code to an Azure app services instance. We can the prerequisite infrastructure via the Azure portal — typically, you should use tools such as Terraform or Bicep, particularly as the size of your organisation’s cloud estate grows. A nice feature here is you can configure your app service to take your code directly, and let Azure handle the containerisation of the application for you.
To spell out a simple hierarchy of what needs to be provisioned:
- We need an Azure subscription…
- That contains a resource group…
- That contains an App Service plan…
- That is consumed by an App Service instance
For most experiments, I recommend picking the cheapest tier possible. Most Azure services have free tiers that will give you most of the core functionality you’d see in the wild & let you provision a prototype with minimal hassle. It does go without saying, if there are specific features you want to experiment with (e.g., app service deployment slots), make sure to provision a SKU that includes that feature! I provisioned the B1 app service plan SKU since the free tier only gives 60 minutes of compute per day. I also configured the App Service at the time of creation to take code rather than a container, and let Azure handle setting up containers for me each time I want to perform a deployment.
Very important: you will need to customise the start up command of the app service instance. In the case of Streamlit, it needs to effectively match the command we would use to run the application locally.
Step three — deploy your code!
Deploying code to App Services can be done in multiple ways, but I tend to think in terms of going “all the way” for production applications or super lightweight for prototypes:
- Tools like GitHub Actions & Azure DevOps are the first things that come to mind and automated deployment pipelines in these (and other tools) are the “best-in-class” solution. This can be great for integrating automated testing, deployments, rollbacks, approvals, and much more.
- Using Git from your device to push your code to a new remote which corresponds to a deployment endpoint for your app service. Here, Azure provides you with a username and password to use for authentication, and it is very similar to pushing code to tools like GitHub.
- There are other ways, but these are the main two to be aware of. Azure’s documentation details some of the other methods available.
For simplicity, I’ll use the method where we add a Git remote to a repo and push to that location. In the screenshots below, note that I first show that I have added a Git remote, and performed a push to my remote called “Azure” using the credentials specified in the Azure portal.
With the code deployed, all as is needed now is to visit the URL of the application and see that it is working as expected! This is quite daunting the first time you tackle this kind of task, but with experience it becomes very straightforward.
Considerations
There’s a lot to think about when deploying app services to Azure in this way:
· Identity and Access Management: you don’t need to build your own authentication/authorisation service. Permissions can be configured through Azure Active Directory, and enabling Seamless Sign-On is just part of the App Service configuration. It then boils down to standard best practices around role-based access control, etc.
· Security: to continue in the security vein, there’s a lot more beyond the identity piece. For example, virtual network integration lets you control traffic to the app service by sitting the application within a subnet behind protections such as Network Security Groups. Another possibility is proactively analysing code for issues, such as credentials being stored in plaintext (tools exist for this such as SonarCube that could be used as part of a build pipeline). Engaging proactively to understand your organisation’s requirements here is very important, especially given the recent wave of cyber crime and high-profile attacks.
· Deployments: this is personally the part I find most interesting, because a lot of techniques open up to you at higher tiers that can make life really easy. For example, past a certain tier you get multiple “deployment slots”, which allows you to deploy multiple versions of the same application side by side, and direct traffic among them as you see fit. One key thing this enables is de-coupling the deployment and release process; you can deploy to a different slot other than the one end users see, and simply switch traffic between slots (i.e., release) at any time after that deployment is finished. The nice thing is configuration follows your deployment slots, so it’s very much a case of flicking a switch. It also makes rollback significantly easier. Google’s architecture centre details a lot about DevOps best practices that makes for an interesting read.
· Cost implications: if you can get away with choosing a cheap tier, this can be very affordable. That said, other tools can be competitive on price. For example, while I used Streamlit to showcase app deployments to Azure, if I were actually choosing a tool for a project in a company heavily invested in Microsoft cloud, I would bear in mind that Power BI Pro is included with every Microsoft 365 E5 license (and otherwise costs $10/user/month). It’s one of tech’s mantras: picking the right tool is always important.
· When to build it yourself: if you’re looking to build something particularly niche that’s unlikely to have out-of-the-box support from most vendors, this is where having an awareness of how to go about building your own in-house tool is important. This is essentially because sometimes you will hit limitations in pre-built products. This includes many standard components of any solution — networking, secret management, etc.
There’s a whole lot more you can get into over time, but these are the main ones. Slowing down and thinking for a while to identify what would be the best solution for your situation is always a wise move.
Conclusion
So, recapping what we’ve seen:
· We explored what Streamlit is, and how it works. It’s one framework among many for Python, and it’s well suited for building webapps for interacting with data.
· We deployed a working Streamlit app to an Azure cloud environment, trying to keep on looking at the issue through a lens of finding techniques that will generalise to applications based off other frameworks.
· We looked at some of the common considerations for going down this route — security, cost, deployment methods, and more. If you want to do further study (which I strongly recommend), I highly recommend anything by John Savill, or Microsoft Learn.
Personally, I find there’s a lot of enjoyment in sitting down crafting a really cool solution to an interesting problem. Tech teams can do a lot of prototyping, but ultimately these ideas need to either hit production to generate value, or at least prove an idea isn’t as good as first thought so time isn’t spent bringing it to production. Hopefully this article highlights that it can be surprisingly easy to get things up and running and in the hands of users thanks to the wonderful thing we call cloud!
