Month: May 2014

Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.

На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.

Но это же не интересно и писать не о чем. Поэтому давайте я опишу личные впечатления о разных системах, которые можно заиспользовать.

Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.

VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.

Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.

KVM. На самом деле это простой гипервизор, который есть в любом дистрибутиве линукса. Управляется исключительно из командной строки. Но благодаря поддержке гигантов, оброс различными системами управления и надстройками, которые позволяют конкурировать с системами на базе VMware. RedHat использует именно его.

Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).

VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.

В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.

По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.

К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.

В общем, крайне рекомендую перед окончательным выбором протестировать все системы под свои требования. Благо у всех систем есть триальные версии.

Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.

Если помните, то в предыдущей части вы разрисовывали связи и самое большое число связей получилось у сети и дисков. Вот эти две штуки и являются самыми больными частями в любом облаке. Любая неполадка или задержка вызывает вал проблем, который остановить очень сложно.

За что борются инженеры?

Во-первых, за скорость. Диск и сеть должны выдавать максимальные значения, дабы уменьшить простой процессоров на нодах.

Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.

Какие основные методы применяют?

Во-первых, разделение машин по функционалу. Скажем, у вас есть 10 веб-серверов. Предположим, что внутри каждого веб-сервера есть сам веб-сервер с каким-то движком (типа php или java) и SQL сервер. Простой вынос всех этих десяти маленьких SQL серверов на один (хорошо, на два, если нужна отказоустойчивость), но которому отдали их ресурсы, уже приведет к увеличению производительности.

Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.

Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.

Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».

Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.

Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.

Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …

Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!

SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.

Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.

Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.

В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.

Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.

И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.

Думаю, я достаточно загрузил вас. Пора немного прерваться.

И да, я опять спер картинку

Данный текст я решил написать в расчете на ИТшников, которые уже задумались про перевод своей инфраструктуры в «облака» и теперь думают, как же это сделать. На мой взгляд, в интернете слишком много уделяется внимания тому, как надо покупать «облака» (дальше буду без кавычек), а не тому, как их использовать, создавать или как они устроены. Дескать, это сложная наука, подвластная только крутым специалистам с кучей дипломов. Ну или интеграторам с такими специалистами в штате. Стоимость подобных облаков обычно получается какая-то негуманная. А если упомянуть про про bigdata, DWH и прочие слова из буклетиков, то к ценнику добавляется нолик-другой.

На самом деле, все не так страшно и я попытаюсь доказать вам это. Может быть даже с примерами и рисуночками.

И да, обычное предупреждение: я рассказываю на основе своего опыта и могу быть неправым от и до. Но вроде созданные системы выполняют свои задачи и жужжат совершенно по делу.

Для начала надо определиться, что же такое облако и с чем его можно есть.

Для ИТшников это куча физических серверов, которые с помощью какой-то системы крутят много сервисов. Сервисам выделяются ресурсы по необходимости или по требованию. Сервисы могут мигрировать с сервера на сервер, размножаться или уничтожаться. Или говоря другими словами, обычный набор железок, который можно встретить в любой серверной.

Для обычных же людей это некая сущность, которая предоставляет им сервисы по формуле «дешевле, быстрее, надежнее: выбери два из трех». Опять ничего нового.

Всякие слова про масштабируемость, отказоустойчивость и прочее можно оставить маркетингу. Методы реализации этого великолепия известны очень давно и облака ничего нового в этом плане не открыли, а просто сильно упростили.

Как-то грустно получается, не находите? Почему же облака так стали популярны? Дело в том, что появились новые методы использования доступных мощностей. И как раз они основаны на сильном упрощении процесса обеспечения тех самых «масштабируемостей», «отказоустойчивостей» и прочего.
В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
– Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
– Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
– Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.

Остальные преимущества в принципе либо укладываются в эти пункты, либо проистекают из них. Давайте я попробую раскрыть эти пункты на примере наиболее распространенных решений.

Для начала про повышение надежности и снижение стоимости. Откуда это получается? Во-первых, обслуживать настроенные однотипно сервера гораздо проще, чем обычный зоопарк. Одни и те же версии программного обеспечения, одно и то же железо. Это дает выигрыш как во времени работы инженеров, так и позволяет получать скидки от вендоров. Во-вторых, возможность вывести любой сервер из кластера для обслуживания. Просто даем команду системе виртуализации убрать с него все сервисы и спокойно занимаемся необходимым. Тем более такую команду может дать и система мониторинга в случае превышения каких-либо значений типа температуры процессора или скорости вращения вентиляторов. И в-третьих, система мониторинга может дать и другую команду: добавить ресурсов «задыхающемуся» сервису. Думаю, любой ИТшник сразу же найдет кучу применений этим возможностям.

«Публичные» и «гибридные» облака благодаря этому и обладают возможностью на время получить буквально на час огромные ресурсы, за которые в обычном случае пришлось заплатить очень дорого. Например, я знаю рекламные агентства, которые в облаке арендуют мощности для обсчета роликов.

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками. И которые связывают с преимуществами для бизнеса.

Вот скажем bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения.Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять не охота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом бигдачность системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI. Или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМов и поэтому в последнее время развивается очень сильно.

DWH или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие система анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общем знаменателям, группируются и так далее и тому подобное. По понятным причинам DWH очень любят всякие финансовые компании.

