5 ms·
I think people often don't realize that depending on the language runtime, micro-services can easily be a must. Most service boundaries at organizations are "I
by parhamn 3y ago
I think people often don't realize that depending on the language runtime, micro-services can easily be a must.
Most service boundaries at organizations are "I need a different version of a pinned package we can't upgrade.". This is common in languages where there is support for only using one version of a given package, and it's worse if there isn't a culture of preserving function APIs. E.g. any python company with pandas/numpy in the stack will need to split the environments at some point in the future, no ifs ands or buts!
- pclmulqdq 3y agoI have heard that the reason Docker (and containers in general) took off was that they solved the problem of Python's awful package management. I didn't believe it until I saw people put Python in production and have to deal with this. At this point, I would rather have a physical snake in my server racks than any Python code.
- nurettin 3y agoI have used python in production for years, multiple servers, multiple racks, and deployment has always been as simple as ./deploy.sh pull sync migrate seed restart pull calls git pull, sync runs pipenv sync, migrate runs django migrate, seed runs django management command seed, restart calls systemctl --user restart
- toomuchtodo 3y agoThis was not my experience building infra for a startup heavily leveraging a Python monolith. It was painful AF (both when developing locally and deploying to VMs) and Docker made the deployment story palatable (build, push to hundreds of VMs, run).
- nurettin 3y agoAny details as to why?
- toomuchtodo 3y agoVirtual envs, dependency hell, etc. I just want a binary to build and push (previously to VMs, now to k8). Docker does that for Python. Target simplicity, it’s the ultimate sophistication.
- nurettin 3y agoI target simplicity by having one virtual environment instead of many and synchronizing dependencies instead with the main branch instead of... hell?
- toomuchtodo 3y agoHave you tried deploying to hundreds or thousands of VMs? In my experience, managing container deployment and state is much easier, vs wrestling with inconsistent env state on compute for whatever reason.
- nurettin 3y agoFor the life of me I don't understand how deploying to 10 machines is functionally different from deploying to a billion machines as the process is exactly the same. Unless you sabotaged your deployment machines with some manual meddling, it's the same with Docker images and Ansible.
- pclmulqdq 3y agoWhen you run a single, simple Python service, it's fantastic. When you scale your Python, it's an awful dependency hell.
- nurettin 3y agoCan you please explain how this dependency hell manifests itself if you are using a dependency resolver such as poetry or pipenv which locates the appropriate maximum version? Once you've locked the appropriate versions, you just do pipenv sync in prod like I said.
- pclmulqdq 3y agoYes - you pull in two third party libraries that need two incompatible versions of a mutual dependency. That library (the common dependency) is not backwards compatible due to deprecated functions or whatnot. That dependency could also be Python itself. This is an incredibly common occurrence, especially with ML systems which are not designed by people with an engineering mindset.
- nurettin 3y agoNot getting the package versions you want is a local dev problem and not specific for python at all. I will remind you that this thread is about deploying to prod and dispelling vague assertions of nebulous problems that are supposedly solved by docker.
- sofixa 3y agoThat only works until you have a conflicting dependency (same codebase: a.py imports libraryA which needs dep>3.0.2, and b.py imports libraryB that needs dep==1.8.3). Then you're screwed.
- nurettin 3y agono, pipenv install will resolve that and use the appropriate max version.
- pclmulqdq 3y agoIt will use the max version, but that version will likely have deprecated things that the other dependency relies on in its chosen version. Specifying that you must use an old version of a library is how a lot of Python maintainers resolve deprecations in their dependencies.
- noitpmeder 3y agoDo we live in different worlds? Virtual environments solve 99% of all python packaging and installation use cases.
- YetAnotherNick 3y agoI guess so. Virtual environments doesn't solve any of the problems as python authors either don't specify the version or their dependency author doesn't specify it. Try running any of the program which is >3 years old. I remember in one of the programs I needed to pin 10 dependency versions manually to make it run.
- biorach 3y ago> I needed to pin 10 dependency versions manually to make it run um... You should have been pinning all your dependencies from the very start
- noitpmeder 3y agoAgreed, or if you dont, you should run pip-compile during CI/merge in order to pin every dependency in the entire tree. These are very solveable (and have been solved for a while) problems. It really pains me that most people are either unaware or do not dive deep enough below the surface to find them.
- YetAnotherNick 3y agoIt wasn't my code. I pin all my dependencies, but lot of python code has been written by people without software engineering experience like university students and to an extent ML engineers.
- biorach 3y agoOK but your occasional contention was that > Virtual environments doesn't solve any of the problems as python authors either don't specify the version or their dependency author doesn't specify it. This is a problem of lack of training or willful poor practice, not an issue with venvs themselves which absolutely do solve this issue. Agreed, the problem would not exist at all if an approach like that of say, node development, existed, but here we are.
- vbezhenar 3y agoI have python service with does some AI job but it just doesn't build anymore. I have "golden image" which I carefully back up, because losing it would mean the catastrophe.
- baq 3y agoHad the same problem with node 16->18 recently. No recent OS version would build some extension. Had to rearchitect a good bit of an app to get back to something working.
- marcosdumay 3y agoPython has a real problem with version incompatibilities for the interpreter, and a few packages require C libraries of specific versions. But outside of that, vitualenvs solve all of the issues of "how do I run those two programs together". After the Py2 vs. Py3 thing settled down, almost all of the operations issues got away. That said, Python has a really bad situation about dependencies upgrade on the development side. But Docker won't help you there anyway. Personally, at this point I just assume any old Python program won't work anymore.
- eptcyka 3y agoDid you read the same article I did? How is this relevant?
- parhamn 3y agoI meant to reply to "good lord is this what modern microservices are like?".
- jmspring 3y ago“Microservices can easily be a must” please explain. Your example talks of packaging issues.
- LegibleCrimson 3y agoMicroservices (or really services in general) solve some of these packaging issues. If I have my application that depends on package A that pulls in dependency C version 1.x, and also on package B that pulls in dependency C version 2.x, this just doesn't work in Python, and many other languages. The only way to make it work is either rectify my dependencies so all my versions match (by running one of your dependencies out of date) or to split them up so my application is composed of one service that pulls in package A and another that pulls in package B, and have them talk over some IPC.