При использовании платформы в качестве услуги (PaaS) работа ведется на более высоком уровне абстракции, чем когда дело касается отдельного хоста. Большинство таких платформ полагаются на принятие артефактов с конкретными технологиями, такими как Java WAR-файл или gem-пакет Ruby, и автоматически предоставляют и запускают их для вас. Некоторые из этих платформ будут самостоятельно пытаться подгонять под ваши нужды масштаб системы вверх и вниз, хотя более распространенный (и, исходя из моего опыта, менее подверженный ошибкам) способ позволяет сохранить за вами контроль над количеством узлов, на которых может быть запущен сервис, справляясь со всем остальным самостоятельно.
На момент написания этих строк большинство самых лучших, наиболее совершенных решений PaaS уже было принято. Когда думаешь о первоклассных средствах в этой области, на память приходит Heroku. Эта платформа не только справляется с запуском вашего сервиса, но и с легкостью поддерживает такие сервисы, как базы данных.
В этой области есть и самостоятельно принимаемые решения, хотя они и менее зрелые, чем те решения, которые уже были приняты.
Когда PaaS-решения работают хорошо, то качества их работы вполне достаточно. Но когда они подходят вам не в полной мере, зачастую вы испытываете дефицит контроля в области внесения каких-либо внутренних исправлений. В этом заключается часть принимаемых нами компромиссов. Хочу заметить, что, исходя из моего опыта, чем более интеллектуальными пытаются быть PaaS-решения, тем чаще допускают ошибки. Мне приходилось пользоваться несколькими PaaS-платформами, которые пытались выполнять автоматическое масштабирование на основе востребованности приложением, но делали это крайне неудачно. Конечно же, эвристика, являющаяся движущим механизмом этого интеллекта, старается подстроиться под некое среднее приложение, а не под ваш конкретный случай. Чем более нестандартный характер имеет приложение, тем выше вероятность того, что оно не сможет идеально сработаться с PaaS-платформой.
Поскольку качественные PaaS-решения справляются с решением довольно многих задач за вас, они могут стать замечательным способом избавления от растущих издержек, возникающих с появлением все большего количества движущихся частей. И тем не менее я все еще не уверен, что в это пространство укладываются абсолютно все модели, а ограниченные, самостоятельно принимаемые варианты означают, что этот подход для решения ваших задач может не сработать. Но я ожидаю, что в ближайшее десятилетие мы станем скорее нацеливаться на развертывание PaaS-платформы, чем развертывать отдельные сервисы на самоуправляемых хостах.
Ответ на столь большое количество вопросов, заданных до сих пор, сводится к автоматизации. При небольшом количестве машин всем можно управлять вручную. Для меня это дело привычное. Помню, когда в работе был небольшой набор производственных машин, я собирал регистрируемые данные, развертывал программные средства и контролировал процессы, заходя в вычислительную систему вручную. Казалось, что моя продуктивность была ограничена количеством окон терминала, открываемых одновременно, а второй монитор стал огромным шагом вперед. Но все это рухнуло очень быстро.
Один из негативных взглядов на размещение по одному сервису на каждом хосте основывался на впечатлении, что объем накладных расходов на управление этими хостами будет увеличиваться. И это действительно так, если все делать вручную. Удваивается количество серверов, удваивается и объем работы! Но если автоматизировать управление хостами и развертывание сервисов, тогда не станет причин для линейного роста объема рабочей нагрузки в зависимости от количества добавляемых хостов.
Но даже при сохранении небольшого количества хостов мы все же собираемся манипулировать большим количеством сервисов. Это означает, что нужно справляться с несколькими развертываниями, отслеживать работу нескольких сервисов и собирать регистрируемые данные. И автоматизация в этом деле играет весьма важную роль.
Автоматизация может обеспечить также поддержание высокой продуктивности разработчиков. Ключом для облегчения жизни разработчиков является предоставление им возможности обеспечения самообслуживания отдельных сервисов и групп сервисов. В идеале разработчики должны иметь доступ абсолютно к такой же цепочке инструментов, которая используется для развертывания сервисов в производственном режиме, чтобы можно было обнаруживать проблемы на самых ранних стадиях. В данной главе будут рассмотрены многие технологии, включающие это представление.
Выбор технологии автоматизации играет весьма важную роль. Он начинается со средств управления хостами. Можете ли вы написать строку кода для запуска виртуальной машины или ее выключения? Можете ли провести автоматическое развертывание написанной вами программы? Можете ли развернуть изменения, внесенные в базу данных без ручного вмешательства? Если вы хотите справиться со сложностями архитектур микросервисов, то без усвоения культуры автоматизации вам не обойтись.
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии