Earlier quoted context omitted.
How else do you run a multitenancy platform?
At minimum separate tables for each tenant.
At that point you might as well just do separate schemas, it's actually less headache.
Inside the longest Atlassian outage
231–240 of 772 posts
Re: Inside the longest Atlassian outage
#232Earlier quoted context omitted.
Most likely the database tables themselves are just a mixture of everyone's data. There's no true multitenancy. So they have to load the backups into a separate database. Then just go through and individually select/insert into the old database. And then you have to worry about things like foreign key constraints complicating the bulk data loading. Are you going to disable constraint enforcement while you bulk load t…
I can't believe that they would intermix the data in that way... but if they did, godspeed to them, they're likely still overpromising what can be done in this time frame.
They don't, you're responding to speculation which is just outright wrong. Jira and Confluence is single tenanted databases, unless something fundamental has changed at Atlassian in the past 4 years.
Source: worked at Atlassian, on Jira, 4 years ago.
Re: Inside the longest Atlassian outage
#233Earlier quoted context omitted.
A lot of companies have integrations to atlassian suite which might not be easy to shift from. Secondly, there are a lot of individual competitors to Jira, Confluence and Bitbucket but which competitor can offer all three under a single invoice? May be Microsoft, can't think of anyone else. Also for such an extended downtime the customers are entitled to a discount or a credit note which a lot of CXOs consider in the…
> May be Microsoft, Is there a Jira replacement/offering in the Microsoft 365 suite?
Microsoft has Azure Devops Boards that is similar: https://azure.microsoft.com/en-us/services/devops/boards/
Re: Inside the longest Atlassian outage
#234Earlier quoted context omitted.
How else do you run a multitenancy platform?
This. It would be an impossible nightmare for every account to have their own DB. Hundreds of thousands of accounts and databases....
This is the case. I won't comment on your "hundreds of thousands" figure because the number of Cloud customers was a closely guarded secret at least when I worked there, but yes one DB per tenant, dozens to hundreds of DBs per server, and some complicated shuffling of tenant DBs when you run into noisy neighbours.
Re: Inside the longest Atlassian outage
#235Regarding the backup restores: I once worked a company that had a data loss issue. There was nothing else we could do, we had exhausted every option we had over almost 40 hours. At the end of the second day, it was decided to restore from backup. We had done this before, as a test. It took about 12 hours to restore the data and another 12 hours to import the data and get back up and running. One small thing was diffe…
In these cases the best thing to do is just give every customer the full month refund; don't make them ask for it.
Re: Inside the longest Atlassian outage
#236Selectively restoring data only for certain rows is super hard. But the communications by Atlassian has been the worst I have ever seen in the industry.
> Selectively restoring data only for certain rows is super hard.
What's the right way to structure your data here that would make restoring more straightforward here? Is this backup/restore scenario niche or they should have designed for it?
Re: Inside the longest Atlassian outage
#237Earlier quoted context omitted.
Atlassian has EOL'ed their non-cloud products https://www.atlassian.com/migration/assess/journey-to-cloud
I have had to correct this too many times already. Server is the name of the deployment type of their on-prem. It means single node non-clustered. Data center is their deployment that supports clustering to multiple nodes (and used to support a few extra features). They are retiring the Server deployment type licenses and pushing everyone to data center or cloud. So no, they aren’t EOLing their on-prem.
The cost of server was lower and fixed (buy it once), the cost of datacenter is MUCH higher (minimum 500 users, pay per year).
Which is even more amusing when you realize Server has been Datacenter with a fake mustache for years now.
Re: Inside the longest Atlassian outage
#238Earlier quoted context omitted.
>Are SLAs even real? SLI: Some metric you use to measure a thing (e.g. uptime, latency, etc.) SLO: Some objective you try to hit, as measured by the SLI (e.g. "99.99% of requests are processed within 3 seconds) SLA: A promise to a customer that they will meet some SLO, and consequences if they don't. If there aren't consequences for not meeting the SLO, then measuring and tracking the metrics is a pointless exercise.…
You could use it as a material breach of the contract and possibly get out of any arrangement you have with Atlassian.
A typical SLA precludes that by specifying the remedy for noncompliance with the performance measure. Only if they fail to apply the remedy is there a material breach. For a month-to-month SLA, this limits liability to one month's subscription, as agreed in black-and-white.
Customers that demand service level agreements often fail to recognise that they cut both ways.
Re: Inside the longest Atlassian outage
#239> Most of them said they won’t leave the Atlassian stack, as long as they don’t lose data. This is because moving is complex and they don’t see a move would mitigate a risk of a cloud provider going down. I still don't understand the strangehold JIRA has on some clients. I can't quickly think of another SaaS product that could be down for almost 2 weeks and not have most customers leave.
>I still don't understand the strangehold JIRA has on some clients. - Integrations with things like the source code repos, incident management systems, confluence or other wikis, Slack, etc. Moving away from Jira creates a bunch of dead links. - Internal dependence on complex workflows and state transition rules that are implemented in Jira. - Various very customized reports that leaders depend on to make decisions,…
Many years worth of source code filled with comments like
// if we don't toggle bit 7 here 10% of transactions will fail on Thursdays
// see JIRA issue BIGPROJ-12654 for detailed discussionRe: Inside the longest Atlassian outage
#240Earlier quoted context omitted.
I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to sit down and think critically about the use cases and instead decided it would be easier to say "yes" to every single feature request. It definitely feels like whoever is buying JIRA is not on the team who is using it (maybe IT or finance) because it ticks the…
The answer is medium to large companies. Jira is a tool that can satisfy hundreds of different teams’ work management needs without having to buy dozens of different products. The fact that it’s so feature packed and customizable is the point. I think the complainers are not really investing the time in to change project settings to fit their needs. My only complaint about the Atlassian suite is the performance of Ji…
I agree. I look at every JIRA killer and think we could maybe move and nope...they're missing something we use. In many ways JIRA is like Excel. On the surface it can appear easy to replicate for a single user, then you realize every user uses 10 different features.