In this third post of our series we want to talk about the ideas and development we made to bring the Virtomize to life.

Our last post ended when we run into a lot of prototype issues. We called this maintainance hell. Now lets see what we learned from it.

First thoughts about creating Virtomize

Around the same time we run into our maintainance hell, I started doing presentations on conferences talking about how we solved our problem of virtual machine provisioning and got amazing feedback. Many small to middle sized companies never reach this point of automation. Often due to a lack of manpower or know how.

My friend and co-founder as well as another good friend of mine, who has amazing experience in UI development, decided to create a commercial software to solve this problem for everyone.

The idea was to create a software that is able to solve the more general use case. The old prototype was developed for a very specific set of infrastructure and was not able to fit into every environment. We decided to use our knowledge of the prototype to redesign the idea and create something that is able to solve the same problem in every environment, instead of just our specific one.

Up to this point we investigated a few concepts to make the workflow of providing virtual machines to users more easy and simple. This became our second big requirement. Make things simple!

Choosing the Way

We want to create a software that not only automates the whole process for every possible infrastructure environment, it also should be able to be simplified in a way that nearly everyone could use it. Even if the person does not have full knowledge about IT infrastructure, networking or operating system configurations.

As we learned from running into the maintainance hell, we have to build it in a way more stable way. So our third big requirement became reliability. Our system has to be able to work stable and reliable.

When talking about IT infrastructure and building a system to automate deploying such infrastructure one big reqirement should never be missed. Security!

The system should not become a single point of failure system from a security standpoint. This was another reason why we decied to go the way of doing customization within the installation instead of doing it after building the system. Within the installation, we just build an image, including installation scripts and hand it over to the hypervisor. To do customization after building the system, we would need access to the system. If you solve the general use case, this access needs to be enabled for all of your networks. You don’t want a system that has access to all of your networks.

How to build it

We startet rethinking the concepts to build one piece of software instead of using multiple tools, to solve the stability problems. While reimagine the whole idea, we build a sophisticated set of microservices from scratch eliminating all third party tools.

Also, using code only instead of a lot of tools, we where able to solve a lot of error issues between the systems. This created another big step into our reliability requirement, as we were able to handle error cases more properly. If something goes wrong on the way, we can clean things up and make sure the infrastrucutre is clean at every state.

This made the whole system incredibly stable and way more reliable than the prototype.

We named this Software Virtomize, a combination of “Virtualization” and “Automization”.

Because that’s what it’s for, automating virtual infrastructure.

In our next post we will investigate the technical inovations a bit more and how Virtomize was filled with life

Thanks for reading so far and see you in the Virtomize.