Иметь некоторые проблемы – это хорошо… но они все равно остаются проблемами. Компания, у которой есть проблемы в масштабе Интернета, вероятно, растет и внедряет инновации, но такими быстрыми темпами, что текущая инфраструктура не успевает за ними. Проблема усугубляется тем, что компании не всегда знают, что у них вообще есть проблема в масштабе Интернета.
В этой статье я расскажу о происхождении и развитии проблем веб-масштаба, о том, как определить, есть ли у вас проблема веб-масштаба, и о том, как оркестровка контейнеров является наиболее элегантным решением, которое мы нашли, чтобы помочь организациям решить эти проблемы.
Ранние предупреждения
Одним из первых предвестников беспокойства в масштабах Интернета мы стали свидетелями индустрии поздравительных открыток. В течение почти 100 лет компании по производству поздравительных открыток в Соединенных Штатах работали, производя и продавая открытки, которые приклеивались к подаркам, отправлялись по почте и приклеивались на холодильники. Затем, в середине 1990-х годов, все изменилось. Это был подъем Всемирной паутины, и каждый хотел стать ее частью. В 1996 году Blue Mountain, American Greetings и Hallmark запустили дотком-сайты для обслуживания электронных открыток, и за этим последовала цифровая битва.
Я работал в индустрии поздравительных открыток, и все было связано с праздниками. День святого Валентина, День матери и Рождество — одни из самых счастливых и, не случайно, самых прибыльных времен года для компаний, производящих поздравительные открытки. По мере того как бизнес перешел в онлайн, эти крупные праздники стали полем битвы в сфере электронных открыток, сочетая в себе учения Искусство войны (Сунь Цзы) с Мифический человеко-месяц (Фред Брукс) для создания современной веб-инфраструктуры и завоевания нового цифрового бизнеса. (Сегодня мы называем это цифровой трансформацией.)
Сначала электронные открытки были бесплатными. Целью было привлечь пользователей, а не заработать деньги. Для доткомов миллионы пользователей стоили миллионы долларов в оценке компании. Какое-то время все было отлично. Все привлекали новых пользователей. Однако вскоре интернет-компаниям потребовалось зарабатывать реальные деньги. Это создало как раздоры, так и возможности.
Когда сайт AmericanGreetings.com решил начать взимать плату за электронные карты, люди не хотели платить, поэтому они заполонили сайт Hallmark.com. Компания Hallmark не смогла справиться с дополнительным трафиком и вышла из строя. Люди по-прежнему хотели отправлять электронные открытки, поэтому они вернулись на сайт AmericanGreetings.com и заплатили за их отправку. Это привело к колоссальному развитию бизнеса American Greetings, но, что более важно, подчеркнуло конкурентное преимущество, заключающееся в возможности обрабатывать не только трафик веб-масштаба, но и непредсказуемый трафик веб-масштаба.
Бизнес-урок, который мы быстро усвоили, заключался в том, что веб-инфраструктура может быть преимуществом в плане увеличения доходов.
Рассвет забот веб-масштаба
Потребители в то время с энтузиазмом относились к идее электронной коммерции, и серверам, обслуживающим небольшие интранет- и интернет-сайты, требовалось выполнять обработку транзакций через Интернет в масштабах, которые никто никогда не мог себе представить. Уже имеющиеся серверы, сетевое оборудование, устройства хранения данных и интернет-каналы не могли справиться с трафиком, создавая первые проблемы веб-масштаба для компаний, ведущих бизнес в Интернете.
В то время не существовало нестандартных решений для решения этих проблем, поэтому доткомам пришлось создавать свои собственные — посредством, по моему опыту, множества проб и ошибок и огромных страданий. Лучшие практики решения проблем веб-масштаба собирались и распространялись по всей отрасли, поскольку талантливые системные администраторы и разработчики обучали друг друга через социальные связи. Не у каждой компании были проблемы в масштабе Интернета — в основном это были стартапы и доткомы, — но те, у которых они были, начали ориентироваться на этот кадровый резерв.
Проблемы веб-масштаба становятся мейнстримом
Конечно, чисто транзакционная электронная коммерция теперь является ставкой на стол. Компании имеют системы локально, в облаке и на периферии, распределенные по платформам нескольких поставщиков. Кроме того, клиенты требуют более мощных и персонализированных приложений, не говоря уже о информации в режиме реального времени.
Масштаб и контекст проблем веб-масштаба изменились, что во многом усложняет их выявление. Вот список вопросов, которые следует задать, чтобы определить, есть ли в вашем бизнесе проблема веб-масштабирования (и насколько велика эта проблема на самом деле):
- У вас есть двусторонний рынок с сотнями или тысячами пользователей, которые покупают или потребляют ресурсы, а также десятками или сотнями ИТ-специалистов, курирующими предлагаемые услуги?
- Есть ли у вас сценарии, в которых нагрузка на систему может резко измениться за короткий период времени?
- У вас есть сотни или тысячи серверов, которые большую часть времени используются недостаточно, но иногда резко повышаются?
- Вы собираете данные, генерируемые тысячами или миллионами небольших устройств или пользователей?
- У вас есть рабочая нагрузка, которая значительно превосходит возможности одного компьютера?
- Вы разрабатываете сотни или тысячи сервисов или микросервисов?
Вы ответили «да» хотя бы на один из этих вопросов? Ты думаешь, что ты воля ответить «да» на любой из этих вопросов в течение следующих трех-пяти лет?
Элегантное решение проблем веб-масштаба
Вернувшись в American Greetings (и в течение многих лет после этого в других местах), я решал проблемы веб-масштаба с помощью программного обеспечения, эквивалентного скудным средствам и жевательной резинке. В то время наша команда использовала сочетание решений с открытым исходным кодом и собственных решений для управления одним из крупнейших веб-сайтов в Интернете. Используя такие инструменты, как Linux, Apache и собственную реплику CFEngine (да, реплику), мы смогли управлять более чем 1000 серверами и 70 приложениями примерно с тремя людьми (которых сегодня большинство назвало бы инженерами по надежности сайтов).
Эти инструменты были великолепными и передовыми для того времени, но набор примитивов более высокого уровня, которые мы использовали для определения кластеров, конечных точек сети и приложений, — это все, что мы просто придумали. Нам пришлось это сделать, потому что в те дни не существовало стандартного способа представить, определить и создать веб-приложения. Каждой компании пришлось изобретать примитивы, и каждый член команды должен был их изучить, если он хотел понять систему и создавать новые приложения или устранять неполадки в сломанных.
Раннее веб-масштабирование было похоже на первые дни существования компьютеров: если вы не знали, как использовать Windows или Linux, вы знали, как использовать конкретный компьютер, такой как COLOSSUS или ENIAC. В те первые дни веб-вычислений не было особой переносимости имеющихся у вас знаний, хотя базовые концепции (сети, балансировщики нагрузки, хранилище, веб-серверы и т. д.) применялись.
После American Greetings я работал в интернет-провайдере и компании, занимающейся веб-разработкой, и решал аналогичные проблемы для более чем 70 различных клиентов. Эта работа помогла мне осознать, что может и должен существовать стандартный способ решения проблем веб-масштаба. Вот почему я был так взволнован, когда увидел появление Kubernetes. Это изменило все. Когда я впервые увидел Kubernetes, я был невероятно взволнован. Я знал, что наконец-то появился способ решать проблемы веб-масштаба стандартным способом.
Потребность в Kubernetes
Во время сборки Kubernetes и контейнеры обеспечивают стандартизированный способ создания приложений. Каждый может научиться этому: используйте Dockerfiles/Containerfiles и зафиксируйте их в Git. Этот стандартизированный язык управления сборкой упрощает когнитивную нагрузку и позволяет перенести знания, которыми обладают SRE, в другие системы внутри вашей организации и из других организаций (что упрощает наем новых людей). Это также значительно упрощает тестирование приложений перед их запуском в производство.
Во время выполнения Kubernetes обеспечивает переносимость приложений между разными серверами в кластере, управляет аварийным переключением, управляет балансировщиками нагрузки в кластере, масштабируется при большом трафике и развертывается практически где угодно — в облаке или локально. На самом деле, когда люди говорят, что им не нужен Kubernetes, это неприятно слышать такому ветерану электронной коммерции, как я.
Моя теория заключается в том, что люди, которые говорят, что им не нужен Kubernetes, не осознают, что у них есть проблемы веб-масштаба. (И весьма вероятно, что так и есть.)
Проект Kubernetes в сочетании со многими инструментами с открытым исходным кодом, предназначенными для его дополнения, позволяет организациям эффективно удовлетворять потребности в масштабе Интернета. Заметьте, я не сказал «легко встретиться.” Я не собираюсь притворяться, что Kubernetes — это легкая задача, потому что это не так. Но помните, что проблемы веб-масштаба непросты, и в наши дни почти у каждого есть одна (или несколько) проблем. У Kubernetes есть возможности, о которых я даже не мог себе представить, когда сходил с ума, пытаясь не дать Дню святого Валентина разбить технологическое сердце моей компании.
В Red Hat Скотт Маккарти является старшим главным менеджером по продуктам RHEL Server, возможно, крупнейшего в мире подразделения программного обеспечения с открытым исходным кодом. Области фокуса включают облако, контейнеры, расширение рабочих нагрузок и автоматизацию. Тесно работая с клиентами, партнерами, инженерными командами, отделами продаж, маркетинга, другими продуктовыми командами и даже с сообществом, Скотт объединяет личный опыт с отзывами клиентов и партнеров, чтобы улучшить и адаптировать стратегические возможности Red Hat Enterprise Linux.
Скотт — ветеран стартапов в области социальных сетей, ветеран электронной коммерции и опытный государственный исследовательский технолог с опытом работы в различных компаниях и организациях: от стартапов из семи человек до технологических компаний со штатом в 12 000 человек. Кульминацией этого стал уникальный взгляд на разработку, поставку и обслуживание программного обеспечения с открытым исходным кодом.
—
Форум новых технологий предоставляет место для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор является субъективным и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговую информацию для публикации и оставляет за собой право редактировать весь предоставленный контент. Все вопросы отправляйте по адресу newtechforum@infoworld.com.
