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

Technology Choices for My SaaS in Retrospect

thomasbandt.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Technology Choices for My SaaS in Retrospect

#61

Post by jaza »

threeseed wrote: post #8
schemescape wrote: post #3

Looks like he’s storing data in the server’s file system, but I see no mention of backups. Hopefully there’s more than one copy of the data somewhere (or it’s not critical data)!

Also the problem everyone makes with backups is that they don't regularly test them. At which point storing the files on S3 would have been far easier, quicker and safer.

Indeed. In my experience, even if you don't use any other cloud service, do yourself a favour, and use S3 + Cloudfront (or equivalent) for static / uploaded files. Then, if and when you need to scale your web tier horizontally, you've solved what probably would have been your main blocker.

Plus, as mentioned, there's your backups sorted. Plus, you'll never have to worry about running out of disk space. Plus, you're taking load off your web tier, for something it really doesn't need to handle itself. Plus, massive performance boost on serving those assets over a CDN. Plus, it's really cheap, most likely a fraction of the cost of your VPS(es) or dedicated box(es).

Re: Technology Choices for My SaaS in Retrospect

#62

Post by soulchild37 »

z9znz wrote: post #21
leetrout wrote: post #9

Earlier quoted context omitted.

Seemed like he was scared to share the idea.

I beleive he said it's a boring B2B SaaS. And it's probably a niche market such that possibly (likely?) nobody reading HN would be involved in and be interested in his product.

I did some digging and think you are right on this, and his product seems to require expertise on tax knowledge.

From his LinkedIn, it seems like the product is https://taxaro.de

Re: Technology Choices for My SaaS in Retrospect

#63

Post by UncleEntity »

Kwpolska wrote: post #40
scarface74 wrote: post #20

Earlier quoted context omitted.

Is it really that much easier than just installing the same version of Postgres and running SQL queries to create the schema/seed the data? You’re not going to be using the same data in production and dev.

How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the De…

Couldn’t you just install the server OS in a VM on the dev machine and solve all the problems?

Re: Technology Choices for My SaaS in Retrospect

#64

Post by davidatbu »

UncleEntity wrote: post #63
Kwpolska wrote: post #40

Earlier quoted context omitted.

How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the De…

Couldn’t you just install the server OS in a VM on the dev machine and solve all the problems?

That sounds like a more heavyweight[0], and much more cumbersome[1] version of using Docker.

[0] Much more CPU and RAM needed.

[1] You rarely work with a fresh OS install; you'll have to install things, edit files in /etc/ or whatever, set firewall rules perhaps. For me at least, many of this comes with googling, say, "how do I allow an incoming TCP connection for a port range?". Ie, tiny details I don't want to memorize. I'll have to replicate these steps between the dev VM and the prod environment. If I use Docker, I can write these things into the Dockerfile and then just do "docker-compose up" in production, and it will just work. Also, I can commit that Dockerfile into a repo. It makes it much easier for others, or future-me, to understand what the dev-ops setup is like.

Re: Technology Choices for My SaaS in Retrospect

#65

Post by leetrout »

soulchild37 wrote: post #62
z9znz wrote: post #21

Earlier quoted context omitted.

I beleive he said it's a boring B2B SaaS. And it's probably a niche market such that possibly (likely?) nobody reading HN would be involved in and be interested in his product.

I did some digging and think you are right on this, and his product seems to require expertise on tax knowledge. From his LinkedIn, it seems like the product is https://taxaro.de

Fascinating. I built a very similar product in 2008. It was focused on CPAs and mortgage brokers specifically.

No special knowledge is needed based on the translated site. It is providing chat with encrypted file transfer (and storage?).

Re: Technology Choices for My SaaS in Retrospect

#66

Post by lazide »

once_inc wrote: post #13
threeseed wrote: post #8

Earlier quoted context omitted.

Also the problem everyone makes with backups is that they don't regularly test them. At which point storing the files on S3 would have been far easier, quicker and safer.

"Nobody wants to backup, everybody wants to restore." This very much. For backups, the great crunchtime isn't when you set up the backups and see them appear where you want them. Crunchtime is when your system is in turmoil, and you need to recover what you've lost. I've seen so many people claim their backups are in perfect order, only to lose data because something broke between setup and recovery.

Also, time to restore for many peoples solutions can be days or weeks (if something goes wrong). Oops if that means you’re down for weeks. For some businesses (SaaS), there is no point event trying to come back from that.

Re: Technology Choices for My SaaS in Retrospect

#67

Post by lbriner »

michalbugno wrote: post #49

Other than already mentioned backups I see no mention of: * staging environment for development * at least another baremetal machine for a copy of production and a loadbalancer in front of them, to prevent from 100% downtime in case your machine is down

The article wasn't about infrastructure or resilience, it was about technology stacks.

Maybe those other things were there, maybe they weren't but it wasn't about what you should do, just what he did.

Re: Technology Choices for My SaaS in Retrospect

#68

Post by lbriner »

A useful read for sure.

However, I wonder about the choice of React (or any SPA framework) if you say you are not designing for scalability. You said that the product is quite basic/boring and I have yet to see how this wouldn't be much easier to produce in any MVC server-side framework than any frontend framework.

If you are used to .Net, you could choose dotnet core MVC (was that around then?), which is super fast and easy to deploy on Docker but also Ruby, PHP etc to suit your taste/experience. The SPA approach means a frontend and a backend developed separately and unless you have FB scale issues and want to move as much work to the browser as possible, the only time I would choose SPA would be if I was most familiar with React/Angular/Vue/Javascript.

Re: Technology Choices for My SaaS in Retrospect

#69

Post by chrisweekly »

lbriner wrote: post #68

A useful read for sure. However, I wonder about the choice of React (or any SPA framework) if you say you are not designing for scalability. You said that the product is quite basic/boring and I have yet to see how this wouldn't be much easier to produce in any MVC server-side framework than any frontend framework. If you are used to .Net, you could choose dotnet core MVC (was that around then?), which is super fast…

Agreed that "SPA by default" is often a mistake. But (slight tangent / refinement), React != SPA.

Next.js and Remix.run (even more so, in that you can deploy a Remix app with literally zero runtime JS) are examples of React frameworks that leverage a server runtime, to great effect. I've been building and improving websites / apps since 1998 and view Remix as a breath of fresh air, built from first principles.

Re: Technology Choices for My SaaS in Retrospect

#70

Post by davnn »

scarface74 wrote: post #16
davnn wrote: post #5

Old-school monolith architecture with not-so-boring technology. I went the same path for a project, but in hindsight I would chose popular, well maintained, not necessarily boring, technology and a cloud architecture for most use cases I can think of.

Disclaimer: I work for AWS in Professional Services. I specialize in “application modernization”. Basically that means a focus on serverless technology. That being said, if someone who doesn’t know “cloud” and has a deadline just to get something done like the author asked for advice, even I would suggest they just throw a monolith on a VM. If they really wanted the optionality to go all in on AWS later, I would sugg…

I think the use cases where you do not need to „know cloud“ are quite limited. Where does knowing the cloud start? When you use a transactional email provider? When you start using an auth. provider? When you integrate an external monitoring framework? When you use a cloud-based object or key-value storage? In my opinion, cloud integration is almost inevitable, but you might realize that a bit later when starting with a monolith.
Post reply on HN