History of Atlassian - Part 2

Back behind-the-firewall, the world of Atlassian was moving on as well.  With Confluence Clustered as good as forgotten about, Atlassian were working hard on building a proper High Availability infrastructure for their larger customers, developing each of their behind-the-firewall tools into a true multi-node Application Server.  In July 2014, Atlassian released Jira Data Center, and later that same year Confluence Data Center was released into the world.

From Atlassian's perspective, this solved two problems that they had.  First of all, vertical scaling was starting to cause real issues for their biggest clients.  At this point in time, their newly-released Cloud offering was targeting small teams, so options for some of Atlassian's biggest customers were thin on the ground.

The second thing this allowed Atlassian to push forward was a new commercial model.  With their IPO coming up in late 2015, Atlassian's licensing model in the early 2010s was troublesome for them.  Server tools (as the single-node version of the behind-the-firewall tooling would soon become known) were sold as a perpetual license, including a year of maintenance (including support and upgrades).  Subsequent years of maintenance could then be renewed with a fee of half the original license fee.  From the perspective of an IPO, this perpetual license plus maintenance model was seen as suboptimal - it could cause revenue volatility through reduced fees in year 2+, requiring new big-ticket sales every quarter, and presented the issue of teams using old versions of the tools well beyond their relevancy by not paying for maintenance, causing support load (even when not valid) and pressure on public opinion from people using outdated tooling.

Data Center gave Atlassian the opportunity to pivot to a new commercial model which better suited their IPO goals.  As a subscription service, there's no "ownership" of the product for the end-user, and no 50% discount on subsequent years use.  With a subscription, companies need to continue paying for the product in order to keep using the product, and so have no financial incentive to not keep their platforms updated - presenting the newest and best Atlassian tools to their users.  Atlassian built up a stream of recurring revenue with this change, and this mechanism to drive commercial growth continues to this day.

From a technical perspective, Data Center is interesting, particularly when compared to Server.  The first thing to understand is that Server and Data Center are, fundamentally, the exact same tool - the Application Server you download to install on your hardware is exactly the same regardless of whether you've got a Server or Data Center license.  This may be surprising, but the Data Center license effectively unlocked the feature flag within the Application Server to utilise the multi-node architecture.

Importantly for customers, this meant that Plugins between Server and Data Center were very similar - there were some limited areas of difference¹, but for the most part Server Plugins could be easily ported to the Data Center platform, resulting in a huge marketplace of Plugins being available from day one².

From a technical perspective, Atlassian retained their relative indifference to tooling external to the Application Server itself, simply requiring a load balancer for request routing, a shared filesystem and a shared database, on top of the local server.  Although Atlassian did provide some guidelines for particular third-party tools, ensuring that all components of the infrastructure provided High Availability was solely in the remit of the customer's IT teams.

For the Application Servers (or "nodes") themselves, much of their processing was identical to when running in Server mode.  The main difference occurs with cache and search index replication between nodes.  EHCache replication using Java Remote Method Invocation is the primary tool here, with direct peer-to-peer communication used in most cases outside of node discovery (which utilised multicast).  For the replication of Lucene search indexes, in the early days, Atlassian, perhaps surprisingly, heavily leaned on the shared database to perform these functions - adding rows to the replicatedindexoperation table whenever a local Lucene Index update was performed, and relying on other nodes to poll this table on a regular basis³.  In 2020, this approach was finally deprecated in preference of a more modern document-based replication approach, where the full Lucene document is sent from node to node the moment the update occurs, significantly reducing latency and CPU spikes that the previous methodology regularly caused on larger instances.

¹Particularly regarding Plugin interactions with caches and Lucene search indexes - relatively minor tweaks for most vendors.

²Atlassian did begin adding additional requirements for Data Center Plugins over time, requiring, at various points, performance testing to be performed on the App and support paths to be provided, in order to become Data Center Compatible or Data Center Approved, which eventually became a requirement for availability on the marketplace.

³This process was notoriously buggy, and caused regular problems with issues not appearing in search indexes when polling threads crashed, or when the sheer scale of the replicatedindexoperation table caused polling requests to straight-up time out.

From the busy period around 2014, with the release of Cloud and Data Center, things calmed down somewhat in the Atlassian ecosystem.  Atlassian acquired some new businesses, building out larger and more all-encompassing Cloud offerings, and all the time the 2 main branches of Atlassian tooling (Data Center and Server on one side, Cloud on the other) kept developing in their own ways.

Although some level of relative feature parity was attempted between the behind-the-firewall and Cloud ecosystems, the reality inside Atlassian was that these teams ran as separate units, both with unique customer bases, and both with their own unique ideas as to where they wanted to take their products.

Broadly speaking (and in danger of leaning into hyperbole here), Data Center focused their feature developments on their clustering tools and the underlying application performance, with relatively limited feature change visible to the end-user - supporting their large, enterprise customer base with a fundamentally stable platform.  Cloud on the other hand became the exciting upstart, a laboratory for a complete reimagining of the user experience of the Atlassian tools.

