6 ms·

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 containe

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.

juanse 5y ago
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.
- kazen44 5y ago
  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.
- omneity 5y ago
  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)
  - louis-lau 5y ago
    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 https://nodejs.org/api/cluster.html
  - deleted 5y ago
    [deleted]
  - juanse 5y ago
    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.
    - j45 5y ago
      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.
  - lostcolony 5y ago
    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.
- zamalek 5y ago
  StackOverflow ran on significantly less for many years, they only had x2 for failover.
- adreamingsoul 5y ago
  Also, at that time, look into how resources are being utilised and try optimising for your needs.
- Youden 5y ago
  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-mobile https://www.hetzner.com/dedicated-rootserver/matrix-dell-mob...
  - juanse 5y ago
    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.
    - hbogert 5y ago
      I never understood the VM backup as a strategy. Think about backup from a database or application layer/perspective
      - juanse 5y ago
        The main benefit I see is quickly rollback to previous state. Really handy when something goes wrong for example updating the system.
        hbogert 5y ago
        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.
      - mycall 5y ago
        Disaster Recovery
    - fomine3 5y ago
      Install VMM like Proxmox or use LVM/ZFS/btrfs?
    - 5y ago
zerubeus 5y ago
I'd just go serverless if I start something solo

juanse 5y ago

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.

kazen44 5y ago
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.
omneity 5y ago
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)
- louis-lau 5y ago
  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 https://nodejs.org/api/cluster.html
- deleted 5y ago
  [deleted]
- juanse 5y ago
  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.
  - j45 5y ago
    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.
- lostcolony 5y ago
  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.
zamalek 5y ago
StackOverflow ran on significantly less for many years, they only had x2 for failover.
adreamingsoul 5y ago
Also, at that time, look into how resources are being utilised and try optimising for your needs.
Youden 5y ago
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-mobile https://www.hetzner.com/dedicated-rootserver/matrix-dell-mob...
- juanse 5y ago
  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.
  - hbogert 5y ago
    I never understood the VM backup as a strategy. Think about backup from a database or application layer/perspective
    - juanse 5y ago
      The main benefit I see is quickly rollback to previous state. Really handy when something goes wrong for example updating the system.
      - hbogert 5y ago
        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.
    - mycall 5y ago
      Disaster Recovery
  - fomine3 5y ago
    Install VMM like Proxmox or use LVM/ZFS/btrfs?
  - 5y ago

zerubeus 5y ago

I'd just go serverless if I start something solo