You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Where We Started
My company has been using Jira for a little over five years now. When we first made the switch to Jira it was for our development team of about 20 people to be able to use a better tool for issue tracking.
We decided to host our own server as there was hesitation about using Cloud technology at the time. As time passed and the company grew not only did the number of developers and testers using our Jira instance increase, but we started to see adoption from other organizations within the company (e.g. Marketing, Design, Training, Support, etc.).
Everything was perfectly fine, I was able to manage downtime upgrades after hours, the number of user support requests was manageable, and overall everyone was happy with the product and the way it functioned.
Last May, we had a network failure on the server that was hosting our Jira VM instance. This caused our Jira server to be inaccessible and because we setup our Jira Server as a Crowd User Directory for our BitBucket & Bamboo server no one was able to login to any of our Atlassian applications.
It was at this moment that we truly realized just how many of our employees either required or interacted with our Jira instance to perform their daily tasks (about 85% of our employees). As we didn't have a fail-over environment our users simply needed to wait for Jira to come back online (ouch).
This unexpected downtime was painful, but it was also a great opportunity to look at what we needed in order to prevent downtime for our users.
The Journey Began
At this point I was tasked with coming up with the best solution that would allow us to either avoid or minimize the downtime impact to our users.
The first option we looked at was having a cold failover environment. The great thing about this was that it was free! We could use a development Jira Server license and all that we needed to have was a second copy of everything in an offsite location that we could start up when our primary server fails for any reason. However, as we looked closer at this option it would require a Database export and Jira Home Directory copy from the point that our primary Jira server goes down. This means that it could take longer to bring the failover environment online than simply getting our production instance working again, (depending on what the problem is) which made it less than the ideal choice.
We realized that what we are truly looking for is High Availability, so that is when we started looking at Jira Data Center. Why didn't we look at On Demand with Jira Cloud? At the time we started our investigation, there were limitations on the size of the attachment and metadata for which we were well above the allowances, I'll get back to Cloud in a bit.
Jira Data Center had a significant cost increase over what our Jira Server cost today as the minimum number of users for a Data Center license is 500 users (we are currently using just under 200 user licenses), however when we calculated the cost to the business of the downtime that put a different perspective on the cost of setting up and running Jira Data Center.
We also decided that this was a good opportunity to look at Cloud infrastructure so that would could count on a bit more reliability and high availability.
Being heavily invested with the Microsoft tools, Azure was our go-to Cloud infrastructure option. We started with the Jira Data Center template that exists in the Azure Marketplace. This template was a great starting point for us to understand the various components that were required in order to make Jira Data Center function on cloud infrastructure. We dissected the template and modified it to suit our specific needs, deploying and destroying the environment multiple times over to make sure we were happy with the deployment without having to make post deployment configuration changes.
Once we were satisfied that we could deploy to Azure and start up the Jira Data Center nodes without any issues, we setup a beta group to start testing both the stability and the version 8.0 upgrade that we would be doing at the same time. While the beta group was testing, I had the fantastic opportunity to attend the Atlassian Summit in Las Vegas.
I planned on going there fully ready to talk with the Data Center team to make sure that what we had done and were planning to do was inline with Atlassian's best practices. It was during the Wednesday morning General Session that Cloud Premium was announced where the file system restrictions were being lifted and Jira Cloud would support up to 10,000 users. This was both great news and a bit of a monkey wrench in the plans we had made up to this point.
Big Decisions Need to be Made
We had put a reasonable amount of effort into preparing to move to Jira Data Center, but we hadn't paid for anything yet. I felt it was still important to talk to the Data Center team and see if they felt that the move to Jira Data Center was the right course of action.
I had the great fortune of being able to explain this story to a group of 5 Atlassian experts from several booths who had gathered around out of interest in our unique scenario. There were members from the Data Center, Cloud, Migrations, Enterprise Accounts booths just to name a few. They were very engaging and asked several questions, and out of the discussions I had with them, I learned the following information:
I have now returned from the Summit and I have done some comparative analysis of costs, pros & cons between Cloud and Data Center.
Regardless of which option you choose, there is one thing that you can do ahead of making this choice that will really benefit either option. Setup a test server, and regularly copy the home directory, export and copy the project data to the test server.
If you can get that server to start without errors and look like a mirror of production, your migration to either Data Center or Cloud will be much easier as you will be confident with your ability to perform that migration.
So now we are now at a crossroads. On one side we have Cloud, on the other side Data Center, we have a big decision to make, but regardless of what we choose I know that we have fantastic software down either path that will help us solve the original business problem of needing Jira to be highly available for our users.