Honestly, curious ... if I understand this correctly, you are deploying multiple versions of your application? So if you have 100 clients, you have 100 deployed versions of your application?
Do you have infrastructure in place to deploy all at once? All I can think about is a time back in the dark ages where I had 50 different instances of an application deployed and some clients didn't want to upgrade. Some didn't care. And some did. It was an absolute nightmare trying to keep all of the individual systems in sync?
I get the feeling that's not what you're describing here though? It sounds like a really convenient setup you guys have, but I just can't envision it very clearly.
Anyhow, thank you for sharing a bit of your infrastructure.
> if I understand this correctly, you are deploying multiple versions of your application? So if you have 100 clients, you have 100 deployed versions of your application?
That is correct.
We've written a lot of code against our cloud provider's APIs to spin up a new instance of our application. The application itself is pretty simple: java runtime, java code and a relational database (plus optional elasticsearch).
> It was an absolute nightmare trying to keep all of the individual systems in sync?
We don't try to keep all the applications in sync. We let folks upgrade on their schedule, not ours. We inform them of features and security issues and let them make the assessment on when is best to upgrade. These are devs and this is sensitive user data, so they tend to be receptive to upgrading when needed.
It's absolutely a tradeoff between more granular control and operational simplicity (for us; the end user doesn't really care).
FYI, I gave a conference talk about our infra evolution which led to that podcast interview I linked. I can try to dig up the PDF if that would be of interest (it wasn't recorded).
> So if you have 100 clients, you have 100 deployed versions of your application?
We in essence do that. We have about 300 customers, each with their own deployment.
We have a set of active major versions which our customers can run, and then bug fixes etc in minor versions gets deployed automatically.
When the customer is ready they can bump the preferred major version, and the database etc gets upgraded over the following night/weekend (depending on activity level).
When signing on, the user can select the version to run, defaulting to the highest minor version of the preferred major version (after upgrade is ready of course). They can select one of the 5 latest minor versions per major version.
The update service checks for any new builds once per hour and grabs them, informing the "boss users" of any new major version if available.
This makes bugs and issues have less impact. If we screw up, the user can always just use one of the previous versions until we fix it. And once we fix a bug we just have to make a new build and tell the user to log back out and in again in an hours time.
As for keeping it in sync, our installations are fairly stand-alone as such. However we have to take locally. So we make sure database upgrades are backwards compatible as far as possible, ie old code should run fine on a newer db schema. Automated services follow the default version policy (so get upgraded automatically). And we don't have too many major versions around, about a year, so they have to upgrade at some point. At least if they want to receive support.
For us it's what's allowed us to do customer specific solutions and logic within our general application, which has been one of our strong points compared to many of our competitors.
But yeah, one of the downsides is when, like last week, we discover a bug in a library of ours which we've used for a while. Then there's like a dozen branches to patch and build. And as mentioned, upgrading the db schema might require care and/or preparation to ensure older versions can still run against it.
Do you have infrastructure in place to deploy all at once? All I can think about is a time back in the dark ages where I had 50 different instances of an application deployed and some clients didn't want to upgrade. Some didn't care. And some did. It was an absolute nightmare trying to keep all of the individual systems in sync?
I get the feeling that's not what you're describing here though? It sounds like a really convenient setup you guys have, but I just can't envision it very clearly.
Anyhow, thank you for sharing a bit of your infrastructure.