Alpha service offering description and rationale

[choldgraf]

Description

We have a draft of our "alpha-level" services for review and feedback from the team!

Instructions

Please provide any feedback, comments, or suggested changes that come to mind. We can also use this issue for discussion around this draft.

Alpha-level service offerings draft: https://docs.google.com/document/d/1FNiDyKNDoe_TgU2WxuNZ5CayYD56tlNJpImQsAIGOmg/edit

Goal of this draft

Our goal is to have something that is reasonable and somewhat sustainable. We want something that is good enough to iterate on, not something that is perfect. We expect that the nature of this service will need to change, and even include a few areas we know we are missing in the draft.

We welcome any suggested edits, and especially any major things that you think we are missing.

Value / benefit

Our goal with this process is to gather input from the most important stakeholders and collaborators of 2i2c, to ensure that many voices and perspectives go into the design of this service.

Tasks to complete

• Confirm Steering Council's general agreement on the planned alpha and the rationale for it.
• Share with 2i2c team and CS&S for feedback or major changes
• Convert to Google Doc so that others are more comfortable reviewing and commenting
• [Proposal] Cloud cost estimation for JupyterHubs on shared clusters #277
• Share with CS&S broader community, CZI, and a representative sample of key communities we serve (CarbonPlan, Toronto, Eric VD)
• Create a more concrete cloud cost estimation plan for the alpha service
• Waiting on feedback from others
• Iterate as needed on the content

Updates

• 2021-10-11: Initial draft sent to 2i2c team
• 2021-10-15: After a few rounds of feedback, we have converted the proposal into this Google Doc to share with other stakeholders.
• 2021-11-01: Proposal semi-finalized and prepped with CS&S letterhead
• 2021-11-10: Waiting for a response from Keith
• 2021-11-10: sent to a few communities for feedback

[colliand]

Thanks @choldgraf for bringing this document together. I like the new "what are we missing" section a lot.

[damianavila]

Made a first pass on the draft and currently digesting the proposal...
I will come back later with some thoughts 😉

[choldgraf]

2021-10-15

After a few rounds of feedback, we have converted the proposal into this Google Doc to share with other stakeholders.

cc @damianavila who wanted to provide comments and suggested a google doc would be easier :-)

[yuvipanda]

I've left a couple of comments - primarily around how often we revise these. But otherwise, this is great! I do want us to actually onboard someone into paying us through this model before we publish it - I don't know how much of this will survive contact with someone paying us, and would love to find out!

[choldgraf]

I've take another pass at the document and incorporated some feedback to streamline things a bit. I have a few questions for the engineering team, and would love feedback on these questions:

1. Can we give a quick rationale / decision guide for when a community would want a dedicated Kubernetes cluster? Do they need this when they have their own cloud credits? When they have institutional barriers that force them to do this?
2. Can somebody provide a specific proposal for how we handle cloud cost pass-through for the hubs that are on shared infrastructure? @yuvipanda you seemed to have some good ideas in there but I wasn't sure specifically what you were proposing, could you take a stab at turning those ideas into a 1-2 sentence proposal?

Draft link here: https://docs.google.com/document/d/1R3ovKIcHCpE7A77ovrXntRc2XkmK8nnZgVhUMWDT4vQ/edit?usp=sharing

[choldgraf]

Update: docs prepared for CS&S

I've updated the documents for CS&S letterhead and sent them for a review from the CS&S team, I hope that we can send this to some communities to try out the invoicing process soon!

• alpha service description
• alpha service rationale; old URL

[damianavila]

@choldgraf, the second document gives you access denied with a 2i2c account, maybe some permissions should be fixed?

[choldgraf]

Update: waiting for response from Keith

We are waiting for a response from Keith at CS&S before moving forward, he should be able to look at it soon.

[choldgraf]

Update: Minor revisions from Keith

Keith said that the 2-pager in general looked good to him, so we are pretty much ready to send this to some communities. I'm waiting for some quick suggested language from CS&S to make sure it's clear in the 2-pager language that the service is within 2i2c's mission to perform, and when that is in I will do the following:

