We’re on a mission to make Forge the platform for building more sophisticated apps on the Atlassian platform, and we need your insights to get there.
We are currently conducting a survey to identify the compute, storage, AI, and real-time services utilised on AWS, GCP or other cloud infrastructure providers for developing Connect apps. This initiative aims to gain insights into the cloud computing primitives that should be prioritised for future development on the Forge platform.
Partners are welcome to share their survey responses for one or more apps. The survey should take around 15 minutes to complete. We will be reaching out to respondents to get more detailed information about your specific use cases.
could you clarify how you interpret “critical” to our Connect app? Is it considered critical for you if we’d need to rearchitect the app to work without the service? If we have a monolithic NodeJS app running in ElasticBeanstalk/EC2/ECS for example, you could obviously do without and rearchitect it completely to micro-services and to work with Forge functions - would you consider this critical? We might not need it from a scale perspective, but it still would be extremely painful from a transitional point of view?
Hi @JamesDumay ,
Thanks for the survey.
What surprised me is that the most straightforward hosting solution for porting connect apps was missing: Simple container hosting (e.g. like Heroku), together with a managed database. This is the default hosting setup for ACE, and would allow vendors a simpler migration path, while running the apps in Atlassian infrastructure.
Thanks for sharing this. We’ve been having thoughts along those lines too and has been a driver for publishing this survey. We certainly don’t get those for zero effort on our side, so I want to be sure before committing to spikes/roadmap for new services.
Data we have received in the last day has been super validating, so thank you to you and other partners for taking the time.
For our app it’s more that we would like to use a more sophisticated runtime, storage and search solution but we don’t in order to stay 100% within Forge. But because it’s sometimes missing, we consider to add remote resources. We were able to avoid this so far but we fear that we might have to go that step in the near future if Forge doesn’t improve in some aspects regarding extremely low runtime limitations of functions and the lack of a quick search within the storage. Developing really starts to feel more like a hacky workaround instead of state-of-the-art cloud development.
The survey doesn’t cover this aspect at all: we would like to use some resources but don’t because we want to be completely in Forge.
another thing which might simplify Forge is the following: There are many threads here about install problems of the forge cli etc.
Atlassian could move to deployment through git push, similar to how Heroku does it. This makes some operations simpler, and lets developers use different SSH keys for e.g. development and production.
Thank you for your invaluable input in helping us shape the future of Forge.We would like your help once again to understand your specific requirements around data migration as we plan and build the migration experience from connect or remote storage to Forge.
We are conducting a survey to collect information on the data migration process, including storage types, data sizes, and potential challenges. This data will help us prioritise the development of features and tools for a smooth transition.
The survey is concise and should take about 10-15 minutes to complete.