Tag: cloud

So where to move to?

Rodney N.3 Comments

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?”

Integrating your Atlassian Cloud with Azure AD

Rodney N.Leave a comment

Well, today, it seems we are going to do something I admittedly rarely do on the blog. That’s right; today, we are going to admit that JIRA Cloud exists!  

It’s not that I have anything against JIRA Cloud. My specialties tend to lie around making sure the underlying JIRA system runs as smoothly as possible, which is hard to do when you don’t own the underlying system. However, there is still plenty of overlap between JIRA Server/DC and JIRA Cloud, so it’s not like I’m unqualified to speak on it!

So it’s no secret at work that I maintain a whole collection of personal test systems. I do this to replicate and test just about anything I want without waiting for permission. The environments include (but are not limited to):

  1. VCenter Environment for VM’s
  2. More Raspberry Pis than I rightly know what to do with
  3. AWS Account
  4. Azure Account
  5. Cloud Environments of Confluence, Bitbucket, JIRA Software, and JIRA Service Desk
  6. Server Environments of Confluence, Bitbucket, JIRA Software, and JIRA Service Desk
  7. Several VPS online, including one running (wait for it…) Confluence.
This is RACK01. As in, “Yes, there is also a RACK02”. I…I might have a problem.

So, when my manager wanted some help looking into some oddness he saw in JIRA Cloud using Azure AD, he knew who had the tools to recreate and test that setup.

However, I didn’t know how to set up the integration when I started. So I had to learn that. And since I had to learn, I might as well help you learn too!  

Pre-reqs

To pull this off, you will need a few things first.

  • An Azure AD subscription. If you don’t have a subscription, and just want to do some testing, you can get a one-month free trial here.
  • Atlassian Cloud single sign-on (SSO) enabled subscription.
  • To enable Security Assertion Markup Language (SAML) single sign-on for Atlassian Cloud products, you need to set up Atlassian Access. Learn more about Atlassian Access.
  • A Claimed Domain with Atlassian. To do this, you will need to be able to modify the DNS records for your domain.

Also, we cannot forget the documentation. This actually was from Microsoft, and not Atlassian! Shocking, I know. But it was on point and guided me through most of the process.

Setting up Single Sign-On (SSO)

Single Sign-On, or SSO, is a mechanism that does what it says on the tin. If you log in to any application participating in the SSO environment, you will not be required to re-enter your password to sign into any other participating app. So if both your JIRA and Confluence are a part of the same SSO environment, you can start working in JIRA, then move over to Confluence without having to pause to authenticate again.

  1. To get started, go to your Azure AD Directory, then click “Enterprise Applications” in the sidebar (underscored in red). This page is where you will set up the Integration with Atlassian Cloud.
  1. Now that you are on the Enterprise Applications Screen click “New Application.”
  1. In the search bar shown, type “Atlassian Cloud”. Doing this will bring the integration up in the search results. Once it appears, click on it.
  1. Clicking the search result will cause the following menu to Pop up on the right-hand side. You won’t need to modify anything here, so you can click “Add” at the bottom of this menu.
  1. We can safely skip “1. Assign users and groups” for now. Proceed by clicking “2. Setup Single sign-on.”
  1. On the next screen that appears, you are presented with three choices. Select the second option that says, “SAML.”
  1. Next, you will get a pop-up asking about Saving. For now, click ‘No, I’ll save later.”
  1. You can save Section 1 on the next screen for later – as you will need information from Atlassian to complete this section. Instead, move onto Section 2 by clicking it’s “Pencil” icon.
  1. Here, we’ll only need to update one attribute. By default, Azure AD wants to send the user’s Principle Name to Atlassian Cloud. However, Atlassian wants the email address in this field. So to change it, click “Unique User Identifier (Name ID).
  1. Doing so will cause the following form to appear. Change “user.userprincipalname” to “user.mail” under Source attribute, then click “Save.”
  1. On the Navbar, click “SAML-based Sign-on” to return to the previous section.
  1. With the Attributes & Claims ready, we can start collecting information Atlassian will need. To begin with, download the Base64 Certificate in Section 3 to your local system.
  1. The next three pieces of data we will need are in Section 5. Copy the three URL’s highlighted below to a notepad you can reference later. To find them, you will need to expand the “Configuration URLs” Dropdown menu.
  1. Now we can switch over to Atlassian and start the setup there. Under your https://admin.atlassian.com admin page, Select Security →SAML single sign-on
  1. On the page shown below, click “Add” SAML configuration.”
  1. Now we can start entering the information we got from Azure AD. Be sure to pay attention to how I have it mapped below, as Atlassian and Azure have different names for each field.
    • Enter Login URL from Azure into the Identity provider SSO URL field
    • Enter the Azure AD Identifier from Azure into the Identity provider Entity ID field
  1. Now open the Certificate you downloaded in Step 12 in a text editor of your choice. Copy the contents into the Public x509 certificate Field, then click “Save.”
  1. Now we will need to give Azure some information on your Atlassian Cloud setup. To do so, copy the “SP Entity ID” and “SP Assertion Consumer Service URL” fields from the next page.
  1. You remember in Step 8, when I had you skip Section 1 on Azure’s SSO Configuration? Now is when we will go back and fill it in by clicking the “Pencil” icon.
  1. Here we’ll copy in the two URLs we copied in Step 18 into the two highlighted fields. Be sure to pay attention below, as again, Azure and Atlassian disagree on what to call these fields.
    • The SP Entity ID field from Atlassian goes into the Identifier (Entity ID) field in Azure
    • The SP Assertion Consumer Service URL field from Atlassian goes into the Reply URL (Assertion Consumer Service URL) field in Azure
    • Be sure to click the “Default” checkbox next to both, then click “Save”
  1. You should get a Pop-up asking if you want to Test single sign-on.  Click “Yes”.  This will open the following screen.  If your user is already provisioned in Atlassian Cloud, click “Sign in as current user”
  1. Congratulations, SAML SSO is now setup!

