This article was written by Kamil Beer, an Atlassian Engineer at iDalko.
There are many paths to traverse in the Atlassian world – along with the risk of choosing the wrong one when choosing the deployment model for your Atlassian Stack. How to deploy Jira? What rules should I set up? And security? How to maintain the application? As an admin, you probably asked yourself these questions already.
Luckily, these paths have been already trodden by many experts, including those at iDalko. And they are what our new series of articles will cover – Atlassian stack best practices, based on our experience.
Alright, so you have decided to use Jira – or Confluence or Bitbucket – to help you out. Great! You searched how to install it and met the first crossroad. Where should the application run?
And they don’t even mention the third option: Data Center. So, what is the right choice?
This article describes the deployment choices, upsides, and downsides. It’s useful to both novice and veteran administrators. The post was inspired by the lecture on “Reasons why (not to) migrate to Cloud” by Tomáš Vrabec on Datascript Jira Conference 2020.
So here’s what we will discuss in the first part of this series of articles:
Simply put: Cloud means Atlassian hosts the application.
Cloud deployment has been around since 2008. Atlassian started offering a development platform with Jira, Confluence, SVN, Crowd, Bamboo, Fisheye, and Crucible called Jira Studio. In 2011, a product named OnDemand allowed the use of separate applications, unlike the bundled Jira Studio. In 2013, Jira Studio was discontinued and OnDemand was named Cloud in 2014.
So, with Cloud, you don’t need to provide the application infrastructure or perform any complicated server administration tasks. But there are other things to consider, detailed below.
To (not) keep it simple, there are four types of Cloud deployments:
- Cloud Free, introduced in March 2020, allows you to use Jira Software, Core, Service Desk, Confluence, Trello, Bitbucket, and Opsgenie for free. It’s a good introduction, but the limitations don’t make it very production-viable (e. g. Jira lacks permissions, Bitbucket is limited to 5 users).
- Cloud Standard is the most common Cloud solution. This article will talk about its upsides and downsides in detail.
- Cloud Premium is a more powerful Cloud Standard. It has 99.9% uptime SLA, unlimited file storage, and 24/7 support. New features include IP Allowlisting and Project Archiving. For small teams, users cost twice as much (e. g. a user in JSW costs $7 for Cloud Standard and $14 for Cloud Premium). But the more users you have, the lower will be the price increase.
- Cloud Enterprise (in Early Access) goes even further. With unlimited users, a 99.95% uptime SLA, the ability to choose Data Residency and “guaranteed integration with many essential enterprise SaaS tools”, it’s certain to be a dream come true for many teams, but also at a cost that won’t make it accessible to most of them. You can try it out here.
Now that we covered the Cloud types, let’s see what Cloud Standard has to offer.
You pay per user, not in bulk. In Cloud, you pay for every active user in the application. But in Server or Data Center, you purchase licenses in bulk. In Server, the price tiers are 10/25/50/100/250/500/2000/10000+.
You probably noticed the large jumps – and yes, this certainly means that once you hit 501 users on Server, you need to purchase the way more expensive 2000-user license including all apps you use. In Cloud, you would pay for that one extra user only. This, however, only applies to the Cloud monthly subscription. Yearly cloud payments still have their own user tiers.
Pricing example – Jira Software
No hardware costs. You don’t need to buy or rent servers, nor take care of their maintenance, scaling, deprecation, cooling, or electricity. You don’t have to hire employees to do that for you. This is taken care of by Atlassian that hosts all of its cloud solutions via AWS. These servers are located all over the world for better access and performance.
And while you still need an administrator, all the necessary tasks are done via the UI.
Easy upgrades. You don’t need downtime, time-consuming deployments on dev and test instances, or partaking in the arduous process of an instance upgrade. Upgrades are done on the background by Atlassian. You simply come to an upgraded instance with new features one day.
Reduced customization and support of popular software. Customization of Cloud applications is severely limited: you can only use some apps from Server, or they might miss some key features you were used to (e. g. Scriptrunner, JEMH).
Some popular enterprise software, like Active Directory, isn’t supported either. You will have a hard time with integrations. Various system settings are missing (no Priority schemes), others cannot be customized (e. g. your own URL).
No custom domain. Whenever you register a Cloud application, it will have a “.atlassian.” second-level domain like this: https://yourname.atlassian.com/. This is currently not possible to change – the difficulties in doing so have been described by the lead developer of this feature here.
Reduced number of users. On Cloud, the maximum number of users is 5000. This might be a problem in large organizations, as you would then need to federate into multiple instances.
Subscription model. Unlike Server, which has perpetual licensing (the initial price is for the application and year-long maintenance that you don’t need to pay again), Cloud requires either monthly or yearly payments to remain working. This is a standard SaaS model. However, it means that once you no longer need any upgrades and still want to use the application, you need to pay for the instance or lose your data. Or you have the option to migrate to a Server instance.
Simply put: Server means you host the application.
Jira 1.0 was made in 2002 to work on-premise. And other applications later including Confluence, Bitbucket, Crowd, Fisheye, and Crucible all became ready for local deployment as well.
So, what do you need when deploying locally? Certainly, your own/a hosting provider’s server to run the application (Linux, Windows Server, AWS or Azure are all options), a database, a file system and an administrator that can put it all together. In the beginning, the help of some other IT technicians might also be necessary. And while it all may seem like a large investment, it’s just well worth it.
User-friendliness. Sure, you might need to upgrade on your own once in a while, but nobody will drastically change your application or its features without you. If you want to keep it as is, after your users spent a long time familiarizing themselves with the tool, nothing stands in your way.
New (Cloud) UI or old (Server) UI?
In Cloud, features appear and disappear, just like the UI that many users complained about in the links above. In Server, once you set your instance up, that’s how it will remain. Few people like changes but if they are necessary, you can approve them first, or do a rollback later. And what helps with this is…
Perpetual model and developer licenses. Once you buy an Atlassian server license, you get the application and a year of maintenance. Paid maintenance means access to new upgrades and to a very helpful Atlassian Support channel.
After the maintenance expires, you can extend it for 50% of the cost of the current license user tier for another year. But even if you don’t, you can still keep using the application. Before the maintenance expires though, you should upgrade to the latest stable version.
You also get a developer license, which is a copy of your production license you can use for non-production servers, for example, a staging instance for upgrade testing, app trials or important changes, a test instance for your users to play around and learn the application, or for an archive instance for old projects/spaces/repositories.
Still, from time to time, various security vulnerabilities surface, and one of the solutions is to upgrade the application. If you don’t have active maintenance, this might become a big problem, but even then, you can…
Keep your Atlassian stack in a private network. Unlike the Cloud instance, which is visible to anyone, you can put the Server instance inside your VPN. This is both a good step, security-wise and also a way to fend off hacking attempts when visible on the internet. Recently, Atlassian has released a beta version of a feature that allows IP whitelisting on Cloud Premium, but a true application integration inside a private network is still missing.
Security aspects get even more complicated on Cloud with third-party apps, as the data they process aren’t hosted by Atlassian but by the vendors. This might cause GDPR non-compliance. On Server, everything remains on your machine.
Keeping Jira or Confluence in a private network is still one of the most requested capabilities for enterprise deployments.
Availability. There’s no guaranteed uptime for a Cloud Atlassian application. When your Cloud instance is down, you submit a ticket to Atlassian Support… and wait. If you use Server, then the uptime is up to you. If you prepare your infrastructure for it, impressive results and low downtime can be achieved e. g. via a clustered Docker pipeline, even in enterprise environments.
While Atlassian guarantees 99,9% uptime for Cloud Premium plans, this still means about 45 minutes of downtime monthly, and that is in theory and given perfect circumstances.
Access. You can access the file system and the database and perform various tweaks and custom integrations. Your filesystem can be scaled as the instance grows, which is not the case with Cloud, which has 250 GB file space as the maximum.
Atlassian’s investment. A couple of Atlassian Summits focused almost solely on Cloud and Data Center. There aren’t that many impressive new features made for Server (e. g. Automation for Jira or Jira Suite Utilities still remain a paid app, unlike on Cloud), not to mention the rumors that further development of Server might completely stop in a few years. And even though Atlassian still helps Server users e. g. to mitigate the mentioned upgrade problems, who knows how long this type of support may last.
Bulk user pricing and other pricing issues. We already mentioned paying for the necessary hardware, software, staff, etc. Another hurdle might concern licensing, with big differences between user counts (if you have 501 users, you need to buy the 2000 user license) – including apps. Some of this can be resolved by omitting maintenance for select apps or the main instance at your own risk.
There were also Atlasssian’s large price increases in October 2019. Users who bought 3 or 5 years of maintenance before have undoubtedly made the right choice. More increases are expected to happen in the future, as the prices have risen almost every year in the past decade.
Atlassian can’t help remotely. On a Cloud instance, in case it comes crashing down, Atlassian technicians will log in to your instance as system administrators and check what’s wrong. On Server, they can help only via helpdesk, which is still very useful. You also need to provide various logs and files, ideally in the form of a support zip.
Simply put: Data Center means you host the application, utilizing the power of several servers.
Data Center deployment was first made available for Jira 6.4 in 2014 and then for version 7.0 in 2015, when Jira was split into Jira Core, Jira Software, and Jira Service Desk.
Other tools quickly followed suit, with Confluence Data Center already being available in September 2014 and Bitbucket Data Center (named Stash by then) in March 2015. In August 2017, Crowd entered the Data Center family.
But what exactly does the Data Center deployment bring?
First, it runs the application on several servers. What this means is that it provides better performance and can sustain a heavier load than a Server instance.
Second, it provides a backup solution. Server A might be down, but your application will still run from servers B and C. Neat and useful when you need high uptime, for instance, for documentation or a support service desk.
True High Availability (HA). On Server and Cloud, there is a single point of failure. On Data Center, you can connect to as many servers as you want and ensure that they will keep you online. Also, the time you wait to get your Cloud or Server site backup is no more an issue.
Performance at scale. When your Jira Server instance grows to about 200 000 issues, you have to do some really advanced stunts to keep it running well. As you distribute the load between several servers with DC, you can scale the instance even further. It’s also a way to ease the pressure on a fast-growing application that you already scaled as much as possible. Again, you can always add more servers hosted either locally or on AWS/Azure to improve performance.
SSO 2.0 An interesting benefit is the addition of SAML connection to Azure AD, ADFS, and several other identity providers. This allows a single sign-on and authentication into Atlassian tools. Note that for SSO, you can choose either Crowd or your local identity provider, not both.
Example diagram of a Data Center deployment
The cost. With the exception of Bitbucket, the starting tier of Data Center is 500 users (Jira/Confluence) or 50 agents (Jira Service Desk) at $12,000 yearly. And that’s just the main application – you have to add the price of any third-party apps to this mix. Clearly, this deployment is feasible mainly for the enterprise. While Bitbucket DC available from 11 users up certainly seems interesting, one has to weigh the value it’d really bring when compared to a regular Server instance.
Licensing model. Even though you host Data Center, the licensing model is different from Server. You need to pay the same cost every year.
Cluster limitations. While Data Center can be deployed on several servers, you have to prepare the rest of the infrastructure for High Availability, too. This means the filesystem (e. g. using GlusterFS) and the database (many database vendors nowadays offer a HA solution). They also all have to be compatible and supported, which might not always be easy.
Now that you know the main properties of the three deployments, there is another point to consider: some applications can be deployed only in Cloud, some only on the Server version, and only a few can be deployed in Data Center. Thankfully, there is a large overlap – see below.
Cloud, Server, Data Center are the deployment options an Atlassian administrator should know about. While Cloud might prove useful in scenarios where you don’t have a server available to host your data, Server might be more useful when you do and when you run more and more use cases and customizations. Data Center becomes relevant once you reach the enterprise scale.
This article’s goal was to introduce them all in-depth. But maybe you already chose your hosting, but it doesn’t work as well as initially planned. You might be even considering migrating to a different one.
That will be the topic of the next part of our guide. Stay tuned for Part 2, where we will explore possible benefits and dangers of migrating instances.