Hacker News new | past | comments | ask | show | jobs | submit login

It's funny that they recently killed self-hosted Jira. If you'd self-hosted you'd be fine.



To be fair, Jira screams SaaS.

I don't want any of my company trapped on it, but if they were I'm sure as well not going to self host that spawn of hell.


Self-hosted full Atlassian stack (jira, confluence, bamboo, bitbucket) for 6+ years. ~200k tickets. To be honest, it just runs with minimal issues.

Mostly downtime is just upgrades. I can remember a few times we've had to add (JVM) memory as our usage increased. Not sure what we're going to do with the discontinuation of server product line. We self-host to keep source code, etc. more than one configuration mistake (or zero-day) away from exposing it to the world.


We are in the same boat. We are looking at the cloud, but the migration tools are just a pain. I can migrate a project to the cloud from Jira, and it even gives me a report of workflow transitions I have to manualy update/change to fix, which is great.

But then, there is no way to keep it in sync. I have to blow that project away in jira cloud, and migrate it again.

So I Have to hard-cut over projects, on a system that has dozens and dozens of projects, and somehow have people figure out which ones are where. or one really, really ugly night to cut it all over, and hope it goes well.

I'm looking for alternatives, but our team is so invested in some very, very customized workflows, its going to be a pain.


Is there any way to migrate away from Jira, or is it full lock-in? I mean, is there any migration tool or service to Redmine, Gitlab, MantisBT, Trac or whatever?

I think one reason Atlassian was successful is that they always invested a lot of effort in building tools to migrate to their products from any of their competitors (obviously not the other way around).


Self-hosting Jira is running a big Java application that has its own directory structure and talks to a Postgres database. It really isn't hard. Even upgrades are automated using shell scripts, although you do need to manually replace some configuration files afterwords for some damn reason. Configuring Jira is complicated, but that's the same regardless of whether you self-host.


Self-hosted Jira sucked because it was shitty software, not because self-hosting has to suck. Mattermost and Jitsi are easy to self-host, to give two examples that are not complete shit.


They've only killed off one version of self-hosted Jira. Their datacenter edition is still alive.


> If you'd self-hosted you'd be fine.

Maybe. But you're counting on your sysadmin(s), who are also managing dozens of other things, to keep up to speed on Jira and its quirks, and apply patches and new versions as they become available without missing any steps or screwing something up.

On average, you're still probably better off having a company that knows the product also host it for you, but obviously they can make mistakes too, and the downside is that when they do it might affect all clients, not just one.


> and the downside is that when they do it might affect all clients, not just one.

This is also potentially an upside. For example when us-east-1 went down recently, customers were somewhat understanding because it was "amazon's fault" and everyone was down - it was in the news, etc. If we ran our own data center and that went down, our customers would've just said "why did you morons roll your own data center instead of just using aws?"


I worked at a company that self hosted Jira, and it was miserable then, I can’t imagine depending on the cloud. I’ll never approve Atlassian products after that experience.


How many tickets do you have in your non-Jira ticketing system? I count 100 tickets per person per year.


We're using the cloud version and we're fine too (no outage). What's your point? Are you claiming that self-hosted is never down? Or that self-hosted is more reliable? Because I doubt that. Difference is just that when self-hosted goes down, it doesn't end up in the news.


I think there is a strange psychological trait that I have, and others may as well, where I am much more forgiving breaking my own stuff than having someone else do it.


When you host Jira yourself, the monthly subscription pays for Software + Software updates. When Atlassian hosts it for you, you're paying for Software + Software Updates + Service (hosting). When you hosted yourself, a team gets blasted for not monitoring it or updating it correctly. When Atlassian fails to do it (and charges for it) then they get the heat.

All that to say, I don't think it's a weird phenomenon, it's just you're realizing that you're paying someone else for something that's not delivered on.


People are more forgiving torwards themselves and their own folks, I can understand that. I'm just thinking it's important to make decisions based on facts. Some self-hosters walk around with this "my own basement is safer than Amazon datacenters" attitude and that's just not true (in most cases, I guess :D).


No. The basic assumption is only, that if I pay somebody money for the service and to keep things running, then sudden data loss is unacceptable (and a multi week downtime even more so).

Some companies cannot operate effectively without atlassian products, so a fuckup of that scale might just have legal consequences depending on whom it hits.


> Some companies cannot operate effectively without atlassian products

Kind of their problem to be frank.

> so a fuckup of that scale might just have legal consequences depending on whom it hits.

Any contract those companies signed would have a cap on the retributions by Atlassian for trashing SLA targets


In my years of selfhosting personal stuff I never had a service “sunset“, never lost data, and never had significant downtime.

In the external services I use, downtime of one service or other is to be expected at least a few times a year, and the “sunsets” happen occasionally.

Thing is, public services are solving a much more difficult problem (keeping things running safely for millions).


My own self-hosted services have about 20 min downtime a month.

I’ve never – not at any point in the past 10 years – gone over 24h of downtime.

JIRA will now have 3 weeks downtime.

Distributed systems have complexity that grows superlinear, which leads to more and longer incidents.


We self-host C & J for just shy of 3,000 users and haven't exceeded that.


One difference might be that when you self-host, you are more sensitive of some of the risks, whereas a hosting service might be balancing that risk with a need to scale, and their appetite for risk and tradeoff considerations might be different from yours. It might be that these companies know something that their customers don't, and thus are more willing to take on risks.

In this case, it seems like the company took a risk and it did not go well. The possibility of being able to restore from backups might have been factored into this risk, but the latency of doing so might not have been.


It sounds like Atlassian is doing individual restores, each restore takes a fair amount of time, and they don't have the capacity to do all 400 simultaneously (because why would they). So you just have to wait.

If you're self-hosted, you dedicate as many people as possible/necessary to restoring your service, and it becomes their top priority.

You also have a lot more insight into the detailed inner workings of the restore, making it easier to plan against, instead of just vague "we're working on it" messages for days a time with no clear end in sight.


if my company would be part of the outage, the restoration part would only take 2 days (if we're counting all the data they have, not just jira/conf) but not 3 weeks

so selfhosting may still have certain upsides even with such outage




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: