11–20 of 259 posts
But does Python scale for back end applications?
Django has just so much stability, it was an obvious decision for me to go with it. And that's speaking as someone who has mostly worked with NodeJS/React for the past 5 years.
I love the pythonic principle of "There should be one obvious way to do it". This helps me cut down on decision making which is something quite annoying to deal with as sole-tech-founder. Now I get to focus on the business, and technology is just a matter of execution.
This seems like a pretty big stack for a single person to administrate - how much time do you spend on doing operations vs development?
There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feeding it is non-trivial (see: ZooKeeper dependency and all the problems you get once you move to a distributed database).
Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know. The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles.
But does Python scale for back end applications?
Yes, it does, as long as performance-bottlenecked code is not in Python (and it usually isn't). In the real world, you may have to extract some hot regions to C++ or Rust or Java, but 99% of your code will scale infinitely.
But does Python scale for back end applications?
There absolutely are performance pitfalls, and Python is less power efficient than other alternatives running some kinds of workloads at scale, but in a ton of environments the perf difference doesn't matter.
As a fairly new dev, this is really great information for me. Thanks for posting this. If you don't mind me asking, roughly how much do you spend (time) on this every week? How much of that is split between development, operations and product or business development?
Since I have a full-time job too, my time on this project is pretty limited, usually no more than 2 hours per day.
That's why I tried to automate and save time as much as I could using Kubernetes operators, well supported open source projects, and most importantly, tools I already feel comfortable with.
I don't have hard rules in terms of how I distribute my time, but recently it may have looked like this:
- 60% of the time I'm trying to understand the problem I'm solving (talking to customers, researching, evaluating features).
- 20% working on features, and issues.
- 20% promoting: writing blog posts, documentation, reaching out on Twitter, HN, Indie Hackers. Helping out customers integrate their website / understand how something works.
Of course, there's tons of other smaller things here and there, but those are the big "buckets" of my time.
Once I know what to work on next, I tend to prioritize as follows:
1) At the start of each week I pick 1-3 topics to work on next (for example writing a new blog post, working on a new feature, or even just writing documentation which I am going to next).
2) Each day when I'm working on my project I pick the most impactful thing I could work on, and start with that. I allow myself to explore a topic in depth, sometimes without a clear goal or deadline. After all it's supposed to be fun if I want to stick to it for the long term.
3) I try to respond to customer emails as soon as I can, and understand why they're giving my product a try. That's my gauge for what to work on the following week.
This seems like a pretty big stack for a single person to administrate - how much time do you spend on doing operations vs development?
Right now the operational effort is pretty minimal to be honest. I spend most of my time developing new features and talking my customers. I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended…
"I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended."
The amount of complexity and interdependencies these "here's my stack" posts describe are always a huge cognitive overhead for running a one-person SaaS.
Heroku costs more, but there's a reason for it. If you're even remotely making money from your product, and are alone in running the show, it's a no brainer to drop a couple hundred dollars a month to eliminate 99% of your ops headaches: the documentation, the add-on's, the fantastic UI, decent reliability, and ease of operations are totally worth it. Literally the worst thing one can say about Heroku is the cost, and possibly, the inability to build certain complex architectures (which most single-person SaaS services aren't).