Kennis New virtualization infrastructure

New virtualization infrastructure

The new machines with a lot of patch cabling

Our infra will have a big upgrade next week. At this very moment the latest issues are being addressed and we will start rolling with a new virtualization setup! But why invest in hardware at a time where cloud / iaas / paas providers are popping up like mushrooms?

Let's start by saying that we use the cloud, a lot. We deploy to Amazon, Heroku and what not, including some serious production. And it works! Seriously, ignoring these services as a software development company will hurt you, money-wise, time-wise and therefore, business-wise.

So, why would we roll our own infrastructure when all the goodness is already out there, pretty affordable and working pretty good? We have more than one reason to:

  • We want to understand the technology. We run stuff for customers on various platforms, including public and private virtualized clouds. How can you manage a provider when you don't know what you are talking about? Most of our projects run all of their development and test environments on our own private virtual cloud enabling us to learn and improve.
  • All customers are unique, which means we run a lot of different services. Not all services work on all clouds, so you need more than one cloud provider. For manageability it's better if we keep all of these together. Our own private cloud provides the flexibility to support a lot of different software stacks, but still keep them in one place.
  • Data protection. Some clients want to know where their software is running and where the data is. We roll test and acceptation instances on our own machines and we can physically show them around. For a lot of customers, this is reassuring. It's all about trust.
  • Costs: the cloud is not free of maintenance. If you roll EC2 instances for example, the cost is not limited to the bare EC2 price. You still need to harden your setup security wise, you still need to update / upgrade your machine images. You still have your devop costs. In other words, it's not necessarily cheaper when you move to Amazon.
  • A plan B. We have a plan B for services that run in the cloud. If a cloud service fails, we can fallback to a scenario that we have in our own hands.

For those of you curious about what we have running, I will follow up with a blog post on that soon.