One of the desirable properties which users expect in a modern cloud-hosted application is portability. Users want to migrate portable applications between private and public clouds or between different cloud regions. With container images as portable application implementations and emerging sophisticated container runtimes, this should be an easy task. But when a containerised application starts to become more complex, a container platform or an orchestration tool needs to be deployed. This add specifics blueprints and together with the persistent data makes the migration of the application tough. This means that the application is not in a condition to be moved as easily between clouds or even between the orchestration tools or container platforms, losing the desirable portability property. With the idea in mind that the next generation of Cloud-Native Applications must be deployable to different cloud providers as the requirements change, we are proud to announce the first proof of concept release of os2os, a tool to migrate cloud-native applications between OpenShift installations. While our research on application migration is not limited to this single container platform, we see it as one of the more popular and technically interesting ones.
Applications are increasingly delivered for cloud deployment as set of composite artefacts such as containers. The composition descriptions vary widely: There are Docker compose files, Vamp blueprints, Kubernetes descriptors, OpenShift service instance templates, and more. Ideally, taking these compositions and deploying them somewhere would always work. In practice, it is more complex than that. Commercial production environments are often constrained depending on the chosen pricing plan. Many applications would still run but due to over-estimating deployment information do not “fit” into the target environment. In this blog post, we look at how to “right-size” an application deployed into such a constrained Kubernetes instance, and furthermore propose a tool to automate this process.
At ICCLab, we have recently updated the Openstack OVA onboarding tool to include an exporting functionality that can help operators migrate and checkpoint individual VMs. Furthermore, researchers can now export VMs to their local environments, even use them offline, and at any time bring them back to the cloud using the same tool.
The OpenStack OVA onboarding tool automatically transforms selected virtual machines into downloadable VMDK images. Virtual machines and their metadata are fetched from OpenStack’s Nova service, and made packed as OVA file. The tool offers a GUI integration with OpenStack’s Horizon Dashboard, but can be also deployed separately.