Live data from Hacker News

The architecture behind a one-person tech startup

anthonynsimon.com

91–100 of 334 posts

Re: The architecture behind a one-person tech startup

#91
post #77
post #58

Earlier quoted context omitted.

I agree with you in terms of using what you already know best. > If you're not already familiar with these tools consider using a managed platform first, for example Render or DigitalOcean's App Platform (not affiliated, just heard great things about both). They will help you focus on your product, and still gain many of the benefits I talk about here. And: > I use Kubernetes on AWS, but don’t fall into the trap of t…

Makes sense, didn't mean my comment as a criticism of your setup Anthony. The product and infra look very cool! Just highlighting that things can be a lot simpler for those of us with more mundane requirements.

Hey no worries :) I think my reply came off differently than I meant it.

I just wanted to complement your sentiment.

Re: The architecture behind a one-person tech startup

#95
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.

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 same as the other infra giants. AWS has even more bells and whistles but I find its console more annoying.

Re: The architecture behind a one-person tech startup

#96

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…

> This goes against the H̶N̶ trope that "you don't need Kubernetes unless you are Google-size".

FTFY.

Why think of groups of people as though they have a single mind?

Re: The architecture behind a one-person tech startup

#97
I'd argue that just about every infrastructure that looks like this benefits from Kubernetes (that you're not setting up and managing), and that's a lot of them. The biggest problem is that not enough people have boiled down Kubernetes enough to look like heroku yet. Google Cloud Run is possibly the best example of what Kubernetes can look like/run like -- it runs on (probably a relatively heavily modified) KNative, a project that runs on top of kubernetes.

The "point" of Kubernetes is to drop the difficulty of building a service like Cloud Run to zero. It drops the cost of building a Heroku down to zero. I'd bet my bottom dollar that fly.io and render are running on Kubernetes (maybe they mentioned it somewhere already and I just missed it). With the right cluster set up, building one of those platforms (or others that I won't mention) is almost as simple as setting up stripe checkout and writing a web interface to turn form fields into JSON fields and send them to a kubernetes cluster (possibly with hard multi-tenancy! not to get too into it, but you can literally provision kubernetes clusters from kubernetes clusters, ephemeral or otherwise).

No other tool in the devops world except for maybe the initial orchestrator wave (ansible/puppet/salt/chef) has been this much of a force multiplier. Ok, maybe that's hyperbole, but if adhoc-bash-scripts->ansible is 1->2, Ansible->Kubernetes is similarly 1->2, especially if you consider baked in cloud provider support/innovation.

But here's the secret -- perversely, I'm happy deep down that everyone thinks k8s is too complicated/is a buzzword/isn't worth the effort. All it means to me is that I'm still ahead of the curve.

Re: The architecture behind a one-person tech startup

#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 datastore APIs I've seen during my experience with AppEngine is:

* Python DB Client Library for Datastore[1], deprecated in favor of...

* Python NDB Client Library[2], deprecated in favor of...

* Cloud NDB Library[3], still supported, but they ominously warn new apps to use...

* Datastore mode client library[4]

[0] https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

[1] https://cloud.google.com/appengine/docs/standard/python/data...

[2] https://cloud.google.com/appengine/docs/standard/python/ndb

[3] https://cloud.google.com/appengine/docs/standard/python/migr...

[4] https://cloud.google.com/datastore/docs/reference/libraries

Re: The architecture behind a one-person tech startup

#100
I am also a one-man SaaS (though not a successful one). The following tends to be my stack (on Google Cloud, if you will):

- Cloud Run (serverless containers)

- Cloud SQL (via proxy)

- Cloud Monitoring & Logging (formerly Stackdriver)

- Compute Engine (if necessary, e.g. websockets)

- Cloud Build for GitOps (deploy on push)

It's clean and simple (to me). Billing is in one place, nicely separated by projects. Monitoring & Logging is already built in. No need to span multiple dev SaaS tools. So far managed to avoid Redis caching because Golang + Postgres is fast enough, so far. But if you need Redis you can DIY on Compute Engine or try Cloud Memorystore (configure the memory to a low amount for cost savings).

Google Cloud drawbacks: Additional charges necessary to connect Cloud Run to VPC (via proxy instances). Load balancing on GCP ain't cheap ($18/month, though to a larger enterprise that is a rounding error). But in my setup I didn't need these things.

As shown above, I have heavily optimized for cost and simplicity in my setup.

Post reply on HN