Учимся плавать в облаках. Как создавался Digital Ocean

Моисей Урецкий, сооснователь и директор по продуктам Digital Ocean

Идея

Как возникла идея DO? На рынке уже были тысячи хостинг-провайдеров, не говоря о таких гигантах, как Amazon, Google, Microsoft. Наверняка все говорили, что ваша идея провалится?

До DO мы с бра­том мно­го лет занима­лись хос­тингом, и в какой‑то момент ста­ло понят­но, что все дви­жут­ся в сто­рону «обла­ка». Мно­гие ком­пании начали нам­ного рань­ше нас — мы и сами тог­да работа­ли с раз­личны­ми про­вай­дерами. Все они стро­или свои обла­ка так, как счи­тали нуж­ным и пра­виль­ным, но получа­лось как‑то неоп­равдан­но слож­но.

Так что мы решили, что зай­мем­ся обла­ками и сде­лаем все по‑сво­ему, соз­дадим свою вер­сию, которая пон­равит­ся нам самим, — что, навер­но, было не очень разум­но. Дело в том, что все, с кем мы это обсужда­ли, говори­ли, что это пло­хая идея и нам вооб­ще не сто­ит за это брать­ся :).

Так что, пожалуй, в этой исто­рии не было никакой магии. Была хорошо зна­комая нам область, в которой мы уже мно­го работа­ли. Нам не нра­вились пред­став­ленные на рын­ке решения, и мы захоте­ли соз­дать свое. Так воз­никла идея соз­дать неч­то, чем мы мог­ли бы поль­зовать­ся сами и пос­мотреть, не захочет ли кто‑нибудь еще тоже этим вос­поль­зовать­ся.

Кто был среди основателей, кроме вас? Вы все были программистами?

Ос­новате­лями выс­тупали я, мой брат Бен, Джефф Кар, Алек Кар­тмен и Митч Вай­нер. Все мы были раз­работ­чиками, но с раз­ными набора­ми уме­ний и с раз­ным фокусом. Бен более под­кован по час­ти работы с сетями, сис­темно­го адми­нис­три­рова­ния и управле­ния кон­фигура­циями. Джефф — спе­циалист по бэкен­дам, низ­коуров­невому прог­рамми­рова­нию. У меня — смесь из фрон­тенд‑раз­работ­ки и сис­темно­го адми­нис­три­рова­ния, плюс у меня есть художес­твен­ный бэк­гра­унд, поэто­му я прис­матри­ваю за тем, как выг­лядит наш про­дукт. Митч — наш мар­кетолог, но и он в прош­лом мно­го занимал­ся раз­работ­кой и успел осно­вать неболь­шую ком­панию, выпус­кавшую CRM-сис­тему. Алек очень хорош в Rails.

В самом начале нашей коман­ды хва­тало для решения всех задач, но потом, конеч­но, начали появ­лять­ся новые проб­лемы и приш­лось рас­ширять­ся. Все‑таки стро­ить обла­ко куда слож­нее, чем прос­то писать софт и его деп­лоить. Нап­ример, мно­гое завяза­но на физичес­кой инфраструк­туре и куче сер­веров.

Изначально вы хотели взять какие-то готовые технологии (вроде OpenStack’а)?

В самом начале раз­работ­ки мы дей­стви­тель­но пос­матри­вали на то, что мож­но было най­ти в откры­том дос­тупе. Мы выбира­ли меж­ду CloudStack, OpenStack, Eucalyptus и еще нес­коль­кими про­екта­ми, но ни один из них вос­торга у нас не вызывал. С любым из них приш­лось бы все переде­лывать под себя. Все‑таки, ког­да соз­даешь высоко­тех­нологич­ный про­дукт, ори­енти­рован­ный на раз­работ­чиков, то все внут­ренние тех­нологии и API важ­ны не мень­ше интерфей­са. Даже начина­ющий раз­работ­чик рано или поз­дно выходит за рам­ки стан­дар­тной админки, и тог­да в дело всту­пает то, что у про­дук­та находит­ся «под капотом».

Успех приходит не сразу

Как вы набрали первых пользователей? Все получилось сразу?

Мы тог­да работа­ли в ковор­кинге и прос­то положи­ли пач­ку рек­ламных лис­товок в лиф­те и приг­ласили людей опро­бовать наш новый сер­вис Digital Ocean, получить на тест бес­плат­ный облачный сер­вер. Разуме­ется, ник­то к нам не при­шел, зарегис­три­рова­лось три челове­ка и на этом все мог­ло закон­чить­ся. В общем, запуск как‑то не очень удал­ся :). Одна­ко мы вло­жили в DO такое количес­тво вре­мени и сил, что решили про­дол­жить работать.

