This post is the start of a series where we want to present us and talk about the long journey until Virtomize became a thing.

Things should be easy

Before founding Virtomize I was working at a middle sized eCommerce company. My Job was administrating and maintaining hypervisor clusters and virtual machines. These virtual machines were mostly provisioned by hand, which took us a lot of time. A normal system was a work of about 1-2 hours, including all configurations that has to be done. Colleagues had to wait between 1 and 2 days to get a virtual machine.

R&D regularly required a lot of virtual machines for development and testing. Sales and marketing used a bunch of them for different production online services, presentation systems and internal tools. And of course IT for almost every infrastructure except the Hardware itself, webservers, mail servers, chat server, video tools, etc. Also the company runs its own hosting platform with a whitelabeled version of their eCommerce software which in the end needed about a third of all the virtual machines.

So I started automating this process just to free up time for more important stuff.

When it became a success

After about 1 year the first early prototype version was finished. It was capable of automating the creation, installation and configuration of virtual machines. This prototype was using our inventorization software as a data backend, a bunch of automation tools and hand written code to talk with the clusters. We started using IPXE for kickstart installing operating systems.

Finally, we were able to provide virtual machines quickly. We were able to provide systems within 10-15 minutes instead of hours. People had to wait way less time for the systems they needed to get their work done.

Thinking even further

By this time we had about up to 20 requests for virtual machines per week. Creating, installing, configuring and customizing all these systems by hand was not possible anymore. This was about 20-40h so one full person to just do it all the time, which we did not have.

vm chart > Using our automation system allowed us easily to provision the systems in parallel and doing our actual work instead. So only special customization was done by hand. This reduces the amount of time drastically we needed for providing virtual machines to employees.

We also started investigating the idea of self service. Instead of getting a request for a system and providing them, we wanted a platform that allows employees to provision the systems by themselves. This should be possible without the need of a deep technical understanding.

In combination with a simple resource management, this allowed our R&D department to create their systems itself, without our help. The overhead in waiting time for getting a system was reduced even more. This was awesome since it reduced the amount of time people needed for their actual work and made the whole development and test processes faster.

Why not integrate

By starting to introduce an early version of something that could be called an API, we achieved a second success. The API allows us a way deeper integration of the virtual machine provisioning into different processes. For example, development and test pipelines that could provision the systems when they were needed and throw them away after the work is done. This gives us a way better resource usage since it reduces virtual machines just idling around waiting for being used. vm chart >

About 2 years later, we scaled the number of virtual machines from about 100 up to a around 1000 virtual machines. This increase would not have been possible if we had continued to do everything by hand. The creation of these virtual machines was completely automated and maintained by this early prototype.

 

When things got worse

My work shifted from doing the provisioning itself to maintaining this giant. As it is often the case, prototypes are … prototypes and maintenance became a mess. Many third party tools and data backends were involved. Integrated processes forced the system to work properly. Updating parts regularly broke everything. Stability was a big problem at this point.

When Virtomize became an idea

Around the same time I started presenting our innovation to people outside the company 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.

I decided to create a software to solve this problem for everyone. This software should solve a more general use case and should be simple to use. It also allows us the rethink the concepts and build one piece of software instead of using multiple tools, to solve the stability problems. Having 2 friends on my side we started to reimagine the whole idea. We build a sophisticated set of microservices from scratch and eliminated all third party tools. This made the whole system incredibly stable.

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

That’s what it’s for, automating virtualization, making it integratable and self service virtual machine provisioning possible.

In the next part of the series, we will talk about the development and the different use cases.

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