So where to move to?

Well, last week was fun, don’t you say? Well, from one perspective, it was. You guys shared, commented, and drove a ton of views to the post – so much so that it got the attention of Atlassian’s top brass. Of all the emails I was expecting in all this, that one was not it. We are still ironing out the details, but exciting things are coming for the blog.

However, time does move on, and so do we. One complaint I heard last week was my numbers were off because of one reason or another. And on that note, I must disagree with you – slightly. The situation was off, not the numbers. I was looking at a pure situation where you were running no add-ons, and you were not applying discounts. And I stated in the post that it was not a realistic scenario, but it was good enough to get a basic idea of what was going on.

The reason I went with this approach in the previous was for the sake of this post. I can analyze one situation and maybe help one person. Or I can provide a method to do your analysis and help vastly more people. I knew I wanted to do this as a follow-up. It did not help with how suddenly Atlassian announced these changes, but that’s another story.

So, let us get into it. How do you know which path you should take for your situation? Is there even an option? What are your constraints: costs, functionality, performance, or regulations? Unfortunately, there are so many variables that this answer is likely to be unique to everybody who does the analysis. So without any more stalling, here we go.  

Analysis

For this analysis, I’ll be going through my process on my instances for The Jira Guy. That way, you can see what this looks like in a real scenario.  

Sensitive Data anyone?

So, let me save you a step here. Are you in a regulated industry? These include industries like Healthcare, education, government work, or the financial sector. And if you are, you will likely have some regulations that apply to you. These take various forms (HIPAA, FERPA, FEDRAMP, SOX), but the fundamental uptake is that you, as the admin, are ultimately responsible (legally) for safekeeping the data stored in your Jira instance. 

This requirement means you need to control your data and not having it floating in the cloud somewhere. So, your answer comes out real quick. You don’t have an option; you must use Jira Data Center. I know Atlassian is working on getting certified against these various regulations, but that doesn’t change where we currently are. And this situation sucks, as Data Center is not currently available below 500 users, but here we are.

Taking Stock

So, let’s assume that you are not in a regulated industry, and therefore have a choice. The next step we need to do is figure out what we have, how many people are in those instances, and how we expect it to grow. I like to use My.atlassian.com to get a baseline. 

Numbers completely made up – but these are the products I personally use

As you can see here, I’ve listed all my current server products, their current tier, current license usage, and where I expect that to be in a year. Estimating growth can be tricky, but a best-guess is sufficient here.

System Size

Next, we need to get a measure of how many resources the system is using. The principal metric I am interested in here is how much space are the attachments taking in Jira and Confluence – as these are one of the regulated features in Jira Cloud.

To get this, I like to go to the system, and as root, run the following commands:

Confluence:

