Skip to main content

Federated sites in an Enterprise Cloud scenario

A bit of context

When enterprises start to work on large-scale migrations, sometimes they identify more cloud initiatives. These often seem to converge into the existing Atlassian Cloud Enterprise subscription, evolving towards a multi-geography environment.
This new scenario splits the audience into different geographies, increasing the environment's complexity and requiring new ways of working. In addition, the current administration model will have to adapt, and admins will need to take into account the optimization of resources (i.e. licensing the apps for the group(s) requiring them instead of the entire audience). These new challenges lead us to consider building an enterprise environment that closely follows the typology of the organization.

Monolith vs. decomposed instances

The Atlassian Cloud Enterprise offering provides companies the option to scale with unlimited instances/sites for organizational autonomy, data segregation, and customization. In addition, per-user licensing allows users access to all enterprise instances/sites with a single license.
Federation with Cloud Enterprise unlocks important workflows, like:
  • Internal/external - Put any content that requires external collaborators into its own instance to prevent an accidental data leak.
  • Data sensitivity - Some instances require highly sensitive data not generally available to the rest of the organization (see finance/legal service desks).
  • Different use cases - Customers literally have a decade of complexity implemented in jira.company.com. Administrators can separate out complex workflows into specific instances, making the administration of those instances easier. For smaller instances, it is easier to make changes and track side effects.
  • Business units - Some teams and business units want more flexibility in how they support (and run) Atlassian tools. For example, central administration teams don't need to be as involved with cloud sites as they are with on-prem sites.
  • Usage patterns - Ops teams often have specific configuration vectors (looking at your batched email settings), which make separating this use case into its own instance a natural fit.
  • Apps spending - With federated instances, administrators can separate apps that have small user bases into their own instance (but this also has the side effect of potentially licensing the same app multiple times). 
Federated sites in an Enterprise Cloud scenario 1

Opportunities

Autonomous organizations: monolithic solution vs. specialized instances
  • Looking to future ways of working, this might allow you to bring in other parts of the business with special needs for their respective cloud environment at low cost/risk.
Federation as a way to support the work of different groups/geographies
  • If companies have a need to work with multiple geographies, they must ensure that they are each kept independent so that data is in the right region to be compliant with local regulations.
High security: administration delegation
  • The ability to administer small instances means admins can delegate some of the responsibility to the equivalent of departmental champions without risking the whole instance, which provides more flexibility and control.
App autonomy: Smaller instances to reduce spending on apps
  • App usage can be compartmentalized so that apps are only purchased for the instance/site they are required for. Especially for expensive apps, this could provide a means of counterbalancing the higher cost of Atlassian Cloud Enterprise over other Atlassian Cloud subscriptions.

Opportunities and obstacles

A multi-instance cloud environment not only gives customers easier scalability, but it unlocks a number of other opportunities that could have a very positive impact on the user experience and administrative overhead.

For end users

Opportunities
  • Users have one account that can access all Atlassian products and instances once authenticated
  • Less clutter as the instance contains more relevant projects and data
  • Potential for faster overall experience
  • start.atlassian.com provides a single landing page with recent projects and issues across multiple instances
    • Also provides cross-site notifications drawer
  • App switcher makes moving between instances easy
  • Jira mobile app supports push notifications for multiple sites
  • Issues and pages can be linked across instances
  • Marketplace apps are available to synchronize or copy Jira issues between instances
Obstacles
  • Users may have a hard time finding their work if they frequently use multiple instances
  • JQL search is scoped to a single instance
  • Boards can only contain issues from one instance
    • Though Marketplace apps provide cross-instance alternatives
  • Dashboards, reports, and charts can only use data from one instance
    • Atlassian is actively building an advanced data lake and reporting capabilities for multiple instances
    • Dashboard Hub for Jira is a marketplace app that can provide multi-instance reporting
  • Users may not be available as assignees if they don't have access to both instances
  • No native issue or project migration tooling is yet available
    • Cloud-to-cloud project migration is in EAP
    • Exalate Jira Issue Sync is a marketplace app that can help with this

For admins

Opportunities
  • Can delegate administration to different administrators for each instance
  • Less overall configuration clutter since each instance has more focused scope
  • Single SSO configuration and set of managed accounts across instances
  • Consolidated view of all instances in the admin hub
  • Each instance can have a separate sandbox
  • App license costs can be lower if apps are targeted at specific user segments
  • Data residency, IP allowlists, and other controls can be defined separately per instance
Obstacles
  • Users and groups are defined separately for each instance (unless synced from external directory)
  • App links must be configured between instances for visibility and some of the technical features
  • Configuration objects (workflows, custom fields, schemes) are defined per instance and cannot be easily moved between instances
  • App license costs can be higher when multiple instances need the same app — this requires a deeper analysis and planning

Cloud enterprise demo

Content extracted from Team' 21 session Atlassian Cloud Enterprise Demo (29th-30th of April 2021)

Was this content helpful?

Connect, share, or get additional help

Atlassian Community