History of Atlassian - Part 1

Back when I started in the Atlassian ecosystem in 2010, terms like "Data Center", "Cloud" and "Server" weren't even a thing.  Each Atlassian product had a single implementation mechanism - a single, monolithic Application Server, running on Tomcat, connected to a Database (often running on the same machine), and optional additions such as Reverse Proxies and Firewalls¹.  At the time, it was not at all uncommon to have Jira and Confluence servers running on a Developer's machine, being used by their immediate team and no-one else - in fact, my very first foray into the world of Atlassian started with the tools running on my desktop, with the local development team directly connecting to it (although, I'll admit, we migrated to a in-office server within a couple of months if only to save my poor machine!).

The one counterexample to this was actually Confluence, which had a version called Confluence Clustered, allowing for multiple Application Servers.  Broad strokes, this was a rarely-used tool, and only existed at the time as a reaction to some major performance issues experienced by some of Atlassian's biggest customers of the era.  The implementation was relatively naive, and to most, it was a feature that would only be used out of extreme necessity.  This feature, however, did act as a setting-off point for the Data Center line of products in later years.

¹It should be noted here that to some extent, Atlassian didn't care about the parts of the infrastructure outside of the core Application Server that they provided.  Beyond the issue of supportability, the reality was that any database with a Java JDBC driver could work with the platform, and any ancillary networking devices such as Reverse Proxies and Firewalls were very much seen as the customer's to own.  This concept will come up again later when discussing Data Center.

In October of 2011, Atlassian began their first foray into the world of vendor-hosted tooling and Software-as-a-Service (as it was commonly referred to at the time), with the release of Jira On-Demand.  This platform began with Atlassian simply hosting the existing Jira behind-the-firewall tool on their own AWS infrastructure, and providing all the expected features of a SaaS offering - SLAs, managed upgrades, direct access support - to the customer.

Although it was not hugely popular at the time (SaaS models still had something of a stigma attached to them), it did cause some major headaches for Atlassian.

The first issue was that the monolithic behind-the-firewall customer tooling wasn't ever really built with a SaaS model in mind.  This meant that scaling was purely vertical, shared resources between customers weren't a thing, and upgrades were still a slow, time consuming, downtime-requiring activity.  If Atlassian were going to scale up their offering, they would need to resolve these issues for themselves.

The second issue, and the one that really impacts Cloud migrations today, is the SLAs.  Back in 2012, I started as a Consultant at Adaptavist, and it was around this time that I was first exposed to the challenges of Plugins (later known as "Addons", now known as "Apps"¹) in the Jira On-Demand platform.

For now, let's take a brief foray into the detail of how these Plugins work.

¹Throughout this document, I will be referring to Server or Data Center plugins made using the Plugins v2 architecture as "Plugins", and Cloud Apps made in Atlassian Connect or Atlassian Forge as "Apps".

In the world of the behind-the-firewall Atlassian products, the vast majority of Apps available in the marketplace to this day utilise the Plugins v2 architecture¹, part of the Atlassian Plugin Framework.

Plugins are deployed on internal OSGi containers within the Application Server JVM, utilising Spring Dynamic Modules to interact with the host application.  In simple terms, Plugins are able to interact with Jira and the underlying operating system in a very similar way to how the core Atlassian application can.

This makes these behind-the-firewall Plugins hugely powerful - they can interact with the host Atlassian application directly with Java APIs, and can do things such as inject themselves into the rendering pipeline to ensure their code completes before render, or directly access other local systems on the network as they need to.

The marketplace back in the early 2010s was full of small-scale point fixes for existing challenges people were experiencing in the Atlassian products, and fully-fledged large-scale additions or replacements to components of the Atlassian tools.

It's worth noting that even features of the Atlassian tools that we know and love today started their life as third-party Plugins.  The best example is the Scrum and Kanban Boards that most Jira users encounter on a daily basis - these all started in a third-party application called Greenhopper, which was developed by a company called Greenpepper, who were acquired by Atlassian back in 2009.

¹There was a Plugins v1 precursor to Plugins v2 in the early days of Atlassian, but v2 when it was released in 2008-2009 was significantly more powerful, managing unloading and dependencies much more cleanly, and became the de facto standard for Plugin development.

With the world of Plugins existing as it did in the days of Jira On-Demand, this presented an existential threat to the viability of the SLAs that Atlassian were offering for its SaaS tooling.

When Jira On-Demand first released, it was feature-identical to the behind-the-firewall version of the tooling.  As such, customers were able to deploy Plugins as they saw fit to the platform¹.  The problem that Atlassian were experiencing was that these tools could run any arbitrary Java code on their platform - this wasn't a security issue per se (as the Plugins would only have the permissions associated with the JVM's associated OS user), but was a real problem from an SLA and performance perspective.

A big example at the time was ScriptRunner (actually called GroovyRunner for part of this period), developed by Jamie Echlin².  As one of the most popular Plugins available in the marketplace, it was fundamental to many companies' experience of Jira.  The problem that Atlassian had was that it would allow you to add arbitrary Groovy code in the front-end of the Jira system that would run within the Plugin - significantly increasing the number of people who would feel able to run their own code on the underlying Atlassian-owned host.

Long story short, it's very difficult to provide SLAs for a platform when the users are able to very easily run whatever code they want on the underlying platform, and directly impact the performance and even the functionality of the underlying host.  Atlassian needed to do something, and quickly, if they wanted to make their SaaS dreams a reality.

