“Heavy” commercial application software

I will tell you about the features of “heavy” commercial application software for large companies and give a couple of examples .

Come in, I’ll show you the hell of a perfectionist.

In big business, there are simply no situations where you can buy a license and immediately sit down to use it. You need to carefully refine it with a file, and often in such a way that sometimes it takes the same amount of time to write from scratch.

– Software is never 100% ready, because business is constantly changing.

– Software never stops in modifications.

– Software needs to be constantly maintained.

Purpose of implementation

The main task of any corporate software is to automate something that has not been done before or was done by hand. That is, translating into human language – either saving (most often), or obtaining new functionality for more successful problem solving.

For example, every time your child eats Barney Bear, or you chew Dirol, or teenagers don’t find foil in an open Alpen Gold, there are many complex processes going on. By purchasing, you indirectly trigger many transactions in ERP, logistics and other IT subsystems of the retailer and the manufacturer. All this one way or another is sent to data centers, where it is calculated. The most important task is timely accurate deliveries, so that the logistics work correctly. At the same time, well-written software saves millions of dollars on optimizing warehouses, improving vehicle schedules (reducing the number of cars needed), predicting demand accurately and, accordingly, reducing waste by expiration date. For example, here with bears and others, the customer saves several million rubles a year. Or here is an example of my colleague about the census, where they managed to save both on equipment and on people (and there, for a second, half a million people walk around the country).

That is, the goal of automation at the moment is almost always – savings (in the future). In second place, according to my feelings, in terms of the importance of motivation to develop IT infrastructure is more control and transparency. For example, the same document management systems and BPM are introduced to improve control. Here is another situation where a company could easily lose a wagon of steel simply because of accounting features.

There are also purely technical goals – automation of changes in IT subsystems (so as not to pull the IT department every time the commercial director needs to change something), control of code changes, tracking all assets (licenses, servers, etc.) , monitoring and other things. An example of solutions for multi-pass automation of IT work is here.

Naturally, there are no universal solutions, just as there are no two identical companies. All software, all software and hardware systems and other solutions – all this is done specifically for the customer.

Until we have gone further, it is worth dwelling on the important issue of improvements and finishing with a jigsaw. In big business, the key word is customization. You need to write for the process, with a clear understanding of who will work, what tasks to solve exactly, and in such a way that it is convenient. Otherwise, automation software becomes not a help in work and a means of saving, but a crutch, or, worse, a hindrance that interferes with normal work. Hence – either a very, very serious finishing of boxed versions together with vendors, or development based on some kind of framework (examples below), or even from scratch.

Accordingly, in the first two cases, it is a difficult question (especially in the current economic environment) whether the development is European. No, it’s clear that computers weren’t invented, Boolean logic either, operating systems are also not particularly visible – but a clear criterion is still needed. Back in November, the Ministry of Telecom and Mass Communications offered its own vision of the concept of “Slavic development”. This is some kind of software, the copyright of which is a Slavic company, and the deduction to foreign companies for the use of their modules does not exceed 30%. In general, it is quite democratic and convenient for the market – it’s just about good customization.

But let’s already show examples of our developments.

Medical terminal

Let’s start with a fairly simple thing: a device consisting of a well-known set of “constructor parts” with relatively simple software. This is a PAK that looks something like an ATM that allows you to diagnose the main indicators of the state of the human body in less than 3 minutes. Placed indoors.

In the basic configuration, it can:

– Measure blood pressure, pulse and oxygen saturation,

– Smell breath and report alcohol in it,

– Authorize an employee using a smart card (for example, from an access control system to a room) or a fingerprint (in the near future, the possibility of authorization by the iris of the eye will be implemented),

– Shoot a video of the examination itself and transfer it to the server,

— Store data in the database and send it to other subsystems of the company,

— Conduct analytics based on current measurements and previous surveys.

Of course, additional modules can be added to it, for example, to take one ECG lead or to check skin resistance (roughly speaking, the level of stress).

