I always wonder if python, auto scaling, and cloud change the kinds of businesses (and margins) required. Running 60+ pods of gunicorn for an app incurs lots of overhead, especially if one is using small VMs.
I can't count the number of war stories I've heard from SRE friends who joined some company and realized they were taking over a Django stack for the core of a business that was blowing gaskets left and right.
This sort of thing just leaves me wondering if margins have to be high to support a slower language, slower framework, and complicated deployment model to work around the Python GIL.
Call me jaded but I just wonder if it's worth the time to market to do Python these days versus say Go and be able to deploy a static binary and use all your CPU cores simply. K8s is way less tempting for a "one-process-architecture " (minus database and maybe nginx) until the system is much larger (instead a couple of systemd units would sort you)
This setup is very similar to the startup that I run. We have used k8s from day one, despite plenty of warnings when we did, but it has been rock solid for 3 years. We also decided to run Postgres and Redis on k8s using Patroni + Sentinel and the LVM storage class. This means we get highly performant local storage on each node and we push HA down to the application.
Was there a learning curve? Yes, it took a solid week to figure out what we were doing. And we've had the odd issue here and there, but our uptime has exceeded what we would have had with a cookie cutter AWS setup, and our costs have been a fraction (including human capital costs).
I remember building a todo app as my first SaaS project, and choosing something called Stormpath for authentication. It subsequently shut down, forcing me to do a last-minute migration from a hostel in Japan using Nitrous Cloud IDE (which also shut down). Just pain upon pain.[1]
Now, you can just pick a full-stack cloud service and run with it. My latest SaaS[2] is built on Google Cloud, so Authentication, Cloud Functions, Docker containers, logging, etc straight out of the box.
Not to mention, modern JavaScript and CSS are finally good. With so many fewer headaches, it’s a great time to build.
[1] Admittedly, I was new to software dev and made some rather poor tech choices
My only complaint Fly.io doesn't have managed DB (https://fly.io/docs/postgres/getting-started/what-you-should...) and task queue.
At work we use GCP, but try to be as high as possible in the abstraction layer (e.g. use Cloud Run and Cloud SQL).
I wonder how they make time to manage it all _and_ iterate on projects _and_ have a life outside of that.
This is the biggest problem I've long struggled with. I don't know of a good solution.
The best tech stack when starting a startup is one you don't have to learn.
There's a million things you learn when starting a company. Don't make yourself learn an entirely new tech stack on top of everything else. This advice means you'll be using whatever you've used in the past which might not be the sexiest or newest technology, but your users won't care. Your users want a working product. Choose the stack that will result in a working product the quickest.
Refactor and migrate to a better stack later, if necessary. (It rarely is)
For me, that meant deploying to Elastic Beanstalk (I know, boring, no one talks about it, but it works!) and using Mongo because I was already comfortable with it. It also meant not using React, at first. This was the right answer for me, but might be the wrong answer for you! Build your app on the technology you know.