Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Как организовать в компании небольшие независимые команды, когда работа замыкается на общий код, который они пишут? Они не могут по-настоящему работать независимо, если изменения, внесенные одной командой, нарушают код, который создали другие команды. Такой продукт просто не будет работать.

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

Микросервисы поставлялись не как часть кода, не как сайт, а как онлайновые API. API – это четко определенные интерфейсы, которые позволяют коду общаться с другими частями кода. Когда команда создает и предоставляет API другим, важно, чтобы она научила других пользоваться им с помощью точной и актуальной документации. Таким образом, в Amazon сформировалась внутренняя культура API-документации. Одна команда могла найти API-документацию другой команды и пользоваться ее сервисами нередко даже без прямого общения. Это позволило командам эффективно работать вместе и решить проблему координации.

Следующая проблема заключалась в оценке эффективности каждого из этих сервисов и учете того, куда уходят деньги. Если одна команда запустила свой сервис на 10 000 серверов, это хорошо или ужасно неэффективно? И на какую бизнес-цель следует относить затраты? Поэтому Amazon начала списывать затраты на использование этих сервисов даже внутри компании. Некоторые называют это трансфертным ценообразованием, но фактически такая система решает две задачи: делает команды ответственными за свои расходы и помогает принимать решения о том, на что закладывать больше средств в бюджетах.

Небольшие команды отвечают за эффективность своих сервисов, поскольку они по существу называют «цену» для внутренних клиентов, а последним приходится покрывать затраты из своих средств. Если эти «клиенты» недовольны вашей ценой, значит, вам есть над чем работать. Внутренняя система учета согласовывает интересы всех сторон и создает естественный стимул для повышения эффективности с течением времени. Внутреннее ценообразование также позволяет лидерам принимать правильные бюджетные решения. Представьте, что у вас есть два клиентских продукта, один из них приносит доход $100 млн и быстро растет, а другой – $10 млн и растет медленно. На какой из них вы выделите больший бюджет? Ответ очевиден, когда у вас есть показатель в виде дохода. То же самое касается и внутренних сервисов. Когда сервис широко используется внутренними клиентами и быстро растет, вы должны выделять на него больше средств. Но без показателя, позволяющего сравнивать инициативы, трудно сказать, какие команды нуждаются в дополнительных инвестициях. Вот почему введение цены даже для внутренних клиентов чрезвычайно полезно.

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

Вскоре стало понятно, что можно делать бизнес на создании микросервисов и их продаже другим. Компания New Relic, основанная в 2008 г., выпустила программу, которая отслеживает результаты работы сайта. Компания Stripe создала платежные сервисы. Компания Twilio разработала облачную коммуникационную платформу. Еще один пример – Google Maps. С помощью всего лишь нескольких строк кода разработчики могут встроить этот сервис в свой сайт. Это намного лучше, чем самостоятельно запускать автомобили с камерами на крыше на улицы городов мира, а затем создавать карты с аэрофотоснимками, видами улиц и всеми другими функциями, которые уже имеются у Google Maps. Ценностное предложение здесь довольно очевидно.

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

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

Создать и купить

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

«Высокотехнологичные компании постоянно обсуждают, какие микросервисы создавать, а какие покупать, – говорит Эштон Катчер, инвестировавший в десятки стартапов и записавший на свой счет несколько крупных коммерческих побед, в первую очередь сервисы Airbnb, Spotify и Uber. – Полагаю, что та часть ПО, которую вы не создаете, так же важна, как и часть, создаваемая самостоятельно. Единственное, что компании должны неизменно создавать сами, так это ключевые элементы их бизнеса. Люди очень часто занимаются созданием того, что уже существует в виде продукта, который можно сравнительно дешево купить или использовать по лицензии. Нужно ли создать собственную систему учета трудозатрат и начисления заработной платы? Я бы никогда не попытался