RIPE NCC and the Cloud: Let’s Start Again

The community’s reaction to our cloud proposal at RIPE 82 was stronger than we expected. We think it’s worth re-starting this discussion, and the first step is to check that we’ve heard you correctly.

Ahead of RIPE 82, we shared our plans to move elements of our core services to the cloud – starting with the RIPE Database and our RPKI Repositories. Judging from some of your reactions at the meeting and on the mailing list (start of thread), we can see now that it’s worth taking a step back and starting this conversation again, a little more consciously and deliberately this time around.

When it comes to sharing our plans and asking for feedback, it can be hard to strike the right balance and know if we are sharing too little or too much. 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’. Suggestions can often be too granular or overlook many of the nuances we have to deal with as a company; it’s much better to hear issues and requirements as opposed to solutions.

Of course, it’s when we think everything is ticking along as normal that we get a reaction we hadn’t expected. This has happened a few times in the past and is bound to happen again. When this happens, it’s important to pause and review some of our assumptions – and to check in again with you as a community.

Before we get into the specifics, it is also worth recognising that one of the overarching reactions from the community was probably surprise. While we started talking about our cloud strategy in 2019, to a certain extent this was either in abstract terms, or it concerned smaller non-core services. In retrospect, it’s hardly surprising that publishing a detailed proposal without signalling that this was in the works would provoke a reaction. This might also have something to do with the way we presented our plans – as a fait accompli – because if that’s what it really was, then the idea of asking for community feedback is disingenuous.

With all that in mind, let’s go over some of the concerns we’ve heard so far, which we’ve grouped into categories. We may have missed or mischaracterised some points. If that’s the case, let us know on the RIPE NCC Services Working Group mailing list.

1. Loss of Autonomy / Independence / Responsibility

A number of different aspects relate to a meta concern: by hitching our wagon to a third-party, the RIPE NCC will be exposed to the whims or actions of an organisation that, however well-intentioned, isn’t accountable to the RIPE community in the same way that we are.

Part of this includes vendor lock-in or high switching costs. In an age of centralisation and walled gardens, there is a risk that we might come to rely on the vendor-specific features offered by certain cloud providers. Over the longer term, our ability to reverse course or even to be independent could atrophy, especially if we move away from open standards and the relevant skills are lost internally. Like the proverbial boiled frog, this could be something that happens incrementally rather than with a singular event.

Another point is that many cloud providers (Amazon and Google in the first instance) are themselves RIPE NCC members and thus reliant on the services we provide. They are also in competition with one another and will not like the suggestion that they should depend on a rival for their operations (such as Google relying on RPKI elements running on AWS).

It is also not inconceivable that the infrastructure of a cloud provider could collapse. We therefore saw strong concerns about the idea of hosting core services with a cloud provider in their entirety – especially if there was not a robust alternative or failback option. As we had noted ourselves, further complicating this is the potential for circular ‘bootstrapping’ problems – if a cloud provider hosting the RIPE Database goes down, not only would the database be inaccessible, but that cloud provider might be unable to recover if doing so depends on accessing the very database it was hosting.

It was also asked whether this would come with a diffusion of responsibility. If we break something tomorrow, you can contact us directly or raise the issue on a mailing list and get a response (“the buck stops here”). But what happens if the problem and the solution rest entirely with a third party? Will our website direct you to Cloud Provider A, B or C according to the service that is affected, while RIPE NCC staff respond with a collective shrug?

2. Legal or Political Risks

Since 2020, we have been dealing with the impact of EU sanctions. Given some of the political fault lines running through our service region, an obvious concern is whether linking our technical infrastructure to third parties (particularly those based in the US) could widen our exposure to these kinds of risks or affect our ability to provide services to all members on an equal basis. The system of international relations is not a stable one, and so we also need to think about scenarios that today might not seem very likely.

Privacy and data protection are also important, not just GDPR-related aspects and the degree to which non-EU providers are compliant, but also in terms of protecting the business data of our members more generally. Also relevant is the risk that we could fall within the reach of governments outside our region. For example, while our current plans include deploying services with AWS Ireland, it is hard to rule out that a subpoena in the United States might compel Amazon to share personal or business data about our members.

3. ‘Buy Local’

Large American cloud providers offer mature services at a global scale. However, there are alternative providers within our service region that could offer similar services. Why not ‘give back’ and instead offer our business to these paying members? This argument might be political as much as a technical one, to the extent that it represents a preference that we not rely on a US company for our infrastructure (though this does not mean it is invalid).

4. Underlying Principles

It’s probably fair to say that many of us at the RIPE NCC take a certain pride in the fact that we build our own network at RIPE Meetings (especially when we encounter bad WiFi at other events). But suppose we found a company that could provide a meeting network for us, with better performance at a lower cost, and spare us the logistical headache of shipping our gear to different meeting venues. Would we approach this on a purely ‘rational’ cost basis?

When looking at the feedback we received so far, some objections seem related to this notion. For example, some people referenced the wider trend of Internet consolidation and asked that the RIPE NCC not contribute to this. This is more speculative than the other categories above, and we should be careful to note we are not implying that concerns based on these kinds of underlying principles are without merit or should be discarded. On the other hand, it is worth noting other feedback that the outsourcing of services is a general trend in the industry and we should embrace it.

Concerns Do Not Apply to All Services Equally

What also seems clear is that all the above really depends on what service we’re talking about. These concerns are much more relevant when it comes to the ‘core’ RIPE NCC services that operators depend on (with RPKI and the RIPE Database sitting squarely in this category). On the other hand, our project that is publishing RIPE Atlas measurements via Google’s BigQuery platform does not seem like such a risk, especially as RIPE Atlas continues to run as normal and so this is ‘opt-in’ for people who want to take advantage of the benefits this platform can offer.

Next Steps

Members of the RIPE community ought to have relatively high expectations in terms of how this discussion should go. As the RIPE NCC, we are committed to meeting those expectations and seeing if we can find a rough consensus with the community.

Finally, starting with a review of concerns in general terms, we want to step back from discussing the technical specifics of our earlier proposal for the RIPE Database and the RPKI Repositories. This work is on hold while we review your feedback and wait to see if additional points arise from this discussion. Rest assured that you will be able to comment on any updated plans before anything significant happens with either of these services.

With the publication of this article, we will start a thread on the RIPE NCC Services Working Group (ncc-services-wg@ripe.net) and the discussion can continue there. To make sure that we haven’t missed anything important or unfairly characterised your point, please speak up. Of course, we will be listening on all channels and you can always comment below.

We don’t want to be too prescriptive regarding next steps, as this will ultimately depend on how the discussion goes from here. However, we are currently looking at scheduling an Open House session for those of you who would like to discuss this in more detail.