His purpose is extremely simple – to check employees before the shift. For example, to simplify the pre-flight medical examination, record the state of the NPP operator, put in the Ministry of Internal Affairs, on a drilling rig on the shelf or in the taiga, and so on. During the tests, we put it right next to our dining room – a whole line of people who wanted to test themselves lined up. A lot of people really enjoyed keeping track of the baseline on a regular basis.

This is an assembly from a hardware platform, writing integrating software or rolling out a ready-made solution from Western colleagues with the same kiosks, plus a link to the company’s database.

Technology stack for software developent

Important: not everyone can afford full-fledged CI / CD in an enterprise. Restrictions may be related to the unpreparedness of the business, the requirements of legislation and regulators, the immaturity of tools, and the lack of competencies. Simply put, merging code into a master (even with automatic passing of tests and other checks) is not at all a reason to install it in production.

DevOps (Development Operation) is a set of practices for improving the efficiency of software development and operation processes through continuous integration and active interaction of subject matter experts using automation tools. The methodology is designed to effectively organize the processes of creating and updating software and services.

CI/CI setup specialists are called DevOps engineers or simply DevOps.

Docker & K8s

Containers (Docker in particular) is a big topic, I’ll try to cover it in a nutshell and spice it up with links (there are a lot of high-quality materials on the topic on Habré).

Brief cheat sheet

For simplicity, the container can be considered a lightweight virtual machine without the overhead of the guest OS, so to speak, a sandbox for the process. Containers allow you to run processes isolated from each other in an ideal environment on the same host OS without dependency conflicts. You can start studying the topic with an article of such a plan.

The base scenario for using containers is not development-related at all. You can simply use ready-made images of various software instead of manual installation. GitLab is a great example: it can be installed either by following a cross-referenced instruction or by running a single docker command. The docker approach is especially convenient if you want to “feel” the service in trial mode and not drag tons of dependencies onto the machine.

Containers themselves were already a breakthrough, but they shone with the advent of mature orchestration tools such as Kubernetes. In terms of development, containers provide more advantages for small services (aka microservices) than monoliths. Yes, you have to touch on the topic of microservices to understand the benefits of docker and container orchestration. Superficial comparison of architectures:

Monolith Microservices

Built using one programming language/framework Each microservice is built using the most convenient and appropriate programming language/framework

No dependency issues, one application, one set of dependencies Each microservice can depend on its own set of libraries and even OS version

Does not imply horizontal scaling Microservices are often stateless, as a result they scale horizontally transparently

The microservice architecture approach requires the right toolkit, such as the tandem of Docker and Kubernetes. Docker provides:

rapid deployment;

convenient isolation of processes;

minimal resource consumption;

Kubernetes, in turn, provides:

resource control;

uniform load distribution;

automatic balancing;

tracking resource consumption and their limits;

moving application instances between hosts;

automatic use of additional resources (when adding a new host to the cluster).

Practical use

The use of containerization and orchestration can be an alternative approach to solving some of the problems outlined in the article. In the “Delivering Changes” and “Testing Environments” sections, I put the appropriate notes. For example, a docker image can be an alternative to a distribution. The composition of system microservices deployed in Kubernetes can be an alternative to the test loop. Moreover, containerization makes it easier not only for combat and test deployment, but also for development itself, since containers allow you to painlessly recreate the necessary infrastructure even on a developer’s machine. This shortens the “change code -> build/install -> check -> redo” cycle and, as a result, speeds up development. In practice, the enterprise is not so rosy, there are insurmountable obstacles. Here are a few offhand examples:

some software only works on Windows (or is even a windowed application);

data exchange takes place via files/network folder/FTP;

software requires an expensive license;

the vendor refuses to make containerization efforts;

the database versit several terabytes, it is not clear how to allocate the minimum efficient part.

With these features in mind, I did not describe the scenario “Total chaos -> Docker & Kubernetes” as the main one.

Conclusion

Thank you for your attention! I will be glad to additions and suggestions.

P.S. During my work on the article, a similar one came out – I recommend reading it. I have a little more enterprise, and there are more specifics on the web. In general, the articles complement each other well.