This short guide discusses the trade-offs between cloud vendors and in house hosting for Atlassian Data Center products like Jira Software and Confluence.
At Modus Create, we often provide guidance and help customers with migrating and expanding their Atlassian product portfolio with deployments into AWS and Azure. We’ve recently discussed the differences between Jira product options, how to prepare for Atlassian certification exams, and more on our blog. In this article, we will be looking at what options enterprise level clients have for hosting Jira or Confluence Data Center by comparing Cloud and in house possibilities.
Over the course of an Atlassian product’s lifespan within your organization, its hosting requirements will change in line with how pivotal of an application it becomes to your teams. For existing Confluence implementers with smaller user bases, Atlassian’s cloud-based service has typically been the right-sized option. However, as the usage, storage requirements, and the number of accounts increases, it is common to switch over to the self-hosted (cloud or on-premises) Data Center or Server versions of the product. This is achieved via a migration path from Atlassian’s Cloud service to another third party service provider, or possibly to an in house solution.
The question many of our customers ask: should I go with Server or Data Center, and where should I host it?
Data Center or Server – Which is Right for You?
New customers implementing Confluence and other Atlassian products will have the ability to decide from the offset which option fits them best. For particularly large teams and enterprise customers, Data Center is the go-to choice. While Server allows in house hosting, it lacks some of the key features that make Data Center the choice for large distributed teams.
The following matrix provides a comparison of the two key products and some of the features available:
The licensing model also differs between these two deployment options. Server offers a perpetual license, meaning it will never expire. Payments after year 1 are cut in half and are strictly for maintenance to allow for upgrades and access to support. Data Center offers a term license, meaning you must purchase the license every year or risk your application becoming disabled. Review the official Atlassian Licensing FAQs as this is subject to change. Third-party apps paid via Atlassian follow the same license model.
While there is some difference in price, there are several other factors to take into account when choosing between Server and Data Center. Many new features Atlassian has released are not available in Server, thus Data Center may be your only route for meeting specific feature needs. We discussed some of these new features coming to the tool suite in our recap of Atlassian Summit 2019. If you outgrow Server, there is the additional migration cost of building out expanded infrastructure to then support Data Center. By starting with Data Center, you skip the additional cost that may be associated with scaling up by having to do installation and build out work twice. Server doesn’t support clustering and high-availability, which is crucial for ensuring a mission-critical system is accessible 24/7. When systems go down, loss of productivity translates into extra cost for your company.
Your organization should use Data Center once you reach the point of needing redundant systems and hosting tens of thousands of users. Capable of integrating with SSO and Active Directory out of the box, and distributing traffic across multiple nodes in a cluster, Data Center can easily scale up to meet your organization’s traffic requirements while allowing you to manage user access through your preferred corporate-wide mechanism.
Having settled on this option, there are two major choices available on where to install the application.
- A third-party Cloud vendor environment, such as Azure or AWS
- In house, meaning building out infrastructure in your own data center in order to accommodate all of the components that make up the product.
Each comes with its own pros and cons, including cost. Read on for our evaluation and recommendations.
As a Gold Solution Partner, Modus supports clients in all stages of the Atlassian lifecycle. We help with licensing, enabling, scaling, and training in the full Atlassian tool suite. Learn more about our work with Atlassian or talk to an expert on our Atlassian partner page.
AWS Offerings
AWS is the largest Cloud vendor on the market at the moment, with the largest number of services offered and customer base. It is also a popular option for hosting Confluence and Jira Data Center due to the out of the box scripts that exist, which allow you to spin up a hosted instance with ease.
Amazon’s infrastructure deployment tools and scripting mechanisms are known as CloudFormation. This service allows an infrastructure as code representation of a Virtual Private Cloud (VPC), with all the components required to successfully host Confluence or Jira Data Center in AWS.
Atlassian has a prepared set of CloudFormation templates and instructions that allows any organization to easily spin up a new VPC and deploy load balanced, multi-node versions of Data Center. However, it should be noted that even with these templates, having an expert on the team to help you get over the finishing line is essential.
The following diagram shows the architecture implemented in the templates for an AWS Cloud Confluence Data Center deployment:
AWS Confluence Data Center diagram, source: Source: AWS Quick Starts.As shown in the diagram, this set of scripts hosted on GitHub represents a best practices version of a hosting environment including:
- Load balanced, multi-node, multi-zone hosted environment
- RDS based database hosting for PostgreSQL
- Network segmentation within the VPC to increase security
- Bastion host machines to act as access points for administrators
- Auto-scaled EC2 instances to handle traffic spikes
- The ability to run Synchrony as a separate scalable EC2 instance
- Amazon EFS for sharing files between nodes
Enterprise level customers may wish to also spin up a redundant version of this architecture in a second AWS region. The database can then be synced between regions. In the event of a region going down or the application crashing, traffic can be sent to the second region. This could be in READ only mode, or if you are prepared to sync the database back to the restored primary region, also in READ-WRITE.
The big consideration here, however, is cost. It may be possible for you to run a smaller environment for your team if you are willing to accept not having a multi-zone setup. However, shifting to a Cloud-based vendor shifts the hosting costs away from your CapX budget to OpX.
AWS’s recommendation is to enable the AWS Cost and Usage Report in order to track the usage costs associated with standing up the infrastructure. In addition the Amazon Simple Monthly Calculator can be used to estimate costs before deployment.
Our deep AWS knowledge is reflected in our AWS Select Consulting Partner accreditation and goes beyond standing up Atlassian environments in the cloud. We also have experience planning, migrating, and optimizing products and portfolios in the AWS cloud. You can learn more about our partnership on our AWS partner page.
Azure Offerings
AWS’ major rival in the sphere of Cloud hosting is Microsoft’s Azure product. As with AWS, Atlassian provides a set of canonical scripts that can be used to deploy Atlassian Data Center products into an Azure private Cloud environment. In addition, they provide instructions for your DevOps team to follow when rolling this out.
The default configuration for Data Center, when hosted in Azure, is somewhat less complex than that provided for AWS. For example, Auto Scaling is not yet supported due to problems related to Hazelcast, so it is not a factor you have to consider at this point.
As an example, the following diagram shows the layout of the private Cloud as configured by the scripts provided by Atlassian for Confluence Data Center.
Data Center architecture hosted on Azure. Source: Atlassian. Using this model a typical Confluence install in Azure will use:
- Azure Application Gateway for load balancing
- Confluence application nodes hosted on Azure Virtual Machines
- A bastion host to allow admin access to the VMs
- Azure Database for hosting the database
- Azure storage for hosting files in the Shared Home directory
- Segmentation of services into Public and Private Subnets for security purposes
- DNS configuration handled through Azure DNS
For enterprise-level customers already heavily invested in using Microsoft products and Active Directory, deploying within Azure allows you to host Data Center on a familiar platform and integrate with your existing AD service. As with the AWS option, you may wish to host a second version of Confluence Data Center in a second region. This will allow you to switch traffic over to this redundant system, should the primary one be unavailable for any reason.
For Azure users, the Pricing calculator and the monitoring usage and estimated costs guide can be used to estimate and track costs.
Other Cloud Vendors
You may wish to host a data center with other Cloud vendors. While possible, at this time Atlassian does not offer templates for spinning up the infrastructure, as they do with AWS and Azure.
Google Cloud Provider has some instructions for standing up Confluence Server in their environment, which can be obtained from here. and Jira Server which can be found here. This methodology could act as a starting point to build out the Data Center version.
Implementing Data Center on another Cloud vendor, while providing you with some of the benefits available in AWS and Azure, may also require you to develop and maintain your own equivalent of CloudFormation templates for their environment. This overhead should be taken into account when calculating the cost of hosting.
In House Options
In comparison to Cloud options, you could host Atlassian Data Center products in your own existing data center, via VMs or similar mechanisms.
In this instance, the hosting bill can be reduced if you have a particularly advanced in-house solution or company-wide personal Cloud. However, maintenance of the RDBMS and other aspects of infrastructure is now your responsibility.
Unless your data center supports multiple zones, the lack of redundancy can be problematic. Also, for failover, you will need a data center in another geographic region. This in itself can be a large capital and an intensive task to complete.
Other technical considerations:
- Can the software be deployed via a scriptable, repeatable process, therefore allowing you to store infrastructure as code representation of your environment in source control? For example, using Terraform?
- Do you have team members available to build the VMs from scratch, including configuring Java settings and the ability to scale out these VMs automatically to meet traffic loads?
- If you don’t plan to autoscale, are you prepared to estimate traffic and load on the servers, and build out a system that can cope with the requirements, and be manually scaled if needed?
If the answer is yes to the above, and for internal business reasons or having done a cost comparison with the Cloud vendors verifying you can host for cheaper while achieving the same service, then hosting in-house may be for you.
If you do not have a mature set of data centers already in place, and your company’s long-term strategy does not foresee needing this and/or extending existing data centers to rival the functionality of current Cloud vendors, you may wish to consider other options.
Conclusion
As we have ascertained in this piece, the better option here will be the one driven by your internal constraints, budgets, user base, and team size.
The following table breaks down a feature comparison between the three deployment options for Atlassian Data Center products, presented in this article:
Deploying Atlassian Data Center to a Cloud-based platform versus an internal one does allow you to shift some of the cost from CapX to OpX expenditure. Added benefits include the failure, upgrade, and maintenance of hardware and physical systems is handled by the Cloud provider, thus freeing up your own internal resources.
In conclusion, if your organization lacks data centers capable of providing a scaled, redundant environment, then going with a Cloud vendor will likely be the cheaper, quicker, and easier option. This is especially true if you already use a Cloud vendor for other projects, thus are familiar with their services and the skill sets required to work with them.
