5 Ways to Scale Atlassian Server Products

As organizations utilize Atlassian Server products to grow their business, they will undoubtedly find themselves in need of a way to scale Atlassian applications to support a bigger company with a wider group of users.

In this article, we share our best practices for helping our clients scale their Atlassian Server products. Specifically, we’ll review governance, federating, warm failover, and a disaster recovery plan. We’ll also indicate critical junctures when organizations should consider moving to Atlassian Data Center, which provides high availability, a robust infrastructure, and the performance needed to maintain reliable uptime.

It’s important to note, however, that there is no one-size-fits-all solution to scaling with Atlassian. If you need support in this endeavor, Coyote Creek has the experience as Atlassian Platinum Solutions Partners to make this transition seamless for you. We can help you determine your team’s unique needs and devise a plan to support your internal workflows and processes.

With that in mind, let’s get started!

How to Determine Your Scale

When you invest in Atlassian products, you want to be sure that you choose a solution that can support your organization for a long time to come. So, how do you decide what you need?

For many of our customers, the first thing that comes to mind is the number of issues that their existing instance can support. While this is one of the factors that you should consider, it isn’t the only one.

There are a number of elements that can, at some point, diminish the performance of your instance and increase the amount of interference needed to keep your infrastructure running smoothly. These can include users, custom fields, permission schemes, and more that we share in the table below.

It’s also important to note that while you may reach the threshold in one area, you might not reach it in another as organizations grow at different rates in certain aspects of their infrastructure.

Atlassian Sizing Guidelines 

The following guidelines have been determined by Atlassian to help you ascertain your scale and what type of Jira Software instance you will need to meet your size requirements.

 

Sizing Legend Small-scale Mid-scale Large-scale Enterprise-scale
Users 100 500 2000 100,000
Active Users 25 200 600 2000
Issues 15,000 60,000 200,000 1,000,000
Issues/month 200 1000 4000 200,000
Custom Fields 50 150 300 600
Permission Schemes 3 15 25 100
Projects 20 80 200 300
Parent Issue Types 10 20 50 160
Resolutions 10 20 30 40
Priorities 10 15 25 40
Workflows 5 20 35 100
System Level Small-scale Medium-scale Large-scale Enterprise-scale

 

5 Ways Atlassian Server Users Can Scale

#1 Implement Governance

When organizations adopt customizable Atlassian products like Jira Software, the concern is always allocating permissions properly to preserve functionality and maintain organization. When our customers are ready to scale your Atlassian infrastructure, we always recommend that they limit the number of configurations made to the application.

Here are a few other important recommendations to keep in mind while creating governance documentation for scaling your Atlassian infrastructure:

  • Consider usage and document guidelines clearly. For example, if Jira should not be used to store documentation as attachments, state that in your documentation.
  • Standardize processes and workflows as much as possible. Be sure to include integrated apps as well. As stated above, limit new configurations as much as possible and create an evaluation process for new apps or integrations.
  • Consider using templates that can be cloned and reused to maintain standardizations.

#2 Consider Federating

Federated environments are created when organizations choose to run more than one server to support an Atlassian application. Larger organizations do this to support growth and maintain uptime to meet performance standards. Here are some common examples of when to consider federated environments.

  • Bottom-up Growth. With Atlassian’s low price point and strong use-case, adoption often begins with a team and expands outward across the organization with new teams spinning up their own server instances. Eventually, it becomes more practical to upgrade as an organization to Data Center.
  • Mergers & Acquisitions. When organizations merge together and maintain the infrastructure of the new addition, an organization can find itself managing multiple server instances at once. Again, at this point, it might be more practical to upgrade the entire new infrastructure to a Data Center instance.
  • Autonomous IT Organizations. Another common scenario to see with larger organizations is separate IT teams within different departments of the organization. These parallel systems can later be integrated into one Data Center instance with careful consideration of cross-divisional processes. This shift also encourages greater collaboration and agility within the organization as a whole.
  • Intentional Federation Setup. You might also create a federated environment intentionally for temporary teams or projects requiring specific permissions or other project-based requirements.

#3 Set up a Warm Failover

Many organizations will institute a warm failover in a single server environment as a means to avoid service disruption in the event that their main server fails. In this instance, users would be directed to a standby server that contains a full backup of the main server infrastructure.

While this method adds an additional level of confidence for administrators, it still leaves customers with only one point of failure in the event that their main server fails. For true, high availability you would need an active-active setup vs a warm failover which is active-passive.

An active-active setup allows you to configure your instance so that you can direct traffic to specific nodes based on activity levels, or add more active nodes to offset high-demand during peak traffic times. You can get this with Atlassian Data Center.

#4 Plan a Disaster Recovery Strategy

We recommend that every enterprise organization plan and maintain a disaster recovery strategy (DR). With this strategy, should a complete site-side outage occur, a separate system in another geographic region will assume functionality to minimize disruption and maintain productivity.

A DR strategy for a single server will allow you to have copies of your database and file system for a standby site that will mimic your primary site. Unlike a federated environment, Atlassian Data Center gives you the ability to copy indexes from primary servers to remote DR servers to maintain consistency during failover.

Without this, the application would need to rebuild indexes which could take several hours and cost your company dearly in lost production revenue.

#5 Consider a Data Center Migration

While there are many routes to take to scale your Atlassian Server infrastructure and create greater reliability, eventually, growing organizations will get to the point where a more robust infrastructure is a must.

It is at this point that we recommend migration to Atlassian Data Center. To learn more about when migration to Atlassian Data Center is warranted, check out Atlassian’s new whitepaper: Server to Data Center: The Tipping Point.