Live data from Hacker News

The architecture behind a one-person tech startup

anthonynsimon.com

101–110 of 334 posts

Re: The architecture behind a one-person tech startup

#101

An important distinction here is that PanelBear (OP's One Man SAAS) is something I would define as an "analytics" SAAS and as such has requirements that are way above what a typical CRUD SaaS might have. That's not to take anything away from the excellent writeup, but more so that someone who is thinking about starting a SaaS maybe doesn't jump to the conclusion of "I should go learn Kubernetes".

Yep, and their recommendation on Render is a good one. I used it for a SaaS / fintech app I built and it couldn't be easier to work with. Great support too if you need it.

Re: The architecture behind a one-person tech startup

#102
post #83

Nice read. I haven't seen any references to Ansible or similar tools. For the ones who know: given the architecture described in the article, does Ansible fit in the picture? I don't know a lot of k8s but I wonder how VMs are provisioned (e.g., how docker is installed?)

They mentioned using managed Kubernetes. Normally that means the VM provisioning is managed by the cloud provider.

Re: The architecture behind a one-person tech startup

#104

How do you start learning this breadth of software engineering? I consider myself good in the python / django space, but where do I start with learning these infrastructure technologies? I find that I use them once or twice periodically, and then don't touch them for so long, so I forget much of what I have learned.

For me the magic trick has always been side-projects. I have a lot of them, and each one is an opportunity to learn new tricks.

(Over time I've learned that it's best to avoid side-projects which have user accounts and store data on behalf of other people, because that's not a side-project: it's an unpaid job.)

Re: The architecture behind a one-person tech startup

#106
post #99
post #28

My one-man-SaaS setup: - Static frontend hosted on Netlify (free unlimited scale) - Backend server on Google App Engine (connecting to Gcloud storage and managed DB via magic) I realize I'm opening myself up to vendor lock-in and increased costs down the road (if I even get that far), but I've wrangled enough Docker/k8s/Ingress setups in the past to know it's just not worth the time and effort for a non-master.

In my experience, the issue isn't that Google will jack up the costs but that they'll deprecate their infrastructure and push the migration work onto you, often forcing you to reimplement major features.[0] One notable example is how their NDB client library used to automatically handle memcache for you, but they got rid of that with Cloud NDB Library and forced clients to implement their own caching. The sequence of…

Are you still with them? If yes, would love to hear why. Otherwise, what made you jump?

Re: The architecture behind a one-person tech startup

#107
post #64

This goes against the HN trope that "you don't need Kubernetes unless you are Google-size". It turns out Kubernetes is actually perfect for small teams as it solves many hard operational issues, allowing you to focus on the important part of the stack: the application. The key is to stick to a simple setup (try not to mess with networking config) and use a managed offering such as GKE. We may need a Kubernetes, The G…

> We may need a Kubernetes, The Good Parts guide What is the closest thing out there today? Or at least a tutorial for sane, small production setups?

Kelsey Hightower's 'Kubernetes The Hard Way' [0] "is optimized for learning, which means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster."

https://github.com/kelseyhightower/kubernetes-the-hard-way

Re: The architecture behind a one-person tech startup

#108
post #95

Earlier quoted context omitted.

I'm curious, as someone knows probably only enough about this stuff to get myself into trouble, what am I missing out on by just pushing to heroku?

First of all nothing important, mostly stuff that's a distraction unless it becomes a need. That said, using a static frontend cached on a CDN in general improves initial pageload and cuts down on traffic to your server by a lot. Netlify makes this easy if you want to use React on the client (with NextJS). With AppEngine you get direct access in one console to all the bells and whistles of Google Cloud, basically the…

You can always add Cloudflare to the mix to cache static assets. This change is additive meaning you can start with a single Heroku deployment and if static asset traffic becomes an issue, you can create a Cloudflare account, configure DNS and be done.
Post reply on HN