Shared hosting costs. How to split infrastructure costs among clients

Discussions - Public
1

Task to log time: SE-4213.
Brainstorming. Private discussion since it’s about company finances.

We want to know how to split the cost of the shared infrastructure and how to present this information in proposals to clients.
For instance, setting up a Kubernetes cluster has a cost, but if the cluster is used by 5 clients, each client could pay a fraction. But if it’s just 1 client, should it pay the whole price, or also a small fraction? What if later there are 2 clients? Or 20? Or 100? Should we tell the client that the prices are dynamic?

SE-4213 is about adding something to the documentation but we’d need to know first what we want to add.
Our previous experience has been:

  • In SE-3810 there were discussions about setting a Kubernetes cluster, and what would be the setup cost, and the monthly cost that would be paid by the client for maintenance.
  • any others? If we have a few examples, the documentation could link to them. I think this topic may need to be decided on a case-by-case basis, and adding examples would be helpful
  • let’s focus on hosting. But outside hosting, I know that some development costs are split among clients. For instance, when upgrading XBlocks to make them work on a newer Open edX version, the cost of upgrading each block is split between the users of that block (between the users that agree to pay for the upgrade, at least!)

In the end this is a financial decision about how much OpenCraft wants to charge to be competitive. But we should at least know what numbers to include in discoveries. Otherwise we can just mention that it needs to be discussed case by case.

2

Then let’s start the discussion.

As mentioned on the ticket and discussed several times, this is a really hard thing to decide. In my opinion, it is not fair to charge one (first) client for all the costs for setting up a new shared infrastructure component, though OpenCraft can’t pay for the decision of a client either.

I thought a lot about this problem when we had to work on SE-3810 and I have often think about that since then. In the case of shared infra, we have (mainly) two scenarios:

  • Adding a new component for (at least) one client / replacing an existing component that we are not planning to replace, or
  • Replacing an existing component that we would replace anyway (like Redis)

At the end of the day, it results in additional maintenance for us and costs for the client. The main problem is not the maintenance for us, but the costs for the client, right? Paying an imaginary fraction based on assumptions could easily lead to loss of profit for OpenCraft, or unfair charging for clients.

I think we tried to solve these two problems at once last time. How about if we solve the two scenarios separately?

Replacing an existing component that we would replace anyway

In this scenario, the client wants to replace something in the infrastructure that bothers us as well, and we would replace it anyway.

OpenCraft and the client share the costs in a reasonable way. As a result, the client is happy as its costs are not skyrocketing, and OpenCraft doesn’t have to pay for everything.

For example, we know we want to replace RabbitMQ (in fact we are in the middle of the task), and the client wants to have Redis either for its instance. In this case, we could say that the client and OpenCraft share the costs (at a rate that is good for both parties). Why? Because OpenCraft would do that anyway.

Obviously, if we want to involve Kubernetes as well, that’s a different story as it is a new component that has no “direct” replacement. – I hope you understand what I mean by that.

Adding a new component for (at least) one client / replacing an existing component that we are not planning to replace

In this scenario, the client wants to replace (or add) something in the infrastructure that is not planned by us.

We could reach out to existing clients to see who is interested in the replacement/addition of the given component. If other clients are interested too, they share the initial costs. For the monthly costs, we could charge based on the resource type they wanted to add/replace. [1] Otherwise, if it is beneficial for OpenCraft the cost ratio could be discussed between OpenCraft and the client, else the first client pays the initial costs.

[1] For example, in the case of Kubernetes, we could charge based on the node pool or similar.

cc: @gabriel @antoviaque @daniel

1 Like
3

From my perspective and given my very limited technical knowledge, what you’re suggesting @gabor makes a lot of sense to me.

We can simply do a technical/admin discovery on a per-case basis and determine the outcome together.

1 Like
4

I’ll include @tikr’s comment from the SE-4213 task to make this thread complete:

I don’t really have a lot to add regarding SE-3810. The main thing that comes to mind is that even though the client definitely had deep pockets (i.e., increased maintenance costs were not a concern to them per se ), they didn’t necessarily like the idea (ref) of being the only party paying for a new setup that would eventually be used by other clients as well. I think that’s understandable, and most other clients would probably share that stance. So for bigger projects we’ll likely have to stick to the approach of trying to find a way to split setup costs between multiple clients (unless we are in a position, sustainability-wise, to only charge one client and absorb the rest of the costs ourselves).

In general, my thoughts are:

  • I’m not sure if it’s possible to come up with a one-size-fits-all approach here. There’s a variety of aspects to consider, especially when it comes to the initial setup of new infrastructure components. For example:
    • How big of a project is it to set up the new infrastructure component(s)? (small/medium/large)
    • Did one or more clients explicitly ask for the new component(s)?
    • Will the new component(s) mainly benefit a specific group of clients, or will they ultimately benefit everyone who is hosting an Open edX instance with us?
    • How much budget are individual clients able and willing to contribute to the project?
    • Where do we currently stand with respect to sustainability? Are we able and willing to absorb any setup costs that we can’t offload to one or more clients?
  • It’s worth distinguishing between setup costs and ongoing maintenance. For the latter, if we’re planning to implement some infrastructure changes that will ultimately reach all of our clients – such as creating a shared Redis cluster for OCIM – we might just need to figure out how to incorporate the added monthly costs into our default pricing for hosting and maintenance. (Instead of picking out a specific subset of our clients and increasing their charges for hosting and maintenance.)
1 Like
5

I also agree with what you suggested @gabor - that seem like a fair and balanced approach.

Nobody ever likes to bear the burden alone, but when a client is the only one to want now a feature/setup that might be useful to someone else later, they are paying for the acceleration of the work. This is a very similar deal as the rest of the work we offer, or even open source in general: you give what you produce to everyone, and in a way it isn’t “fair” for the one who spends the time – but at the end, by doing that work you gain the ability to include the features you want and when you want, plus what you eventually get back from other similar contributions from others in the community.

3 Likes
6

Alright, it sounds like the conclusion here is to

based on @gabor’s suggestions.

As for where to document this info, two options come to mind:

  • If we’re OK with making it public, we could consider adding it to the Estimates section of the handbook.
  • If we’d prefer to keep it private, perhaps it could go in the Accounting section of our private docs?

@antoviaque @gabriel @gabor Let me know what you’d prefer? :slight_smile:

CC @daniel

1 Like
7

I think this should be public, unless I’m missing something.

1 Like
8

@tikr I have no preference where it goes. I’d say that if other parts of the billing/price calculation is public, this should be public as well, otherwise private.

To be honest, since the pricing is public on the website, I cannot see the point why it shouldn’t be public too. Also, it may be worth adding a link pointing to a dedicated page on the website where we explain it to customers, so they can choose what they need better. Though that may be an overkill.

9

Yup, transparency on this kind of topic is important - especially since it’s about the principle, rather than specific amounts charged to specific people. I would add it to the handbook, and probably also make the current thread public, since the discussion here doesn’t end up having anything specific or secret to specific clients?

1 Like
10

@gabriel @gabor @antoviaque Thanks for the input, I created public#386 for adding relevant info from this thread to the handbook.

OK, I removed explicit mentions of client names from this thread and made it public.

4 Likes
11

Just a quick update that public#386 has been merged, so the results of this conversation are now available in the handbook :tada:

6 Likes