This article is written by weSystems.
Edinburgh in November. Grey skies, good whisky and three days with people who care about Apache CloudStack as much as we do. We’re proud to be part of the CloudStack Collaboration Conference 2026 (18th to 20th November) as a sponsor.
On Friday, 20 November at 11:30, our colleague Stephan Bienek will take the stage to talk about a topic that has kept us busy for years, and occasionally awake at night. More on that further down. First, a little about who we are and how CloudStack became such a big part of our story.
Ten years of running the real thing
weSystems is a cloud, IT infrastructure and managed services provider with locations in Germany, Bulgaria, Denmark and Switzerland. Our own sovereign cloud, the weSystems Cloud, has been running on Apache CloudStack for nearly ten years now, across different data centre locations in Germany and Europe. Alongside it, we build and operate CloudStack platforms for our customers.
When we started, CloudStack looked quite different from what it is today. We’ve followed it release by release, upgraded through more versions than we’d like to count, swapped hardware generations, rethought storage and rebuilt parts of our network more than once. Some of those steps were smooth. Others taught us things we’d rather not learn twice.
What a decade in production really gives you isn’t a feature list. It’s a feel for how the platform behaves on an ordinary Tuesday afternoon, when a host doesn’t come back after a reboot or an upgrade touches something nobody expected. You don’t get that from documentation. You get it from running the thing, every single day.
From running it to helping others run it
Somewhere along the way, people started asking us questions. Other providers wanted to know how we had built our zones. Companies looking for a way out of proprietary virtualization wanted to understand whether CloudStack could carry their workloads. Partners wanted a second pair of eyes on a design before going live.
So we started sharing. What began as conversations between community members grew into a real consulting practice. Today we work with providers and enterprises along the whole journey, from the first workshop and architecture design through concept and implementation to day-to-day operation, if they want us to stay on. Some teams need a sparring partner for one tricky decision. Others hand us the entire platform. Both are perfectly fine with us.
Two stories show what that looks like in practice. One provider wanted to build their own cloud on CloudStack. The team already knew an impressive amount about the platform, but turning that knowledge into the first steps of a real provider cloud is a different kind of challenge. Together we turned their challenges and requirements into a design built for exactly their situation, and today we’re at their side as a sparring partner. Their deep CloudStack know-how and our years of running a cloud in production turned out to be a really good match, two worlds that complement each other.
Another company had already been running CloudStack for a while when we first met. In that first conversation we asked a lot of questions and challenged quite a few settings and configurations. Many of them, it turned out, had simply been set that way because nobody knew better at the time. And hey, it worked. We showed them the alternatives that hold up much better as the platform scales, which configurations make sense if they want to raise availability, and a few more things along the way. Nothing was broken. The point was making sure it stays that way as they grow.
And part of the motivation is simple. We think CloudStack is a fascinating platform that deserves a lot more attention than it gets. Every team that builds on it successfully makes the whole community stronger, and helping that happen is a pretty good way to spend a working day.
Our mistakes, your shortcut
Let’s be honest. Not everything went right the first time. We’ve made design decisions we later had to undo. We’ve found out the hard way which shortcuts come back to bite you during an upgrade, and which assumptions about hardware don’t survive their first week in production.
The good news is that nobody else has to repeat those lessons. Providers and companies working with us today get nearly ten years of real operating experience served on a silver platter, including all the things we wish someone had told us back then. That saves time, nerves and now and then a weekend.
We also believe this kind of knowledge should build independence, not new dependencies. The goal of our consulting is a platform our customers understand and are able to run, whether they keep working with us or not. For us, that’s what open source is really about. The freedom to choose, and the knowledge to make that choice count.
CloudStack never lives alone
Here’s something we learned early on. Almost no CloudStack project is only about CloudStack.
The moment you sit down with a customer, the questions start branching out. Which hypervisor fits? What should primary storage look like, and does Ceph make sense here? How do backups work in a multi-tenant world? Where do the firewalls sit, and how do you automate all of it? And sooner or later, every one of those conversations ends up in the same place. The network.
That’s why our consulting looks at everything beside, above and below CloudStack, not only at the orchestration layer. A beautifully configured CloudStack on top of a fragile network is still a fragile cloud. Because we design, build and operate the whole stack ourselves, from physical connectivity and switching through storage and virtualization up to the services customers actually use, we look at a setup as one system. And because we run these environments in daily operation, our advice comes with operational reality already built in.
The network is where it gets interesting
One part of a CloudStack environment that varies a lot from one company to the next is the network. Every provider brings their own hardware history, their own vendor preferences and their own set of compromises. Over the years we have designed, reviewed and supported setups on very different network stacks, and every single one had its own surprises waiting.
VXLAN is a perfect example. Built on BGP and EVPN, it gives CloudStack a clean way to isolate tenant networks and lets the whole network stack leave the risks of large Layer 2 domains behind in favour of Layer 3 stability. That’s a huge step forward. Making it run reliably on hardware and software components of different vendors is a different story, though.
That’s exactly what Stephan will dig into in Edinburgh. Earlier talks on the topic focused on FRR running on hosts and switches. Stephan will talk about experience with other hardware many providers use. He’ll walk through the challenges we faced in real-world CloudStack deployments with VXLAN on Juniper and MikroTik switches, including a data centre network built entirely on MikroTik, and why Juniper doesn’t always equal Juniper.
Come and find us in Edinburgh
“CloudStack and VXLAN – MikroTik and Juniper Challenges”
Stephan Bienek, Head of Hosting, weSystems
Friday, 20 November 2026, 11:30
CloudStack Collaboration Conference, Edinburgh, Scotland
Whether you’re planning a new CloudStack platform, moving away from another virtualization stack or wrestling with your network design, come and say hello. Bring your questions, your diagrams and your war stories. We’ll bring ours.
See you in Edinburgh!
