DPS Pricing gotchas - workflows storage cost

[r_weber]

Hello,

I'm engaged in DPS migration projects and wanted to share an interesting thing I just learned. Wanted to ask what the community thinks of that:

Immediately when someone creates a workflow it is accounted towards your bill. Once the workflow is created it will consume "workflow-hours" (billed at $13c/hour). This is regardless if the workflow is enabled or executing, just the fact that we store a few kB will cost per hour! Executing the workflow will incur additional cost, depending on the appengine functions you are calling in your workflow ($0.1c/invocation).

I think that pricing model is a bit developer-unfriendly as you have no chance to develop without additional cost. Imagine you start experimenting with workflows and are not aware that every created workflow already costs and you just let them sit there. Every WF costs $3.12 per day or $1,139 per year....just for the storage.

IMO only enabled workflows should cost, if the trigger is disabled they should not incur costs.

Additionally, workflows seem to consume DDUs (if you are not on DPS yet) - my workflows all stopped when we ran out of DDUs.

Whats your thought?

[tijust1]

@r_weber Thanks for sharing this, I am on DPS and didnt know that workflow creation itself consume cost. I am agree with your point like if WF is not getting trigger then what is the pint to consume code.

Thanks,

Tijust

[Julius_Loman]

@r_weber I totally agree with you. Workflows should not be subject for billing when not in use especially when this is just definition. Maybe there are some cloud services provisioned internally for each workflow? such approach turns Dynatrace into a tool people will be cautious to use since just touching it will cost you $. Maybe @martin_moschitz can explain what the reasons are.

Anyway DPS is way more complicated, especially when it gets to the sales side and doing estimations and forecast for new customers. 

[martin_moschitz]

Adding in @Horst who works in the Automation solution and can provide more background on the workflow pricing reasoning.

@Julius_Loman would be great if you could share your observations on the complexity with myself, Brian Howard and Ryan Covell. I assume you are referring to the estimations and forecasting in terms of ingest and query costs? Compared to the offerings we also already had with SKU based licenses, there should not be much of a difference in estimations and forecasting (Full Stack, Infra, Real User Monitoring, etc.), in fact, it even got slightly easier, as your forecasting per SKU does not need to be 100% accurate anymore, as in DPS you can re-use unused quantity for any other Platform functionality.

@r_weber could you please share with myself and gerald.binder@dynatrace.com your observations on the workflows stopping once you ran out of DDU via email or slack so we can look into this? (environment, user, workflows in question). Thanks

[Horst]

Q: "Additionally, workflows seem to consume DDUs (if you're not on DPS yet)"
A: Answer: No, workflows never consume DDUs directly. Depending on what you're doing with a workflow, it might trigger or directly call Dynatrace functionality that consumes DDUs. 

Q: "My workflows all stopped when we ran out of DDUs."
A: When you're not on DPS the creation/ingestion of events consumes DDUs. After the depletion of DDUs, no more events will be ingested (unless overages are activated). The workflow is waiting for an event that can’t be generated. The workflow can still be started manually, via schedule, or via API.

[Horst]

Q: Provide some background on the reasoning behind workflow pricing.
A: Workflows can be used for high-value critical remediation scenarios only triggered on occasion, but also for essential cost-saving scenarios with high execution frequencies (where charging per execution would result in exploding costs quickly). DPS workflow-hours is a predictable “flat-rate” base cost model for workflows.

Q: IMO only enabled workflows should cost, if the trigger is disabled they should not incur costs.

A: We don't differentiate between enabled or disabled workflow. Any workflow that exists can be executed at any time, either manually or via API, even if a starting condition like a trigger or schedule is defined. 

Q: Every WF costs $3.12 per day or $1,139 per year.
A: Yes, this is true for list prices. Due to discounts, the average street price will most likely be considerably lower. Furthermore, cost savings by reducing manual effort with automations should outweigh the workflow costs by far.

[36Krazyfists]

A: We don't differentiate between enabled or disabled workflow. Any workflow that exists can be executed at any time, either manually or via API, even if a starting condition like a trigger or schedule is defined. 

---

I think there's a relatively simple fix for this.  The issue the op is talking about is that this pricing model discourages development, and I totally agree.  However, I also understand that you have to charge for disabled workflows due to the fact that they can still be executed by other workflows and the API. 

So, why not have another setting for a workflow called "In Development".  This could be the default setting for a workflow (that way when a user creates a brand new workflow they don't have to remember to set this and thus accidentally start incurring charges despite the fact that it probably isn't being used yet, as stated in the op's original problem statement here). 

You could make it so that "In Development" workflows cannot be executed or ran other than from the web GUI for testing purposes.  Or, even better, to keep it simple, have the Run button be greyed out when the workflow has "In Development" mode turned on and, when a user hovers over the Run button to see why it's greyed out, you could have a tooltip that informs them that they need to turn off the "In Development" setting to run their workflow for testing.  You can then have a pop-up occur when a user saves a workflow informing them about the "In Development" toggle and the implications it has on licensing and the ability to run it (for example, if it's currently toggled on, inform them that they will not be able to Run this execution until this setting is toggled off, but that they will not occur any licensing costs while it is on.  Conversely, if the setting is currently off when they save the workflow, the pop-up could warn them that, even though the workflow may be disabled, they will still incur charges unless they turn the "In Development" setting on). 

You could also set it so that it could not be toggled from "In Development" to "Disabled" or "Enabled" from the API to prevent users from abusing this setting by using other automation worflows to turn this mode on/off to get around your billing.  Just configure it so that the "In Development" mode can only be turned off/on from the Workflows App web GUI.

This would solve the originally stated issue of letting people develop and "play around" with Workflows (which is what you want for a new product, I would think) without companies having to worry about incurring unnecessary costs for workflows that may never be used and it would still allow Dynatrace to keep this billing model that doesn't charge for each execution of a workflow (which I appreciate because, as you stated, that could stack up real fast).