Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The architecture behind a one-person tech startup

anthonynsimon.com

Post reply on HN
Print view View original

301–310 of 334 posts

Re: The architecture behind a one-person tech startup

#301

Post by wmichelin »

suifbwish wrote: post #257
wakatime wrote: post #152

Earlier quoted context omitted.

I really enjoyed your post too! I would be interested in more details around the "100s of hours". I want to try a k8s setup like yours, but after investing those 100s of hours into my Flask setup it's hard to justify spending that time again for something else when this already works. Also interested in the costs for your setup. My costs are in my other comment [1]. [1] https://news.ycombinator.com/item?id=26740911

You should be able to run a flask app pretty easily in kube. Basically you would build a docker image containing the app then deploy it with k8 I believe

This is a dramatic oversimplification of how complex it is for a python developer to configure and deploy an application on kubernetes.

Re: The architecture behind a one-person tech startup

#302

Post by ngrilly »

mtlynch wrote: post #233
ngrilly wrote: post #226

Earlier quoted context omitted.

You don’t want to maintain your own database server, even managed by GCP, but with SQLite you have to maintain state on GCP Persistent Disks and backups to S3 using Litestream. Why do you think this is easier?

I don't have to maintain state on GCP persistent disks. I can blow away a server without warning, and I'll only lose a few seconds of data. True, I have to maintain state on S3, but there's not much work involved in that. If I was maintaining my own database server, I have to manage upgrades, backups, and the complexity of running an additional server. With Litestream, I don't have to manage upgrades because nothing…

If you can lose the last few seconds then yes that's fine. But for most applications I've been working on, we didn't have that flexibility (committed means durable).

I don't see any operational complexity with Litestream.io. I think that's an awesome tool. But it's not that different of managing PostgreSQL backups with something like WAL-E.

The complexity of managing your own database server only exists if you don't use a managed service. Then there is no server to maintain and they do all the things you mentioned for you.

Re: The architecture behind a one-person tech startup

#303

Post by ngrilly »

mtlynch wrote: post #233
ngrilly wrote: post #226

Earlier quoted context omitted.

You don’t want to maintain your own database server, even managed by GCP, but with SQLite you have to maintain state on GCP Persistent Disks and backups to S3 using Litestream. Why do you think this is easier?

I don't have to maintain state on GCP persistent disks. I can blow away a server without warning, and I'll only lose a few seconds of data. True, I have to maintain state on S3, but there's not much work involved in that. If I was maintaining my own database server, I have to manage upgrades, backups, and the complexity of running an additional server. With Litestream, I don't have to manage upgrades because nothing…

SQLite is really great. By using it, you don't have to install and maintain another service, and you don't have to think about things like network security. From that point of view, that's clearly simpler.

But it also introduces a few challenges. It's not as easy to connect to your database remotely to inspect it, with something like SequelPro for MySQL. It's not possible to create an index or drop a column without blocking all writes, which can be annoying if your database is large. Database migrations in general are harder with SQLite because ALTER TABLE is limited. [1]

One last thing regarding losing the few seconds of data. If you use something like Google Cloud Regional Persistent Disk, then your data are replicated synchronously in two different data centers, which means you can lose your server, restart another one, and not lose any data. Can still be combined with Litestream for backup to S3 with point-in-time restores.

[1] https://sqlite.org/lang_altertable.html

Re: The architecture behind a one-person tech startup

#304

Post by toomanybeersies »

mark_l_watson wrote: post #37
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.

Interesting, thanks. I used to use Google AppEngine a lot and very much liked it, but haven’t touched it for years. Now, I like the idea of using Heroku better, and just pay a little more.

My experience of Heroku has mostly been the pain of migrating to a different platform once you grow to the point that their pricing (and abstraction) starts to act against your growth.

Heroku is great for general applications, but if you're trying to do something that isn't a standard CRUD app, it can really start to bite you in the arse.

Their DB pricing in particular is incredibly inflexible compared to AWS RDS. Among other issues we had with Heroku at my old job, was having a DB that was hitting its storage limits, but was miles away from hitting its memory or connection limits. There was no option but to upgrade to the next tier, with additional memory etc., even though all we needed was additional disk.

That's not to say that Heroku is bad, but like any tool, you need to be aware of the long term costs that are often associated with term convenience.

