Something to consider is that Jira can require a great deal of configuration to tailor it to your needs. If you already have a DevOps team of some capacity (not everyone does) then it may only be a small incremental increase to run thinks on prem. I did it myself: I'm ver much not a DevOps person, mostly unfamiliar with optimizing JVM parameters for apps like this, but it still only took me about 5 hours to get things running stable, and then another 2 hours or so a few weeks later to tweak things like heap size to help things go a bit faster (though it was still somewhat slow)
To be complete open though I don't know how much DevOps overhead is involved in maintenance or feature updates. I hated the app and used it for less than a year so I didn't have much exposure. I guess my point though is simply that you may not need to use their SaaS option if you have a decent DevOps team already. After the initial setup time I doubt I spent more than half an hour a month managing the internals and updates.
I did spend more than that on configuring the system for use, which you'll need to do regardless.
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 datacenter product also seems geared towards people reselling Atlassian stacks. For example there's a company that offers HIPAA compliant Confluence (complete with signing a BAA, so you can actual store PHI on it). It doesn't seem like a great replacement for the server version.
DevOps really is not just doing DevOps on cloud platforms and SaaS. Besides, the sysadmin aspects of self hosting should be handled by, well, sysadmin. DevOps should be handling other aspects like developing solutuons necessary to have things (in this case Jira) work together with other systems. (Among other responsibilities) Though DevOps can implemented in different ways with responsibilities that are different from one organization to another, but I've never heard it defined as "we don't deal with on prem"
But I also get the impression that you may just be expressing a preference, not a rule of DevOps? If so then I definitely understand. Custom solutions to integrate or glue disparate systems together is often not the most interesting work. My area... A single word doesn't encompass what I do, I'm a generalist in my domain with one or two specialties, but glueing data together (not the same as a full integration, I know) is a big part of my job, and usually the least interesting.
Though in this case from other comments on prem seems a a dwindling option anyway for Jira. I worked with it about 7 years ago under one of their free licensing programs and disliked it enough that I didn't bother following them after that.
Yes, I should have written a bit more. It is definitely a preference. Currently, in my team Devops is a one man show (me). So I have to be careful with how much burden I allow. There are things that make sense to self host, I agree. I am just trying to avoid becoming classical IT and having to provide lots of end user support and such.
To be complete open though I don't know how much DevOps overhead is involved in maintenance or feature updates. I hated the app and used it for less than a year so I didn't have much exposure. I guess my point though is simply that you may not need to use their SaaS option if you have a decent DevOps team already. After the initial setup time I doubt I spent more than half an hour a month managing the internals and updates.
I did spend more than that on configuring the system for use, which you'll need to do regardless.