Gitlab Dedicated – our new single-tenant SaaS offering

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).

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.

Sure generated book sales, crowning of thought leaders, and busy work to soak up easy money for anyone paying attention.

GitLab Dedicated is for customers who want GitLab team to manage GitLab for them but not on GitLab.com

(I work there)

Enterprise deals can go anywhere between $50k and $10m+ per year.

No one parts with that amount of money to “self serve” themselves by entering a credit card.

I do remember the first time I have a bit of a meltdown with the stage upgrade procedure. Granted the same thing can be said of any upgrade, you follow steps toward latest and greatest. But it was a bit of a job to get that up to date from the image provided by Vultr.

There's a bigger issue: security updates. With self-host, you have to subscribe to a ton of better-or-less-well-organized mailing lists, and once a 0-day is published you are in the race between your IT team and exploiters (who can and will find your instance on Shodan).

In contrast, SaaS vendors (usually...) get informed about vulnerabilities prior to everyone else, so you don't have to worry about timely updates.

First, depending on where you are taking about, “meager” full time staff for that 5 minute response time would be a few hundred thousand dollars because you’d need multiple people per site to be on-call. Could those people do other things? Maybe! But thinking you can hire people for $35 an hour to be on-call or on-site if the servers go down is really misguided. In some parts of the world, that might be possible, but having multiple full-time staff to hit that “5 minute response time” claim is still going to be more expensive than you let on.

Second, you now get to multiply this figure by however many different regions you are in that have to be physically isolated for GDPR or other compliance reasons. And if you’re doing any government work? Well, that requires special audits (that are not cheap and governments love to spend money, regardless is where they are based) and very specific data residency rules and requirements. Even if you’re not contracting with a government, highly regulated industries have very specific data residency rules that must be followed that your local colo may or may not be able to handle. And if it does, that colo is often a lot more expensive than usual.

> Not batting an eye, or rather, "...so much as blinked", as you said, are bourne of business models with factored in wreckless budget kruft that may at first be acceptable until one merely scratches the surface of cost savings.

This reads to me like something a consultancy firm that hasn’t actually done the long-term math would say.

Look, for businesses of a specific size, I do agree that self-hosting can be a more efficient and economical model. But that size changes based on usage and is often elastic.

A smaller business that doesn’t already have its own on-prem setup already and needs single-tenant stuff for regulatory reasons is probably better off looking at getting a dedicated offering from Gitlab or using a third-party vendor who is setup to handle and manage that stuff for them. The hard costs (capex) are often large upfront and taxes work differently (amortized over time for capex) versus the economics on cloud (opex), which might provide some tax savings that are more beneficial.

A business of a certain size and volume who likely can amortize the costs better over time and has a lot of dedicated staff to do their own specialized and customized work, and who is already very deep in the regulated space? They are going to be better off self-hosting.

But the super huge businesses that have hundreds of thousands of employees and need to follow data residency requirements in dozens of regions? They are probably better off using a mix of both. Dedicated on-prem self-hosting in areas where they have lots of clients and business. Use a single tenancy SaaS for places that have high regulatory needs but that aren’t huge business centers (or that are in regions where it is difficult to setup your own tenancy or where you aren’t incorporated as a business).

There are trade-offs with everything. And this is a product that isn’t for 95% of the businesses out there. But for those that it is for, for a lot of places — especially places that don’t count devops as a core competency or product focus — it’s useful and not blinking an eye at the price doesn’t mean people are burning money. It means that the service is of value for their time and energy and focus.

Disclosure: I work at GitHub, who is obviously one of Gitlab’s competitors. But I find this knee-jerk “just self-host” rhetoric to really miss the nuance of all of this stuff.