Как Изменился Процесс Поддержки Сайта За Последние Двадцать Лет



Гуру информационных технологий и технический директор журнала Ars Technica Джейсон Марлин имеет более чем двадцатилетний опыт поддержки информационных инфраструктур – и, по его мнению, в этой области многое изменилось

Как изменился процесс поддержки сайта за последние двадцать лет

Игра The Pit, которая работала как дверь BBS. На этом скриншоте Ли Хатчинсон нападает на этих парней.

Или они его.

В 1980-е годы я рос настоящим ботаником — не в хипстерском смысле, а в том смысле, что везде таскал с собой пятикилограммовый номер журнала.

Компьютерный покупатель (да, эти публикации были действительно большими).

Я увлекся системами досок объявлений, когда мне было десять лет. Неудивительно, что в итоге я стал техническим директором веб-сайта, посвященного науке и технологиям.

Я могу провести четкие параллели между работой по обслуживанию моей BBS (то есть работой сисопа) и управлением современной веб-инфраструктурой.

В честь 20-летия Ars давайте проясним эти параллели.

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



НАГРУЗКА «*», 8, 1

Мой первый опыт работы в качестве системного оператора был на Commodore 128 (разумеется, в 64-битном режиме), где я запускал программу Color 64 Грега Пфонца.

Я отправил Грегу свой чек (ну, он был подписан моей мамой) и получил 5,25-дюймовую дискету с вышитыми вручную инструкциями, напечатанными на матричном принтере.

И тут началось.

Color 64 выглядел потрясающе с ASCII, раскрашенным в соответствии со стандартами ANSI, в отличие от большинства других программ BBS, которые создавали бесцветный скучный текст. Color 64 предоставил возможность создавать пользовательский опыт. Я уже не могу вспомнить название своей BBS, но гарантирую, что основная тема была связана с драконами и/или кунг-фу.

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

К сожалению, моя сетевая инфраструктура состояла из одной телефонной линии, а это означало, что мне пришлось отключить все звонящие устройства (например, настенный дисковый телефон) и работать с 23:00. и 17:00. Это также означало небольшую интерактивность BBS. Благодаря одной линии и одному диску на Commodore 1571 пользователи не могли общаться друг с другом или загружать более одной игры одновременно.



Как изменился процесс поддержки сайта за последние двадцать лет

Commodore 1670 по-прежнему заставляет ваше сердце биться чаще В своих мечтах, в ближайшем будущем, я руководил настоящей BBS, чем-то вроде знаменитого тогда Лас-Вегаса «Страх и ненависть», который я посещал очень часто.

В моих мечтах было 10 телефонных линий, чтобы пользователи могли общаться друг с другом в реальном времени, и подключаться к модемам на скорости 1200 – нет, даже 2400 бод! И на мифическом жестком диске емкостью аж 10 Мб системы Лейтенант Кернал Будет бесконечное количество игр.

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



1990-е годы

Я продолжал возиться с программным обеспечением BBS, включая этого очень интересного предшественника HTML. Экскалибур ББС .

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



$:cd ~/public_html

Впервые я познакомился с HTML в колледже в середине 90-х; В то время я делал домашнее задание и загружал его в общедоступный домашний каталог, и учителя могли просматривать его в свободное время с помощью браузеров Netscape или Mosaic. Отличным мотиватором тогда были дополнительные 10 баллов за «использование технологий».



Apache + Perl + XML + общий хостинг

Одним из первых настоящих «приложений», которые я создал как веб-разработчик, был отдел новостей телекоммуникационной компании.

Все это работало на распространенной на тот момент комбинации: Apache как HTTP-сервер, Perl как серверный язык и база данных в виде текстового файла.

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

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

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

Взлом одной машины может поставить под угрозу сотни сайтов.



IIS, расширения и доступ FrontPage

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

К моему огорчению, это оказалась машина под управлением Windows, на которой запущен IIS (Internet Information Services).

Для меня это была совершенно новая территория, но после запуска Frontpage IDE я был поражен тем, насколько просто Microsoft упростила обычно сложную задачу по сохранению проверенных входных данных в базе данных.

(Нет, серьезно, просто потрясающе).

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

Управление IIS под Windows NT 3.5 также выглядело опасно простым для человека, имеющего опыт работы с Unix. И в то же время было ощущение жёстких ограничений — где файлы .

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

Это ужасно.



Начало 2000-х, начиная с ColdFusion.

Сейчас я понимаю весь ужас ситуации, но тогда мне очень нравилась обстановка Аллера.

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

Он работал на основе языка CFML (язык разметки ColdFusion).

Он был похож на HTML, но делал запросы к базе данных и интеграцию с внешними технологиями, такими как Java Servlets или CORBA, тривиальными.

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



Появляются веб-фреймворки