du -sh /*

Jira:

du -sh /data/*

For Bitbucket, this isn’t as important to measure out.  

Given the attachment pool for Jira or Confluence, we can make a few decisions right away. We can look at the attachment limits listed here and make some inferences. 

Product with PlansStorage
Jira CoreFree2 GB
Standard250 GB
Jira SoftwareFree2 GB
Standard250 GB
PremiumUnlimited
Jira Service DeskFree2 GB
Standard250 GB
PremiumUnlimited
ConfluenceFree2 GB
Standard250 GB
PremiumUnlimited

So for my example, I’d be good at the Standard Tier for Jira Service Desk and Software, but for Confluence, I would need to use the Premium Tier.

Of course, if the cost of a higher tier at your user count is high enough, Data Center might be a worthwhile move. But this is why we do the analysis.

Apps

So, another thing to consider in your move is what Apps you are running. Unfortunately, not all Atlassian Apps are created equal, and each one has varying compatibility. That is to say, you might not be able to run a Server App on Data Center, and likewise, you might not find that App available on Cloud.

So the first step here is, you guessed it, taking stock. Go to each system you run, and make a list of which plugins are active on that instance. If you have any disabled, now might be a good time to uninstall them outright.  

While you are looking up what you are running, also put down how vital that App is for your company. Is it a Must have or a nice to have? This determination will help you make some decisions here in a moment. 

Now that you have a good idea of what is running, you have a bit of a tedious task ahead. You need to go to the Atlassian Marketplace and look up each App. We want to know which Apps are available for Cloud and which ones are available for Data Center.   

At some point, you will run into a situation where an App you are running is not available for either Cloud or DC (or both!). This situation is where that Priority column comes in handy. Can you live without the App? How important is it?  

As you can see from my list, most of my Apps are not available for Cloud, whereas I am only missing two for Data Center, and only one is listed as a must-have. At this point, I have two options: I can try to find an alternative, or I can re-evaluate how important it is. In this case, Reactions are nice, but they won’t kill the use case.  

Now comes the “fun” part.

Do you like math and research? I hope so because that’s what’s next. We need to start looking at the pricing for the various options. To do this, I’d start looking at the pricing page on each of the products.  

Take special note of the Cloud pricing as, by default, they give it to you in a “per user per month” figure – making the cost seem lower than it is. To fix this, I multiply the provided number by 12 and then again by the current number of users I have. When I get done, the figures look something like this.

Discounts

These numbers are great to have, but they still aren’t a complete picture as Atlassian is offering a one-time “Loyalty Discount” if you upgrade to Data Center. These break down as follows:

Before July 1, 2021:

  • Jira Software and Confluence (up to 1000 users): 25% discount from then-current published list price
  • Jira Software and Confluence (1,001 users and above): 40% discount from then-current published list price
  • Jira Service Desk, Bitbucket, Crowd (all user tiers): 40% discount from then-current published list price

Before July 1, 2022:

  • Jira Software and Confluence (up to 1000 users): 15% discount from then-current published list price
  • Jira Software and Confluence (1,001 users and above): 30% discount from then-current published list price
  • Jira Service Desk, Bitbucket, Crowd (all user tiers): 30% discount from then-current published list price

Before July 1, 2023:

  • Jira Software and Confluence (up to 1000 users)): no discount
  • Jira Software and Confluence (1,001 users and above): 15% discount from then-current published list price
  • Jira Service Desk, Bitbucket, Crowd (all user tiers): 15% discount from then-current published list price

So the earlier you move, the more you save. Combine that with the fact that Data Center’s prices are going up in Feb. 2021, waiting can cost you a LOT of money if you are leaning Data Center.

So applying these Numbers, I get the final picture of:

So now I have a complete picture. I know that I’ll be saving money this year with Data Center on every item but Bitbucket, and the price difference is close enough, I can justify the increased cost.  

Looking forward

However, that’s this year.  Next year, the bill will come soon enough. And with the price increases, what does that look like? I decided to extend the Excel out another row to see precisely that, and here’s what I came up with, using these tables from Atlassian.

Ouch. Well, we’ve already switched to Data Center based on last year’s number, so let’s look a bit closer. Yes, Cloud Standard is cheaper than the new prices. However, Your Jira instance already has 150 GB of attachments this year, and that’s only going to keep growing. You may need the Premium tier for that next year, or you might not. But eventually, you would cross that 250 GB Limit. And at that point, Data Center looks more favorable. So you can either go through two migrations in as many years or absorb the costs if you even still qualify for Standard next year. 

Intangibles

So we’ve talked about Legal Requirements, Usage, Storage, Pricing, Discounts, and Future Price Increases. Now we get to talk about Intangibles. You can’t put a hard number on these factors, but they will have sway on how you choose.

For example, if your organization is “Cloud-First,” you will be looking to put as much into the Cloud as possible. You can’t put a number on that, but this will likely cause you to choose Atlassian Cloud over, say, hosting a Data Center instance in Azure.

Then there are the factors your users demand. Do they value Jira being available no matter where they are? Or do they rather Jira perform well no matter what? Each of these considerations would lead you to choose one platform over the other and will vary wildly from company to company.

Unfortunately, I cannot help you here without knowing your specific circumstance, but I did want to get you thinking about it.

And that’s it.

I wasn’t lying when I said a lot of factors come into play. Between App availability and requirements, legal data residency requirements, pricing, growth, usage, and even the things you can’t quantify, you have a lot to consider. However, sitting down and weighing each option should lead you to the best choice for your situation.

Remember, while you save more if you choose Data Center earlier, Jira Server will not go anywhere for three years, and the situation is very much still in development. So maybe Atlassian will consider a lower DC Tier. Or perhaps Cloud will be re-written to be much faster. As an independent blogger, I cannot tell you what’s going on inside Atlassian – I have the same view you do most of the time.

So – about the blog.

Last week…Just wow, guys. You shared the blog, helped spread it, and I still have to do a double-take at the resulting numbers. Seriously, this happened today.

Image

Four thousand in a month. So, thank you so much. You all make this worth doing each week.

Last week, I was also contacted by someone high up at Atlassian. I won’t reveal contacts, but they stated they appreciated the post and that while Atlassian knew customers would be upset, they would hope that customers would eventually understand. And Atlassian felt my post went a long way towards that.  

They also noted my concerns about having access to the Tools to make blog posts and offered to help. And as of yesterday, The Jira Guy’s Atlassian tools are sponsored and paid for through Server End of Life! I had joked once that if I could get my Atlassian bill paid for, I’d consider the blog a success. Well…here we are. 

And while I still celebrate this good news, I haven’t forgotten that many of you out there are still confused, upset, and worried. I want to remind you that I intend to be your partner through this. I’ve already written a guide on setting up your own Jira Data Center instance, and once I can get approval for it, I intend to write a guide on Jira’s Cloud Migration Assistant. I’ve had my worries lifted so I can help you, and I won’t lose sight of that. 

So, don’t forget to go ahead and subscribe if you found this post helpful. You can find the form for that below the post. I post new content every Wednesday at Noon EST, so also follow me on Twitter, Facebook, and LinkedIn to be alerted when new posts come up. And if you can and want to help fund what I’m doing here, head on over to Patreon and subscribe. You’ll get access to exclusive content I won’t be posting here, a chance to vote on upcoming articles, and a chance to join our monthly conference calls.  But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”


Upgrading JIRA Data Center – with no Downtime!

So last week we took a dive into upgrading JIRA Server. So naturally this week it stands to reason that we will go over it’s big brother, JIRA Data Center. To be fair, doing an upgrade in Data Center isn’t much different than in Server. There are minor changes though that take full advantage of Data Center’s architecture, and those are what we’ll be focusing on today. We can sit here jabbering about it for a while, or we could get into it.

Zero Downtime Upgrades

So one of JIRA Data Center’s super-powers is the ability to stay online and completely functional while you are doing an upgrade! Called “Zero Downtime Upgrades” by Atlassian, this is the technique we will review today.

This seemingly superhuman feat takes advantage of the fact that JIRA Data Center runs on multiple nodes. Zero Downtime Upgrades allows you to put JIRA in a special “upgrade mode”, which allows nodes to be on different versions, then only bring down one JIRA node at a time while you perform the update. After the upgrade, you take it out of “upgrade mode” and let it start humming along on it’s new version!

Here is the doc we will be following that explains the what and how of doing a Zero Downtime Upgrade:

Before you begin

So, just because Data Center has fancy features, doesn’t absolve you from your own responsibilities. You will still need to go out and research what version makes sense for your instance, make sure it won’t impact any Apps, make sure your support systems are still supported under the new version, etc.

And I shouldn’t have to say this (I mean, I’ve pretty much said it the past two weeks now), but it is on you to thoroughly test each upgrade before putting it into production. JIRA is not a system that protects you from yourself. That is on you to do.

Also, “Zero Downtime” does not mean “Zero Risk”. It is still on you to make sure you have a good backup of the shared home, the database, and each node prior to upgrading the system. Remember our rule of thumb with upgrades:

ALWAYS give yourself a path back to before you changed anything.”

Entering Upgrade Mode

So, you’ve selected your version, have everything ready to go, but where do you start?

To Enter the mythical “Upgrade Mode”, Head on over to Applications -> JIRA upgrades in the admin section (or hit “g” twice, then type JIRA Upgrades into the search bar that pops up).

That DB Collation Error will be taken care of shortly….

Click the “Put JIRA into upgrade mode” button, and you are off!

Upgrading each node

After putting JIRA into Upgrade mode, it’s time to do each node. Depending on the number of nodes you have, this can take a long time. Just remember, for this to be truly zero downtime, at least one JIRA Node must be up at a time.

I should also point out that every JIRA node that is still up will be getting the load of the nodes that are down for the upgrade. To me, if you have the capacity, it makes sense to build out extra nodes before a JIRA upgrade to make sure that no single node becomes overloaded while some part of them are down.

I won’t bore you with how to do the upgrade on each node – because I already covered it last week. At this point you treat each node like an individual JIRA server, download the installer onto each one, upgrade that system, then make any filesystem changes you need to.

If you have any customization in the JIRA install directory, you will need to copy these over as well. Remember, you can backup and restore the modified file – but during an upgrade that does carry a chance of breaking that node. It’s always a better idea to make a diff between the old and new files, identify the differences from your edits, and apply those edits to the new version of the document.

As each node comes back up, test it by bypassing the proxy and going to it’s IP directly. If you have customizations, you will get the warning about that, but then it should pop up with it’s new version.

Also check back at the proxy (System -> System info) to make sure each node is connected back to the cluster after upgrading.

Complete this for all remaining nodes, then continue on.

After you’ve upgraded all nodes

Once you’ve completed the install for all JIRA nodes, go back to Applications -> JIRA upgrades in the admin section. Here you will see a new button lit up, “Run upgrade tasks”. Go ahead and click it.

This will do all the edits necessary to the Database and Shared Home to get you running fully on your new version. As this is an important step, DO NOT SKIP IT!

Once complete, this will take you out of “Upgrade Mode” and return JIRA to normal operation.

Take this time to do your normal tour of the health checks, Apps, and basic functionality to make sure it is all working as expected on every node. Once you are satisfied, you’re done! All without any end-user interruption!

And if something went very wrong?

Well, depending on when it went wrong, you’ll change what you do.

If you have entered upgrade mode, but have not modified any nodes yet, you have the option to cancel out of upgrade mode. No harm, no foul.

If you’ve already started working on a node – but have not brought any nodes online under the new version, simply restore that node to the previous version, then cancel out and go back to test.

If – however – you do have nodes online under the new version, and want to back out fully to the old version, you are in for a bad day.

This is the point of no return for the upgrade, which means in order to return, you are going to have to bring the whole cluster down. Afterwards, you will need to restore the database, restore the shared home, and then restore each and every node that is running a new version. Then you can bring your cluster back online. Then write an email to all stakeholders explaining why you just brought JIRA down when they weren’t expecting it.

And this is why I keep telling you to test until you are confident. It won’t catch everything, but it will catch far more than not testing.

So, Listen – we have, like, a lot of nodes. Like, A LOT.

So, you are wondering if you can automate this on nodes somehow. Well….

You can automate a JIRA upgrade using tools like Ansible, Salt, etc. I actually have an Ansible job running of my Jenkins (sorry, no Bamboo here) which keeps my personal Confluence up to date without me having to upgrade it every time. However, I do not recommend you do this for production.

Atlassian is changing things all the time, and they don’t always get into the nitty gritty of what they are changing. That Confluence Upgrade job in Ansible I mentioned? It was actually broken for four months because Atlassian changed the URL you download from, and Ansible couldn’t make sense of the redirect, and I didn’t have time to debug it.

Humans are much better to adapting to these small changes. That’s why I prefer to always keep a human somewhere in the loop for a production upgrade on each node.

But, if that doesn’t dissuade you, I guess I can’t stop you. Just know I won’t be the one to tell you how to do it, just that it can be done.

And that’s Upgrading JIRA Data Center!

I hope you got something useful out of this guide. I think I’m done with upgrades for a while though – between work and the blog, I’ve upgraded 5 nodes across 4 instances in the past two weeks. So yeah – we’ll be covering something new next week.

Don’t forget to hop onto our discord community! There you can chat with fellow Atlassian Admins, get help, and see what’s new! https://discord.gg/mXuRsVu

And until next time, this is Rodney, asking “Have you updated your JIRA issues today?”