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

The Tech Stack of a One-Man SaaS

panelbear.com

Post reply on HN
Print view View original

91–100 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#91

Post by throwaway894345 »

akiselev wrote: post #80
throwaway894345 wrote: post #36

Earlier quoted context omitted.

> The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles. Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. When we pivoted to a continuous deployme…

There may be a rare exception here or there where network effects or some other unique market need require a startup to treat their infrastructure as cattle, but otherwise it's absolutely true. Running `git init --bare` on a server, setting up some remote origins, slapping some bash scripts into the git hooks folder, some .service files for systemd, and then running `git push origin dbhost && git push origin apihost…

> is a hell of a lot simpler than even getting a toy version of kubernetes up and running.

Getting it off the ground is one thing, keeping things reproducible so you can stand it back up reliably if the instance goes down is another thing. You need to know what are the relevant changes that people have made to the instance over its lifetime in order to reproduce them on the new machine. Maybe this is not what people mean by "pets vs cattle", but they seem pretty closely related if nothing else. I guess the thing I care about is "reproducibility" and for all of its complexity, Kubernetes makes the happy path pretty clear in this regard whereas with EC2 you need Ansible and a whole bunch of playbooks to reproduce things like SSH, logging, monitoring, process management, etc that Kubernetes or ECS or whatever give you out of the box. And if you find that you need to scale beyond one or two instances (not everything is a CRUD webapp, after all) especially autoscaling, then it seems like the EC2 story becomes even more complicated (you now need something to automatically invoke Ansible with the right playbooks for each node). I'm probably biased by my experience (aren't we all?) but it seems like Kubernetes or ECS/Fargate are simpler in these regards.

Re: The Tech Stack of a One-Man SaaS

#92

Post by ecf »

joshmn wrote: post #54

Serial one-man SaaS builder here with a pair of soft-landings and one big hit: I would agree with others who have opined that this is overkill. You couldn't pay me to use Terraform or Kubernetes for my SaaS unless it was a much larger team. My stack usually consists of this: A framework I am comfortable with that removes a lot of boilerplate (happens to be the one I know best in the language I know best), the databas…

Please, please, please listen to this person’s advice about Terraform and the like.

The last startup I was at hired a DevOps engineer to come in to completely containerize our simple Rails monolith at a time where they were just simply way too small to warrant it.

Development velocity plummeted. Deploys started to take half an hour. Features weren’t being released. The professionals our app was servicing lost trust in the engineering team.

All in the name of checking off a box on the CTO’s list of “things that Google does”.

Re: The Tech Stack of a One-Man SaaS

#93

Post by fxtentacle »

tensor wrote: post #66
fxtentacle wrote: post #43

Here's my self-serving advice for every one-man SaaS: Use Heroku. It's super easy to get started. And when you reach $2000+ in monthly bills, hire me to move things over onto dedicated or EC2 so that you'll get 10x that performance for the same price. As for the actual language, I think PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. All those great architectural ideas don't matter mu…

I'd actually suggest PostgreSQL + Hasura + React with Ant Design or Material UI

For many newcomers starting out, the Rails CRUD generators are good enough to generate their entire admin area. And Rails comes with sane security defaults.

I agree that GraphQL + React will be pretty and work well. But for one-man start-ups, the focus is usually on "looks good enough and kinda works".

So I believe I'd go with Bootstrap & Glyphicons, just to get results faster.

Re: The Tech Stack of a One-Man SaaS

#94

Post by 0df8dkdf »

eric_b wrote: post #14

It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should follow the stack in this article. There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feedin…

> There are too many dependencies

Agree. Blindly recommend this to anyone is not a good idea! It comes down to author's skill sets, and if the author is truly interested in tech, or just some guy want to implement an idea. Personally I am full stack and know how to make server scale without using Kubernetes. Since I've being using commonJS since it's inception, it is pretty easy to write web apps that scales using a light weight server layer like v8.

Re: The Tech Stack of a One-Man SaaS

#95

Post by throwaway894345 »

fweespeech wrote: post #84
throwaway894345 wrote: post #36

Earlier quoted context omitted.

> The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles. Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. When we pivoted to a continuous deployme…

> Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. That is an issue a disciplined one-man operation won't have since (generally) they have a Dev and a Prod environment, the changes would be made in Dev first then duplicated in Prod. If you have 2+ developers, you have environment drift like you…

What happens to the disciplined single dev when their EC2 instance falls over in either environment? How do you get things back in sync without code to automatically stand things up in the right state? And if you're going through the work of writing/maintaining that code, are you saving anything over using Kubernetes (consider out of the box, Kubernetes gives you logging, ssh, process management, service discovery, etc)?

Re: The Tech Stack of a One-Man SaaS

#96

Post by dobg24 »

PM for DO Kubernetes here. My views are biased.

This is an insightful article. A learning for me was how the author managed to switch multiple cloud providers even while being a one man SAAS.

Kubernetes is overwhelming because of 2 things: Overload of terminology, and Distributed systems day 2 operations.

Author succeeds so well because he has a starter stack (install, CI pipeline, secure, monitor, scale) maintained as code, and it works every time.

