6 ms·

Exactly this. For most startups Heroku, Dokku, or plain docker is enough. The stack will certainly evolve as growth (and success) comes. Building with 12-facto

Exactly this. For most startups Heroku, Dokku, or plain docker is enough. The stack will certainly evolve as growth (and success) comes. Building with 12-factor principles make that transition effortless when the time comes.

thu2111 7y ago
What about raw systemd? It can do resource control, service monitoring and restart and seems pretty lightweight compared to Docker. Fewer ways to footgun with data being erased, no separate shells or finding a tool you need isn't available inside the container.
- hedora 7y ago
  Or, you could use a distro with a sane init system, which eliminates all the systemd and reinvented wheel footguns. The last time I installed ubuntu 18.04, DNS queries took ~5 seconds. It’s a well known issue, with no diagnosed root cause. The solutions involved uninstalling the local dns stack, starting with systemd’s resolver. 2018 was well after DNS was reliable. How can stuff like that break in a long term support release?
  - montjoy 7y ago
    5 seconds is the amount of time Linux takes to fail over to the next dns resolver in resolv.conf. You likely had a bad/unreachable DNS server.
    - Spivak 7y ago
      Which is ironic because systemd got a lot of hate for doing the right thing and not just querying DNS servers in order but discovering the remembering the servers that are up/fastest. Turns out a lot of people just ignored the fact that all configured DNS servers are assumed to serve the same records and used DNS ordering to implement shitty split-horizon DNS.
- wdroz 7y ago
  you can use systemd to manage your dockers
  - arpa 7y ago
    Because systemd is an operating system by itslef nowadays.
p_l 7y ago
From experience: Plain docker - hell on earth. Literally some of the worst stuff I had to deal with. A noticeable worsening vs. running the contents of the container unpacked in /opt/myapp. Heroku, Dokku - Very depends. A dance between "Simple and works" and "Simple and Works but my Startup is bankrupt". K8s - Do I have more than 1-2 custom deployed applications? Predictable cost model, simple enough to manage (granted I might be an aberration), easy to combine infrastructural parts with the money-making parts. Strong contender vs Heroku-like, especially on classic startup budget
- alexbanks 7y ago
  I have desperately avoided K8s since it became popular, but this seems to be pretty opposite of everything else I've read? Can you share what specifically makes plain docker so terrible?
  - p_l 7y ago
    Plain docker (no swarm etc.) for practical purposes resulted in containers that were in weird position when it comes to decoupling from the host OS. Integration with init system was abysmal. Docker daemon had its own conventions it wanted to follow. Unless you ensure that the state of the docker daemon is deleted on reboot, you could have weird conditions when it tried to handle starting the containers by itself. A very easy thing to use for developer, a pretty shitty tool (assuming no external wrappers) on server. One of the greatest joys of k8s for me was always "it abstracts docker away so I don't have to deal with it, and it drops pretty much all broken features of docker"
    - mdaniel 7y ago
      > One of the greatest joys of k8s for me was always "it abstracts docker away so I don't have to deal with it, and it drops pretty much all broken features of docker" It also offers portability away from docker via the Container Runtime Interface; we use containerd and it has been absolutely rock solid, without the weird "what happens to my containers if I have to restart a wedged dockerd?" situation
joana035 7y ago
Two virtual machines are more than enough to a startup for the first 2 to 4 years.
- justinclift 7y ago
  One for Website + database, the other for monitoring? I guess backups could just be snapshots or something, depending on how active the database is. ;)
  - jordic 7y ago
    Haha, some scripts to manage the deployments and rollbacks, plus some other scripts to manage the environment (ansible, terraform.. ).. also some scripts to manage the machines.. log aggregations, cleanup, upgrades... Later add some crons.. some more scripts to manage Dev environments.. and a bit more for having an staging env... That's without using any big cloud provider (add to it firewalls, vpcs, iam.. ) You know, managing some yml files that describes all of this it's so hard and so expensive...
  - peterburkimsher 7y ago
    One for dev, one for production. Database snapshots and code can be backed up locally.
