Everyone assumes cloud == multi-tenant, but single-tenant cloud has a lot of benefits and is becoming more common: GitLab Dedicated is single-tenant, GitHub is prioritizing and rebuilding "GitHub AE" (their single-tenant cloud offering), and Sourcegraph (of which I am a cofounder) Cloud is single-tenant[1].
For self-hosted products, offering a single-tenant cloud product is much easier than multi-tenant because single-tenant cloud "just" requires automating and managing infrastructure, not completely changing the core application to support multi-tenancy. This also means nobody should be worried about self-hosted being deprecated in favor of a single-tenant cloud product; companies generally find it easy to keep both.
Single-tenant cloud is also a lot more appealing to large customers because the security is (arguably) fundamentally better and scalability is easier to prove (you can just point to scalability on a self-hosted instance, which has the same scaling characteristics).
Expect to see more single-tenant cloud offerings come out for dev tools, especially those that have a big self-hosted offering (like GitLab, GitHub, and Sourcegraph).
So a code monolith I can just dump on a Linux box is in again?
Our figurative ideas, ephemera, seem to be in a loop of taking a simple mental model, branching it into a mess, feeling over extended, circling back to a simpler mental model, branching it into an over extended mess.
Monotheism versus polytheism, and dozens of flavors of a religion rooted in a central umbrella idea.
Nation states allow creating over leveraged branches of economic Ponzi schemes.
And we’re all certain this is net new and never before seen of humans because the labels are all different!
Just nitpicking, but code monolith does say nothing about the way it's deployed. Could be a massively distributed system, fwiw (we did that and were quite happy with it).
Extensive dependency chain of brittle logic that needs tons of planning and preparation to update and manage is not unreasonable description for microservices architecture from an ops perspective.
Sure generated book sales, crowning of thought leaders, and busy work to soak up easy money for anyone paying attention.
> Extensive dependency chain of brittle logic that needs tons of planning and preparation to update and manage is not unreasonable description for microservices architecture from an ops perspective.
I've seen monoliths that fit that description.
Once you've automated the deployment and configuration of load balancers, firewalls, caches, proxies, and have a DB with automatic failover, that is also sharded for performance, spreading the code out across a few machines is not the hard part.
Maybe it’s a bit literal but I see lots of people at computers planning updating just like I did 20 years ago.
From the IT workers context a lot has changed but the end user outputs are still; video game, chat app, email app, todo app, fintech app, dating app, state management DSL.
AI isn’t going to change the outputs so much as minimize the people and code needed to generate them. Because we’ve mined the value prop of desktops and phones to death.
Materials science, additive manufacturing, biology, are outputting actual net new knowledge. Consumer facing IT is whittling a log into a chair leg, grabbing a new log, whittling a chair leg… but faster!
> From the IT workers context a lot has changed but the end user outputs are still; video game, chat app, email app, todo app, fintech app, dating app, state management DSL.
All of those are working at scales 10x-100x what they were 20 years ago.
Back in 2002 people had to worry about how many emails they had on their machine. Searching unlimited emails? Not happening.
Now with SSDs, better search indexes, more memory, more CPU, handling instantly searching gigabytes of emails on my laptop is not even considered to be a "problem", it just is.
I can drop a hundred 10 megabyte GIFs into a Discord thread and my phone will render everything just fine. Go back to 2008 and, well, there isn't any equivalent because no one was crazy enough to build a platform where you could even try doing that.
OKCupid's backend was written in C++ and was probably the pinnacle of what dating site backend design will ever be, so actually you have a point there. :-D
A good todo apps can geofence[1] your position, remind you to get milk when you are at the supermarket! The amount of tech making that possible is insane. IMHO todo apps have a long way to go, it is sad that Android is going backwards in this regard.
> Consumer facing IT is whittling a log into a chair leg, grabbing a new log, whittling a chair leg… but faster!
That is the entire history of computing.
Our faster whittling has allowed other fields to improve themselves many times over.
Yes! We're doing this at my job for our single tenant cloud offering for a data processing and analytics product.
Monorepo, single Go binary, dump on an instance via cloud init, run it as auto scaling group with count of 1. Only dependency is S3 and database service like RDS.
Super simple for us to build, maintain and operate. Still get a reasonable economy of scale in right sizing the instance / db for the customer workload.
Easy to have a customer set the same thing up themselves for self-managed / any IaaS or on prem version.
More portable than any pre-containerized contraption, because all our enterprise clients all know how to manage instances, and only a few have container expertise, and its trivial to wrap it your container of choosing anyway.
> Our figurative ideas, ephemera, seem to be in a loop of taking a simple mental model, branching it into a mess, feeling over extended, circling back to a simpler mental model, branching it into an over extended mess.
It's pretty standard, the pendulum swings to one side and then eventually swings back to the other. If you stay flexible you can just ride it back and forth throughout your career.
> So a code monolith I can just dump on a Linux box is in again?
Aren't you grossly extrapolating a tad? Nothing suggests there's a "code monolith" involved in the story. Just because the topic is single-tenant instances. Also, single-box deployments are completely orthogonal to "code monolith". Finally, just because a company offers a product that does not mean there's a major architectural shift in the industry.
You can still put it on a Linux box this is more like you enter in a support contract with GitLab and they setup the SaaS for you and the cloud infrastructure instead of being intermingled with their other multi tenant systems.
What this is trying to solve for is companies that can’t buy their other offerings which they said are enterprise companies and or heavily regulated .
Pretty much everything on the cloud is inherently multi-tenant at some layer of abstraction, but because the underlying infrastructure is multi-tenant doesn't mean the application layer needs to be (or that the fact that it's hosted on multi-tenanted infrastructure needs to be relevant at all to it).
It’s still an accurate term under that definition. Single-tenant cloud is technically multi-tenant with respect to the underlying cloud provider (AWS/GCP/etc.), but not with respect to the software service provider (GitLab in this case).
But I believe language and communication are emergent, decentralized phenomena. Single-tenant cloud is a good and useful term.
GitHub has deprioritized AE due to azure capacity and data consistency issues. Maybe AE lives on in some different format, but the Azure-based platform has taken a backseat to other enterprise features for GitHub
I wouldn’t be surprised if they pivoted back, but they lost a lot of talent on that team
I agree. At FusionAuth (my employer) we have a single tenant SaaS solution . I think this has legs and serves a real need.
Interesting to note that you mentioning mostly devtime solutions (version control, source navigation).
I think the proposition is even more compelling for components of your application that are used at runtime (like auth servers, databases or message queues).
Wins for the company offering the self-hosted solution:
* Easier to build the SaaS offering as you mention.
* Can leverage same code for SaaS and self-hosted versions.
* Unique value proposition: "run it yourself or let us run it, or migrate between these as needed" has been a compelling message for some of our clients
Wins from the developer perspective:
* Easier to version the tool like a library. No more surprise upgrades. Especially when you using a component that other pieces of code depend on, devs want control over the upgrade process.
* No noisy neighbor problem (at least, no more than you'd have using a VM in a public cloud).
* Still a SaaS, so you get ease of delivery/usage/maintenance.
The major cons:
* it costs more.
* deployment time can take longer (you're not just adding a row in a database and configuring a hostname).
* making sure folks know when/how to upgrade (it's still a learning experience for many devs to have a single tenant SaaS solution).
I had an interesting discussion with the Cloudility folks about the three models for multi-tenancy:
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.
How does one handle cross-customer data work in a single-tenant SaaS arch? Do you pipe a lot of "exhaust" data from those envs into a shared env for analysis, ML model development, etc.?
For products like GitLab and Sourcegraph that started self-hosted, there is not really any cross-customer data or cross-customer functionality. This is what customers expect. They want their data to be isolated and not shared.
For other products needing cross-customer features, I think you'd need to define clear APIs and pipelines for exporting some form of the data that the customer can inspect to be certain it is not violating their security/privacy expectations. I'd love to hear from people who have built such a system!
Single tenant app is also better from data security point of view: there's no way to make a mistake that allows to access someone else's data, if it resides in a different database/object storage. On the other hand, single tenant app is more expensive to scale: memory footprint and caching layer are not shared between clients.
For self-hosted products, offering a single-tenant cloud product is much easier than multi-tenant because single-tenant cloud "just" requires automating and managing infrastructure, not completely changing the core application to support multi-tenancy. This also means nobody should be worried about self-hosted being deprecated in favor of a single-tenant cloud product; companies generally find it easy to keep both.
Single-tenant cloud is also a lot more appealing to large customers because the security is (arguably) fundamentally better and scalability is easier to prove (you can just point to scalability on a self-hosted instance, which has the same scaling characteristics).
Expect to see more single-tenant cloud offerings come out for dev tools, especially those that have a big self-hosted offering (like GitLab, GitHub, and Sourcegraph).
[1] https://about.sourcegraph.com/blog/enterprise-cloud