As enterprises journey from on-premises to the Cloud, carefully vetting apps is an essential part of the process. When an app is installed in an Atlassian Cloud platform, mission-critical data could be transferred to third-party servers. The Atlassian Marketplace contains over 5,700 apps, provided by Partners based all over the globe, so it’s important to consider where and how data is potentially stored.
This article was inspired by discussions with customers moving to the Cloud, who often advocate for apps that don’t transmit any data outside of Atlassian products at all – a concept we call ‘no-egress’ apps. When apps exclusively process data on the Atlassian platform, eliminating the need for data egress to other servers, it greatly simplifies data protection.
Atlassian’s Forge platform forms the foundation for delivering ‘no-egress’ apps. Forge’s architecture is designed to sandbox apps and transparently lists all external servers involved in the app’s functionality. Offering storage and computing features, Forge has evolved enormously since it was launched five years ago.
We want to use this article to highlight how customers and app vendors can benefit from apps hosted solely on Forge and illustrate how Seibert adopts this principle in developing successful Jira Cloud products like Templating.app and Agile Hive.
Why should customers care about app data egress?
The power of the Atlassian ecosystem lies in its extensibility. Apps allow customers to assemble a unique solution perfectly tailored to them, and because of this, enterprises quickly end up with many apps on their Cloud instance. Ten Cloud apps could mean the data is potentially stored on ten servers in multiple countries with different legislations.
Company policies and legal regulations often require customers to examine vendors they entrust with their user data. During the vetting process, a Marketplace Partner may receive a request to fill out a questionnaire like CAIQ-Lite. Atlassian helps customers make well-informed decisions about app data handling through the Privacy and Security Tab for Cloud apps on the Atlassian Marketplace. Still, that source of information needs to be reviewed manually and regularly to be aware of changes.
We find our customers appreciate when the app they are evaluating completely runs on Forge and has no egress permissions. Backups are handled by Atlassian. Compute resources are scaled automatically. Having the confidence that Atlassian, as maintainer of the host product, also takes care of the complete app infrastructure has often made customer requests about the app’s architecture obsolete.
How do you identify ‘no-egress’ Forge apps on the Atlassian Marketplace?
Helping customers make the right app choices is part of every Cloud migration. Seibert is a leading Solution Partner in the Atlassian ecosystem, so app data egress becomes more critical in discussions with large enterprises and regulated industries. As noted previously, the Privacy and Security Tab can provide useful information about how apps handle data. However, the provided data is often tedious to analyze and can be outdated.
Inspired by discussions at Team ‘24, we decided to create http://forge-apps.com . This free website offers a unique tool for app assessment. It lists all apps on the Atlassian Marketplace, clearly differentiating between egress and non-egress apps. It also provides detailed information about the URLs an app might connect to. The list is completely data-driven, ensuring it’s always up-to-date.
We invite all partners and customers to utilize http://forge-apps.com to decide which apps to use. In the first days after its launch, the website had around 1,000 visitors from 30 different countries, which indicates the level of interest in how Atlassian Marketplace apps work under the hood.
Skip the shortcut: Why we reduce our reliance on external services
Before implementing a new feature, our development teams often have to decide whether it makes sense to connect an external service to an existing Forge app. For example, choosing an SQL database over the existing Forge Storage API is sometimes tempting. We are confident that there are use cases where we could ship a feature faster using egress. Still, we have decided to avoid egress in many of our newer projects.
This is not only because it makes apps a better fit for enterprise customers. Using external services to take a shortcut during development usually comes at a cost. Making regular backups then becomes an app vendor’s task again. The same goes for auto-scaling and tenant isolation, which are mostly handled by Atlassian as long as developers rely on Forge. You can easily end up in a situation where the saved time is not worth the technical debt that comes with it.
When Forge was announced in 2019 at Atlas Camp in Vienna, we launched Templating.app and decided to avoid egress at any cost. This product started as an experiment and quickly became one of the most successful solutions for Issue & Project templates on the Atlassian Marketplace. It is maintained by a small team that would not have been able to ship that many features if they had to take care of all the infrastructure burden Forge handles. Features like data residency have been automatically implemented by Atlassian, and the app will automatically support new data realms as soon as they are available.
In fact, Templating.app won one enterprise customer with over 5,000 users in the first months because the company loved that we do not involve external servers. This anecdote recently led to Seibert’s decision to rely solely on Forge infrastructure with our Agile Hive app. As a product supporting enterprises on SAFe, it especially targets large instances, showing how much we bet on Forge’s reliability.
How to move toward no-egress app development
While we bet that apps running on Atlassian infrastructure will be the future gold standard, not all apps are a perfect fit for Forge today. However, we are shifting our tooling away from our own servers where possible and are happy to share our learnings so far.
First, try to align your product plans with Atlassian’s Forge roadmap. When we prioritize our backlog items, we review the Forge roadmap for developers. What’s not possible today might be easily achievable in a few months. Support for Jira Automations in Templating has been a frequently requested feature by customers, but we were blocked by the 25-second invocation limit. Then Atlassian’s AI Hackathon | Codegeist Unleashed came around, and the Async Events API underwent improvements. Instead of implementing the Automation support for Issue Templates as fast as possible on external servers, we offered a no-egress solution a few months later. Perhaps a quick look at the Forge changelog could reveal a clever shift in your product backlog, too.
Additionally, we have had great experiences working on new Forge features together with Atlassian. Have you looked at the Early-Access-Programs (EAPs) frequently announced on the Atlassian Developer Community? The programs offer the chance to actively communicate the technical requirements you have, which would allow you to offer a no-egress app experience. Besides the EAPs, the Developer Community is also a great place to exchange tips & tricks with other developers to get the most out of the given capabilities.
There are still many apps on the Atlassian Marketplace for which a no-egress implementation isn’t a viable option yet. For those cases, we recommend having a plan for migrating to Forge when the time comes. When you do use an external server, choose Forge Remotes. This new feature allows you to connect to a remote backend from Forge, in a secure way. As the Remotes are centrally configured from the manifest.yml file of your app, it is easy to get an overview of where your application needs the help of external services. Looking at the manifest files can be the starting point for your plan to migrate back to no-egress when the time comes.
Is your app still on Connect?
In that case, it always involves communication with a remote server. For our existing apps whose rich feature sets are not yet a perfect fit for Forge, we are using the Connect-on-Forge API to make our way to Atlassian’s infrastructure. This turned out to be especially useful for our Confluence Cloud intranet solution Mantra, as we can use Forge’s complex queries on the custom entity store, which would not have been possible on Connect alone. Atlassian’s announcement of the new AI-driven Enterprise knowledge product Rovo and its extensibility via Rovo Agents show that partners can expect future extensibility features to be Forge-only, too.
Conclusion
We believe that ‘no-egress’ apps on Atlassian Forge will become increasingly prominent in the ecosystem. Today, they have already eased the transition to the Cloud for many enterprise customers. We invite customers and partners to reach out to us for a more detailed exchange of experiences and to explore http://forge-apps.com as a starting point for finding the best ‘no-egress’ apps for your needs.