RIPE NCC Cloud Strategy Framework

NOTE: This is updated by RIPE NCC Cloud Strategy Framework (v2)

This August, we shared a draft version of our cloud strategy here on RIPE Labs. Following that, we saw further discussion of the topic on the RIPE NCC Services Working Group mailing list and we also held two interim WG sessions - on 28 July and 6 September - where the community was invited to give input on our draft framework. After receiving positive feedback there, we made some final edits to produce a version that was approved by our Executive Board at its meeting in late September.

Here, we share with you this final version of our cloud strategy framework. As you'll see, it outlines a set of underlying principles and requirements and describes a framework that we will use as a starting point when developing any cloud implementations going forwards. We think this will provide a good starting point for any discussions on specific proposals for our services.

Content-wise, everything here is consistent with our previous draft, only the text has been cut down to make things more concise and straightforward. It's also worth noting that there is one part still outstanding, which is to agree on the criticality of our various services with the community. This is in the works and we aim to share something soon.

Cloud Principles and Requirements

Principles

Shaping this strategy are a series of basic principles regarding how we work with the RIPE community:

• We solicit input on all services that are critical for the operation of the global Internet, or that directly affect the operations of our members or the RIPE community.
• We have full authority and responsibility for the design, deployment, and operation of our services.
• We must remain neutral and operate our services for the benefit of all members.
• The integrity of our services and data must be maintained in the face of geopolitical, regulatory, and economic threats.
• Open standards should be used; where open standards are not viable, we should prefer industry standards over proprietary interfaces.

Requirements

Taking the principles above, and using input from the RIPE community, we have identified the following set of requirements for our use of cloud providers:

• Ensure resilience, accessibility, availability and low latency for our services.
• Minimise vendor lock-in.
• Avoid dependence on any single cloud provider.
• Our engineers can innovate and improve the quality of our services.
• Comply with applicable laws and regulations.
• Ensure the security of our services.
• Prefer providers in our service region.

It is important to recognise that there are tensions between some of our principles and requirements, and trade-offs will be necessary. It is not worth choosing low-quality solutions simply because they are the best fit for this framework – we will apply sanity and engage with the community if something is not working.

Cloud Strategy Framework

Our cloud strategy framework uses the principles and requirements outlined above to set boundaries and identify where we need to be strict and where we can be more relaxed. This provides clarity about how we will approach the use of cloud providers and supports future discussions with the community when we look at moving specific elements to the cloud.

Requirements According to Strictness

We have defined three levels of strictness for each of our requirements (Strict, Heightened and Standard). What these levels mean for each requirement is outlined in the table below. Some requirements, such as ‘Comply with applicable laws and regulations’, apply equally across all levels and so lack any differentiation (the final four rows on the table).

* Availability measured per quarter (99,999%: 1m 18s, 99,9%: 2h 11m 29s, 99%: 21h 54m 52s)

** The addition of 'or containers' here is the only small addition made to this table since we last shared this on RIPE Labs

Level of Strictness According to Criticality

The table above describes how we interpret our requirements on a scale from Strict to Standard. To determine where a specific service should sit within this framework, we need to determine its criticality. To do this, we start by defining services as falling into one of two categories:

• Global Internet Services: required for the Internet to function properly (e.g. RPKI)
• RIPE NCC-specific Services: critical for the RIPE NCC, but will not have a noticeable impact on the wider Internet if offline for a short period (e.g. LIR Portal)

Services within each of these categories can have differing levels of criticality (in terms of their importance either to the operation of the Internet or the RIPE NCC). We have identified three levels of criticality:

• High: outages have a direct operational impact
• Medium: outages have an operational impact within a few hours
• Low: we can afford to be more forgiving regarding outages

The table below indicates how we identify the level of strictness that should apply to specific services, according to their criticality. Example services are included to make this more concrete. Note that we intend to work with the community to define the criticality of specific services and so these examples could change.