Hey Community, my name is Jacob and I’m a Product Marketing Manager on the Data Center team. We want to hear from you! We understand that the move to our Data Center products doesn’t happen overnight, but when you are ready we want to help you make the strongest case possible.
Before we embark on creating assets and materials, we thought it would be best to hear from y’all.
For those who have switched to Data Center, what helped you build your case? Are there materials you presented to your company, or are there resources you wish you had?
For those who haven’t made the switch (yet), what can Atlassian do to help support your case? What kind of assets? What information do you need?
Thanks for your input. Please share your comments, input, feedback and any ideas below.
Cheers,
Jacob
Thanks for sharing @Mikael Sandberg this is great feedback and exactly what we are looking for.
My Summit 2019 presentation has some slides with our reasons at LinkedIn
https://www.atlassian.com/company/events/summit/schedule/by-track?sessionid=508706
Hey @Matt Doar love your presentation thanks for sharing
We had Jira/Confluence instances that soon became mission critical to our organisation. Moving to Data Centre was a no-brainer for us, with high availability being the number one reason.
As we had > 15k users, we became the first customer in Australia to enter into an ELA with Atlassian. There have been a few occasions where Premiere Support and TAM's have been lifesavers, so highly recommend getting them on-board if you can.
No Data Centre migration goes without a few gotchas. Our's was around performance. Our Data Centre's couldn't provide the reserved performance that we needed, so we migrated to AWS (*in progress)
My two cents would be:
- Pick a platform (cloud / on-prem) that can scale
- Get access to TAM or PS
- Test, test, test - this includes performance monitoring so you can tweak your environment as required
- Infrastructure as code: You don't want to be doing manual deployments and upgrades. Think Puppet / CloudFormation etc
- Start small: if you have several Jira/Confluence instances, pick a small one and deploy that as Data Centre, get a feel for your environments limitations. HINT: NAS/SAN, your shared home drive needs to be quick, else you'll be waiting hours/days for re-indexes to complete!
- Monitor, monitor, monitor: NewRelic / Dynatrace, know what is going on. This information is crucial should you expect support from community / PS
- Don't be afraid: Ask first, there's no such thing as a stupid question. What sometimes may not seem obvious as the time will be revealed quicker if you put your hand up. Use the community, use google, and always test, test, test.
- Prod, QA, Dev: If you don't already have a Dev environment, get one. This is crucial to learning how your Data Centre deployments will either succeed or fail.
- Finally, Demonstrate: Show your stakeholder/sponsors in real life the benefits of a highly available Jira/Confluence DC. For every hour that Jira/Confluence is down, it's costing someone $$$
Hope this helps!
Jared.
Hi @JiraJared thank you so much for all of this, it is great information. I know you mentioned that moving to Data Center was a "no brainer" due to HA, however, at any time during the process did you need to be persuasive, help convince someone of the value add, or build a business case? Did you use assets like the Business Value Calculator or a pre-made presentation deck? Would you have wished like to have a 1-page pass along or a checklist?
Thanks!
TBH, the users wanted more reliability. The requirements were to provide a solution that Data Centre solves.
Hello!
We went through this process for Crowd and Jira and are happy with the result!
In particular, increased availability and the possibility of a full indexing of Jira without inaccessibility to users.
We use Oracle 12 as a shared database, and we use Hitachi NAS storage with NFS connectivity as a shared file storage. For ease of setting up new application server nodes, we run Jira in docker.
There may be nuances with finding the nodes as the multicast traffic is not always routed correctly. Then you should use the options for those applications where it is possible. For example, HAZELCAST_NETWORK_TCPIP, HAZELCAST_NETWORK_TCPIP_MEMBERS for Bitbucket and
discovery.zen.ping.unicast.hosts for Bitbucket ElasticSearch.
We also planned to migrate Bitbucket, but found out that the performance of the shared storage is several times less and does not satisfy the current load on the application. We are working on reducing the load and plan to complete the migration.
Our deployment scheme:
In result we have this beautiful graph:
Hi @Max Malygin thank you for the detailed response and sharing your insights and experience, this is great information. Love seeing the results in your graph and happy to hear that you are experiencing such positive results.