[ncc-services-wg] RIPE NCC and the Cloud: Draft Principles, Requirements and Strategy Framework

The desire to use upgraded and modern technologies is strong among
engineers, but it is essential to temper it with a sense of
responsibility towards our users. RIPE's affairs are of critical
importance for matters ranging from economics to national security for a
broad range of countries and people, and this necessitates a careful,
conservative approach to technology. RIPE lacks the privilege to
experiment with unproven technologies or take a radical approach to its
infrastructure. This can be balanced with an open-minded eye towards the
state-of-the-art, and indeed it must in order to meet some requirements
imposed on RIPE's infrastructure (such as security and performance), but
a great deal of care must be taken in this process, with matters of
international security, economics, and sovereignty in mind. It is a
matter of our pride as engineers that we consider these issues carefully
and incorporate the broader context into our decision-making on
technology. With that in mind, the choice to use GCP and AWS seems
misjudged.

There are several principles laid out in this document which are not
upheld with this choice. The most obvious is the preference for local
providers.  Amazon[0] and Google[1] are multi-nationals, but are
US-first, hiring for AWS and GCP mainly (or entirely, in Amazon's case)
outside of RIPE service areas.  If Cloud is the future, the talent
necessary to maintain that future is being centralized outside of RIPE's
areas of interest, and by relying on them rather than investing in that
talent locally, it betrays the sovereign interests of its members.
Furthermore, these providers have a record of legal problems which stem
from a US-first mindset and an unwillingness to obey laws in RIPE
service regions, particularly the EU, with a historical record of GDPR
violations, leading to steep fines[2][3]. These links cover only two
fines, and there have been several more.

[0]: https://www.amazon.jobs/en/search?base_query=%23SecOps&loc_query=&latitude=&longitude=&loc_group_id=&invalid_location=false&country=&city=&region=&county=
[1]: https://paste.sr.ht/~sircmpwn/15aa14e9009a7ca99ba2511354c84a878a7f7894
[2]: https://edpb.europa.eu/news/national-news/2020/swedish-data-protection-authority-imposes-administrative-fine-google_en
[3]: https://www.bbc.com/news/business-58024116

Additionally, the concerns regarding vendor-lock in and single-provider
dependence in conflict with the prioritization for engineering time. The
requirements necessary to establish a robust provider-neutral cloud
deployment are comparable in effort to the requirements of a private
cloud, and such a deployment would impose frustrating limitations such
as limiting feature-use to the mutually-compatible subset of both
clouds, or making the infrastructure more difficult to audit.

And this is my recommendation: a private cloud. Tools like OpenStack and
Kubernetes are widely available industry standards which allows for many
of the same improvements RIPE seeks to establish with this initiative,
but rates much better within the principles laid out here, as well as in
terms of RIPE's stewardship over international interests. A private
cloud also makes more sense in economic terms, a matter which is not to
be taken lightly by the thoughtful engineer, as the move from private
infrastructure to a commercial cloud would convert assets (the
infrastructure) into liabilities (the cloud servers) by extracting a
rent from RIPE, which, furthermore, is a rent paid to the US. Is the
return to the economies in RIPE's service regions in greater than the
expense of paying a tax to the United States? Even without considering
the export of cloud expertise, or the difficult-to-measure effects on
the soft power of RIPE's constituent nations, the answer is likely "no".