Hi everyone, let me do what I normally do and answer the FAQs regarding something I see on HN about us. I'm one of the founders of HashiCorp, creator of many of

Hi everyone, let me do what I normally do and answer the FAQs regarding something I see on HN about us. I'm one of the founders of HashiCorp, creator of many of our tools, and so I have the authority to respond here as well as the bias. In no particular order, the feedback or questions we get asked about commonly about this are below. If you have any additional feel free to ask and I'll try to answer. I'm flying today so I may be in and out. 1. "Scheduling 1M containers isn't realistic" Nobody is going to schedule 1M containers right now in a short period of time. I don't argue that and we don't make that claim anywhere. HashiCorp has always believed that if you build something that scales UP, it always scales DOWN. Now you know Nomad can schedule containers at ~4,000 containers/sec with 5 servers. You may only need a few per second, but when you get a bunch of batch jobs you want to run (data processing, queueing, etc.) and maybe have thousands to submit in a short period, you can now be confident that Nomad is going to be very, very okay. I fly a lot, and I've always been in awe of airplane wings. Did you know a Boeing's wings can bend enough to nearly touch each other at the top before they snap? I fly over 100 times per year (for 6 years now). Have I ever seen wings even get 10% of the distance to that? Nope. But because they CAN, I feel really confident in that plane [under those circumstances]. In addition to that, I think schedulers will only get more loaded over time. We allude to this in our conclusion: think about Lambda, or using schedulers for basic queueing, etc. All of these require a scheduler, and the load that they'll put on a schedule is easily 10x if not 100x more than what we put on schedulers today (in practice). Knowing _today_ that Nomad can handle this load allows us to design for the future. Maybe its never needed, maybe. 2. "But how does Nomad act under failure scenarios?" This challenge actually demonstrated this! In our 1M container launch, we actually launched 1.003M due to failures in hardware, network, as well as finding a bug in the Docker engine itself. Amidst all of this, Nomad self-healed and relaunched failed jobs. As a result, we actually launched 1.003M containers to complete our jobs. 3. "Starting containers isn't impressive, keeping them running is." The goal of this benchmark and this post was to show the speed at which we can binpack with constraints and high pressure and relatively few servers (five). However, it isn't every day we get access to a 5,000 node Nomad lab, so we did and measured a _lot_ more than what we published. We kept the cluster running for some time. Nomad continued to self-heal any failed jobs, and the 5 servers kept up just fine. Nomad client's monitor the health of their own tasks so that is never very expensive, and the clients and servers heartbeat periodically. We didn't publish any of that because its just so boring: Nomad just kept things running, CPU was within bounds, network was quiet, etc. We're planning on a more strenuous benchmark around disaster scenarios currently. We now know Nomad can scale, we're now designing tests to observe how resilient it can be.