10K Agents (and beyond)! A new scale and trust frontier in Jira Service Management

[#1]

I am excited to announce that Jira Service Management can now support up to 10,000 agents on a single instance in cloud. This is a significant increase from the previous 5,000 and comes as the result of a successful Early Access Program and a number of efforts to manage large sites.

Built for scale

Over the last 18 months, we’ve been working with large organizations - both cloud-native and migrators - to better understand how they operate at scale. Through these conversations, we’re able to identify and prioritize improvements to our products so they can go beyond how you’re using them today.

Here are some recent updates where we have improved queue scalability for large organisations. Because they are the mission control center for a project, we focused our R&D efforts to optimize the experience at scale by:

• Increasing the number of queues per project and implementing a priority queue limit
• Improving the performance of queues to help balance loads for large projects and identify inefficiencies
• Introducing Team Priority queues to ensure important queues are easy to manage
• Providing guidance on how to better manage queues at scale

Scaling our trusted cloud platform

One of the biggest advantages of our cloud products and solutions is they’re powered by our cloud platform. Because of this, we’ve been able to take a more holistic approach to scale. While we continue to focus on supporting even larger userbase and data sets, we’re also developing solutions that enable us to address business requirements - specifically security, privacy, compliance, and reliability - in a faster, more scalable way.

Broadening compliance and data residency

Hosting data in specific regions is critical for many organisations and continues to become more important as you expand your business into other geographies. Our data residency strategy is centered on continuously unlocking multiple regions rather than delivering bespoke solutions. As a result, data residency for Singapore will be available later this calendar year.

We also recently broadened the scope of privacy and security in Jira Service Management by extending Data Residency to all components included out of the box, including Opsgenie. You can learn more about this update and our future data residency plans in this blog.

This approach also extends to our compliance program. We announced HIPAA compliance for Jira Software in February 2022 and because of our approach, Jira Service Management Cloud Enterprise was certified HIPAA compliant in December 2022.

Protecting data at scale

While many of these improvements have been made on the backend, protecting your data at scale is a shared responsibility. One area that we’ve invested heavily in is building controls that enable you to efficiently and effectively manage who has access to your data.

Many of you aren’t just working with people within your organization - you’re collaborating with your customers, partners, and vendors. However, you still have authentication and authorization requirements that need to be met to protect your data. To help you address this need, we’re currently running an early access program for external user security, which will enable you to enforce 2FA on people outside of your organization.

Jira Service Management and Atlassian Access are also extending their capabilities to support single-sign-on for portal-only customers. This solution is designed to help users outside of your business leverage the authentication credentials you already have for them. You can learn more about these upcoming SSO capabilities for external customers in Jira Service Management here.

Grow your team with Atlassian - 20K Early Access Program

We know there are organisations that are looking for more than 10,000 Agents. These enterprise-scale organisations are front of mind for us as we move into our next scale horizon. That’s why we’re excited to announce that we’re running an early access program for 20,000 agents in Jira Service Management beginning in April.

How do I get involved?

You can reach out to your current account manager, comment below, or contact me directly (bpaton at atlassian dot com).

If you are coming from Server or Data Center, we are eager to work with you on a compatibility assessment; a process we have designed to better understand how your current data can better scale in cloud. Your account manager will tell you more about this process upon inquiring about the Early Access Program.

[Jimi Wikman]

I am still confused as to why a cloud platform would have scaling issues, especially when it comes to handling things like licenses and access?

Can someone explain why there are limits like this at all in the Atlassian Cloud platform?

[Edouard Kaiser]

Hi @Jimi Wikman , great question. Scalability and performance is impacted by many factors. Giving access to tens of thousands of users is usually not the challenge. The challenge is when you add extreme volume of data processing and high concurrent access to the platform (millions of custom fields, very complex JQL, millions and millions of issues created/read/updated....). That's why we apply limits today to guarantee a high level of performance in most circumstances. And we are continuously working to increase those limits while guaranteeing the same level of performance.

[Jimi Wikman]

I understand that, I ran a hosting company for almost 20 years, so I am well familiar with the concept of resource usage over number of users :)

What I mean is that limits like the 5k issues in a board or the number of licenses in a platform does not make sense to me as it has nothing to do with actual resource usage. One instance with 2k agents could have just out of the box configuration and have a few hundred agents active on a daily basis. Another could have 2k agents with tens of thousands of custom fields, dozens of apps and all 2k agents active all the time, running thousands of queries every second.

Instead of charging more for usage, you have focused on number of licenses or set hard restrictions in the code for number of issues in a board, for example. That makes no sense to me.

Cloud setups should scale based on the need of the system that run on it. Not on the number of licenses connected to it. The code should never force a limit on the number of issues in a view, regardless of the data related to those. If the number of issues is a problem, then the technical solution behind it is wrong.

Just my two cents from working with some of the largest e-commerce platforms in the world that have no problem managing millions if not billions of items and presenting them in dynamic fronts for multilanguage and multi store perspective.

I am guessing the reason Atlassian has chosen this approach is that it is easier to present than trying to have a conversation around resource usage in a cloud setup as most users believe the cloud to be magically infinite and not just clusters of servers :)