Hey Community,
I am Mike from the Atlassian Data Center product team.
Today, we are making an announcement about ending support service for AWS Quickstarts and Azure deployment templates in the coming months and keep investing in using Helm Charts to deploy Data Center products (Jira Software, Jira Service Management, Confluence, Bitbucket, and Crowd) on AWS and Azure in a Kubernetes cluster. Please follow and read more details from the article link below.
Cheers
Mike Ni
Hi @MikeNi,
CC: @tpettersen
Please note that this change is now blocking us from performing Data Center approval performance tests. We were actively engaged and participated in several discussion when Atlassian was migrating from AWS Cloudformation templates to Kubernetes, Terraform and Helm, and during those discussions we were promised several times that the process would not differ in terms of Developer Experience from the AWS Cloudformation templates.
CC: @jmort and @danielwester as they were also in these meetings.
Looking at the current documentation of starting a Confluence instance for Data Center performance testing, and more specifically the prerequisites it is clear that Atlassian has not hold up that promise. I am now required to install software for running the Data Center performance testing tooling on my local machine that I do not need personally.
We were also promised that we did not need any knowledge of Kubernetes, Helm or Terraform as the new process would be similar to pushing the button on the AWS Cloudformation templates. Yet the documentation now reads:
A basic understanding of these tools and their associated concepts is also advisable.
We will pause our collaboration with the Data Center approval program until Atlassian can provide a solution that does not have any local prerequisites.
If Atlassian decides to withdraw Data Center approval for our apps, so be it. I rather hold Atlassian accountable and explain the situation to our mutual customers than having to deal with an unpredictable and untrustworthy partner.
I echo @remie’s concerns. This increases the friction for developers to do this work. It is one thing debugging cloudformation errors and another k8s and helm. The one thing this program doesn’t need is more barriers to entry and disruption of existing ways of working
This smells of a sub-text of the beginning of the end of DC.
The program requires testing of API endpoints and anything that performs DB operations, as I recall. So, we could remove the functionality that performs DB operations. Not sure what we can do about the API testing.
I’m thinking a cheaper, degraded DC version that is approved and a full functionality one that isn’t.
We tried to follow the Kubernetes documentation to setup the JIRA DC Environment but failed to do so and decided to still use the AWS Formation Template to do this years DC Approval. We just hope that it will improve within the year and didn’t bother yet to give feedback as it seems to be a first version and give atlassian time to improve it.
After reading remie post, I decided to give atlassian a bit of insight of our experience with our kubernetes tour.
We have no prio knowledge about kubernetes / helms, and we are using AWS only in the context of DC Approval and the current documentation very much feels like a documentation for IT Admins that are interested to setup a DC Instance for their company.
This is however not the case for all plugin developers. I myself don’t care how to setup a DC instance for thousands of users and possible choices on the way. I just want to provide atlassian the required test results and every placeholder or unclear step in this documentation may produce an error I’m not able to interpret without a lot of time invest as I can’t say how it should work.
The AWS Cloudformation stack was quite simple to setup, without any placeholders and manual steps. (only a few Default values needed to be changed in the forms)
This was exactly the feedback @jmort, @danielwester and myself gave during the discussions and we were assured by the DC team that they would provide a similar experience.
The switch from AWS Cloudformation to Kubernetes/Helm was not driven by Atlassian Marketplace Partner community request. After a few years we all got the hang of it and we’re able to run the program at acceptable effort/cost.
It was solely driven by the fact that someone at the Atlassian Bamboo team looked at the AWS Cloudformation templates, had a personal preference against them, and chose to use Kubernetes instead, just because shiny & new.
It was retrofitted to “make sense” by adding some random bullshit claim that customers were demanding it, even though the documentation now reads:
This project is designed for Atlassian vendors to run DC App Performance Toolkit and is not officially supported.
This is also why I’m pushing back and holding Atlassian accountable, because they do not get to just have some random engineer (that is probably not even working in the same team anymore) upend the entire Atlassian Marketplace partner community and have us spent hours on bullshit without getting called out on it.
Thank you @remie for bringing this up. We’re going to go with the CloudFormation templates as long as we can. After that we might just as well just build our own cluster manually - it will probably be cheaper and less expensive.
More and more it’s getting increasingly more expensive to develop apps for Atlassian and the feedback is falling on deaf ears. Fast forward 3 years and it wouldn’t surprise me if we see the same type of thing in Forge…
Hey @danielwester @remie @daviddrawio @m.herrmann @jmort,
I wanted to express my gratitude for the valuable feedback you have provided us with. Your input is crucial in helping us improve our DC App certification program. Please rest assured that I will be sharing your concerns with the program so that we can work together to find a feasible solution that addresses your needs and helps you become more familiar with our Terraform tool. Our goal is to make the deployment process using Terraform as easy, if not easier than using AWS Quickstart.
I would also like to take this opportunity to assure you that our decision to end support for AWS Quickstart templates is driven solely by our desire to better invest in container and Kubernetes deployment, which is increasingly becoming a preferred choice for our DC customers.
Once again, thank you for your feedback and please don’t hesitate to reach out if you have any further questions or concerns.
Cheers
Mike
hi @m.herrmann,
Jira DC with Terraform for DCAPT approval process is not released yet, so that’s totally expected to use CloudFormation templates for now.
With a new release, you would be able to deploy Jira DC with a “large enterprise-scale” dataset for DCAPT approval process with a one-liner command. No need to ssh to the nodes, run scripts, wait, etc. Also, no need to learn kubernetes / helms for context of DC Approval.
So the user-experience for DC Approval process would be - one-liner command to deploy entirely suitable for DC approval process environment which has a needed dataset from the box (restored from snapshots).
Thank you,
Oleksandr
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.