Cloud lift with a plan: how we achieved real migration success with Public OpenStack

Cloud migrations rarely fail because of the technology - but because of the implementation. A lack of automation, complex dependencies and a rigid understanding of infrastructure often mean that the "lift" does not succeed and the "shift" fails to materialize. But what if you rely on an open platform such as OpenStack - provided as a managed public cloud, with a full focus on control, flexibility and data sovereignty?

In our previous post we have learned the basics of OpenStack and the possibilities of Managed OpenStack as a public cloud offering. Now we would like to go one step further - and report from the field: How existing applications can be reliably and efficiently migrated to the OpenStack cloud. We will show how we have implemented a large number of successful cloud lift projects with Public OpenStack over the last few years - from the automated migration of classic workloads with Terraform to stable network, compute and storage setups.

Lift & shift made easy: Terraform as a key tool

A key element for the successful transition of traditional workloads to the public OpenStack environment for us was the excellent Terraform provider for OpenStack. As already described in part 1 of our series, OpenStack is ideally suited for the so-called Lift & Shift - i.e. the migration of existing applications that are based on classic virtual machines.

With Terraform, we were able to completely define the underlying infrastructure - from VMs to networks and storage - as code and deploy it automatically. This brought several advantages:

Reproducibility: The infrastructure configuration is versionable and can be reproduced consistently at any time - whether for test, staging or production environments.
Automation: Manual intervention is minimized, which both saves time and reduces the susceptibility to errors.
Infrastructure as code: Thanks to the declarative description of the target state, Terraform takes care of the implementation independently - efficiently and comprehensibly.

The OpenStack provider integrated seamlessly into our existing workflows and enabled the simple provisioning of instances (Nova) with different operating systems and sizes.

Vendor lock-in with restrictions: Migrations between OpenStack vendors

A frequently cited argument in favor of OpenStack is the reduced Vendor lock-in. In theory, this is true - in practice, however, we have learned that switching providers involves certain hurdles. Although the OpenStack API and the core principles remain the same, many providers implement individual configurations. This manifests itself, for example, in:

Different region names: The designations for the geographical regions may vary from provider to provider.
Different instance flavors: The names and specifications for the different VM sizes (instance flavors) are rarely identical.
Inconsistent OS image names: The names of the available operating system images may differ. Or also the availability of Oses.
Other names for public networks: The labels of public networks are not always standardized.
Varying block storage classes: The names and possibly also the underlying technology of the block storage classes may differ.
Subtleties in the granting of rights: The mechanisms for rights management for customers may differ slightly.

The good thing is that a migration rarely means a complete redevelopment of the Terraform code. As a rule, targeted adjustments - especially to variables and provider configurations - are sufficient to get the application running in the new environment. Compared to proprietary platforms, the effort involved is therefore manageable - a clear advantage in terms of long-term flexibility.

Strong foundations: network and compute services at eye level

In our projects, the core functions of OpenStack in particular have proven to be stable, performant and reliable - first and foremost:

Neutron for flexible, virtual network configurations with subnets, routers and load balancers
Nova for robust compute resources with customizable instances

The performance of the virtual machines provided consistently met our requirements - both in terms of availability and scalability.

Block storage with scope: Cinder and its classes

We also gained good experience in the area of block storage (Cinder). Depending on the provider, different classes with different performance and price models were available - such as fast SSD storage for high-performance applications or cost-effective HDD storage for less demanding workloads. This variety helped us to match workloads optimally to our customers' requirements and budgets.

Public OpenStack in the project reality

Our experience to date clearly shows that Public OpenStack is a mature, flexible and practical platform for cloud migrations. OpenStack really comes into its own in classic lift-and-shift scenarios where virtual machines are at the center. The integration with Terraform ensures a fast, reproducible and maintainable infrastructure - while the manageable migration effort between providers represents a real advantage over closed platforms.

Although OpenStack does not (yet) offer the same variety of specialized managed services as the large hyperscalers, it scores points with its openness, control and data protection-compliant architecture. For many companies, this is the right basis for a confident and future-proof start in the cloud.