Нам неожи­дан­но пред­ста­вил­ся шанс про­демонс­три­ровать DO на New York Tech Meetup, которую орга­низу­ет Meetup.com. Сре­ди при­сутс­тву­ющих наш­лось 700–800 очень под­кован­ных тех­ничес­ки людей, все они были в вос­торге. Пом­ню, ког­да мы про­води­ли демонс­тра­цию, мы пытались про­тес­тировать пару новых штук, нап­ример пытались выс­тро­ить интегра­цию с GitHub’ом, но все было еще не сов­сем готово, так что на сце­не нам приш­лось показать фейк и пред­ста­вить его как бета‑вер­сию.

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

А к инвесторам вы обращались, пробовали что-то еще?

Да, нап­ример, мы решили поп­робовать поучас­тво­вать в TechStar и даже ста­ли финалис­тами New York City TechStars, но Дэвид Тиш ска­зал нам: «Я не сов­сем понимаю, чем вы занима­етесь, пар­ни, потому что я не тех­нарь. Так что не уве­рен, что смо­гу вам помочь». Как бы то ни было, он посове­товал нам при­нять учас­тие в прог­рамме Boulder http://boulder.me. Мы обра­тились к ним, и они сог­ласились про­вес­ти тех­ничес­кую экспер­тизу. Но в ито­ге мы услы­шали все то же самое, что нам до это­го говори­ли дру­гие инвесто­ры: что Amazon AWS — наш круп­ней­ший кон­курент, что успе­ха не будет, что у нас ничего не получит­ся. Мы отве­тили: «Лад­но, вы „очень нам помог­ли“» — и про­дол­жили занимать­ся тем, чем занима­лись.

А потом, в янва­ре, спус­тя нес­коль­ко месяцев, мы все‑таки запус­тились. Отклик воз­ник гигант­ский и поч­ти момен­таль­но. До это­го у нас под­клю­чалось пять‑шесть человек, и вдруг все прос­то взор­валось — каж­дый день регис­три­рова­лись сот­ни раз­работ­чиков. Мы осоз­нали, что нам нуж­но немед­ленно регис­три­ровать ком­панию, нанимать под­дер­жку для поль­зовате­лей, убе­дить­ся, что сер­веров в дата‑цен­тре дос­таточ­но, и так далее. Этот про­цесс, в общем‑то, завер­телся и не прек­раща­ется по сей день. Мы очень быс­тро уве­личи­ли штат ком­пании до ста человек, но по сути, мы дела­ем все то же, что и рань­ше, прос­то воз­ника­ют новые чел­лен­джи. При этом нуж­но пос­тарать­ся не огор­чать кли­ентов, которые в нас повери­ли и полюби­ли наш про­дукт. Мы ста­раем­ся сде­лать все, что­бы отпла­тить им тем же и про­дол­жить радовать их и даль­ше.

Digital Ocean изнутри

Как со временем менялся ваш технологический стек? Вы действительно используете Go для разработки?

Лю­бая ком­пания про­ходит через одни и те же фазы. Все начина­ют с минималь­ного про­дук­та (MVP), выпус­кают про­тотип, который смог­ли соз­дать, имея в рас­поряже­нии малое количес­тво людей. В подоб­ной ситу­ации отталки­вают­ся не от нор­маль­ного пла­ниро­вания, а преж­де все­го от того, что кон­крет­ный человек хочет раз­рабаты­вать и как он будет это писать. Из‑за это­го тол­ком не пред­став­ляешь, ког­да напорешь­ся на проб­лему.

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

В общем, мы уби­ли кучу вре­мени на то, что­бы перес­тро­ить код и переп­ланиро­вать всю архи­тек­туру. И вот тог­да в наше поле зре­ния и попал Go, потому что это очень быс­трый, новый язык, в котором мно­го инте­рес­ного. Думаю, это боль­шая ред­кость — иметь иде­аль­ную тес­товую пло­щад­ку для таких вещей. А ког­да у тебя тысячи сер­веров, рас­сре­дото­чен­ных по все­му миру, Go очень естес­твен­но ложит­ся в эту рас­пре­делен­ную сис­тему.