¹It's fair to say that at the time, Plugins were fundamentally necessary to effectively utilise the Atlassian tools, particularly Jira - the out-of-the-box experience of the tools was somewhat limited to say the least.

²Who I know very well, and worked alongside for over a decade at Adaptavist - he's bloody brilliant!

In 2014, having dealt with the challenges of On-Demand's infrastructure and the Sword of Damocles that was the Plugins v2 world, Atlassian rebranded their On-Demand services to Atlassian Cloud, and with that, they brought changes.

From an architecture side, this is the point that Atlassian forked the code of their behind-the-firewall offerings, and started to develop a new architecture that would better suit the needs of a SaaS host¹.  Although much of the underlying Atlassian architecture is something of a black box to outsiders, from discussions with the teams at Atlassian over the years, this is where shared services and true multi-tenancy started to come to the fore within the products.

The biggest change that was relevant to Cloud migrations however was in the world of Plugins.  The biggest co-release alongside the Atlassian Cloud was the Atlassian Connect Apps model, which still makes up the majority of Atlassian Cloud marketplace Apps to this day.  Initially, a small subset of Plugins v2 Plugins remained available on Atlassian Cloud systems².  This was relatively short-lived though - the future was inevitable - a Cloud-first ecosystem made of Atlassian Connect (and later Atlassian Forge) Apps.

Atlassian Connect was a completely different beast to Plugins v2.  No more were third-party vendors able to run arbitrary code on Atlassian's own servers.  Instead, the Connect model required vendors to host their own infrastructure to run their App code, and provided specific web APIs to call to interact with the Atlassian host product.  Apps would be naturally asynchronous in this new world, and hard time limits (typically of 10 seconds) were put on responsiveness from vendor systems.  This would ensure that third-party code could never again negatively impact Atlassian's SLAs, and resulted in a whole new marketplace for the vendor ecosystem to explore.

¹One of my favourite examples of how this developed over time was actually with Atlassian's short-lived Atlassian Stride business communication tool.  Originally billed as a replacement for Atlassian HipChat when it released in late 2017, it was announced that it would be discontinued less than one year later in mid-2018 as Atlassian partnered with Slack.
Surprisingly, when discussing this with some Atlassian developers at Summit after the announcement, they pointed out that Stride was in some ways a huge success for Atlassian.  Stride actually provided the first instance of a global, shared login system (what became Atlassian ID a few months after Stride's release), and acted as a test-bed for many more modular elements that found their way into products across the Atlassian Cloud suite.

²I recall our pleasure at managing to get Adaptavist's Content Formatting Macros Plugin retained as a Plugins v2 Plugin on Atlassian Cloud.

Atlassian Connect presented a number of huge challenges to vendors across the ecosystem.  Although the reasoning and logic behind the decision made sense, when Atlassian Cloud was first released in 2014, Atlassian Connect presented real problems for the developers of popular behind-the-firewall Plugins to overcome.

Upon release, Atlassian Connect was troublesome for developers across the ecosystem.  Atlassian marketing was presenting the Atlassian Cloud products as functionally equivalent to the existing Atlassian Server products, and with Plugins being such a key part of most teams' Atlassian usage, it was imperative that feature parity had to be reached.  The problem was, technically speaking, in many cases this wasn't possible.

The world of Plugins v2 has been built on the idea that as a Plugin developer, you could fundamentally change any part of the underlying Atlassian host to meet the needs of your specific product.  Whether this meant building new user interfaces, arbitrarily changing existing interfaces, or completely changing the operating flow of the underlying product, all paths were open to you.

In the new world of Atlassian Connect, developers felt restricted in ways that they had never done in the past.  UI interaction was heavily limited, only allowing for very specific sandboxed integrations - no more moving Atlassian elements around the screen or injecting into arbitrary points - everything was sandboxed and iframed away from negatively impacting the vanilla experience of the tool.

With asynchronous interactions required, this completely removed a number of key abilities from Plugins - the best example is of Conditions in a Jira Workflow.  With Plugins v2, it was trivial for a developer to build a custom Condition, pausing the rendering of the issue screen to check whether a transition should or shouldn't be shown.  With Atlassian Connect upon release, this was simply no longer possible - the render pipeline was sacred, and Atlassian could not wait for a third party to respond and delay the rendering of a page.

On top of all of this was the cost to the vendor - from now on, the vendor needed to provide their own infrastructure to host their own Apps, and bore the cost of this hosting.  This was something of a death-knell for the already dwindling supply of non-commercial Apps on the marketplace.  Although there has been a light resurgence of non-commercial Apps following the release of Atlassian Forge in 2021¹ (more on that later), this particular subset of the market has never really fully recovered.

All of this together resulted in a lot of stress for developers working at vendors, and, as a piece of personal opinion here, a lot of perhaps questionable practices with some vendors marketing the feature comparisons between their behind-the-firewall Plugins and Cloud Apps in a less-than-honest way.  As a customer, the messaging was (and still is!) confusing and in some cases quite misleading.

¹Although the recent change in commercial model for Atlassian Forge at the start of 2026 may hamper this growth.

In the next part of this series, I will be continuing my exploration of the history of Atlassian's offerings, diving into the release of the second behind-the-firewall platform, Data Center, and where it sits compared to the existing Server and Cloud products.  We will then cover the age of divergence - the period where the Atlassian platforms really started to develop independently from one another - which really helps to drive our understanding of the fundamental challenges of Cloud Migrations.

History of Atlassian - Part 2 will be released on Monday 9th March 2026.