Introduction of the challenge
Many of you already know that we have been supporting OpenNebula and been using it for our infrastructure. After years of using OpenNebula, we've seen its beauty, and also its limitations. Now we're at a point at which we really have to question ourselves, how we can grow as we want : we couldn’t do everything we wanted with OpenNebula because of its limits, and we were often questioned if we should go for Openstack.
As a team of curious and open geeks, we had a look at Openstack - and it looked HUGE, or in other words: very complex. We are UNIX company and we adhere to KISS, so it looked like not really compatible with our philosophy of how we do things.
So here is our new challenge. We will build our own thing from scratch. Again. And we will challenge Openstack and OpenNebula, to do better, and to better fit our need as a cloud provider.
What we want
In general what we want is something easy, portable, light, and simple. Simple is the word we are all into at ungleich. No mess, no fuss, something straightforward and clean.
Why do it on our own?
If there are plenty of solutions out there, why would we go for something on our own? Because there is nothing that fulfills our needs really. Nothing that fits what we like. What we want is a virtualisation ("cloud") framework that
- Has IPv6 as a first-class citizen
- Is easily extendable
- Does not have a hard-to-get-rid-of a single point of failure (SPOF)
- Is written with portability in the mind (i.e. supporting *BSD next to Linux)
The limits of OpenNebula
While we still prefer OpenNebula very much over OpenStack, it has some limitations for our use case, us being a cloud provider. For example we cannot let users use the web interface of OpenNebula, because its interface is confusing for users. Because we cannot let users use the web interface of OpenNebula, we cannot easily let users use the console, which users want to.
Just to name a few of other examples, OpenNebula does not have methods to easily support per customer IPv6 networks or handle /64 routes that are delegated to a VM, or automatically assign them to a VM. So it is not exactly enabling us in giving our users the experience we want them to have.
The tech stack
So we will build our own thing, and will call it as ucloud. For building ucloud, we decided to go for the following technologies
- Python3 as the main programming language
- Flask for handling http
- nginx for SSL termination
- etcd for storing data
- json as the data format
- bird (announcing of service IPs)
- guacamole (for console access)
We try to reuse as many existing projects as possible to not reinvent the wheel where unnecessary.
Our 100 days plan
So this is our ambitious plan of challenging OpenNebula and Openstack. You might have noticed that we've been ambitious from the beginning anyway (100% renewable energy, 100% open infrastructure, 100% IPv6, just to name a few) but as a business we need to know: will this be doable or not? We want to find out more than anybody, so we set ourselves a goal of building ucloud in 100 days.
How will this be done? While developing we will phase in ucloud for our internal VMs alongside OpenNebula. Later we will be disabling the OpenNebula firewall helper, replacing it with ucloud-firewall. Then we will introduce a new test cluster for running the first test VMs from ucloud, likely in an incomplete and insecure way. Then we will migrate our internal VMs to this version and squish bugs on the way until we can migrate customer VMs to it.
We know this will be not exactly easy, but it will be a lot of fun. While it is very exciting to plan a simple cloud solution, this is a complex topic.
For those who want to see our development more upclose, or want to be part of our challenge, our chat is open for everybody where we discuss the project in detail. Also you can checkout the development ticket for ucloud. Everybody is welcome to come by and share thoughts. :D
We have 100 days to go: let's see how we make it!