- vorpalhex 7y ago
  While your average startup doesn't need to go "uberscale", they probably need to be highly available.
  - bpicolo 7y ago
    Two VMs in two separate availability zones is pretty ridiculously available. Certainly more so than other least-common-denominators in your stack. There are a ton of successful startups who made it a long way with less than 2 VMs.
    - Spivak 7y ago

thu2111 7y ago

What about raw systemd? It can do resource control, service monitoring and restart and seems pretty lightweight compared to Docker. Fewer ways to footgun with data being erased, no separate shells or finding a tool you need isn't available inside the container.

hedora 7y ago
Or, you could use a distro with a sane init system, which eliminates all the systemd and reinvented wheel footguns. The last time I installed ubuntu 18.04, DNS queries took ~5 seconds. It’s a well known issue, with no diagnosed root cause. The solutions involved uninstalling the local dns stack, starting with systemd’s resolver. 2018 was well after DNS was reliable. How can stuff like that break in a long term support release?
- montjoy 7y ago
  5 seconds is the amount of time Linux takes to fail over to the next dns resolver in resolv.conf. You likely had a bad/unreachable DNS server.
  - Spivak 7y ago
    Which is ironic because systemd got a lot of hate for doing the right thing and not just querying DNS servers in order but discovering the remembering the servers that are up/fastest. Turns out a lot of people just ignored the fact that all configured DNS servers are assumed to serve the same records and used DNS ordering to implement shitty split-horizon DNS.
wdroz 7y ago
you can use systemd to manage your dockers
- arpa 7y ago
  Because systemd is an operating system by itslef nowadays.

p_l 7y ago

From experience: Plain docker - hell on earth. Literally some of the worst stuff I had to deal with. A noticeable worsening vs. running the contents of the container unpacked in /opt/myapp. Heroku, Dokku - Very depends. A dance between "Simple and works" and "Simple and Works but my Startup is bankrupt". K8s - Do I have more than 1-2 custom deployed applications? Predictable cost model, simple enough to manage (granted I might be an aberration), easy to combine infrastructural parts with the money-making parts. Strong contender vs Heroku-like, especially on classic startup budget

alexbanks 7y ago
I have desperately avoided K8s since it became popular, but this seems to be pretty opposite of everything else I've read? Can you share what specifically makes plain docker so terrible?
- p_l 7y ago
  Plain docker (no swarm etc.) for practical purposes resulted in containers that were in weird position when it comes to decoupling from the host OS. Integration with init system was abysmal. Docker daemon had its own conventions it wanted to follow. Unless you ensure that the state of the docker daemon is deleted on reboot, you could have weird conditions when it tried to handle starting the containers by itself. A very easy thing to use for developer, a pretty shitty tool (assuming no external wrappers) on server. One of the greatest joys of k8s for me was always "it abstracts docker away so I don't have to deal with it, and it drops pretty much all broken features of docker"
  - mdaniel 7y ago
    > One of the greatest joys of k8s for me was always "it abstracts docker away so I don't have to deal with it, and it drops pretty much all broken features of docker" It also offers portability away from docker via the Container Runtime Interface; we use containerd and it has been absolutely rock solid, without the weird "what happens to my containers if I have to restart a wedged dockerd?" situation

joana035 7y ago

Two virtual machines are more than enough to a startup for the first 2 to 4 years.

justinclift 7y ago
One for Website + database, the other for monitoring? I guess backups could just be snapshots or something, depending on how active the database is. ;)
- jordic 7y ago
  Haha, some scripts to manage the deployments and rollbacks, plus some other scripts to manage the environment (ansible, terraform.. ).. also some scripts to manage the machines.. log aggregations, cleanup, upgrades... Later add some crons.. some more scripts to manage Dev environments.. and a bit more for having an staging env... That's without using any big cloud provider (add to it firewalls, vpcs, iam.. ) You know, managing some yml files that describes all of this it's so hard and so expensive...
- peterburkimsher 7y ago
  One for dev, one for production. Database snapshots and code can be backed up locally.
vorpalhex 7y ago
While your average startup doesn't need to go "uberscale", they probably need to be highly available.
- bpicolo 7y ago
  Two VMs in two separate availability zones is pretty ridiculously available. Certainly more so than other least-common-denominators in your stack. There are a ton of successful startups who made it a long way with less than 2 VMs.
  - Spivak 7y ago