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.
Feedback
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.
Comments 5
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Shane Kerr •
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.
Hide replies
Kaveh Ranjbar •
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 •
Good point. I wonder whether other readers have experiences with shells around cloud services that provide some degree of provider independence?
Paul Polyakov •
I don't like the term Cloud, I think it means ignorance in most cases. If I understand well, you want to host data outside of the ripe's own infrastructure? Well, then you just have to find a suitable hosting company. I think it's a bad idea to go with a solution where you won't have control over the network and the hardware.
Hide replies
Peter Gervai •
"cloud is someone else's computers". I don't really understand how an internet tech centre thinks hosting their own services and data on the Blackbox of someone else is a splendid idea.