Setting up User Provisioning

So, we have SSO setup. Great!

As things stand now, you still have to go and manually populate every new user in your Atlassian environment. Not Great.

To resolve this, we’ll next setup User Provisioning, which also does what it says. This process will automatically set up new users in your Atlassian Cloud system as you add them in AD. Which, once again, will be Great.

  1. Go back to the Atlassian Cloud Integration page in Azure. This is the page from Step 5 of the SSO setup above. Once there, click “Part 3. Provision User Accounts.”
  1. On the next screen, we will select “Automatic” under Provisioning Mode:
  1. Next, we’ll need to set up some things under your Atlassian Access screen (https://admin.atlassian.com). To get started here, click “Back to organization” → Directory → User Provisioning.
  1. Now we will click the “Create a Directory” page to get started here.
  1. Enter a Name for your Directory. To keep it descriptive, I like to copy the name from the Azure Directory. After we enter the name, click “Create”:
  1. With this created, Atlassian presents us with two pieces of information that we’ll need to give Azure. Copy both the URL and the API key.
  1. Back within Azure, we will enter both of these into the Admin Credentials section. Again, be careful here as Atlassian and Azure disagree on what to call them.
    • The Directory base URL from Atlassian will go into the Tenant URL field in Azure
    • The API key from Atlassian will go into the Secret Token field in Azure
    • Be sure to test the connection after you enter both
    • OPTIONAL: You can also enter a Notification Email to get failure notices.
  1. On the next page, Mappings, you can use the defaults as-is. Just click “Next.”
  2. Under Settings, Set “Provisioning Status” to “On,” then Set Scope to “Sync Only Assigned users and Groups.”
  1. Click “Save,” and you are done!

Azure AD will not sync your selected users to Atlassian automatically! But which users will Azure sync? That is the focus of our next section!

Adding Users and Groups to sync to Atlassian Cloud

So with our setup right now, we have Azure syncing over only selected users to Atlassian. We set it up like this because if you sync everyone and have a large AD environment, you can quickly find yourself out of licenses on JIRA. So let us explore how we tell Azure which users it needs to set up in Atlassian Cloud.

  1. Back on the Atlassian Cloud Overview Page (again, from Step 5 of the SSO Setup), click “Users and Groups” from the sidebar.
  1. On this screen, click “+ Add User” at the top of the screen.
  1. Click “Users” then select the Users that Azure should sync with Atlassian Cloud. Repeat for Groups that you would like to also sync over to Atlassian Cloud.
    Note: As I did my testing on Azure’s free tier, I didn’t have groups available to get a screenshot of. Sorry!
  1. Select Role then click Assign. Congratulations! These users will now be populated into Atlassian Cloud during the next sync operation!

And that’s it!

You now have your Atlassian Cloud environment setup and ready to use Azure for Authentication! If you are already leveraging Azure AD to manage your users, it is just one less headache to worry over. 

Job Seeker Profile!

So, it does happen where someone searching for a job will contact me to ask if I know of any open positions. Unfortunately, I am not always able to help them in that regard. However, given the uncertain times we live in, I want to do something. So I’ll feature them here.

That is the case today with Siva Kumar Veerla from Hyderabad, India. He has recently been thrown into the job market due to the COVID-19 Pandemic. From his CV, he is a solid Atlassian Administrator who has led several projects, including upgrades and system installs. He is currently looking for opportunities in India or Europe. If you think he might be a good fit for you, please feel free to contact him on LinkedIn or through the information on his CV.

sivakumar_resumeDownload

And Other exciting things!

Let me just say…Wow. This month has been amazing! For starters, look at this.

Yes, that is a new record month for the blog! Thank you for continuing to read, comment, like, and share the blog on the various Social Media platforms.

I’d also like to thank Predrag Stojanovic especially, who pointed out an Atlassian Group on Facebook. And well, that group loved last week’s blog post! So, I’ve gone ahead and set up a Facebook page for thejiraguy.com blog! Like Twitter, like this page to get the latest posts from the blog and random Atlassian news I find interesting! You can also subscribe below to get new posts delivered directly to your inbox!

Also, I will be giving a presentation tomorrow on Monitoring your Atlassian Applications using Nagios! If you are in the Atlanta, GA area, tune in Thursday! If you are not, I am trying to refine this presentation to submit to Atlassian for Summit. So, with a bit of luck, you’ll be hearing it from me next April!

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