Ладно, хватит красивых слов, тем более, что интересующиеся могут спокойно напрячь поисковик и начитаться по любому интересующемуся термину. Пойдем практиковаться.

Планируем облако.

Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нету аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и все обдумав, отвечаете на следующие вопросы:

– Время работы сервиса. Круглосуточно, ночью, днем в рабочие часы. Бухгалтерия ночью не работает, а веб-сайт должен быть доступен круглосуточно.

– Доступность сервиса. Может ли он делать паузы во время работы? Скажем на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.

– Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТшники их спрашивают про их тяжелую долю и пытаются ее облегчить.

– Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов вовремя этого пика. А тот же веб-сервер толерантен к таким проблемам.

– Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.

– Сложность обслуживания? Сколько ИТшников в среднем требуется для обслуживания этого сервиса. Стоимость ИТшника?

– Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.

– Зависимость сервиса. Скажем, бухгалтерия не выживет на одном офисе без бухгалтерской системы, ей будет очень плохо без сервиса печати, чуть полегче без телефонов и ей абсолютно будет начихать на веб-сайт. Но все умрет без работающей системы хранения данных.

– Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.

– Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.

– Сложность масштабирования системы в зависимости от нагрузки. Веб-сайты обычно довольно легко сделать масштабируемыми, а вот телефонию без бутылки не отмасштабируешь. Тут очень хорошо подумать, а какие функции этого сервиса можно отдать наружу.

При этом очень желательно максимально детализировать сервисы. Скажем типичный веб сервис на самом деле состоит из кеширующего сервера, веб-сервера, сервера базы данных и сервера хранения данных. Чем более высокой будет детализация, тем в дальнейшем будет проще.

Это очень нудная, сложная и муторная работа (хотя и должна быть сделана в рамках ITIL/ITSM). Но в качестве утешения я вам обещаю, что вовремя или после процесса вы обнаружите кучу интересных вещей, которые были раньше скрыты.

Кстати, рекомендую сразу же вооружиться чем-нибудь типа visio (или хотя бы листочком с бумагой, но лучше visio) и сразу зарисовывать получаемые ответы. Я рисовать не буду, ибо мне попросту жалко своего времени, ибо это работа огромная и впустую ее делать лень.

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

Следующим по числу «использований» будет сервер баз данных. Но большая часть будет с двумя линиями – к серверу приложений и к хранилищу данных. Зато этих серверов баз данных будет много. Веб-сервер, бухгалтерия, мониторинг, чертлысый – и везде какой-нибудь да серверок будет.

В принципе, уже полученную схему можно распечатывать и вешать на стенку. Непосвященные люди будут впечатляться и водить пальцами по бумаге, отслеживая линии.

Теперь настала пора взять в руки краски и любым приятным способом раскрасить сервера по критичности для бизнеса. При этом рекомендую брать как минимум два цвета: один для «критичный всегда», а второй для «критичный только в рабочее время». Скажу сразу, если у вас получилось, что все сервисы «критичные всегда», то что-то вы не так сделали. Весь мой опыт говорит о том, что так не бывает. Понижайте градус критичности.

Затем закрашивайте тем же цветом те сервисы, от которых зависит данный сервис. Скажем, если вы пометили, что телефония у вас критичная, то следом должны стать критичными «интернет», «локалка», «фаерволл», «сервер данных о пользователях» и стораджи, на которых все это лежит. Ведь без любого из этих сервисов телефония попросту не будет работать. Скажем, отнимаем интернет или фаерволл – перестаем принимать звонки из внешнего мира. Убираем локалку – пользователи перестанут получать звонки. При закраске необходимо строго соблюдать уровень критичности по повышению – если сервис «критичен всегда», то он не может быть перекрашен или зависим от «критичен только в рабочее время».

Данный процесс очень напоминает настройку сервисов в системе мониторинга или для change management из ITSM, поэтому эта работа или уже сделана или должна быть сделана. Поэтому в любом случае работа не будет сделана впустую.

Следующим шагом необходимо изучить у критичных сервисов механизм масштабирования и его стоимость. Где-то будет все просто: добавляем кучку однотипных сервисов и все будет в порядке. А где-то дешевле ограничиться добавлением аппаратных ресурсов. Тут можно покрасить разным цветом рамки или еще как-нибудь разделить «хорошо масштабируемые» от «плохо».

И я очень надеюсь, что вы использовали visio или что-то подобное. Для понимания текущей ситуации очень полезно сгруппировать сервера по критичности/доступности/расположению (как вам больше нужно).

И наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервера большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?

В результате у вас получится большая портянка, по которой будет сразу понятно, какой сервис выгодно тащить в облако, для какого лучше построить локальный кластер (и какими ресурсами он должен обладать), а какие реализовать по остаточному принципу или вообще оставить на отдельных машинах.

Теперь необходимо причесать картинку и полученную табличку, чтобы получить практически непотопляемые аргументы для любого совета директоров/ акционеров/ финансистов/ ещекого. Эти люди по роду своей деятельности очень любят картинки, которые подкреплены реальными цифрами.

Наиболее внимательные сразу отметят один очень важный момент, который вроде нигде не упомянут: а как выбирать систему виртуализации? Ведь ее тоже необходимо закладывать в бюджет.

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем он будет более «продвинутей», тем больше шансов, что у вас все взлетит.

И да, картинку спер из интернета. Автора не знаю, а то бы написал.