По сути, мы прош­ли через все муки рос­та, наша работа не огра­ничи­валась соз­дани­ем новых фишек и допили­вани­ем про­дук­та. Нап­ример, пла­ниро­вание выг­лядело сле­дующим обра­зом: мы оце­нива­ли свои мас­шта­бы, умно­жали их на десять и уже на эту циф­ру опи­рались, работая со сво­ей архи­тек­турой. И поч­ти каж­дый раз, ког­да мы прак­тикова­ли это «упражне­ние», Go впи­сывал­ся иде­аль­но. К тому же люди, которым инте­ресен Go, как пра­вило, очень хорошие раз­работ­чики, и им инте­рес­ны те проб­лемы, над которы­ми работа­ем мы. Бла­года­ря это­му мы смог­ли наб­рать боль­шую коман­ду отличных инже­неров, готовую как под­держи­вать сущес­тву­ющие про­дук­ты, так и делать новые.

Что сейчас находится «под капотом» Digital Ocean? Признаться, я удивлен, что вы используете все свое.

Мы дей­стви­тель­но поч­ти не исполь­зуем сто­рон­ние инс­тру­мен­ты. Исклю­чение — некото­рые низ­коуров­невые тул­зы, но и их мало. Все, что каса­ется управле­ния, пла­ниро­вания, ивен­тов, управле­ния акка­унта­ми, мы все дела­ем сами.

Не спо­рю, OpenStack — инте­рес­ная шту­ка. Но его откры­тость силь­но пере­оце­нена — все‑таки этот про­ект раз­вива­ется ком­мерчес­кой орга­низа­цией, а это как‑то неп­равиль­но. Это не типич­ная опен­сор­сная исто­рия, в которой два‑три челове­ка соб­рались вмес­те и в сво­бод­ное вре­мя что‑то написа­ли, а потом их под­держа­ло комь­юни­ти, помог­ло им, и все ста­ли поль­зовать­ся про­дук­том. Есть немало при­меров про­ектов, которые не очень под­держи­вались сооб­щес­твом и раз­вивались в основном бла­года­ря ком­пани­ям. Поч­ти во всех слу­чаях все закан­чива­ется оди­нако­во: раз­работ­чики пыта­ются уго­дить всем сра­зу, в про­цес­се учас­тву­ет слиш­ком мно­го заин­тересо­ван­ных лиц, в ито­ге — пол­ная дезор­ганиза­ция. Мы со всех сто­рон слы­шим о проб­лемах с OpenStack и о том, что пос­ле деп­лоя все вре­мя раз­работ­чиков ухо­дит на отлов багов и попыт­ки зас­тавить все нор­маль­но работать. Мы счи­таем, что если уж тра­тить свои ресур­сы на баг­фиксы, то пусть это по край­ней мере будут наши собс­твен­ные баги.

Какое железо используете?

В основном Dell и SuperMicro. Они пос­тавля­ют надеж­ное железо, так что мы работа­ем с ними уже нес­коль­ко лет. Они очень хорошо отно­сят­ся к нам и ста­рают­ся вся­чес­ки под­держать. Нам при­ходит­ся осу­щест­влять закуп­ки в самых раз­ных стра­нах, и каж­дый новый дата‑центр толь­ко при­бав­ляет слож­ностей с логис­тикой, заказом сер­веров, их дос­тавкой, сбор­кой и так далее. Поэто­му иметь такого пар­тне­ра, как Dell, у которо­го, как пра­вило, в каж­дой стра­не есть пред­ста­витель­ство, очень удоб­но. Нап­ример, мы недав­но откры­ли дата‑центр в Амстер­даме, и на то, что­бы дос­тавить туда пар­тию сер­веров, понадо­билось 12 дней. Рань­ше это занима­ло у нас поряд­ка двух месяцев. Поэто­му мы бы и рады собирать собс­твен­ные сер­веры, но сей­час для нас основным при­ори­тетом явля­ется логис­тика.

Безопасность и другие проблемы.

Для любого PaaS и хостинга безопасность — головная боль. Особенно когда с твоих мощностей начинают делать всякие гадости. Как вы это отслеживаете, как боретесь?

Бе­зопас­ность — это боль­шая проб­лема. Мы обща­лись с раз­ными ком­пани­ями и стар­тапами, спра­шива­ли у них, какие циф­ры по абь­юзу и фро­ду наб­люда­ют они. Мы говори­ли со мно­гими круп­ными ком­пани­ями в Нью‑Йор­ке. Поряд­ка 1–2% их тран­закций — мошен­ничес­кие. Но пара про­цен­тов — это нич­то, потому что нам при­ходит­ся иметь дело с 30–40%! То есть каж­дый тре­тий зарегис­три­рован­ный поль­зователь Digital Ocean — фей­ковый.

