gomox

49 ms·

241.
by gomox 6y ago
Both of the setups I'm familiar with run multiple application servers on the same "iron" (EC2 clusters), with shared services (database servers, caches, routing, load balancing, etc). Monitoring, backup, ELK, New Relic etc ar
242.
by gomox 6y ago
Flexible and disciplined is a good alternative to rigid, and for young software business, probably the safer one!
243.
by gomox 6y ago
I don't think we share the definition of "scale". Extremely few companies that sell B2B SaaS software for enterprises have 10K customers, let alone 100K (that's the kind of customer base that pays for a Sauron-looking to
244.
by gomox 6y ago
You can probably run the environment itself, but other systems (release management, monitoring, billing, etc) probably rely on the account_id being unique.
245.
by gomox 6y ago
As you can see now that the thread has matured, there are a lot of proponents of this architecture that have production experience with it, so it's likely not as dumb as you assume.
246.
by gomox 6y ago
Multi-single-tenant actually makes it easier to do transactional schema upgrades because these operations only impact one customer at a time. No fiddling with middle-of-the-migration state.
247.
by gomox 6y ago
Everything has a solution, but want to bet that at least 20 different internal systems at HubSpot assume that the account ID in that URL is globally unique?
248.
by gomox 6y ago
High interactivity between accounts is a good reason to not adopt the proposed multi-single-tenant architecture. The scenarios discussed are B2B enterprisey apps in which the environments are essentially independent from each other.
249.
by gomox 6y ago
See my sibling comment with the Hubspot example. Even though the system might work internally, other things will break if you start having duplicate account IDs because other systems don't think of the account ID as a cluster-local ide
250.
by gomox 6y ago
No. For example, HubSpot runs a multitenant system. URLs look like: https://app.hubspot.com/section/$ACCOUNT_ID/etc/etc In the simple, YAGNI implementation of this, when you create a new HubSpot account, most
251.
by gomox 6y ago
You can, but a transactional database migration is much nicer, predictable and less prone to bugs.
252.
by gomox 6y ago
If you have 500 medium customers and you need to add sharding to a multitenant production behemoth, it's not trivial.
253.
by gomox 6y ago
True, but: In my experience by the time you reach this point you have a lot of operational complexity because you and your team are used to your production cluster being a single behemoth, so chances are it's not easy to stand up a new
254.
by gomox 6y ago
If it works, then it works :) Company B I mentioned above still runs location specific infrastructure, but each one of these clusters can host several customers. Of course there is some overhead (i.e. very new regions sometimes operate at a
255.
by gomox 6y ago
Indeed, but if you are making a B2B enterprise/SMB SaaS, I think you are most likely to regret the opposite choice [1][2]. A lot of companies run a single instance, multitenant application and have to develop custom sharding functional
256.
by gomox 6y ago
How does the architecture block major refactors or improvements? Are you running a single codebase for all your tenants, albeit with separate schemas for each? Edit: on reading the link you included, it seems like a lot of the problems are
257.
by gomox 6y ago
I don't know your application enough to comment, but that seems like an extreme version of what I'm proposing, which would be to share application and DB servers between customers, but not application code and databases (i.e. you
258.
by gomox 6y ago
Many versions of the schema: indeed, that's one of the main tradeoffs. I consider this to be a feature, not a bug, in an enterprise application context. The correct version of the schema that corresponds to a given version of the code
259.
by gomox 6y ago
Most enterprise systems either don't require or deliberately forbid mixing different customers' data in aggregate queries. So it's a bad use case to optimize for.
260.
by gomox 6y ago
Enterprise systems have little to no cross-customer functionality, and customer isolation is paramount. I think you are assuming that they will have a database per individual user, but the original question pointed to "tenants" (i
261.
by gomox 6y ago
My hunch is that they did this because that was a reasonable way to operate in the old shared hosting days (where you got a single application and a single database server). A lot of people would also run multiple "blogs" from one
262.
by gomox 6y ago
You don't need an RDS per customer. In MySQL jargon, an RDS instance is like a MySQL "server". You just need a "database" per customer. On the other hand, if a tenant pays you less than $12 a month or any amount whe
263.
by gomox 6y ago
It's a terrible idea in the same way that using PHP instead of Rust to build a production large scale application is a terrible idea (i.e. it's actually a great idea but it's not "cool").
264.
by gomox 6y ago
Actually, I think conventional multitenant (shared database with tenant_id on database rows) is a bad idea (as well as premature optimization) in the previously described context. One of the companies I am thinking of had no dedicated ops t
265.
by gomox 6y ago
What I have experience with is separate DB, and separate applications. Then basically you orchestrate a bunch of applications, a task for which a myriad of tools already exist.
266.
by gomox 6y ago
If an "account" is an "enterprise" customer (SMB or large, anything with multiple user accounts in it), then yes, I know at least a few successful companies, and I would argue in a lot of scenarios, it's actually ad
267.
by gomox 6y ago
Most absurd missing feature ever. I tried to get some support for the feature request a while ago but got no attention [0]. I feel like every day I bump into this issue at least once, and there's always someone saying "don't
268.
by gomox 6y ago
Intuitively, I don't think so. The steel is colder than the actual oven, what it does better is transfer heat by conduction into the dough (better than stone at that). That only works if it's touching the pizza.
269.
by gomox 6y ago
Most likely gluten development. Aka you need more kneading, or higher protein content flour, or both (but most likely just the former).
270.
by gomox 6y ago
Steel slab ("pizza steel") + broiler at full blast does a good job.

More ›