Re: [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=®ion=&county= [1]: https://paste.sr.ht/~sircmpwn/15aa14e9009a7ca99ba2511354c84a878a7f7894 [2]: https://edpb.europa.eu/news/national-news/2020/swedish-data-protection-autho... [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".
drew, i like your general analysis of the situation. but i see private cloud as unnecessarily complex and expensive, especially if you say openstack. a sailboat is a hole in the water in which you throw money; openstack is a hole in your organization in which you throw engineers, and expensive ones. from 10,000m, i see two general cloud strategies provide a highly scalable front deployment for services which are actually based in-house. this can be done with MAAS so as not to be locked in to a cloud vendor's shiny toys. and yes, k8s is a common pattern here; though maybe a bit much for the ncc's seemingly rather simple (from the outside:) use cases. move totally to a single cloud provider taking advantage of the great tools and features they provide to make development and scaling easy. of course, as there are no standards in this space, you are locked in to the cloud provider. and, as has been pointed out, likely a non- emea one. i believe the discussion is moving from the latter to the former. at least i hope so. also, it might help how we think about it if we framed it in terms of the technical attributes we want, scale, resilience, performance, ... as opposed to moving to the cloud. and maybe i see it as more 'extending' rather than 'moving'. visions of slimy pseudopods :) randy
On Wed Sep 1, 2021 at 4:35 PM CEST, Randy Bush wrote:
i like your general analysis of the situation. but i see private cloud as unnecessarily complex and expensive, especially if you say openstack. a sailboat is a hole in the water in which you throw money; openstack is a hole in your organization in which you throw engineers, and expensive ones.
For what it's worth, I actually dislike OpenStack and Kubernetes, and think any deployment of it should be done with a healthy amount of distaste for either such that the bare minimum is deployed and under carefully laid rails as to avoid letting it all get out of hand. These are easy to build rube goldberg machines out of, but a conservative deployment can still gain some value from it.
also, it might help how we think about it if we framed it in terms of the technical attributes we want, scale, resilience, performance, ... as opposed to moving to the cloud. and maybe i see it as more 'extending' rather than 'moving'. visions of slimy pseudopods :)
All engineering metaphors are best explained in grotesque terms :)
maybe i see it as more 'extending' rather than 'moving'. visions of slimy pseudopods :) All engineering metaphors are best explained in grotesque terms :)
and i get no credit for the k8s pun? sigh. :) yes, we use k8s in one of my $dayjobs. it is far more architecturally organized/structured than, e.g., openstack. as with many very powerful tools, you can make as complex a mess as you want; and it takes mature skills not to do so. but one can deploy on maas, which is really nice in this case. i know this is a violation of mailing list rules; but i do not understand the ncc's needs in sufficient depth to have a valid opinion if k8s is an appropriate tool here. randy
participants (2)
-
Drew DeVault -
Randy Bush