Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the longest Atlassian outage

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

171–180 of 772 posts

Re: Inside the longest Atlassian outage

#171

Post by ofrzeta »

Rimbo wrote: post #157
closeparen wrote: post #136

Earlier quoted context omitted.

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque : you have no way of knowing whether they're working or not. Another problem you face is that they're uppity : people who went to college and got used to managing their own time now have all kinds of idiosy…

Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.

I don't see how it is cheap. Standard may be cheap but then you are missing a lot of features that are announced on the product pages with a small footnote saying "only in premium".

Re: Inside the longest Atlassian outage

#172

Post by rectang »

x0x0 wrote: post #114
stickfigure wrote: post #103

Earlier quoted context omitted.

I have built multiple multi-tenancy platforms and I never create separate databases for each customer. If you have separate databases, it's almost impossible to run meaningful queries across all of them. That architectural choice creates far more headaches than it solves. Usually people end up with the split-database architecture when they want a quick retrofit for a system that wasn't designed with multiple tenants.…

I can't believe anyone would do separate databases. Just wait until a migration doesn't run on 2 of your 400+ customer databases. Or multi-hour migrations.

When all customer data lives in the unified database: Just wait until a bug in a query exposes the data of customers to each other, creating instant regulatory and privacy nightmares for everyone.

Re: Inside the longest Atlassian outage

#173

Post by snarkerson »

> 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. However, all customers said they will invest in having a backup plan in case a SaaS they rely on goes down.

The real key lesson here. Your business is important to you. Not so much to the service provider.

Re: Inside the longest Atlassian outage

#174

Post by HeyLaughingBoy »

travellingprog wrote: post #158
judge2020 wrote: post #101

Earlier quoted context omitted.

> May be Microsoft, Is there a Jira replacement/offering in the Microsoft 365 suite?

Never used it, but looks like Microsoft Project would fit that box.

Oh god, no. We moved from Project to Jira and life became immeasurably better!

Re: Inside the longest Atlassian outage

#175

Post by tyingq »

nemothekid wrote: post #45

> 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, despite the often dubious value and/or accuracy.

Re: Inside the longest Atlassian outage

#176

Post by ezekg »

taeric wrote: post #87
ZetaZero wrote: post #81

Earlier quoted context omitted.

This. It would be an impossible nightmare for every account to have their own DB. Hundreds of thousands of accounts and databases....

Wait. Why? This sounds like something that feels hard, if you are used to the giant DBs of old. But you can probably get many many instances of the smaller databases without much trouble. Would still be some maintenance, don't get me wrong. But far from impossible.

Imagine the database schema migrations...

Re: Inside the longest Atlassian outage

#177

Post by Viliam1234 »

Rimbo wrote: post #157
closeparen wrote: post #136

Earlier quoted context omitted.

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque : you have no way of knowing whether they're working or not. Another problem you face is that they're uppity : people who went to college and got used to managing their own time now have all kinds of idiosy…

Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.

Cheaper than whatever is the open-source alternative?

Re: Inside the longest Atlassian outage

#178

Post by HeyLaughingBoy »

mrits wrote: post #96
brianwawok wrote: post #25

Earlier quoted context omitted.

Is it? We use JIRA. Not impacted. If this had hit us.. we would just switch to excel or something for a week/month? But maybe we are a very light user of JIRA. Nothing in there can't be replaced. It's "nice" to be able to go look up a 3 year old bug and which client reported it, but not really crucial for day to day ops.

I wonder why you use Jira if a spreadsheet is sufficient for your use case.

He didn't say it was sufficient; he said they could do it for a short while. I consider myself in the same situation: we depend on Jira, but for a week or so it's not a big deal to use a bunch of Post-It notes.

Re: Inside the longest Atlassian outage

#179

Post by hinkley »

bombcar wrote: post #93
dxf wrote: post #62

Earlier 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.…

Most SLAs say "if we miss this, you get time for free" which means that these companies will hopefully get a refund ... for the time they can't use the service. SLAs are mostly aspirational.

Cars warranties are also aspirational/virtue signaling, to a point.

If the maintenance costs exceed the margins on the cars you lose money. Do that on too many product lines for too often and you’re looking at bankruptcy. But some makers clearly are more risk averse than others, so a 6 year warranty from maker X does not translate to a 7 year warranty from maker Y.

Re: Inside the longest Atlassian outage

#180

Post by mywittyname »

dylan604 wrote: post #64
chrsig wrote: post #61

Earlier quoted context omitted.

It's more "this is our contractual obligation, if we're down more than this, then we might not charge you"

Lawyers are involved, so I'd assume some text about "excluding acts of god, sabotage,etc" to weasel their way out of things. They might even be able to get away with "acts of incompetence" how ever a lawyer might phrase that to allow their client to weasel.

That's a good way to get executive approval to replace a system. Google or Apple can get away with this kind of behavior, I doubt Atlassian can.

This outage alone has spurred conversations in slack about how terrible JIRA is and why we should replace it. If this kind of shit was pulled, I can guarantee we'd be on shortcut, linear, or something else in short order.

Post reply on HN