The architecture behind a one-person tech startup • Hacker News Board

Re: The architecture behind a one-person tech startup

#131

Post by luckylion » Thu, Apr 08, 2021, 4:18 PM UTC

anarsdk wrote: post #86

ThePhysicist wrote: post #13

Earlier quoted context omitted.

No it's not, you can check e.g. the EDPB's recommendation [1] on this. At the very least you'd need to use data mapping and ensure EU citizens data stays within the EU, the author's service advertises "200 edge locations around the world" so I'm skeptical whether data won't leave the EU. Not many companies care about this and there's little enforcement so far, I think it's fair to think about this though if you're ru…

Edge locations refer to the CDN which his static assets are served from, i.e. HTML, JS, CSS, images. Not customers data.

Data is passed through -unencrypted- those edge locations though.

Re: The architecture behind a one-person tech startup

#132

Post by mattferderer » Thu, Apr 08, 2021, 4:18 PM UTC

yalogin wrote: post #122

This is probably not the best place to ask this question, but as a solo founder or just to reduce costs/time are there some standard free software packages that are used when creating sites? For example most sites need a user sign up mechaism, a authN and authX mechanism to gate access to different pages. Are there open source projects that provide this? Or do site owners develop these from scratch every time?

You might find this useful - https://github.com/gothinkster/realworld

Different framework implementations of a CRUD website with authentication.

A lot of popular web frameworks have basic authentication out of the box & easily allow you to tie free authentication with accounts like Google, Microsoft, and many others. There are also paid alternatives that may save you more money than the free ones if you need advanced authorization controls or other features.

Most devs probably have a collection of ways they've done it in the past that they pull from when needing to adjust from the default framework's methods.

Re: The architecture behind a one-person tech startup

#133

Post by uh_uh » Thu, Apr 08, 2021, 4:19 PM UTC

rory wrote: 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.

If your frontend is on CDN, how are you handling auth? Do you use Firebase for that?

Re: The architecture behind a one-person tech startup

#134

Post by adamhp » Thu, Apr 08, 2021, 4:21 PM UTC

wmichelin wrote: post #9

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.

Work somewhere where you're the big fish in a small pond. You're forced to wear a bunch of different hats and learn multiple tools across multiple business functions.

Re: The architecture behind a one-person tech startup

#135

Post by adamhp » Thu, Apr 08, 2021, 4:24 PM UTC

chrisandchris wrote: post #4

> From a technical point of view, this SaaS processes a large amount of requests per second from anywhere in the world, and stores the data in an efficient format for real time querying. That is the closes thing to a number of requests I could find. So this architecture, no matter how solid, is somewhere between „way to large“ and „matches perfect“. It seems like a solid breakdown on how to deploy your services to k8…

> But it does never mention whether it actually makes sense at the scale he actually has.

What does "make sense" in this context mean? It sounds like you're assuming he chose K8s for the scalability, but scalability isn't the only consideration here. Familiarity of the tooling is the biggest one that he mentions in the post. He even goes so far as to say that k8s probably isn't right for everyone, it's just what he knows.

It's efficiently supporting a profitable application and requires minimal maintenance. That seems to accomplish the goals of "infrastructure", broadly speaking.

Re: The architecture behind a one-person tech startup

#136

Post by hn_throwaway_99 » Thu, Apr 08, 2021, 4:27 PM UTC

iamgopal wrote: post #63

rory wrote: 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.

People here underestimate google app engine a lot. But I doubt if there is better one person Saas service out there.

If you haven't checked out App Engine in a while, you really should. Especially check out the App Engine "Flexible" editions, which make it really easy to run on App Engine withOUT getting locked in.

I run a NodeJS GraphQL server in App Engine Flexible, and it is basically just like running it in a Docker container. It's also pretty trivial to run in Google Cloud Run if I so desired, there is even a tool to assist: https://github.com/GoogleCloudPlatform/app-engine-cloud-run-...

Re: The architecture behind a one-person tech startup

#137

Post by hn_throwaway_99 » Thu, Apr 08, 2021, 4:30 PM UTC

mtlynch wrote: post #99

rory wrote: 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…

If you're using the App Engine Flexible editions, it's really easy to not worry about vendor lock in or really even deprecation much at all. E.g. it's easy to run a basic Node, Python or Java backend in App Engine Flexible, making use of a MySQL or Postgres DB in Cloud SQL, so you don't have to worry about managing servers at all and you get all the benefit of automatic scaling without the semi-nightmare of running your own kubernetes cluster. Then even if App Engine totally went away you just have a normal Node, Python or Java app running against a MySQL or Postgres DB that is pretty trivial to migrate to another platform.

Re: The architecture behind a one-person tech startup

#138

Post by bulte-rs » Thu, Apr 08, 2021, 4:33 PM UTC

knodi wrote: post #61

I have done with before, ran and one man b2b saas platform with 30clients from around the world. Infrastructure was the easiest part. We where processing roughly 100million messages a day, about 5 nodes. Monitoring was good, application performance tracking was good. Business ran for close to 7 years, making about 1.3mill a year on an average year.

Care to elaborate on the use of past tense?

I.e.: are you no longer in business, sold it or no longer running it solo?

Re: The architecture behind a one-person tech startup

#139

Post by efortis » Thu, Apr 08, 2021, 4:33 PM UTC

My infrastructure is $2,800/year.

There are two Servers load balanced with DNS.

Each Server has 3 jails (Nginx, App, DB) and 2 NICs

The internal NIC is for replicating the DB, and for the App Servers to target the Primary one.

Diagram and Configs: https://blog.uidrafter.com/engineering/freebsd-jails-network...

Re: The architecture behind a one-person tech startup

#140

Post by void_mint » Thu, Apr 08, 2021, 4:35 PM UTC

Sodman wrote: post #65

A lot of people are going to jump on the "he used k8s and he doesn't even work at Google scale!" part of this writeup, but I think it's a perfect demonstration of the concept of innovation tokens [1]. He admits in TFA that clickhouse was the only new piece of tech in his stack, and he was already familiar with k8s et al - so he's able to focus on actually building the products he wants. I could see somebody unfamilia…

> Where the wheels come off is when you've never touched k8s, postgres, aws, rust, graphQL or vue - and you try to mash them all together in one ambitious project.

In my experience (both myself and observing others) this is the cause of lots of side project (sometimes even startup) failure. Lots of people choose a tech stack that's far away from what they've worked with, so they never get past the "read the docs and try to get anything working" stage. For a real chance at completion it seems like the recipe for success is choosing a stack that's 1ish derivative away from a dev's competencies so they have a new and exciting thing to learn, but are able to continue progressing and adding value.

I am also a person that, prior to using Azure, was an absolute "Kubernetes is a big waste of my time and I'll just skip it" person. I wrote it off as predominantly "resume-driven". Now, having used Azure for about a year, I'm rewriting all my Azure infra to use AKS to better insulate me from the inevitable issues that come up when I GTFO of the Azure sphere as soon as our credits run dry. And, what I'm learning, is Kubernetes is a just-fine deployment/orchestration/management tool for containerized infrastructure that is _not_ a massively complex microservices infra. It's just a more streamlined approach to scaling and managing cloud-agnostic tooling/containers.