Some of the divergences that happened during this period were obvious.  The Jira (and subsequent other tool) Cloud UI overhaul around 2017-2018 was one of the biggest.  Taking "inspiration from Japanese, Taiwanese and Chinese bento box"¹, these changes were a radical overhaul, switching from the traditional top navigation bar present in Jira behind-the-firewall across to a collapsible left-hand sidebar.  Alongside this, the new issue view was implemented, providing in-page overlays to view tickets rather than navigation to new pages, changing the way that teams interacted with their Boards completely.

Another big change during this period was the launch of so-called Next-Gen Projects for Jira Cloud (later rebranded as Team-Managed Projects).  This new Project type promised the ability for Project Administrators to be able to change their workflows, fields and permissions directly within their own Project, without having to be a Jira Administrator.  This change was huge, and many businesses running on Cloud platforms started using these features with abandon².

It wasn't just Jira that had major changes implemented during this time - around 2018, Confluence released its new editing experience, fundamentally changing the user experience of building and editing pages.  Real-time collaborative editing was the stand-out feature, but this change also brought with it slash commands and live macros (which showed their content in the editor context).

Throughout all of this, however, the tools were still Jira, or Confluence, or Bitbucket.  Atlassian's marketing heavily lent on the Cloud platform during this period, highlighting its fancy UI and new features, but for most people who were still on Server, their Atlassian estate may have felt like a very different beast.  Beyond the Cloud, Server and Data Center monikers, Atlassian tools weren't really differentiated in marketing or discussion from Atlassian during this period.

This messaging would become one of the biggest challenges that I had to personally deal with when in 2020, Atlassian made a shock announcement³.

¹Their words, not mine - Evolution of Jira Design - Part 2.

²I have thoughts on Team-Managed Projects.  They come with a lot of promise, but the reality is that these projects can be quite problematic in the real world.  I have worked with countless companies that have found themselves in a really sticky situation caused by overuse of these Project types over the years.  There's too much detail to get into on this topic for the moment, I will put together some further detail on this topic in a future article.

³I say a "shock announcement", the reality was that most people in the Atlassian ecosystem were just waiting for the inevitable day...

On the 16th of October, 2020, in a Blog post that was provocatively entitled "Accelerating our journey to the cloud, together"¹, Atlassian announced that they would be bringing their longest-standing line of products to the end of their life.  In particular, from early 2021, new Server licenses would not be available, by early 2022 existing users would not be able to up- or down-grade license tiers, by early 2023 no new renewals for application licenses would be available, and new marketplace Apps would not be purchasable, and finally in early 2024 the official EoL would kick in, stopping all support and security patching.

This became a bit of an earthquake in the ecosystem, with businesses desperately working out their best path forwards.  For many larger businesses at the time, a migration to Cloud would not be viable - either because Cloud had capacity limits that they would exceed², or simply their own internal policies would not allow them to use a Cloud platform in this way.  For these businesses, the path was actually relatively simple - migrate to Data Center, which would eventually require just a license switch (to a significantly more expensive subscription, it should be noted), giving them the ability to utilise the High Availability, multi-node functionality somewhere down the line.

For smaller businesses, however, the picture was less clear.  Data Center at the time had a minimum license tier of 1,000 users, far higher than was needed by most Server instances that were out there.  The Cloud would appear to be the most appropriate option to many of these businesses, but when the EoL was announced in 2020, the path to the Cloud was unclear - the Jira Cloud Migration Assistant (JCMA) had just been released, but was feature-deficient in many ways. The standard recommendation from most Consultancies was still to utilise a Site Import from Server to Cloud.  Even so, Atlassian put their full marketing force behind using JCMA (and the related tools for other products, referred to generically as xCMA) as a way to simply move your existing Jira Server instance into the Cloud³.

As an Atlassian Consultant throughout this period, I can say with a degree of authority that this marketing message (which although has been softened somewhat by now, is still broadly presented by Atlassian), and the expectations that it has set in the minds of many Atlassian customers, has caused me more sleepless nights than either of my kids as they've been growing up⁴!

¹Accelerating our journey to the cloud, together.

²Atlassian had only recently increased the user count limits on Cloud systems from 5,000 users to 10,000 users the previous year, and end-user experiences at the top ends of these ranges had been less than ideal at this point.

³The original blog post from early 2020 really goes to highlight the tone used by Atlassian.

⁴I hope in this case that obvious hyperbole is obvious, but just in case - I'm kidding!

With Server's End of Life on the horizon, the world of Atlassian Cloud Migrations began to evolve and grow at an almost alarming rate.

In our next part, we will be getting into the technical weeds of how Atlassian Cloud Migrations evolved from 2019 to today, what options are out there, how they work, and where their deficiencies can easily trip up even the most hardened of Atlassian experts.  Fair warning - it's BIG.

The Evolution of Atlassian Cloud Migrations will be released on Thursday 12th March 2026.