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

Re: The architecture behind a one-person tech startup

#291

Post by ablekh » Fri, Apr 09, 2021, 10:10 AM UTC

tonyarkles wrote: post #252

brigandish wrote: post #246

Earlier quoted context omitted.

> I like to talk about to Cs is their strategy on capex vs opex, because honestly that determines quite a lot For example?

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. performance, full isolation / no "noisy neighbors", pretty much total control of the equipment that you rent, cloud-like elasticity, flexible, usually globally distributed, network architecture and reasonable pricing.

Re: The architecture behind a one-person tech startup

#292

Post by mark_l_watson » Fri, Apr 09, 2021, 10:26 AM UTC

nocommandline wrote: post #272

mark_l_watson wrote: post #37

Earlier quoted context omitted.

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.

If you don't mind my asking, can you say why you moved from GAE to Heroku and/or why you prefer Heroku over GAE?

I used them both in the same time period. I liked GAE because it was basically free to use for low use web apps, but has scalability built in. I liked Heroku because it was just so easy to develop and deploy with.

Re: The architecture behind a one-person tech startup

#293

Post by habosa » Fri, Apr 09, 2021, 10:59 AM UTC

JimDabell wrote: post #22

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.

It only takes two things – curiosity and time. When you are working on a project, if you hit the edge of your current knowledge / skills, push just a little bit further when it’s something that interests you instead of just aiming to hit the basic requirements / lean on other people. This minor effort compounds over time; do it for twenty years and you’ll be an expert in multiple disciplines and also an expert in how…

Actually I think it takes a third thing: need

At least in my experience I can read about different architectures all day and sort of understand them, but I only really "get" it once I find a non-toy problem I need to solve and attempt to apply the knowledge. Then you see how it really works and form hard skills which stay with you.

Re: The architecture behind a one-person tech startup

#294

Post by drbojingle » Fri, Apr 09, 2021, 11:47 AM UTC

skynet-9000 wrote: post #114

fnord77 wrote: post #80

Earlier quoted context omitted.

cloud vendor lock-in fears are overblown. pricing and features will always be competitive between the big vendors. I suspect people waste a lot of time/money trying to be cloud agnostic. Real vendor lock-in is when you have decades of code written against an Oracle DB and you're getting charged outrageous Oracle rates and it would also cost a fortune migrate.

... a decade later: Real cloud vendor lock-in is when you have decades of code written against a [cloud vendor] and you're getting charged outrageous [cloud] rates and it would also cost a fortune migrate.[sic]

A decade has to past first. Most start ups don't last 5 years. Statistically speaking he's right and if he's not, well, a project that lasted 10 years ought to be profitable so pay up. Not profitable? Then who cares that cloud lock-in broke the camels back. If it wasn't profitable enough to justify the investment needed to switch to another vendor then it wasn't profitable enough to begin with.

Re: The architecture behind a one-person tech startup

#295

Post by kaydub » Fri, Apr 09, 2021, 12:10 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.

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.

Re: The architecture behind a one-person tech startup

#296

Post by kaydub » Fri, Apr 09, 2021, 12:15 PM UTC

skynet-9000 wrote: post #114

fnord77 wrote: post #80

Earlier quoted context omitted.

cloud vendor lock-in fears are overblown. pricing and features will always be competitive between the big vendors. I suspect people waste a lot of time/money trying to be cloud agnostic. Real vendor lock-in is when you have decades of code written against an Oracle DB and you're getting charged outrageous Oracle rates and it would also cost a fortune migrate.

... a decade later: Real cloud vendor lock-in is when you have decades of code written against a [cloud vendor] and you're getting charged outrageous [cloud] rates and it would also cost a fortune migrate.[sic]

Any company after a decade is going to have growing pains.

Spend your early time working on your core business. If your core business isn't cloud agnosticism then you shouldn't be investing your resources there.

Re: The architecture behind a one-person tech startup

#297

Post by ZeroCool2u » Fri, Apr 09, 2021, 12:37 PM UTC

rory wrote: post #166

ashconnor wrote: post #153

Earlier quoted context omitted.

>managed DB via magic What product is this?

Google Cloud SQL. I say magic because locally I need a service key to connect to the proxy, but the production app doesn't seem to need anything but the internal google address.

The service credentials are supplied via an env variable that points to their location. Locally, you can provide the location directly or set the env variable yourself. When deployed, most GCP service environments just have that variable setup already and you don't have to think about it, so it feels a bit like magic. Same thing underneath the good though.

Re: The architecture behind a one-person tech startup

#298

Post by rory » Fri, Apr 09, 2021, 1:14 PM UTC

ZeroCool2u wrote: post #297

rory wrote: post #166

Earlier quoted context omitted.

Google Cloud SQL. I say magic because locally I need a service key to connect to the proxy, but the production app doesn't seem to need anything but the internal google address.

The service credentials are supplied via an env variable that points to their location. Locally, you can provide the location directly or set the env variable yourself. When deployed, most GCP service environments just have that variable setup already and you don't have to think about it, so it feels a bit like magic. Same thing underneath the good though.

Oh cool, that makes perfect sense, thanks for the explanation!

Re: The architecture behind a one-person tech startup

#299

Post by hinkley » Fri, Apr 09, 2021, 1:15 PM UTC

pdimitar wrote: post #220

hinkley wrote: post #179

Earlier quoted context omitted.

Many sites have low write:read ratios and don’t leverage that fact in their architectural choices. Availability for maintainers is often less critical than for consumers, and your life is better if you build that in. My current employers still haven’t learned this lesson and think caching fixes everything.

Not sure I am following you: why shouldn't we use cache?

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 obscured across the codebase, where or your team can delude yourself of the true system cost of a suspect feature.

Re: The architecture behind a one-person tech startup

#300

Post by pdimitar » Fri, Apr 09, 2021, 1:40 PM UTC

hinkley wrote: post #299

pdimitar wrote: post #220

Earlier quoted context omitted.

Not sure I am following you: why shouldn't we use cache?

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.