Comment by davismwfl | Hacker News Reader

Comment by davismwfl | Hacker News Reader

If you don't have a reason to use it, and if it isn't solving an existing problem for you, then don't use it.

This idea you should use docker or other container solutions when there is no compelling and logical problem they are solving is just a time suck. As a solo founder your time is super critical to manage closely, optimizing things that are not high paybacks is a bad idea.

Docker can be great, just IMO and especially for a solo founder you need a compelling reason(s) to add any complexity and/or extra time to your system. Especially if your solution is a simple project that you deploy on a single VM (or maybe multiple for reliability) there is no reason to use docker.

I've been a solo founder more then once, guard your time carefully. With some exceptions, only build things that have an immediate payback, use only enough tools to get it done and don't add any complexity or dependencies that can cost you extra time to debug, understand or learn. As you add people you can do more and be a little more aggressive on things that don't have immediate need/payback.

Amazing comment. Thank you. In these age of hype and complexity I really miss common sense.

I agree 100% in your approach. Specially when we have access to VM with 48 dedicated cores and almost 200GB of RAM for less than €500/month.

If you go beyond that, you have really into something.

also, is allows you to focus on the problems you are having right now (building a product that runs on a server) instead of theoretical problems you might never reach later. (Scalability and portability).

VM's are quite scalable, especially if you can scale vertically, and they massively reduce complexity.

Let’s say you have a run of the mill nodejs express app that connects to Postgres (let’s assume it’s managed in this scenario).

How do you make use of all the 48 cores and the RAM available to you? (I’m genuinely interested so please ignore any snarky tone if any)

You'd either run multiple instances of your app with an http load balancer in front, or make use of nodejs clustering: https://nodejs.org/api/cluster.html

I will start by saying that I'm super average and still learning, but it is my understanding that you use RAM to keep things on memory (faster access), and cores for parallelization (different instances reads).

In my case, I use Ruby on Rails, so I configure Puma based on the number of cores that I have to set the workers (threats). Not yet, but I will use Redis for caching. It is also an "in-memory" database.

Using more resources than average also comes into play when using less performance (but rapid to develop with) technologies.

Best practices are a funny thing, understanding where they come from and who they were intended for an go a long way in having a better context.

There's two parts to this.

The first is the broad question of "how will any app (regardless of the technology) saturate that much hardware", and to that I simply say it won't; it will saturate -something- first (with enough load), be it RAM, CPU, network I/O, disk I/O, etc, which will limit utilization of the rest. If this was your own datacenter you might try and "right size" to that, to try and have as little unused hardware capacity as possible, but in the cloud you don't (can't) do that.

The second is maybe more what you're trying to ask, which is given that node is single threaded, you would only be using one core, and that would implicitly also limit how much of the other resources you can use. To that, you'd use something like PM2, a node native utility which essentially spins up multiple instances of your app locally, and load balances across them, or the cluster lib, a less feature rich solution to the same problem, but supplied as part of the standard library.

I don’t know about nodejs, but serving a twitter-like feed with an in-memory database of everyone’s tweets is one use-case. It’s a database query workload and would benefit from caching raw data or views of the twitter feed and has a latency requirement of 100 milliseconds or so.

> How do you make use of all the 48 cores and the RAM available to you?

The point I take from gp’s comment is, there’s a lot of room to scale within a single instance when the nano-sized VM you started with is overwhelmed. Focus on the things that cause growth first, then add complexities of distributed computing when it is actually needed.

Most likely answer: the application is small and there's no need, and no useful way, to extract value many cores or a lot of memory. So don't waste effort on something that isn't needed.

Boring answer: use a pool of threads (or subprocesses, like Apache) to deal with web requests. Without stupid locking, many concurrent requests can be handled for each core. If you don't know your QoS targets, how many threads you need to meet them, and how much memory each thread requires it's a serious red flag.

Pragmatic answer: do you want to invest in fault tolerance and being able to upgrade your application? Then you need a load balancer to route traffic to multiple instances and switch them on and off properly, and a good load balancer is going to be outside your VM and probably a specific piece of hardware, irrespective of clever techniques in your application.

If you know you're going to want this type of parallelism and simple deployments, use languages that have better threading stories.

That said, one place I worked had a legacy Python service on 16+ core machines. We happened to deploy with dpkg, apt, and docker (I wouldn't necessarily recommend this), and the start script spun up cpu count - 1 instances with CPU affinity set. There was something like nginx for routing out in front.

depending on your node.js version. nodejs has a cluster mode. before that tools like pm2 had cluster | loadbalancing modes. But yeah you can easily run as many instances of the node.js app on your 60 virtual cores. Let node use half of those. Then the rest for db, monitoring. Then have a load balance ie nginx.

--Edit also node.js now has Workers e.g for instances where you need to do CPU bound work. Remember node.js is really fast. most apps out there won't be able to use it to the max.

StackOverflow ran on significantly less for many years, they only had x2 for failover.

Also, at that time, look into how resources are being utilised and try optimising for your needs.

You can do better than that. For €500 per month you can get a DX181 [0] from Hetzner with 768GB of RAM, an entire dedicated 32-core CPU (worth 64 VM "cores"?), a 960GB NVMe SSD and unlimited bandwidth.

[0]: https://www.hetzner.com/dedicated-rootserver/matrix-dell-mob...

This is crazy value for the money. Hard to imagine the limit where you need to leave this behind. My only concern is that with physical servers you don't have snapshots that save your ass quickly in case of some process gone wrong.

I never understood the VM backup as a strategy. Think about backup from a database or application layer/perspective

The main benefit I see is quickly rollback to previous state. Really handy when something goes wrong for example updating the system.

Sure, but having a stateful VM is where the self-inflicted pain started imo. Though reading all parent posts, my point is not well placed.

Disaster Recovery

Install VMM like Proxmox or use LVM/ZFS/btrfs?

There are lots of snapshot and backup solutions for physical servers.

You could run your own vm solution like proxmox as well on the bare metal, takes 10 minutes to install locally.

I'd just go serverless if I start something solo

Reply on news.ycombinator.com