Переехали от Майкрософта

Произошло то, о чем я давно думал, но боялся сказать. Хотелось перестать «кормить» Майкрософт.

Этот монополист настолько обленился делать вещи качественно, что еще год назад внутренняя изжога к Виндовсу привела меня к мысли, что от серверов на Винде надо уходить… Как это сделать, если C# на Линуксе через Mono в нашем случае прямо не заработает? Плюс еще MSSQL, от которого тоже нужно было уйти.

Не уложились мы в месяц, как было задумано изначально тут. Не уложились и в два. И даже в три не уложимся, потому что проблем оказалось сполна. Время и деньги потеряны… Но также к счастью мы больше не тратим по 15К в месяц на Ажуру. А имеем контейнер за меньшую цену, в котором можем разворачивать еще и несколько схожих по конфигурации с Ажурой VDS’ок для своей работы.

Мой ультиматум про «не уложимся с миграцией в 1 месяц — уходим с Шарпа» был вполне конкретным критерием, чтобы от слов перейти к действиям и инициировать перепись проекта на другой ЯП. Логика простая — если быстро получилось мигрировать, хорошо, давайте пока дальше наращивать функционал на том решение, что есть. Если быстро не получается — то сразу по окончания месяца я не трачу времени на раздумья как долго еще это продлится и сколько денег мы еще сольем на простой (была заблокирована полностью разработка нового функционала) — я ищу программистов для разработки нового бэк-энда. Что имеет смысл. Первое, сократить расход с Винды, раз уж начали, но одновременно с этим перестать тратить время впринципе на толкание трупа. Сейчас в коде имеется и лишний функционал, и структурные ошибки в проектировании помимо всего того что про миграцию. Все это «обслуживать» очень дорого. К слову, новое АПИ я сократил примерно на 40%. Более того, мы пошли дальше и планируем использовать конструктор запросов с фронт-энда, чтобы бек-энд вообще стал гибчайшим и не был завязан на конкретные методы.

Найти программеров оказалось непросто, в одном случае я ошибся с постановкой требований и связка Python/Django оказалась избыточной для решения моей задачи. Один программер проработал неделю, написал код и с ним решено было прекратить — результат получался не очень.

Сейчас успокоились и пришли к Python/Flask. Цель — построить новый бэк-энд более просто, чтобы задествовать принцип «меньше кодов — меньше багов» и чтобы код можно было поддерживать меньшему числу программистов.

Касаемо пункта про «высокую цену» за Windwos. Я косякнул, когда поставил задачу именно как миграцию на Linux. Никакого переезда на другую ОС можно было бы и не затевать. Расходы реально сократить иначе.

Изначально мы сливали на MSSQL Enterpirse, плату за которую нам включили из-под тишка, когда мы этого не ждали, и которую мы потом перенесли в Ажуру в облачный SQL сервер, который построил Джек Майкрософт. Шутка. Первая проблема была решена сразу. Вторая — количество баз — четыре. Каждая из которых съедала по тысячи с чем-то в месяц. Можно было две удалить, ибо девелоперские, вторую перенести в первую, приложение это позволяло. Итого расход уменьшался на 3 тысячи — на фоне 20-25К это конечно казалось смехом, так что я понимал, но не брал всерьез. Третье — мы периодически включали обратно девелоперский и прошлые серваки. Из-за этого расход в 20-25К был раздут, на деле вся требуемая конфигурация на Ажуре съедала 12К в месяц.

Соответственно сам Ажуровский сервак можно было бы заменить таким же по мощности с помощью Российских хостинг-провайдеров, по нашим конкурентным, рыночным ценам. Получилось бы 3000-4000 р за Винду плюс 1-1,5 тыс. за базу в облаке. Базу MSSQL перенести в Россию получалось или дорого, или геморно, потому что подход к лицензированию у MSSQL весьма своеобразный (можете почитать об этом на сайтах дата центров). Основной минус такого подхода — это то, что база и приложение были бы вынесены из одной сети на разные сервера, удаленные на существенное расстояние (следовательно получаем дополнительное время на коннект).

Но сделать такую миграцию стоило сразу, это бы сократило расходы быстро и существенно. Затем стоило продолжить работу на Винде и Шарпе, и параллельно начать кодить новый бэк-энд. Стоит ли вообще кодить новый бэк-энд? Работы на 4-5 месяцев минимум. Скорее да. Текущие программеры в виду того, что обстоятельства изменились, не могут полноценно уделять время разработке, а искать нового человека на Шарп или Пайтон, в свете того, что рефакторинг даже в нашем текущем решении — это назревшая необходимость, как-бы говорит — рискни и сделай как считаешь нужным. Вот я и делаю. Думаю, что получится лучше, чем было.

Один минус — некоторых людей я заставил ждать несколько месяцев того, о чем мы договаривались еще в конце 2016 года. К сожалению, сроки не выдержал. Но и откладывать миграцию больше не хотел, об этом я задумывался еще в конце 2015 года. Следующее поколение Avenda уже запущено. Скоро, на всех картодромах страны! 🙂

Добавить комментарий