For someone starting new, the learning curve is high. Bootstrapping is easy, but day 2 on kubernetes is hard. Benefits outweigh is learning curve imho.

Specific to DigitalOcean kubernetes API server issues, we have rolled out some resource provisioning improvements for newly created clusters very recently. Also making ongoing improvements to backend monitoring.

Re: The Tech Stack of a One-Man SaaS

#97

Post by amzans »

vladletter wrote: post #81

Thank you for the sharing! About pricing: - Do you have any tool for cloud pricing tuning/estimations ? - Are you using specific tool to track all your expenses in general ?

I have used https://calculator.aws/ in the past, but to be honest it's difficult to account for the egress costs/networking fees using their calculator. Simple things like networking between Availability Zones/Regions can really creep up in your monthly bills if you don't watch out.

I do track my expenses on a sheet manually, using a ballpark figure. At the end of the month I compare it with my AWS bill. If something seems off, I investigate it further. But I don't try to predict exact figures, more like expected ranges.

I do miss the fixed-cost nature of DigitalOcean/Linode. I didn't have to worry about sudden charges, you pay $20/mo per node and that's it. Lots of bandwidth included.

But for the most part it's fine, as long no bot starts bombarding your services with useless requests, egress costs tend to scale with revenue in my case, as my product's pricing is based on usage.

I also have Cloudflare in front of my AWS stack, it has blocked a few small attacks already, but nothing serious yet.

Re: The Tech Stack of a One-Man SaaS

#98

Post by amzans »

underdeserver wrote: post #11
FreekNortier wrote: post #6

But does Python scale for back end applications?

Yes, it does, as long as performance-bottlenecked code is not in Python (and it usually isn't). In the real world, you may have to extract some hot regions to C++ or Rust or Java, but 99% of your code will scale infinitely.

My team migrated a service handling >1.6k req/s at peak time, from Scala (Finatra), to Python (Django). Same number of servers (3x c5.large), just higher CPU utilization (from ~15% to 70%).

Scala was great, but unfortunately it made it difficult to onboard new team members into the project, so development suffered. Also the rest of our stack is mostly Python, so we couldn't use a lot of the common tooling, and libraries we had built for other projects.

We migrated it within a month, and it's been running for almost a year without issues.

At some point the service even recorded 3k+ req/s at ~200ms 99p latency. Yeah, maybe not Google scale, but more than enough for 99% of the businesses out there.

This service handles about 2.5 billion requests per month from one AWS region. We're a small team, and that's only one of the services we support. Which is great because we don't need to spend all of our time optimizing it.

Re: The Tech Stack of a One-Man SaaS

#99

Post by Wirerack »

smu wrote: post #55

Seems like there are a couple of tech stack posts on HN lately and I certainly enjoy reading them. But as a techie, the magic to me no longer lies in the product building, but in the ‘finding the first 10-100’ customers part. Have there been any posts on that lately?

I'd definitely appreciate seeing something like that too. After a couple of "build it first" failures I've come to see the wisdom in finding your customers and validating your idea first.

I've read several of these SaaS walkthroughs and it invariably seems to follow this pattern:

1. Author has a blog with a large following on some topic.

2. Finds niche in that topic.

3. Makes a product and pushes it via their blog.

4. "Incredibly" their product gets tons of customers.

Re: The Tech Stack of a One-Man SaaS

#100

Post by jturpin »

ramraj07 wrote: post #77
jturpin wrote: post #57

Earlier quoted context omitted.

Setting up Kubernetes is a fixed cost in the beginning with clear payoffs. Things like microk8s, Rancher or GKE/EKS make it a lot easier to set up than it used to be. Deploying your app is then just a simple Helm chart, or another way of getting deployments out. If I was running any kind of business that was making more than zero dollars I would absolutely go with Kubernetes. I don't think it's as complicated as peop…

No it's not, assuming your database sits outside k8s there's absolutely nothing that needs to be fit inside k8s, a simple machine running docker if needed is more than sufficient. K8s is such a huge mental overhead that if it's not already naturally in your head because you've had extensive experience (or apparently born geniuses) no one with limited tech budget should ever do this.

All of these tools (Terraform, Kubernetes, Github Actions/Other CI) seem like overkill until a node dies and you need to recreate it, or configuration gets messed up and you don't remember how you deployed it in the first place. It sounds like the OP has had experience with these problems. If these aren't problems you have interest in solving, then Heroku or a similar platform would be the way to go.

Running a business on a single node is not advisable. If your scale is that small, or uptime doesn't matter, then sure go with that. If you're running on multiple nodes, you're going to need a way to schedule containers to your cluster one way or another. Scheduling and orchestrating is where complexity get introduced - Kubernetes wrangles this complexity.

You can run a lot on a $5 server. I would probably run 3 $10 servers for a small business at least, which feels like still within the realm of a cheap budget for business infrastructure costs.

As far as Kubernetes complexity goes, I think this is a self-perpetuating idea on internet tech communities. I don't think it compares to the complexity of actually programming the web apps themselves. There's like 6 resource types you have to be familiar with to work with Kubernetes, and most of that will just be Deployments (where containers actually get scheduled and run, health checks, etc). The others are for configuration and routing.

Post reply on HN