New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
Dear colleagues, The community’s reaction to our cloud proposal was stronger than expected. In this article we look at some of the concerns we have seen so far, to make sure we heard you correctly: https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud... Please share any comments on this mailing list so the discussion can continue. Kind regards, Alun Davies RIPE Labs Editor RIPE NCC
hi alun, perhaps a partial cause of the fluff up was that the project was revealed rather late in its process. my eye is drawn to There can also be a concern that if we approach a community of problem-solvers too early or in the wrong way, we risk inviting ‘solutioneering’. my experience is that you can have the solutioneering early or late; your choice; but you will have it. but if you choose late, you can find yourself in a state of siege on something to which you may have over-committed. the fun thing about a community of engineers is that there will be solutioneering. maybe it is a feature or maybe it is a bug. but it is a process which is pretty much bound to happen. and it will take a month or two and probably converge on a few local minima; or maybe it's maxima depending on your point of view :). my personal experience is that, if i reveal early and am open, i usually learn a lot. at my age and stage, i am not afraid of appearing st00pid; everybody already knows i am. there are some folk in the community who have a wealth of experience in diverse circumstances. and their advice is free! :) randy
Hi, On Mon, Jun 21, 2021 at 11:13:33AM +0200, Alun Davies wrote:
https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud...
Is it just me or is this a somewhat reactive article that still does not cover the "what does the NCC want to achieve with 'going to the cloud'" bit? Just because it's en vogue doesn't mean it's the right thing to do. (And given that the glorious example of outsourcing the NCC ticket system has *still* not led to an acceptable user experience...) Gert Doering -- LIR contact -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear colleagues, Thank you everyone who has commented - this is useful and we hope it continues. Below is a summary of the discussion so far. We have formed a team internally that is focused on making sure we have this discussion properly. We are tracking your concerns and plan to share a detailed response with the working group in mid-July. Here is what we’re hearing (in no particular order): - Requests for more clarity about the "why" - Risk that relevant technical skills may be lost internally - Concerns related to security (e.g. cloud providers may present more of a target for state-sponsored actors) - Some privacy aspects might be overlooked (e.g. while services like the RIPE Database are public, metadata or log files could be a concern) - Compliance: make sure the RIPE NCC doesn't violate any regulations - The discussion should focus on requirements rather than implementation... on the other hand, you're going to get solutioneering whether you like it or not - accept it! It is helpful to see whether people agree or disagree with any of the points being raised. We are also interested to hear from anyone who hasn't spoken up yet, especially if you have real-world experience to share. Kind regards Felipe Victolla Silveira Chief Operations Officer RIPE NCC Here's a link to the article on RIPE Labs again: https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud... <https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud-lets-start-again/>
On 21 Jun 2021, at 11:13, Alun Davies <adavies@ripe.net> wrote:
Dear colleagues,
The community’s reaction to our cloud proposal was stronger than expected. In this article we look at some of the concerns we have seen so far, to make sure we heard you correctly:
https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud...
Please share any comments on this mailing list so the discussion can continue.
Kind regards,
Alun Davies RIPE Labs Editor RIPE NCC
felipe,
Here is what we’re hearing (in no particular order):
- Requests for more clarity about the "why" - Risk that relevant technical skills may be lost internally - Concerns related to security (e.g. cloud providers may present more of a target for state-sponsored actors) - Some privacy aspects might be overlooked (e.g. while services like the RIPE Database are public, metadata or log files could be a concern) - Compliance: make sure the RIPE NCC doesn't violate any regulations - The discussion should focus on requirements rather than implementation... on the other hand, you're going to get solutioneering whether you like it or not - accept it!
let me try again, more simply disclose and discuss early in your process. the community is talkative but we are your friends and peers. randy
On 25 Jun 2021, at 13:52, Randy Bush wrote:
… disclose and discuss early in your process. the community is talkative but we are your friends and peers.
Thank you, we re-learned that. We have re-started the process and we will not proceed until we are sure we heard what the ‘talkative community of friends and peers’ has to say. Daniel
Dear Felipe, On 25/06/2021 11.43, Felipe Victolla Silveira wrote:
Here is what we’re hearing (in no particular order):
- Requests for more clarity about the "why" - Risk that relevant technical skills may be lost internally - Concerns related to security (e.g. cloud providers may present more of a target for state-sponsored actors) - Some privacy aspects might be overlooked (e.g. while services like the RIPE Database are public, metadata or log files could be a concern) - Compliance: make sure the RIPE NCC doesn't violate any regulations - The discussion should focus on requirements rather than implementation... on the other hand, you're going to get solutioneering whether you like it or not - accept it!
Thank you for this summary. I think it covers most of it, but several folks have mentioned avoiding vendor lock-in. I think that is a reasonable requirement. Now for the solutioneering! 😆 I believe the best approach to avoiding lock-in includes actively using multiple vendors all the time, although not necessarily with the same amount of resources. Such an approach will automatically ensure that any proprietary functionality at any one cloud provider has equivalent functionality at other providers used. It will also ensure that failures at one cloud provider can be addressed by scaling up resources as needed at the other providers, rather than by invoking a failover or other emergency measures. Cheers, -- Shane
--- Sent from a handheld device.
On 25. Jun 2021, at 15:54, Shane Kerr <shane@time-travellers.org> wrote:
…. avoiding vendor lock-in. I think that is a reasonable requirement.
How could we forget to mention that? Probably overlooked it because it because it is soooooo obvious. 😉 Daniel
avoiding vendor lock-in. I think that is a reasonable requirement. How could we forget to mention that? Probably overlooked it because it because it is soooooo obvious.
to be sure to get some solutioneering in <g>, i do not see how one really gets to this place (well described by shane as being able to easily move between vendors) if one buys services above metal as a service (aka MASS). a side benefit of buying MAAS, is that this brings in emea vendors, not just aws, azure, or goog. randy
On 2021-06-25, at 09:51:47, Randy Bush wrote: [ref: avoiding vendor lock-in]
i do not see how one really gets to this place [...] if one buys services above metal as a service (aka MASS).
"Shim the APIs", e.g. Terraform or similar, and use lowest common denominator in terms of refined higher-level services.
a side benefit of buying MAAS, is that this brings in emea vendors, not just aws, azure, or goog.
There are more cloud APIs than those three in EMEA. /M
i do not see how one really gets to this place [...] if one buys services above metal as a service (aka MASS).
"Shim the APIs", e.g. Terraform or similar, and use lowest common denominator in terms of refined higher-level services.
and what shim do we use on OVH et alia?
a side benefit of buying MAAS, is that this brings in emea vendors, not just aws, azure, or goog. There are more cloud APIs than those three in EMEA.
two things o those three are not based in emea. see others' postings on gdpr and other issues with american providers o there seem to be extremely few emea based providers above MAAS; which was my point randy
On 2021-06-25, at 14:58:34, Randy Bush wrote:
i do not see how one really gets to this place [...] if one buys services above metal as a service (aka MASS).
"Shim the APIs", e.g. Terraform or similar, and use lowest common denominator in terms of refined higher-level services.
and what shim do we use on OVH et alia?
https://www.ovhcloud.com/en/public-cloud/ => https://registry.terraform.io/providers/terraform-provider-openstack/opensta...
a side benefit of buying MAAS, is that this brings in emea vendors, not just aws, azure, or goog. There are more cloud APIs than those three in EMEA.
two things
o those three are not based in emea. see others' postings on gdpr and other issues with american providers
o there seem to be extremely few emea based providers above MAAS; which was my point
There are actually many, only a small sample is represented on https://www.openstack.org/marketplace/public-clouds/f/a/Compute%20Service%20... The list of additional providers for terraform is long. /M
On 26/06/2021 12:14, Martin Millnert wrote:
On 2021-06-25, at 14:58:34, Randy Bush wrote:
i do not see how one really gets to this place [...] if one buys services above metal as a service (aka MASS).
"Shim the APIs", e.g. Terraform or similar, and use lowest common denominator in terms of refined higher-level services.
and what shim do we use on OVH et alia?
https://www.ovhcloud.com/en/public-cloud/ => https://registry.terraform.io/providers/terraform-provider-openstack/opensta...
a side benefit of buying MAAS, is that this brings in emea vendors, not just aws, azure, or goog.
It humors me to see companies going for MAAS as well as cloud on-prem which is more or less exactly what you have now just someone else owns the metal :-) -Hank
It humors me to see companies going for MAAS as well as cloud on-prem which is more or less exactly what you have now just someone else owns the metal :-)
it's about horizontal scale. they can provision a LOT quite quickly and diversely. as with everything, there can be downsides, of course. randy
On 26/06/2021 21:46, Randy Bush wrote:
It humors me to see companies going for MAAS as well as cloud on-prem which is more or less exactly what you have now just someone else owns the metal :-)
it's about horizontal scale. they can provision a LOT quite quickly and diversely. as with everything, there can be downsides, of course.
A researcher or R&D might need a lot of metal quickly for a day/week. That is what cloud is geared for. For day to day IT, where you know what you need with no big surprises - cloud is the latest fad. -Hank
randy
For day to day IT, where you know what you need with no big surprises
i think we live in different worlds randy
On Sun, 27 Jun 2021 at 18:26, Randy Bush <randy@psg.com> wrote:
For day to day IT, where you know what you need with no big surprises
i think we live in different worlds
+1. If you don't sell it to our customers, and the regulator, law or customer contract doesn't require it, don't do it. Doing your first server is like 1MEUR YRC, you can probably capitalise that investment with a more core business focused target. If you are going to do compute, do it right and sell it. The days when acceptable compute is tower pc in your broom closet lundia shelf and maintained on 'if someone is awake and wants to do it' basis are not really acceptable but often used as cost comparison towards cloud. -- ++ytti
Hi On Mon, 28 Jun 2021 at 08:31, Saku Ytti <saku@ytti.fi> wrote:
On Sun, 27 Jun 2021 at 18:26, Randy Bush <randy@psg.com> wrote:
For day to day IT, where you know what you need with no big surprises
i think we live in different worlds
+1. If you don't sell it to our customers, and the regulator, law or customer contract doesn't require it, don't do it. Doing your first server is like 1MEUR YRC, you can probably capitalise that investment with a more core business focused target. If you are going to do compute, do it right and sell it.
Developing, maintaining and operating the RIPE Database is part of the core business of the RIPE NCC and has been since the start of the company. They are a member based, service organisation, not a sales company.
The days when acceptable compute is tower pc in your broom closet lundia shelf and maintained on 'if someone is awake and wants to do it' basis are not really acceptable but often used as cost comparison towards cloud.
The RIPE NCC has been operating the RIPE Database as a very resilient and high performance, professional service for many decades. cheers denis co-chair DB-WG
-- ++ytti
On Mon, 28 Jun 2021 at 15:11, denis walker <ripedenis@gmail.com> wrote:
The RIPE NCC has been operating the RIPE Database as a very resilient and high performance, professional service for many decades.
It is also inefficient de-facto monopoly with massive mission creep. My statement was more generic about companies who have to be competitive. -- ++ytti
Saku Ytti wrote on 28/06/2021 13:13:
It is also inefficient de-facto monopoly with massive mission creep.
you're assuming that the RIPE NCC was instituted solely as a registry: that was never its sole function - it was established as the operating company for the RIPE community, which is defined in ripe-001. If anything, branching out from the terms of ripe-001 to include an address resource registry is mission creep. Nick
On 28 Jun 2021, at 14:13, Saku Ytti wrote:
… It is also inefficient de-facto monopoly with massive mission creep. …
Saku, You sneered. Here is my response in your terms: The RIPE NCC is a pretty bottom-up de-facto monopoly. Its mission creep is steered by RIPE. In fact this very working group is the major venue for steering the mission creep. Anyone can participate here and we will never know they are a dog. Let’s follow the money: the mission creep is funded by the *membership* of the RIPE NCC *association*. Sure, the vast majority of the membership probably are paying members because of the de-facto monopoly. Yet they have full control of the mission creep because they control the association. They elect the board. The board hires and fires the CEO and controls the budget. The membership even votes on how they are charged. This is a pretty good way to organise a de-facto monopoly and manage its mission creep. If you think it is massive and worth more than a sneer, see above for ways to engage. Daniel Full disclosure: I am one of the founders of RIPE and one of the designers of the RIPE NCC association. I have been working for the RIPE NCC for almost 30 years; the first 7 years as the director (CEO) and since then as Chief Scientist. Before that I was one of the people wo proposed a plan to avoid the de-facto monopolies in this area to the US National Science Foundation; they did not buy the plan and they were probably right.
On Sun, 4 Jul 2021 at 08:11, Daniel Karrenberg <dfk@ripe.net> wrote:
The RIPE NCC is a pretty bottom-up de-facto monopoly. Its mission creep is steered by RIPE. In fact this very working group is the major venue for steering the mission creep. Anyone can participate here and we will never know they are a dog.
My intention was not to sneer, I just wanted to point it out to elaborate why RIPE is better equipped to operate its own compute and why that may not translate to generic cases. While in relative to product procured it is a significant cost, in absolute terms to the bottom line it is quite an immaterial cost. It would be very work intensive to try to change this, with no personal benefit whatsoever, and significant personal cost. There are strong status quo biases at play, where people justify what we have is right because it is what we have, which would support equally well any type of alternative RIR setup we could imagine. If we could shop around for our resources from any RIR or if number management and extra curriculum would be separated, I'm sure we can all agree that the wide market would pay the least it can to receive the number service sufficient to its goals and that true costs of number management are significant lower that RIR costs. This is not RIPE specific by any means. -- ++ytti
On 4 Jul 2021, at 7:29, Saku Ytti wrote:
On Sun, 4 Jul 2021 at 08:11, Daniel Karrenberg <dfk@ripe.net> wrote:
My intention was not to sneer, …
I am happy you did not *intend* to sneer. Maybe it even did not sound like that to everyone. ;-) You certainly hit one of *my* sensitivities because to me you sounded like countless others who take cheap shots at the ‘de-facto monopoly’ and its ‘mission creep’ while they ignore the bottom-up way the RIPE NCC is organised. Typically their only suggestion on how to improve is to call for ’competition’. Well, ‘competition’ and ‘monopoly’ are not really compatible by definition. With your explanation this ‘sneer’ turns into the strangest way ever of saying that a comfortably funded ‘de-facto monopoly’ with sensible amounts of ‘mission creep’ is more resilient and stable than a company that is focussed on shareholder value in the next quarter or a bare bones registry operation. And I agree with you; which will not really surprise anyone. It is essential to keep both the registry service and the ‘mission creep’ acceptable to both the community and the paying membership. Such acceptance comes from a combination of trust and control. That was the essence of what I was trying to say. Now let’s stop this intermission and get back to the matter at hand, ’RIPE NCC and the Cloud - Let’s Start Again’. We have noticed some damage to community trust and we are working hard to repair that. Gaining trust is always harder than loosing it. Stay tuned for another summary of the concerns and requirements that we heard so far and suggestions on how to move forward. Everyone, please let us know if we missed something important. It does not hurt to say something positive about how we all deal with this either. ;-) ;-) :-) Daniel
Dear colleagues, Thank you for the discussion so far. This is what we summarised earlier: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2021-June/003422.htm... <https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2021-June/003422.html> Since then we have seen these major additional points: • Avoiding vendor lock-in (thanks Shane for pointing this out) • Use of metal as a service (MAAS) If you see something important missing from our summary, please speak up soon as it will help with our work. We will use this summary to produce a first draft of community requirements and, based on those, a list of principles we would like to agree on, reasons and requirements for deploying RIPE NCC services in the cloud, and a high-level draft strategy. We will share this in a RIPE Labs article around mid-July. We are going to liaise with the chairs to ask this working group to organise an interim meeting to discuss this draft in the coming weeks. We aim to finalise the draft strategy in September in time for submission of the Draft RIPE NCC Activity Plan & Budget 2022 to the Executive Board. We realise that working on this while many people are taking vacation is not ideal, but we will take as much time as is needed to do this properly. Once we see rough consensus emerging on the draft strategy we will revise our deployment plans for the RPKI repository and the RIPE Database. We will share our draft plans with the Routing WG and the RIPE Database WG at an early stage. Thanks again for your contributions - I believe we are moving towards a positive outcome. Kind regards, Felipe
On 25 Jun 2021, at 11:43, Felipe Victolla Silveira <fvictolla@ripe.net> wrote:
Dear colleagues,
Thank you everyone who has commented - this is useful and we hope it continues. Below is a summary of the discussion so far.
We have formed a team internally that is focused on making sure we have this discussion properly. We are tracking your concerns and plan to share a detailed response with the working group in mid-July.
Here is what we’re hearing (in no particular order):
- Requests for more clarity about the "why" - Risk that relevant technical skills may be lost internally - Concerns related to security (e.g. cloud providers may present more of a target for state-sponsored actors) - Some privacy aspects might be overlooked (e.g. while services like the RIPE Database are public, metadata or log files could be a concern) - Compliance: make sure the RIPE NCC doesn't violate any regulations - The discussion should focus on requirements rather than implementation... on the other hand, you're going to get solutioneering whether you like it or not - accept it!
It is helpful to see whether people agree or disagree with any of the points being raised. We are also interested to hear from anyone who hasn't spoken up yet, especially if you have real-world experience to share.
Kind regards
Felipe Victolla Silveira Chief Operations Officer RIPE NCC
Here's a link to the article on RIPE Labs again: https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud... <https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud-lets-start-again/>
On 21 Jun 2021, at 11:13, Alun Davies <adavies@ripe.net <mailto:adavies@ripe.net>> wrote:
Dear colleagues,
The community’s reaction to our cloud proposal was stronger than expected. In this article we look at some of the concerns we have seen so far, to make sure we heard you correctly:
https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud... <https://labs.ripe.net/author/felipe_victolla_silveira/ripe-ncc-and-the-cloud-lets-start-again/>
Please share any comments on this mailing list so the discussion can continue.
Kind regards,
Alun Davies RIPE Labs Editor RIPE NCC
participants (11)
-
Alun Davies -
Daniel Karrenberg -
denis walker -
Felipe Victolla Silveira -
Gert Doering -
Hank Nussbacher -
Martin Millnert -
Nick Hilliard -
Randy Bush -
Saku Ytti -
Shane Kerr