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/[email protected]/
[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] That's So Meta (was Re: New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Patrik Fältström
paf at netnod.se
Wed Jun 23 06:34:12 CEST 2021
On 22 Jun 2021, at 23:50, Nick Hilliard wrote: > Patrik Fältström wrote on 22/06/2021 21:23: >> I personally think deployment "in the cloud" implies an ability to >> deploy services in such a way (orchestration) that resources are >> dynamically allocated depending on for example load. This implies >> automatic scaling and dynamic allocation of storage, memory and CPU. > > "the cloud" just means someone else's computer. There are plenty of reasons to use this as a procurement model, e.g. outsourcing of specific types of headaches, ease of scale, connectivity, insta-cdn functionality, etc. But in the end it's rental of infrastructure and specific infrastructure-related competencies, and it's a legitimate business decision to deploy infrastructure in this way. My point is exactly the opposite. That "in the cloud" implies dynamic scaling of resources in the most optimal method possible. That one use some orchestration (quite often based on Kubernetes today) to manage the matching between available resources and need. For economical reasons the most effective way is quite often to orchestrate things primarily on your your silicon, but you can scale when needed into resources someone else have invested in, and you "just" rent the resources when you need it. Quite often to a higher cost than your downpayment of your own silicon. So I specifically disagree with the statement that "the cloud is someone else's computer". It's a modern very efficient technology to manage compute resources. >> but to be honest, this is what I always expect the Managing >> Director to do, and I do not think we members should do micro >> management. > > Pretty much this. We don't tell the RIPE NCC legal or finance or outreach or any other departments how to do their jobs. The NCC is an executive and it needs the freedom to be able to make its own operational decisions. Just because something happens to be within our area of expertise as stakeholders, that doesn't mean that we should start back-seat driving because they made a decision to go one way that someone else might have made to go another. Well written! > With regard to the ripe database and the rpki repo, it doesn't look like > there are any specific legal issues that haven't been considered. All of this information is publicly accessible anyway. There may well be a different set of considerations for other types of data. Agree. >> Personally, I think the Managing Director and his staff is doing good >> stuff and see no reason what so ever to question what decisions they >> have made. That said, I am curious in some cases to know what >> decisions they have made as maybe I have the same or similar >> deliberations to do at Netnod and might want to know more. But I do >> not question them. >> >> So, many things are intertwined and specifically mixed up are "us >> members being curious" and "us members actually wanting to provide >> input". >> >> From a technical stand point, I think the most important thing for >> "cloud" is to choose interoperable solutions so that migration from >> one cloud to another is possible, or at least as easy as possible. >> Including on-prem-clouds. > > yep all this, in spades ^^^ Good! > The important takeaways here are two: 1. ensuring service stability and 2. ensuring that long term business continuity isn't compromised (e.g. vendor lock-in). Once these requirements are fulfilled, it's great to get an inside view of what the NCC's plans are. +1 Patrik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/ncc-services-wg/attachments/20210623/f2beed03/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] That's So Meta (was Re: New on RIPE Labs: RIPE NCC and the Cloud - Let’s Start Again)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]