Consider this scenario. A customer installs your app. Your app is super popular within the company and tons of employees within the company use your app throughout the day. Each time a user interacts with your app, your app consumes a certain amount of storage and compute time. Atlassian provides some “free” storage and compute each calendar month and when you exceed the free threshold, you get charged for what your app consumes. So if your app is really popular, you would potentially blow past the free tier in no time. This means that each time an employee uses your app, your costs for the month is ticking up. At the end of the month, you could end up in a situation where, for that customer, you incur more costs than you earn in revenue from the customer, simply because the customer used your app and you have no way to control it.
When Atlassian announced their pricing model change for Forge earlier this year, I didn’t really pay attention to it until today when I encountered a scenario in an app that I’m currently developing. You can read more about that issue here. The issue outlined in that post and a couple of the comments attached to it has caused me to consider a broader question. Why is Atlassian going to charge Forge app developers for storage and compute that is generated by the customer? Shouldn’t this be a cost that the customer incurs? When my app has exhausted the free tier threshold for the month, am I supposed to disable the app and put up a message “Sorry. You’ve exhausted all of my free tier storage and compute for this month. The app will be available again next month.” ? Obviously I can’t do that because it would be ridiculous. If a customer installs an app, the app will consume storage and/or compute if the customer uses the app. If the customer does not use the app, the app will not consume any storage and/or compute. I think this makes it pretty obvious that it is the customer who is ultimately consuming storage and using compute resources, via the app. Why then is Atlassian charging the app developer for the customer’s consumption? Doing this reduces the revenue app developers earn and puts the money right back into Atlassian’s hands. Maybe this was the plan all along?
totally understand where you are coming from. However this isn’t anything new – if you’re hosting with aws - you have the same issue. If you’re storing documents in s3 - you’ll get charged by how much you’re storing (granted - it’s not as large as Atlassians).
Some customers will be cause more costs than others - that’s just the nature of the beast.
In the end it’s going to be the market that decides how the Forge pricing will be passed on.
@danielwester With AWS, you as a vendor control how much storage or compute you give to a customer.
However with Forge, you are very challenged to do that, and it goes against the spirit of Forge.
So vendors are in a difficult situation. Given this pricing model, it is prudent for vendors to overcharge the average customer to have some “insurance” to pay customers who use a lot of resources. My thought is that this situation does not make the Atlassian app ecosystem attractive for most customers.
My counter to your S3 argument would be that I have full control over the data stored in S3. S3 has multiple storage classes and I can configure how my data is stored in S3 to minimize my costs. I don’t have that ability with Forge storage. No matter how frequently or infrequently my data at rest is accessed in Forge storage, I will get charged the same flat rate once I cross the free tier threshold. If a company has certain data retention policies that mandate that certain types of data in their company needs to be preserved for a certain period of time, why should I be responsible for footing the bill to store that data? As the amount of data grows each month, the cost to store it increases each month.
Although this is true, there is one big difference: I can choose to move my data away from AWS and use another provider. In addition, these providers offer me many types of alerting & controls to manage my spending.
I cannot move away from Forge without A) loosing the Runs on Atlassian badge and B) have my app surrounded by Atlassian fear mongering with warning models about data egress. Atlassian also still does not have a solution or policy for cost spikes or budget alerting in general.
My management’s comment on the new pricing model - “are they out of their mind???”
I realize that atlassian is not the only app platform vendor to go this way - e.g. snowflake uses the same model. Atlassian is likely going to argue that we have to factor this into the app pricing. As far as I can see if you app is really popular, you get punished twice - you lose the 0% revenue share bonus and you have to pay for platform usage. I can understand that atlassian would like to use either option (and of course we are fine with a revenue share), however both…
My main gripe with the usage based model is that it’s impossible to calculate this in advance. Luckily our app doesn’t really use any of these usage counters (apart from maybe app properties)
But the thing is - you’re the owner of your app and you chose Atlassian Forge as the hosting (even if Atlassian wants you to choose to forge that part).
Yes - I think Forge pricing is not good because of the commercial competition (it doesn’t have the same features as S3).
But I don’t think the answer is to have the customer pay for their own usage on a per basis.
Of course the customer should pay for their usage. It’s their data.
When you sign up for a Google account, Google gives you 15GB of free Google Drive storage. If you use the Google Doc app, you can store as many documents as you like in Google Drive until you hit your free tier storage limit. Once you hit your free tier limit, to continue saving docs to your Google Drive, you either have to delete existing docs (to free up space) or pay to upgrade to more storage. It would be crazy to expect Google to allow customers to store unlimited data in their Google Drive without charging for increased storage.
In Atlassian’s case, they’re asking us to provide unlimited data storage (at our expense) to all customers who use our app. For one customer, If you plot this on a graph over time, your revenue from that customer will be a flat line and your storage cost will continuously increase over time. Eventually you’ll get to the point where your storage costs exceed your revenue. How on earth does that make business sense?
IMHO the real problem here is the lack of dynamic/configurable egress: you have to set the price now for usage that you won’t see until later, and it’s not even easy to guesstimate the compute costs in Forge, so you probably want to be conservative and set a higher price, thus hurting the customer.
Had it been available, or at least on the horizon, you could set reasonable prices and enforce your own limits, if the customer wants to exceed those, they can provide their own e.g. S3 bucket and store whatever they want, wherever they want.
I think one way Atlassian can solve this is to provide customers a base amount of storage for each app install, just as Google gives everyone who signs up for a Google account a base amount of free storage. As customers use the app and it starts generating data, it counts against their base storage plan. This is going to be different for each app. Some apps may generate a lot of data, some apps may generate very little. As customers approach their free tier storage limit, Atlassian notifies them and provides them the option to upgrade to additional storage. The customer can then decide to upgrade or reduce their current consumption by deleting stuff. What I like about this approach is that it is between Atlassian and the customer and keeps us out of the picture. We don’t get charged for storage because the free storage tier is now assigned to the customer and it is up to the customer to decide whether or not they want to pay for additional storage.
You’ve definitely hit the nail on the head by highlighting the absurdity of pricing based on number of people in a company. This was fine back in the nineteen nineties but definitely does not make sense today.
Consider this scenario. You have a small customer (5 person company) who uses your diagramming app on Jira Datacenter. Over the years the customer has generated 20GB worth of diagrams. The customer hears that Atlassian is about to get rid of Datacenter apps so they decide to migrate to the cloud. They see that your app is available for Jira Cloud and it is certified as “Runs on Atlassian” so they go ahead and do the migration. After they migrate to the cloud, you, the Forge app developer, are now responsible for paying Atlassian to store the customer’s 20GB worth of diagramming data. To make matters worse, because the customer only has 5 people in their company, they’re using Jira Cloud (and your app) for free. Bonkers.
This topic has touched a nerve for me because I’m developing a diagramming app that runs on Forge and is certified as Runs on Atlassian. I have no control over how many diagrams a customer creates and what’s stored in those diagrams. If Atlassian sticks to their proposed pricing model, this app will eventually cost me money instead of make money. What am I supposed to do? Should I tell customers not to create diagrams? Just pay for my app each month but don’t use it because that’s the only way I’ll make any money.
We have quite large data volumes eg monthly 1.5M ‘records’ of up to 25MB+ each totalling ~200G every month (just one region) with one customer having over 500K ‘records’ summing to 50GB of data every month, blowing past all manner of Forge limits.
The Forge Storage quotas seem to exclude all storage variants for our case. We recently had a question from an Atlassian asking on behalf of a customer “when will we be 100% forge”. I could not really see that happening any time soon with things as they are, Forge is simply too limited (literally) and would likely be too expensive in any case.
About Capacity, we allocate linearly based on ‘user tiers’ (yes, the mapping tables are a pain). We allocated limits that work for at least 95%+ of customers but there are always edge cases and customers hitting those limits do need an out - we have out of band solutions for that as marketplace has no such features. Stopping due to ‘limits’ is awkward and does impact customer, but that’s just part of the solution, it can be viable if there is an out for more.
I think it’s reasonable for ‘usage’ driven by a customer to be ‘paid’ by the vendor as vendors can price in ‘some capacity cost’ into the per-user cost and hitting limits has to have consequences but those limits cannot be ‘hard’ customers must be able to simply buy more capacity (marketplace has no such features).
For now we will require Connect to enable us to make use of S3 direct and more, I hope that Forge+Connect remains viable even being deprecated, as there is simply no viable Forge functionality we could use right now or any time soon. Without the connect part, functionality would be severely degraded, I ‘hope’ Atlassian does not force our hand. Lots of hopium there.
Just curious, would app editions solve this problem for you?
I recognize I don’t know much about your app or its architecture, but it seems generally feasible that a diagramming app could programmatically enforce quotas on the number (or size) of drawings that it will store per customer. So you could add this to tiered pricing, thus giving even the small 5 person company the option to “upgrade” for larger storage.
Part of my curiosity is wondering if there are limitations in the Forge platform that would prevent that sort of storage tiering.
@AaronMorris1 I think that is where all of this is heading because its the only way for a Forge app developer to control costs. If your app is running on AWS, you can optimize your AWS architecture to reduce cost. You don’t have that option on Forge because the platform is pretty much fixed from the app developer point of view. This means that the only way the app developer can control cost is to control how much the customer uses the app. When you think about it, its just a matter of passing the quotas and limits that Atlassian has put on Forge apps on to the customer. As an app developer, I now have to track customer usage in my app and provide a way for customers to view their usage so they can adjust their usage as they approach their limit. It sort of sucks but it’s really the only option if you don’t want to end up losing money.