Our app is small, we don't care about running multiple instances...

... or do we?

You have a small, simple web app. For your small, simple company. Doing small, simple work.

So obviously, you don’t need the ability to run multiple copies of your service at the same time.

Right?

Well… maybe.

But I’ve put together a list of some often-overlooked reasons that the ability to run multiple instances can be useful, even for small, simple apps. Do any of them apply to you?

  • Zero-downtime deployments

    Back in the old days, we’d just bring the service down, perhaps with a “check back in 5 minutes” (or an hour) message to any visitors. And we’d do that at 2am. And if you’re StackOverflow, for some reason, you still do that… 🤔

    But zero-downtime deployments are great. And they’re effectively a requirement (at least in most businesses) if you want to do continuous deployment. But Zero-downtime deployment (typically) means that you need to bring up a new instance of your app before bringing down the old one. Which means that for a brief moment, perhaps only minutes or even seconds, you are running two instances of the app.

    Can your app handle that?

  • High(er) availability

    Most often when I hear people say they don’t need multiple instances of their app, they’re thinking in terms of load. “We have 5 visitors per minute. My grandfather’s 386 could handle that with one hand tied behind its back…”

    Okay… but what if your objectivley over-provisioned server goes down for some reason? What if you have a hardware failure? Or a power outage? Or someone accidentally runs sudo shutdown -r now on the server, thinking they’re running it on their laptop, not realizing they still have an open SSH session… (I would never make such a mistake. That’s my story, and I’m sticking to it!)

    The point is, high load isn’t the only reason to run multiple instances. You may just want higher availability than a single instance can provide.

  • “Canary” deployments

    Maybe you’re not concerned about downtime during upgrades, or high availability. Cool.

    Would you ever like the ability to try out a new feature, or do some testing, on the live data? Maybe you want to expose some new functionality only to specific users, or maybe just to internal stakeholders, but it needs to be against live data.

    Of course there are feature flagging libraries and tools that can allow you to do this on a single instance, but if you don’t already have that set up, the easiest way can often be just to spin up a new instance of your service, running your experimental or new feature.

    But can your service handle that?

Share this