Очень низкий входной барьер ColdFusion заработал ему плохую репутацию языка для идиотов, привлекающего в эту область программистов низкого уровня - так же, как когда-то это делал PHP. Не могу с этим поспорить, но ирония в том, что мое первое знакомство с хорошим веб-фреймворком произошло в виде Блок предохранителей .

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

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

я играл с Стойки , но так как на основной работе использовать Java было невозможно, я так и не научился этому.

Но Fusebox открыл мне глаза на платформы с парадигмой, выходящей за рамки конкретных языков.

MVC (контроллер представления модели).

И это было за много лет до появления того умопомрачительного 15-минутная презентация Рубин на рельсах сделал Дэвид Хайнемайер Ханссон .

Сегодня я бы никогда не рассматривал возможность создания большого приложения без выбора платформы, и сегодня у нас есть много интересных вариантов на выбор.

Для PHP мне это нравится больше всего Ларавел .

Да, тогда это было просто сногсшибательно.



Кластерный веб-хостинг

Мой первый опыт работы с сайтом с высокой посещаемостью был в 2002 году.

По мере роста трафика росла и ответственность, а также количество звонков посреди ночи с требованием перезагрузить сервер.

И наконец, я решил узнать всё о балансировке нагрузки, кэшировании и хостинге кластеров.

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

Если одна машина выходила из строя, у нас были машины безопасности, чтобы убедиться, что все работает. У нас была аналитика и подробные метрики по кластеру.

Жизнь была прекрасна, как и моя мечта.



Расцвет виртуальных машин: AWS, Vagrant

AWS (Amazon Web Services) появился словно из ниоткуда и дал разработчикам именно то, что нам было нужно.

Они также исключили посредников из традиционного хостинга.

Нам не нужно было спрашивать, какие технологии нам разрешено использовать; внезапно все показалось возможным.

Хотите попробовать создать приложение на Django или NodeJS? Без проблем.

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

Он превратился в самодельный центр обработки данных — и это было одновременно проклятием и благословением.

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

Чрезмерно увлеченному разработчику было очень легко откусить больше, чем он мог проглотить.

Что AWS сделал возможным в облаке Бродяга сделал это возможным на рабочей машине.

Vagrant предоставил нам простой доступ с возможностью сценариев к различным поставщикам виртуальных машин.

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

Если во время установки что-то пошло не так, простая команда vagrant Destroy позволяла начать все сначала с тем же образом.

Это сделало разработку гораздо более приятной, чем запуск серверов на домашней ОС или непосредственно с использованием VMWare или VirtualBox.

2010-е – от веб-мастеров до DevOps

Давайте немного замедлим шаг и поговорим о том, как я всегда ненавидел термин «веб-мастер».

Мужчина: Чем ты занимаешься в жизни? Я: создание крутых веб-приложений с использованием различных языков программирования и работа с инфраструктурой.

Мужчина: Аааа, так ты ВЕБ-МАСТЕР!

Я хочу вывести это отвратительное слово из употребления.

Если не считать того, что оно напоминает 20-гранную игральную кость, оно не совсем описывает роль, которую многие из нас играют в программировании и управлении инфраструктурой.

Вот почему мне нравится этот сдвиг за последнее десятилетие в сторону более уважаемых терминов, таких как DevOps .

Инженеры DevOps используют программирование для создания, управления и документирования реальной инфраструктуры.



Шеф + Ансибль

Когда я начинал в Ars Technica, мы хотели иметь возможность легко добавлять или удалять веб-серверы и серверы баз данных в виртуализированной среде.

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

Узнав, как свойства переменных или «атрибуты», как они здесь называются, вытекают из ролей и сводятся к отдельным узлам, становится очень просто управлять серверным программным обеспечением и версиями с единой платформы.

Chef позволил нам отказаться от микроуправления отдельными серверами в кластерах и облегчил задачу массовых обновлений.

Сегодня я лично предпочитаю работать с Анзибль , система на основе Python, разработанная Redhat, с которой проще работать и она немного менее хрупка при работе в небольших организациях.

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

Уже несколько лет мы принимаем гостей СерверЦентральная группа Тьюринга .

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

неудачи.



2019 г.

и далее

Я всегда буду испытывать ностальгию по тем безмятежным дням ручного ввода команд модема, когда где-то на горизонте появлялись обещания " Газонокосилка или Hal 9000. Но текущий момент также содержит захватывающие возможности для следующего этапа развития инфраструктуры.

Есть еще очень много многообещающих инструментов, которые мы планируем внедрить в действие, например Докер Рой или Кубернетес .

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

Так что пожелаем нам успехов в ближайшие 20 лет! Теги: #История ИТ #Администрирование серверов #Разработка веб-сайтов #веб #сайты #модем #bbs

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.