Это дей­стви­тель­но огромная проб­лема, зат­рагива­ющая всю индус­трию. Если у тебя есть низ­коуров­невый дос­туп к сер­веру, делать мож­но что угод­но: ска­нить пор­ты, DDoS’ить, занимать­ся фишин­гом, рас­сылать спам и так далее. То есть спи­сок воз­можных гадос­тей прак­тичес­ки бес­конечен, но мно­гие зло­умыш­ленни­ки даже не понима­ют, что наносят кому‑то вред. Мно­гие из них прос­то учат­ся писать код и раз­бира­ются в тех­нологи­ях, для это­го они и занима­ются раз­ными сом­нитель­ными экспе­римен­тами. Они не понима­ют, что их пос­тупки вызыва­ют мно­жес­тво проб­лем, прос­то они любоз­натель­ны. Наша работа зак­люча­ется в том, что­бы выяв­лять такие инци­ден­ты и не мешать «законо­пос­лушным» поль­зовате­лям. К сожале­нию, это ско­рее искусс­тво, чем наука.

Но каких-то успехов вы добились?

Ко­неч­но, мы исполь­зуем мно­жес­тво раз­ных тех­нологий. Иног­да сот­рудни­чаем с дру­гими ком­пани­ями, которые спе­циали­зиру­ются на решении такого рода проб­лем, но мно­го авто­мати­зации про­изво­дим и сами. Одна­ко даже ком­пании, для которых это основная работа, где работа­ют мега­умы, гении... даже эти ком­пании ска­жут вам: «Слу­шай­те, мы пос­тепен­но этим зай­мем­ся, будем работать день за днем, но все рав­но не гаран­тиру­ем вам стоп­роцен­тно­го резуль­тата. Как толь­ко мы най­дем какое‑то решение, зло­умыш­ленни­ки при­дума­ют, как его обой­ти». Но мы это понима­ем, нор­маль­но к это­му отно­сим­ся.

Са­мая неп­рият­ная ситу­ация — это ког­да в резуль­тате авто­мати­зиро­ван­ных тес­тов нор­маль­ного поль­зовате­ля отме­чают как наруши­теля. Естес­твен­но, для них это ста­новит­ся пол­ной неожи­дан­ностью и при­водит к раз­личным проб­лемам. Мы ста­раем­ся общать­ся с такими поль­зовате­лями, объ­ясня­ем им, почему мы так пос­тупа­ем. К сожале­нию, это, конеч­но, пор­тит им весь юзер‑экспи­риенс и огор­чает их, и такие поль­зовате­ли име­ют пол­ное пра­во злить­ся и воз­мущать­ся. Но, увы, если ничего не делать, то проб­лем будет еще боль­ше, в ито­ге пос­тра­дают вооб­ще все поль­зовате­ли. Обой­ти этот воп­рос прос­то невоз­можно. Поэто­му нуж­но про­дол­жать работать, ста­рать­ся изо всех сил.

Когда речь идет о таких масштабных проектах, как DO, возможно, глупо спрашивать про главные проблемы, с которыми вы сталкивались. Но все же — что вы могли бы выделить отдельно?

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

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

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

DO сегодня

Я довольно активно использую API. За три последних года он уже дважды менялся. В чем была проблема оригинального API?

Су­щес­тву­ют ошиб­ки, которые так или ина­че совер­шают­ся; что‑то получа­ется хорошо, что‑то хуже. Пер­вый API был пот­ряса­ющий, им поль­зовалось огромное количес­тво людей по все­му миру. Но наши кли­енты «взрос­лели» и со вре­менем обна­ружи­ли ряд огра­ниче­ний. Было две основных вещи, которые мы хотели изме­нить.

Пер­вое: мы очень хотели сде­лать API пол­ностью RESTful. Ори­гиналь­ная вер­сия этим пох­вастать­ся не мог­ла, что соз­давало опре­делен­ные проб­лемы с Google, написа­нием wrappers и так далее. Это не удов­летво­ряло мно­гих.
Вто­рое: поль­зовате­ли ста­ли выт­ворять с нашим API такое, до чего мы сами бы никог­да не додума­лись. Нап­ример, люди начали писать мобиль­ные при­ложе­ния для работы с DO. Наш API не под­держи­вал OAuth, поэто­му для авто­риза­ции при­ходи­лось копиро­вать в при­ложе­ние ID и длин­нющий ключ — явно не луч­ший юзер‑экспи­риенс. Все это мы учли в новой вер­сии.

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

