From OpenStack to CloudStack: why we are moving away from OpenStack after 10 years

The reasons are very organisation specific, which I will dive into in a second. First though, let's take a step back: what are the kind of factors you need to consider when planning a migration? These are also going to be organisation specific in terms of ranking or presence, but some that we consider are the following:

• Network interoperability

• VM migration ease

• Capacity reusability

• External integrations (i.e. backups, SANs, SDN software/hardware)

What to consider when planning a VMware migration

Now network interoperability is the main killer, so to speak, and one that we think most organisations (including us) struggle with. Our enterprise cloud consists of a flat network. This means that there exists no overlap in networks, networks are separated by VLANs, use private IP space addresses and obtain Layer 3 capabilities through virtual routing appliances.

So let's consider a scenario where you have got two options to migrate to:

• The CloudStack configuration we had in mind for our public cloud. VXLANs, RoH (Routing on the Host), EVPN BGP, BGP peering between hypervisors, switches and physical routers, and so on.

• A Proxmox cluster with VLAN 802.1Q bridged VLAN interfaces for guest networking.

You are migrating a customer's HAProxy based web application or MariaDB Galera Cluster. You have built up a reputation as being a high uptime MSP provider who excels in setting up high availability environments for downtime sensitive customers. Which of these is plug and play into your current infrastructure? Which will let you reuse your existing network capacity? Which setup makes sure your high availability configurations remain the same? These are considerations that have to be made and will have a tremendous impact on the ease of migration.

Moving thousands of VMs with customer services on them is one thing, but reengineering all these boutique environments in that same track to fit with a new network model is another.

OpenStack is configurable in Neutron networking configuration, but in general it expects OVS and in our case we run it with OVN as well to provide multitenant virtual networks. OVS is directly comparable to a flat Layer 2 translator on the hypervisor host, whereas OVN is a Layer 3 enabling SDN technology.

Why OpenStack is not the right fit for a VMware replacement

OVS can be installed on solely the hypervisors, but one critical point we take issue with when evaluating it for a non NSX VMware migration is that it simply becomes far more complex than the existing setup on VMware with more running parts that need expertise to troubleshoot in case something goes wrong. In general this is also the killer for OpenStack as a whole.

Cyso Cloud has run an OpenStack public cloud for over 10 years now, but not all of those years were easy and many iterations were done over the years on anything from the orchestration backbone, project choices and even hyperspecific configuration of certain OpenStack components. It is not an easy stack to build, upgrade or keep running by yourself. So you require two things: time and resources, both of which are often in short supply for migration projects. Can you offload those needs to an OpenStack flavour provider?

Of course, but if you never build that underlayer of platform knowledge, are you not, again, entirely reliant on your third party provider? This is an acceptable cost to some, both in risk to that provider, and how heavily it weighs is organisation specific. But, in our case, not one we want to take.