The post has been translated automatically. Original language: Russian
Cyberpunk in uniform: how IT works in military service and what a civilian developer can learn there
When we talk about extreme programming and severe limitations in IT, space programs, high-powered fintech giants, or IoT devices with microscopic memory usually come to mind. But there is another area that is rarely mentioned on specialized resources — this is army development.
I spent a total of about 8 years in military service as a developer. During this time, my team and I had to face such infrastructural and architectural challenges that a civilian IT specialist can only dream of in a nightmare.
In this article, I will tell you how to develop enterprise systems in a complete information vacuum and how to make a database replicate in the middle of the steppe via a satellite channel from the last century.
Case 1: Complete information vacuum, or Notebook Programming
The main shock for any commercial developer entering a closed loop is the absolute lack of Internet. The servers do not have a network, the workstations do not have a network, and it is strictly forbidden to bring smartphones into the territory itself.
Our main technology stack was defined in advance and could not be changed: the .NET Framework and the MS SQL database management system. All software was official and licensed, including the Visual Studio development environment. But you're left alone with this studio. You can't go to Stack Overflow, Google the error text, spy on the syntax, or download the required package via NuGet in a couple of seconds.
How we got out of it:
- The code is in the notebook. If the task reached a dead end, it had to be solved outside of work hours. In the evening at home, you open the Internet, study the documentation, find a solution and ... rewrite the necessary algorithms with a pen in a notebook. In the morning, you bring a notebook to the service and use your notes to enter the code into the project.
- Strict mode for flash media. It is strictly forbidden to bring home flash drives or disks to the territory. Only special, registered service drives were used for work, which were deposited in a safe at the end of each working day against receipt. There is no "take a job at home".
- Archaeology of the local network. Our Google was the source code of old projects that had been written by employees before us for years. We spent hours digging into someone else's code, looking for similar functions and interfaces in order to understand how this machine functions in general.
Business insight: Such conditions completely kill the habit of mindlessly copying ready-made solutions (the so-called Ctrl+C / Ctrl+V development). You begin to deeply understand every line of code you write, because the price of a mistake is a lost day at work and another evening with a notebook at home.
Case 2: Data center on wheels and replication at 100 Kbit/s
Writing a system in isolation is half the battle. The most interesting part started when the product had to be deployed in the field during exercises.
To ensure autonomy, a KSM (command and staff vehicle) leaves the field. In fact, this is a full-fledged local data center on wheels. A physical server is installed inside the machine, on which the MS SQL database and related services are running. All specialists in the field work from their laptops, connecting directly to the server inside the KSM via a local network. It turns out to be an isolated distributed ecosystem.
However, the data from the field must be synchronized with the central server. To do this, the car used satellite communications. And here we faced severe restrictions.:
- Speed from the last century. No full-fledged Internet connection. The data transfer rate over this closed satellite network was a maximum of 100 Kbit/s.
- Aggressive replication. To keep the data in the center and in the field up-to-date, automatic MS SQL replication was configured every two minutes.
Every 120 seconds, the field and central server tried to "talk" to each other through this narrow satellite channel. Communication in the field was constantly cut off and faded due to the weather or terrain, but the system had to live.
Business insight: In such conditions, you learn to value every byte. No "heavy" queries, no bloated traffic and unoptimized tables. The entire backend and database structure are licked to the limit so that data packets are guaranteed to fit into the bottleneck of communication and not hang the system tightly in case of another failure.
Instead of concluding: what does it teach
My experience in army IT gives me two powerful skills that are now incredibly helping me in civilian business and project management.:
- Absolute composure in front of deadlines. When you submitted a project where people in uniform were responsible for the system failure in front of you, no one, even the most capricious commercial client or a "burning" release, is able to scare you anymore.
- The ability to find solutions when resources are scarce. When clouds, gigabit Internet, external libraries, and Stack Overflow are taken away from you, and the task needs to be solved by morning anyway, a completely different level of engineering thinking is activated.
In the following materials, I plan to talk about management in army IT: who set the tasks and how, what the technical specifications looked like from people in uniform, and how the demonstration of ready-made software to management took place.
Colleagues, what are the most severe infrastructural constraints that you have encountered in your practice? Let's discuss it in the comments.
Киберпанк в погонах: как устроено IT на воинской службе и чему там может научиться гражданский разработчик
Когда мы говорим об экстремальном программировании и жестких ограничениях в IT, на ум обычно приходят космические программы, финтех-гиганты под нагрузками или IoT-устройства с микроскопической памятью. Но есть еще одна сфера, о которой редко пишут на профильных ресурсах — это армейская разработка.
Я провел на воинской службе в качестве разработчика в общей сложности около 8 лет. За это время мне и моей команде пришлось столкнуться с такими инфраструктурными и архитектурными вызовами, которые гражданскому айтишнику могут присниться только в кошмаре.
В этой статье я расскажу, как разрабатывать энтерпрайз-системы в условиях полного информационного вакуума и как заставить базу данных реплицироваться посреди степи через спутниковый канал из прошлого века.
Кейс 1: Полный информационный вакуум, или Программирование по тетрадке
Главный шок для любого коммерческого разработчика, попадающего в закрытый контур — это абсолютное отсутствие интернета. У серверов нет сети, у рабочих станций нет сети, а на саму территорию строго запрещено проносить смартфоны.
Наш основной стек технологий был определен заранее и изменению не подлежал: .NET Framework и СУБД MS SQL. Все программное обеспечение было официальным и лицензированным, включая среду разработки Visual Studio. Но ты остаешься с этой студией один на один. Ты не можешь зайти на Stack Overflow, загуглить текст ошибки, подсмотреть синтаксис или за пару секунд докинуть нужный пакет через NuGet.
Как мы выкручивались:
- Код в блокноте. Если задача заходила в тупик, решать ее приходилось во внерабочее время. Вечером дома ты открываешь интернет, изучаешь документацию, находишь решение и... переписываешь нужные алгоритмы ручкой в тетрадь. Утром приносишь блокнот на службу и по своим записям вбиваешь код в проект.
- Строгий режим для флеш-носителей. Приносить домашние флешки или диски на территорию категорически запрещено. Для работы использовались только специальные, зарегистрированные служебные накопители, которые в конце каждого рабочего дня под расписку сдавались на хранение в сейф. Никакого «взять работу на дом».
- Археология локальной сети. Нашим «Гуглом» были исходники старых проектов, которые годами писали сотрудники до нас. Мы часами копались в чужом коде, выискивая похожие функции и интерфейсы, чтобы понять, как эта махина вообще функционирует.
Инсайт для бизнеса: Такие условия напрочь убивают привычку бездумно копировать готовые решения (так называемый Ctrl+C / Ctrl+V девелопмент). Ты начинаешь глубоко понимать каждую строчку кода, которую пишешь, потому что цена ошибки — это потерянный рабочий день и еще один вечер с блокнотом дома.
Кейс 2: Дата-центр на колесах и репликация на скорости 100 Кбит/с
Написать систему в изоляции — это половина дела. Самое интересное начиналось тогда, когда продукт нужно было развернуть в полевых условиях во время учений.
Для обеспечения автономности в поле выезжает КШМ (командно-штабная машина). По сути, это полноценный локальный дата-центр на колесах. Внутри машины установлен физический сервер, на котором крутится база данных MS SQL и сопутствующие сервисы. Все специалисты в полевых условиях работают со своих ноутбуков, подключаясь по локальной сети напрямую к серверу внутри КШМ. Получается изолированная распределенная экосистема.
Но данные с поля необходимо синхронизировать с центральным сервером. Для этого машина задействовала спутниковую связь. И здесь мы сталкивались с суровыми ограничениями:
- Скорость из прошлого века. Никакого полноценного интернета. Скорость передачи данных по этой закрытой спутниковой сети составляла максимум 100 Кбит/с.
- Агрессивная репликация. Чтобы данные в центре и в поле оставались актуальными, была настроена автоматическая репликация MS SQL каждые две минуты.
Каждые 120 секунд полевой и центральный сервер пытались «поговорить» друг с другом через этот узкий спутниковый канал. Связь в поле постоянно обрывалась и затухала из-за погоды или рельефа местности, но система должна была жить.
Инсайт для бизнеса: В таких условиях ты учишься ценить каждый байт. Никаких «тяжелых» запросов, никакого раздутого трафика и неоптимизированных таблиц. Весь бэкенд и структура БД вылизываются до предела, чтобы пакеты данных гарантированно пролезали в узкое горлышко связи и не вешали систему намертво при очередном сбое.
Вместо заключения: чему это учит
Опыт работы в армейском IT дает два мощных навыка, которые сейчас невероятно помогают мне в гражданском бизнесе и управлении проектами:
- Абсолютное хладнокровие перед дедлайнами. Когда ты сдавал проект, где за сбой системы перед тобой отвечали люди в погонах, тебя больше не способен напугать ни один, даже самый капризный коммерческий клиент или «горящий» релиз.
- Умение находить решения при дефиците ресурсов. Когда у тебя отбирают облака, гигабитный интернет, внешние библиотеки и Stack Overflow, а задачу все равно нужно решить к утру — включается совершенно другой уровень инженерного мышления.
В следующих материалах я планирую рассказать о менеджменте в армейском IT: кто и как ставил задачи, как выглядело ТЗ от людей в погонах и как проходила демонстрация готового софта руководству.
Коллеги, а с какими самыми жесткими инфраструктурными ограничениями сталкивались вы в своей практике? Давайте обсудим в комментариях.
Share
