There are many challenges users face while migrating data service instances from one Cloud Foundry deployment to another. But anynines has solutions to address these challenges. However, the problem becomes more complicated when a user wants to migrate data services from Cloud Foundry-based VMs to containers orchestrated by Kubernetes. In this clip from our longer interview, Julian Fischer, CEO and Founder of anynines, talks about those unique challenges and how anynines is building solutions to make that migration easy.

Raw transcript of the video:

The challenges of migrating data service instances from one Cloud Foundry to another really depends on the circumstances and the context. It’s different when all you want to exchange is the Cloud Foundry runtime. Let’s say you want to reduce the BOSH-based environment in favor of the Kubernetes-based environment.

If your data services still sit somewhere, and you can still refer to them, then you may even have no urge to migrate your data service instances. Our data service product called a9s Data Services is a set of different service brokers with lifecycle automation. They basically deploy virtual machines triggered by BOSH. Our service broker talks to BOSH, which creates virtual machines.

We recommend that all our a9s Platform customers have the data service installation in an isolated network segment and not to use, if possible, our PCF tiles, but instead use BOSH to deploy our automation and also keep it in a separate network segment. This way they can basically just add another Cloud Foundry instance and refer to the same service brokers and therefore migrate service instances from one Cloud Foundry instance to another. There is still some work to be done; for example, integrating or importing metadata but you will have the service instance available.

Now, it’s a different scenario, when the goal is to really get rid of virtual machines altogether and move to a pure Kubernetes native container-based platform. To enable that, we will be offering suitable solutions starting with PostgreSQL. We are also going to add operators under the same license as the a9s Data Services.

Customers will be able to create service instances natively on Kubernetes as well. The challenge will be a bit different because then you have to migrate the service instances. You basically have to do either replication-based or a backup restore-based migration path.

With our data service, the advantage will be that backup and restore interfaces will be compatible so that you can basically bulk export and bulk import service instances.

With the absence of such an automation that will span multiple data services, the problem may be more complex, because for each data service, you’ll have to create your own migration path to get from virtual machines into a container-based solution. So if you have 10 different products doing service automation, you’ll have to talk to them to 10 different vendors or find 10 different migration paths somewhere else. And that’s, I think, where a lot of work will cause a lot of effort.