This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ncc-services-wg@ripe.net/
[ncc-services-wg] New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
- Previous message (by thread): [ncc-services-wg] New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
- Next message (by thread): [ncc-services-wg] New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Fri Jun 25 15:52:51 CEST 2021
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3732979CF967B306.asc Type: application/pgp-keys Size: 11589 bytes Desc: OpenPGP public key URL: </ripe/mail/archives/ncc-services-wg/attachments/20210625/d520e2ce/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/ncc-services-wg/attachments/20210625/d520e2ce/attachment.sig>
- Previous message (by thread): [ncc-services-wg] New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
- Next message (by thread): [ncc-services-wg] New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]