When you write your application (web application in Python in this case, but
doesn't really mater) you want to focus on the logic and useful function it does. But we always need to have in mind production-readiness, deploy-ability and future maintainable right in the beginning. I usually find this hard, especially when moving between different frameworks, underlying back-ends, etc.
A friend of mind recommended my talk by Hynek Schlawack from this years PyCon 'How to Write Deployment-friendly Applications' which I found very much interesting and helpful.
https://www.youtube.com/watch?v=wuCpCkrfeMs
Below are my thoughts on what I really liked (and will use) and things that I still need to find answers to.
Main quote to take away
Even if you deploy with git-pull, on a prod server, like an animal.
This was such a to-the-point saying, I will use it now all the time. Unfortunately I do see cases when I'll need this ;)
Logs should go to stdout
I really like this idea being re-iterated in this talk. I've seen it before too and I find this really important part of decoupling your application from environment. Your code should not know or care where logs will be stored, how they are processed and handled.
Quoting Hynek:
Please do not try to log into files anymore nowadays and god forbid do not try to rotate them yourself.
Machine readable logs in prod
This one is also usually non-obvious, but so very true. I am amazing seeing people parsing logs of their own apps with regexps (like animals ;). Unless there is some external requirement for log format (like apache format, or similar), why not just write in a structured format?
Redeploying apps to change config (no reloads)
This sounds very much like immutable deployments. Again looks very useful and definitely a concept to have in your app ecosystem. It does add complexity of orchestrating the switch between 'old' and 'new' version of application. But you will have it for other reasons anyway, on the other hand the benefits provided should outweigh these.
Configuration by environment variables
I like how env vars are quite 'standard' between environments and indeed can be a good place to get config from. Although I like this idea, unfortunately it still requires some kind of 'config example' to convey to users/customers variable list supported by app.
Readiness/health/metrics API endpoints
This is a great idea, akin to something like JMX for Java (for metrics). But also the idea that an application has a clear API to ask 'Are you ok?' or 'Are you redy?' is much better for monitoring, than trying to figure out health based on side-effects. This doesn't mean of course that you do not need external health probes. This is even more true for metric collection. Who else than application itself can gather and provide important metrics to monitor?
Using conventions in variable and file naming
This is a controversial one. I'll only comment that conventions are only great when they can be easily conveyed to everyone who works (and will work) on the project. This is usually quite hard, especially in the long-term. In this particular example application includes gunicorn (third party code) which is getting it's configuration from env variables HOST/PORT. This looks cool, but I am really worried for the first person who will be debugging for few hours why gunciron selects wrong port in some edge case only to find this convention. From what I saw in past applications relying too much on 'unwritten' conventions end up in a 'it works, but we are not sure how' state and got rewritten from scratch .
What do you guys think on this topic? How does it match with your past experience?
Top comments (0)