Hacker News Reader

Comment by superMutex | Hacker News Reader

In our case it's due to regulations in place. For example, our data must stay on Canadian servers at all times.

Makes a lot more sense now, the flexibility to configure to your own resources for regulatory reasons.

You'll probably also encounter people who are a bit jaded after their experience with Jira's hosted cloud versus on-prem. Jira on-prem can be slow also, but at least you can throw ridiculous amounts of hardware at it and make it okay-ish.

We had a horrendous experience with on-prem during my last tenure. A lot of it came from lack of support and performance improvements. Atlassian has its way to strong arm it’s biggest customers into paying more or throwing in sub processors in the mix. At some point we had IT, Dev Ops and Engineering consultants trying to get our workflows running.

Eventually we caved and pushed their account execs to support a “secure” private cloud that passed our IT teams compliance criteria. Fun times!

Can you define what data has to remain on Canadian servers? If it's just user data, and not your actual code, then you could use a synthetic data provider like https://synthesized.io to convert real user data to synthetic with similar properties, then host your code wherever you want.

Jira tickets (and Tara tickets) are going to have user data (including poorly-defined user requirements). Turning that into synthetic data with Synthesised will almost definitely lead to developers building software that does not match the original requirements.

If you have real user data in non-production systems (e.g., development JIRA/tracking system) you're already doing it wrong. At the firm I work at we scan all non-prod systems for user identifying data and flag it up for removal.

Reply on news.ycombinator.com