My previous article recommended that one should reconsider using Python in production. However, there’s one category of use case where Python is the dominant option for running production workloads. And that’s data analysis and machine learning. Almost all bleeding-edge work in data analysis and machine learning, especially around LLMs, happens in Python. So, here are some of my learnings on how to run Python in production. ...
I started writing in the 2010s when Python 2 was going to be deprecated and Python 3 was too early to support. Python might have died there and then but was picked up by the data science and machine learning community, so, it survived. Running Python in production comes with various gotchas though. Python is resource-intensive Let’s consider a simple Docker image containing “Hello World”. Dockerfile 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 # Build: docker buildx build -t python-fastapi -f Dockerfile_python . # Size: docker image inspect python-fastapi --format='{{.Size}}' | numfmt --to=iec-i # Run: docker run -it --rm --cpus=1 --memory=100m -p 8000:8000 python-fastapi FROM python:3.12-slim AS base WORKDIR /app RUN pip3 install --no-cache-dir fastapi==0.115.11 uvicorn==0.34.0 SHELL ["/bin/bash", "-c"] RUN echo -e "\ from fastapi import FastAPI\n\ app = FastAPI()\n\ @app.get('/')\n\ async def root():\n\ return {'message': 'Hello World'}\ " > /app/web_server.py ENTRYPOINT ["uvicorn", "web_server:app", "--host=0.0.0.0", "--port=8000", \ "--workers=4", "--limit-concurrency=32"] And a similar web server in Go. ...
In MusicSync , one of the views became complex and too slow to be inflated on the UI thread. So, I decided to do some Pooling around it to inflate it on the background thread and use it on the UI thread. This made the UI snappier, reducing multiple-second load times when opening some folders. However, soon I ended up with an edge case where re-opening the activity (and not the app) led to a semi-functional app. This edge case is hard as it gets triggered only in particular scenarios where the user destroys the activity via swipe up. At the same time, the app keeps running due to the attached foreground service that’s playing the media. And on activity re-creation, I got stale views! ...
This is a story of a messaging app used by billions of users. The app followed an extremely strong model of privacy. The app never persisted the user’s data on the servers. All the communication is end-to-end encrypted. A lot of users of this app, especially, on Android would regularly uninstall and reinstall the app. Now, to prevent these users from losing messages, the messages were backed up to the user’s SD card. In the Android security model, an SD card is a public storage space , accessible to all apps. So, to keep messages private, the backups were encrypted. ...
Google Domains A year back, I had to migrate my domain after Google decided to shut down Google Domains. I had to, not only, painfully setup multiple side-projects sub-domain mappings again on a new domain registrar but also re-verify my domain and re-create those mappings on Google Cloud Run . Google Container Registry Google Container Registry is shutting down in 2025. It has been replaced with a new project called Artifact Registry. So, why is Container Registry being shut down? Probably because it 10X cheaper than Artifact Registry. ...
I use Makefile for Android just like I use Makefile for my non-Android side-projects .
Android has two distinct navigation guidelines as opposed to iOS. Getting them right is nuanced.
Let’s say you are building a git analytics product. Your product supports GitHub and GitLab for now. It might support more products in the future. 90% of the codebase that supports GitHub and GitLab is identical. 10% is specific to GitHub and GitLab. There are two ways to build software abstractions here. The easy path to fall for is to have unified objects that take care of both GitHub and GitLab data. These objects would, however, behave 10% differently depending on whether it is GitHub or GitLab. Your codebase will be ridden with conditionals that trigger only for one or the other. ...
If you run any web service always enable support for serving compressed responses. It will save egress bandwidth costs for you. And, more importantly, for your users. Over time, the servers as well as client devices have become more powerful, so, compressing/decompressing data on the fly is cheap.
Hugging Face is GitHub for machine learning models. Their on-the-fly model download scheme, however, is difficult from a DevOps perspective. Here’s how to disable it.