You are here: Home > Publications > RIPE Labs > Kaveh Ranjbar > Our Approach to the Cloud

Our Approach to the Cloud

Kaveh Ranjbar — 21 Nov 2019
We have plans to move some of our technical infrastructure to the cloud in order to achieve greater agility in our technical setup. Here's an overview of our approach.

In our draft Activity Plan and Budget 2020, we talk about our plans to use cloud technology at the RIPE NCC. The idea is to look at different components of our technical infrastructure that are currently being maintained in-house and to figure out, on a case-by-case basis, whether it would make sense to move them to the cloud.

Why and How

The main reason for making the move is that it would make our existing technical setup more agile. Making more use of cloud-based solutions would make us less reliant on hardware alternatives, and so would allow us to reduce existing commitments to maintaining connectivity and providing adequate storage space. That’s the general benefit.

More concretely, we need to weigh up the benefits of applying cloud solutions for each area in which such solutions could, in principle, be applied. With that in mind, our plan is to run a number of individual projects, each aimed at assessing what might be gained from making the move for a specific part of our technical infrastructure. The main areas we’re looking at are as follows:

  • Storage and processing infrastructure for measurement data collected via our Routing Information Service (RIS), RIPE Atlas and the RIPEstat Data API 
  • Some of our data back-up systems
  • Some of our administrative systems

Proceeding with Caution

For now, a lot of the work we’re doing is still investigative in nature. Although we have a pretty good idea of those areas in which cloud solutions could be applied, we still have to ask in each case whether they should be applied. In some cases, even if it’s possible to make the move to the cloud, there will still be good reasons not to do so.

For example, special consideration will be given to cases involving essential services - i.e. services that network operators rely on for providing information, including (but not limited to) whois, rDNS and RPKI. Given the importance of these services, even if we make the move, we will be relying on the cloud as a secondary solution only, and will ensure that the services are kept fully operational and accessible in-house as with the existing setup.  

We will also avoid making the move if there's any risk of confidential and personal data being exposed in the transition. One of our priorities will be to ensure that, for any cloud provider we end up working with, such data is protected, and that we remain compliant with all applicable data protection regulations. 

Next Steps

For each project, we will begin with an exploratory phase. During this phase, we will not migrate anything, but will run part of the service in the cloud in parallel to our in-house infrastructure. Before any migration takes place, we will consider:

  • The technical feasibility and challenges for delivering the results
  • Operational and Maintenance considerations
  • Jurisdiction, privacy regulation and other legal considerations
  • Information Security considerations
  • The financial Impact of migration both in terms of investments and operational costs

After reviewing these for each project, we will then be able to make a decision on whether to migrate an operational service to the cloud, or use the cloud as a parallel solution, or not to use it at all. As always, as we start rolling out these initial projects, we will make sure that the community remains informed about their scope and their progress.


If you have questions or comments about any of the plans outlined here, we want to hear from you. Please leave your comments below or contact us directly.


Shane Kerr says:
21 Nov, 2019 11:44 AM
One issue with cloud services is that they are mostly proprietary offerings. I suggest that the cost of moving off of a particular cloud provider (whether back to self-hosted or to another cloud vendor) be counted as a cost of that solution. For example, if a cloud service offers a particular service that no other company offers, the cost of doing without or building a replacement should be factored in as an additional cost of using that service.

Often companies end up locked in because it costs too much to move off of a particular solution, but this is less likely to happen if the cost of "unlocking" a given service is accounted for the entire time.
Kaveh Ranjbar says:
25 Nov, 2019 10:28 AM
Thank you very much Shane. Fully agree with you and that is why we are treating the subject with caution and as small, independent exploratory projects. One of the key findings we are going to look into from each project, before deciding to migrate to the cloud, is changes in the Total Cost of Ownership for a particular service. Inputs to that will include how our in-house IT and OPS can provide monitoring, support and maintenance for each platform as well as effects to portability of each service and their dependencies.
Daniel Karrenberg says:
21 Nov, 2019 05:14 PM
Good point.

I wonder whether other readers have experiences with shells around cloud services that provide some degree of provider independence?
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.