Re: The architecture behind a one-person tech startup

#305

Post by toomanybeersies »

kaydub wrote: post #295
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.

I work at a unicorn. We're all in on AWS and don't care about lock-in. The vendor lock-in argument isn't worth considering for most businesses.

I'm almost inclined to believe that the relationship is inverted from what many assume.

Amazon will bend over backwards to accomodate a company spending $500 mil a year on hosting (apparently what Snap spends). Sure it's only a fraction of its revenue ($386 bill for AWS), but half a billion is half a billion.

Re: The architecture behind a one-person tech startup

#306

Post by slt2021 »

rkwz wrote: post #256
slt2021 wrote: post #186

Earlier quoted context omitted.

I wonder what happens during blue green or canary deployment? if your migration changes database schema in a way that affect previous version negatively? is it even possible to do blue/green deploy if your schema changes radically?

It's definitely possible but we need to spend sometime to make sure the changes are backwards compatible and gradually rollout the destructive change. Here's a really good guide on how to do this - https://docs.gitlab.com/ee/development/avoiding_downtime_in_...

thank you very much! this is a treasure find for me

Re: The architecture behind a one-person tech startup

#307

Post by tonyarkles »

ablekh wrote: post #291
tonyarkles wrote: post #252

Earlier quoted context omitted.

The ultimate “vendor independence” is racking your own servers in your own on-prem data centre with multiple internet connections. Very high capex, potentially low opex depending on scale. In the middle would be racking your own servers at multiple DCs. Less capex (you’re still buying servers, but not air handlers and power distribution), higher monthly opex. On the other end are things like GCP and AWS, where you ha…

You are painting an incomplete picture. Between high (racking your own servers at multiple DCs) & very-high (your own DCs) CapEx options and low CapEx options (IaaS and PaaS), there is a middle ground that - unless you need specific managed services, the larger PaaS ecosystem and/or an extreme scalability - is to use bare-metal cloud providers. This approach combines multiple benefits, including bare metal's max. per…

Totally true :). It's a spectrum and there's a ton of options in the middle. I was mostly pointing out the extremes.

Re: The architecture behind a one-person tech startup

#308

Post by hinkley »

pdimitar wrote: post #300
hinkley wrote: post #299

Earlier quoted context omitted.

Tons of reasons, but the main one is that cache is shared mutable state, pretending not to be. It has all of the ugly attributes of global variables, especially where knowledge transfer and reliability are concerned. In a read-mostly environment you can often more easily afford to update the state all at once. It’s clear what the effects are because they happen sequentially. The cost of an update isn’t fanned out and…

I agree that caching is mostly a bandaid fix. But IMO if it's used judiciously -- namely in response of a demand for a quick fix of a performance problem -- they can be OK mid-term. As for shared mutable state, yes, that's true, but what are the alternatives? Whether it's memcached or Redis or an in-process cache (like Erlang/Elixir have), the tradeoffs seem mostly the same.

> namely in response of a demand for a quick fix of a performance problem

Caches are addictive. The first one is 'free' (easy) and people start wanting to use that solution for all their problems, especially social problems (we can't convince team A to get their average response time to match our SLA, so we'll just cache them to 'fix' it)

They defer thinking about architectural problems until later, when they are so opaque that "nobody could blame you" for having trouble sorting them out. But I do. Blame them, that is.

Re: The architecture behind a one-person tech startup

#309

Post by suifbwish »

wmichelin wrote: post #301
suifbwish wrote: post #257

Earlier quoted context omitted.

You should be able to run a flask app pretty easily in kube. Basically you would build a docker image containing the app then deploy it with k8 I believe

This is a dramatic oversimplification of how complex it is for a python developer to configure and deploy an application on kubernetes.

If they have the drive to create an entire SAAS app, how is following a a few tutorials on deploying it to a container in k8 too difficult? It only takes 20-30 minutes to setup and there are hundreds of videos and step by step walk through a that hold their hand through it start to finish. Maybe I am over estimating how difficult it is to build an app in Flask then.

Re: The architecture behind a one-person tech startup

#310

Post by rebolyte »

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?

It’s still in the early stages, but Blitz[1] is a Rails-esque framework that expands on Next.js to add things like authn/authz

[1]: https://blitzjs.com/

Post reply on HN