• send to 3-4 of the communities we have been working with
• ask them for feedback
• ask them to pick one of the service offerings
• work out an invoicing plan with the communities we've been working with previously

[choldgraf]

Updates on procedure from CS&S

I heard back from CS&S again with some more feedback and suggested next steps. Here's roughly the plan:

We need two things from communities in order to be able to invoice them:

1. An email acknowledgement of the service tier that they want. We can send them the 2-pager, ask them to tell us which they want, and this is enough. We need to cc fsp@codeforsociety.org on the email so that they can keep track of this.
2. An email acknowledgement once the services have been provided. For example, at the end of the month we can send them an email that has template language like "This email is to confirm that services XYZ have been provided as planned". And they respond with "yes I agree"

When we have those two things, we can send an invoice. We might need something more complex like a contract at some point as well (or for certain communities) but this is the starting point.

[choldgraf]

Alpha service docs sent to two communities and a few stakeholders

I've sent our two-pager to the Grenoble Hub and the PaleoHackWeek Hub teams, to see if they can pick a specific hub service / price point, and to ask for any feedback they might have. Once we go through a round of conversation and/or feedback with them, we can pick another group of people to send this information to.

I have also sent these documents to Dario/Carly at CZI, Josh Greenberg at Sloan, and Kay Thaney at IOI for feedback.

[colliand]

I reviewed the documents and think things here look excellent. There is one aspect where I think we need to make some improvements.

A bullet point [☁️ Cloud costs (based on usage)] in the alpa service description document indicates that 2i2c will estimate cloud costs in the shared infrastructure scenario. The reader is invited to click a hyperlink to learn more about pricing information. That link target doesn't provide a clear answer to the question: How will cloud costs be estimated by 2i2c in the shared infrastructure scenario?

The beginnings of an answer to that question does appear in the "Estimating cloud costs" section of the rationale document. The discussion there suggests that 2i2c will be able to estimate cloud usage costs based on RAM usage per month by users associated to the customer. The text there also says that 2i2c will refine this approach during the alpha so it's not so clear.

A prospective customer who wants to buy hub service using shared infrastructure will want to know how cloud costs are calculated. Can we do either of these things?

1. define a RAM-based algorithm that specifies how cloud usage costs will be calculated.
2. define guardrails around cloud costs? Something like: 2i2c will charge between [$100, $2500] per month for education hubs?
3. define a fixed cloud cost during the alpha? Something like shared cloud costs will be $500 per month?

[choldgraf]

@colliand did you follow the conversation in #277 ? We talked through some of these things there and I'd love to hear your thoughts. I agree that the current setup is under-specified - in an earlier draft we actually had a much more explicit equation in there, but decided on something more intentionally vague because we don't yet know the right way to do this

[colliand]

No. I apologize for not tracking the thread in #277 as well as I should have. I recall seeing the first few entries but didn't appreciate how this got baked into the customer-facing alpha docs.

I'm anticipating customers asking questions just like Chris imagined in that thread: How much will cloud usage cost? How will that cost be calculated? Beneath those are more difficult questions: Am I being charged too much? Am I paying more than the other customers using that infrastructure?

2i2c's commitment to being fair and as transparent as we can be, combined with our values/mission, and nonprofit status are vital here. I will review the alpha docs on this point soon.

[colliand]

I shared the alpha service offering and pricing rationale documents with Ian Allison. He will likely share more feedback soon. I like the quick reaction he shared:

I'll read through those. For the first one, in the first paragraph. I would extend the last point to say why that right to replicate is important. Basically we want to put the science first and protect it from financial, organizational, political etc. obstacles.
At first glance the document looks very good

I think this is smart advice. That said, I rejected my first few attempts at adding another sentence to amplify the right-to-replicate.

[choldgraf]

I'm closing this one as we have been running with the alpha service description for a while now, and are focusing our efforts on other issues to structure work.