Sharing Some Context On Our New Pipelines Step Sizes

[#1]

Hi all,

Since releasing our new Pipelines Runtime we've received a huge amount of positive feedback, widespread adoption, and also a range of questions relating to some of the more low-level details of how the new runtime works and what the plans are for it over the next few months.

One specific question that has been raised a few times is relating to IP Allow Listing and our 1/2x step sizes. In particular, people wanting to understand the reasoning behind restricting the `atlassian-ip-ranges` capability to 4/8x step sizes. 

In light of these questions, I'd like to share some context around the decisions so everyone can understand the thinking.

---

Fundamentally, the decision to restrict the `atlassian-ip-ranges` to 4x/8x steps comes down to a function of "cost" & "customer fairness" (for lack of a better word).

You may/may-not be aware that over the last few years, cloud infrastructure vendors have changed the way they charge for services, and one area in particular that has impacted is network ingress/egress. To put it bluntly, the cost per MB of traffic via a static-IP has grown exponentially over the last few years, to the point that >50% of the cost of running Pipelines as a service was being consumed by the network traffic via those static IP addresses alone.

Where this gets more complicated is the fact that only a tiny minority of customers actually leverage IP Allow-Listing, so essentially a huge portion of the cost of running the service was being spread across every single customer, but the benefit that cost was paying for was only being gained by a very small minority (<10%) - something we believe is not fair from a customers point of view.

Given the rapidly rising cost of providing static IP's as standard, we were left with effectively two options:

1. Keep static IP's as a standard feature for all builds (noting that competitor services do not offer static IP's at all, let alone for all builds), and implementing a non-trivial cost increase for all build sizes to cover the cost of the static IP's.
2. Restricting static IP addresses to larger step sizes, allowing us to more feasibly absorb the increased cost of providing them.

Removing static IP's for 1/2x steps allows us to continue offering those step-sizes at the price-point they are currently being offered at, the alternative would have been a pretty significant price increase, which we obviously wanted to avoid.

4/8x steps are, by nature, much more heavily utilised by customers at the more "mature" end of the DevOps spectrum, and we are expecting there to be a much higher overlap between customers implementing 4/8x steps, and customers using IP allow-listing, reducing the imbalance of value being provided to customers who are/aren't using that feature.

A few notes to end on:

• We did consider the option of offering some kind of "1/2x premium" which would include the ability to run those steps with static IP's for an incrementally higher cost.

  • However, once we ran the numbers on what those steps would have to be priced at in order to cover the significantly higher network costs, it didn't make sense to offer that option at all.

  • The pricing that would be required for those steps to be commercially sustainable would have put them within a stone-throw of the price of a 4x step anyway, making the whole offering redundant.

• The floating IP model being moved to for our 1/2x steps is the same model already used by all other Tier 1 SCM + CI/CD providers for all of their step sizes.

  • Even after this change, we will still be the only service in our space that provide any way to implement static IP's for builds without having to spin up your own runners.

  • All other equivalent providers operate exclusively off dynamic IP ranges for their SaaS tier CI/CD services.

  • We are very aware of the importance of this functionality from a security & compliance perspective, and we have put in significant effort to continue to make this available to customers quickly and easily, without requiring them to do things like spin up dedicated runners.