How to manage software in corporate IT infrastructure?

Many companies have to deal with lifecycle management issues of their own or third-party products. Let’s see how it’s done in our HOSTKEYand explore alternative systems.

Popular Instruments

If you need to solve the problems of delivery, updating and rollback of applications, you should pay attention to the following options:

  • Docker;

  • universal package system (Snap, Flatpack, Appimage);

  • delivery through a configuration management system or other system associated with CVS / CI (for example: Git\Jenkins);

  • Linux distribution’s package system (RPM, Deb, etc.).

Let’s explore the advantages and disadvantages of each of them.



  • Docker is an industry standard, which means it will not be difficult to find specialists to support and develop the system.

  • A notable advantage of Docker is the ability to deploy applications regardless of the execution environment: the container is also launched in the product Kubernetes and on a separate developer machine. There are some nuances here, but in general the situation is as follows.


  • Docker is picky about the quality of the infrastructure. If you want real containers with orchestration, you need running and configured services: an orchestration system, a monitoring and alerting system, centralized logging, a service discovery system, and a configuration management system. You also need the ability to build CI / CD processes and the readiness of developers to manage the entire system.

  • The abundance of candidates on the market with the word Docker or Kubernetes in the resume does not say anything about their competencies, and a professional team will cost a lot. These costs are not always justified and the cost of the solution must be taken into account, as well as the willingness of the company to pay for its development, implementation and support. It will not work to jump off, this will add a fair plus to OPEX.

Docker will work in a company of any size, but without a developed infrastructure, it will create a lot of problems. The absence of at least some of the tools from the list of its disadvantages will lead to administrative complexity and the emergence of vulnerabilities, as well as reduce the speed of restoring information systems after failures. This is a powerful and flexible solution in the right hands, but not a silver bullet.

Universal bagging system


  • It is simpler than Docker and is not tied to the infrastructure. This results in a distro-independent solution that is well integrated with modern security systems.

  • Packages are self-contained just like Docker containers. It is possible to run multiple applications on one host, update and rollback occur transactionally and carry everything you need to run.


  • There are few ready-made specialists to work with any of these solutions, and their high-quality integration with security systems is difficult.

  • Development requirements remain high, as is the case with Docker. If the packages are built according to the principle: throw all the dependencies from the developer’s machine into a heap, wrap it up and send it to the prod, the result will be appropriate.

  • No Docker flexibility: a package is not a container, it will run on almost any Linux, but that’s all. Running it as a container on MacOS or Windows will not work.

As a result, you get a lightweight Docker with a limited set of pros and cons. The problem of the lack of ready-made specialists makes such a system unattractive compared to containers.

self-written system



  • There are no external specialists, onboarding is required.

  • Support is labor intensive.

  • Power and flexibility are limited by the allocated resources: if there are enough qualified people to support and develop the system, everything works well. If there are few specialists, there is no need to talk about power and flexibility.

Distribution package system


  • Allows you to fully describe and document the deployment procedure in a single form.

  • Delivery of self-written and third-party software has been worked out and unified.

  • The system is relatively undemanding to specialists and infrastructure.

  • Availability of industrial software life cycle management tools.


  • Link to distribution.

  • It is impossible to deploy the software version uniformly at the developer and in the production environment, which means that there is a need for additional testing.

  • Availability of specialists and complexity of assembly: it is not difficult to learn the system, but there are few ready-made professionals on the market who know it well.

The distribution’s package system is, in our opinion, the only real competitor to Docker. You get a solution with virtually no development ceiling, and switching to Docker is relatively easy. The application can always be packaged in a container, and the whole system is well documented.

HOSTKEY selection

For a number of reasons, we use the distribution’s package system to deliver applications:

  • The hosting company initially had to deploy the OS for clients. Through the package base of the distribution we collect LiveCD. The deployment itself, in terms of hardware support, is also convenient to expand through packages.

  • HOSTKEY had a developed platform for virtualization and monitoring, as well as unification across the infrastructure distribution.

  • We have previously implemented Foreman — an industrial software lifecycle management system through packages.

  • We did not have advanced configuration management systems, a container orchestration system, a service discovery system, and centralized logging.

  • Developers were not ready to actively use containerization. We would have to immediately document and automate development, testing and deployment, and expand the infrastructure and competencies already in the process.

This choice allowed us to document the software, deal with hardware support and get time to develop the infrastructure.

The current IT infrastructure of HOSTKEY already includes a system of centralized logging, service discovery and configuration management. We are gradually moving towards limited use of containers where necessary. The simplicity and flexibility of the batch system will allow us not to think about replacing it with something else for a long time.


In this article, we wanted to show readers the logic of decision making. It is important to adequately assess the capabilities of the company, the specifics of its work and development plans. The introduction of a fashionable tool without economic and technical justification will be a very expensive mistake, but no less mistaken is the closure from innovation and extensive development.

Readiness for change and an adequate assessment of the task is the key to building a high-quality, well-documented and durable infrastructure. In the next article, we will describe some useful life hacks for building an RPM-deploy system.

By the way, in HOSTKEY you can use all the features of the technologically advanced API for fast ordering and server management. Select network settings, operating system and get any server within 15 minutes. You can also collect custom configuration serverincluding professional GPU cards.

We can also add NVIDIA A5500, and a special promotional code for our readers “I FROM HABRA” gives an additional discount on any purchase. When placing an order, name the promotional code to the consultant – and your discount.

Similar Posts

Leave a Reply Cancel reply