Какая фича в DO самая крутая, на ваш взгляд?

Я счи­таю, что самая кру­тая фича любого про­дук­та — это не то, что вы видите, а то, чего вы не видите. Ины­ми сло­вами, луч­шие фичи — те, которые мы не ста­ли внед­рять. Это осо­бен­но важ­но, ког­да речь идет о про­дук­те, ори­енти­рован­ном на раз­работ­чиков. Ког­да дела­ешь что‑то для прод­винутых поль­зовате­лей, всег­да есть желание напихать поболь­ше фун­кций и нас­тро­ек. Но в резуль­тате получа­ется неудоб­ный интерфейс и пло­хой юзер‑экспи­риенс. Так что думаю, наше глав­ное пре­иму­щес­тво — в уме­нии находить баланс.

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

Почему важно комьюнити

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

Комь­юни­ти — это, бес­спор­но, один из наших при­ори­тетов. У нас есть три глав­ных прин­ципа: любовь, прос­тота и комь­юни­ти. Все начина­ется с люб­ви — мы сами дол­жны любить свой про­дукт, ведь если даже мы его не любим, то почему его дол­жен полюбить кто‑то дру­гой? Так­же нуж­но любить сво­их поль­зовате­лей. Ког­да эти усло­вия соб­людены, ты понима­ешь, что можешь сде­лать очень мно­гое, что­бы помочь людям. Думаю, мы так плот­но на этом кон­цен­три­руем­ся, потому что без под­дер­жки, которую нам ока­зыва­ет комь­юни­ти, у нас ничего бы не выш­ло.

Речь даже не о комь­юни­ти вок­руг Digital Ocean, которое, конеч­но же, прос­то замеча­тель­ное. Речь о том, что, к при­меру, без воз­можнос­тей, которые сегод­ня пре­дос­тавля­ет Linux, не было бы DO. Linux пре­дос­тавля­ет вир­туаль­ные сер­веры, без Linux нас не было бы вов­се. Мы исполь­зуем язы­ки прог­рамми­рова­ния, за которые не про­изво­дим никаких отчисле­ний, мы не пла­тим никаким авто­рам, пра­вооб­ладате­лям и так далее.

Мне кажет­ся, для нашего поколе­ния и пос­леду­ющих это уже образ жиз­ни и дан­ность, ког­да‑то ведь такого поп­росту не было. Без это­го соз­дать ком­панию было бы куда слож­нее. Сей­час мно­гие говорят о том, что зат­раты на соз­дание ком­пании ста­ли гораз­до мень­ше, и во мно­гом это про­исхо­дит бла­года­ря open source. К при­меру, если вы решите сегод­ня запус­тить собс­твен­ный облачный хос­тинг, вы можете либо зап­латить кучу денег, либо обра­тить­ся к open source аль­тер­нативам.

А что вы, со своей стороны, делаете для комьюнити?

Мы спон­сиру­ем нес­коль­ко кон­ферен­ций, что­бы лич­но общать­ся с поль­зовате­лями. Нуж­но всег­да оста­вать­ся на свя­зи с комь­юни­ти, потому что, если не делать это­го, очень ско­ро вы перес­танете понимать, что для них важ­но. Они замеча­тель­ные, они дарят нам столь­ко люб­ви и под­дер­жки, вдох­новля­ют нас работать даль­ше. А еще прек­расно то, что они пре­дель­но чес­тны. Ког­да мы совер­шаем ошиб­ки, они поч­ти сра­зу говорят нам: «Эй, пар­ни, вы накося­чили», и это очень здо­рово. Ведь ког­да ты совер­шаешь ошиб­ку, луч­шее, что ты можешь сде­лать, — это приз­нать, что допус­тил про­мах, и работать над его исправ­лени­ем. Это очень высокая план­ка, но нам при­ходит­ся сопер­ничать с ком­пани­ями, сто­ящи­ми мил­лиар­ды дол­ларов, они вынуж­дают нас кон­куриро­вать на высоком уров­не и мотиви­руют нас делать это с позити­вом, а не сидеть в сто­рон­ке, гля­дя на этих гиган­тов, и думать: «нам такого уров­ня не дос­тичь никог­да». Они бук­валь­но при­нуж­дают нас оста­вать­ся в тонусе, сдер­живать свои обе­щания. Мне кажет­ся, мы обя­заны сво­им успе­хом имен­но это­му. Если мы про­дол­жим в том же духе, я полагаю, мы дос­тигнем еще боль­шего.