Создание облачного сервиса


Создание своей облачной системы за час / Habr

В последнее время появилась возможность создать свой облачный сервис (IaaS) без усилий и программирования. В простейшем случае можно создать Cloud-In-A-Box используя всего один компьютер с процессором который поддерживает виртуализацию. Данное облако имеет свои ограничения и, по-моему, подходит только для тренировки. Если у вас есть две машины с процессорами которые поддерживают виртуализацию, то можно создать полноценное облако пригодное для тестирования и разработки облачных решений. Недавно компания Eucalyptus представила новую версию своего продукта Eucalyptus 3.4. С помощью программы FastStart можно создать полноценную AWS и S3 совместимую IaaS систему без усилий и глубоких знаний продукта.

Я использовал две Intel NUC машины для установки Eucalyptus. Так как у NUC нет дисковода, то я воспользовался CentOS 6.2 машиной для создания загрузочного USB ключа. Для начала надо получить FastStart ISO зайдя на www.eucalyptus.com/eucalyptus-cloud/get-started/try#faststart. После этого создать загрузочный ключ. Я использовал UNetbootin для создания ключа. Не забудьте скопировать FastStart ISO на ключ после окончания работы UNetbootin. На моей машине UNetbootin оставил файловую систему на ключе в read-only режиме после окончания работы и надо было сделать umount и mount ключа для записи файла.

Перед началом инсталляции решите какие IP вы присвоите машинам и какие будете использовать для виртуальных машин в вашем облаке. Я решил присвоить 192.168.10.1 Frontend машине, 192.168.10.2 Node Controller(NC) и использовать 192.168.9.1-192.168.9.100 для публичных адресов виртуальных машин. Убедитесь, что ваши сетевые настройки позволяют задавать машинам статические IP. Если это невозможно вам придется использовать DHCP, что чревато проблемами если сервера получат новые IP после инсталляции системы. Так, что я бы рекомендовал использовать статические IP.

После создания ключа загрузите первую машину с USB. Сначала я установил Node Controller. При инсталляции помимо нескольких стандартных вопросов CentOS мне надо было ввести IP сервера, маску сети, Default Gateway и DNS.

После создания NC я загрузил вторую машину с USB и выбрал Install CentOS 6 with Eucalyptus Frontend в меню. При инсталляции было задано несколько дополнительных вопросов про сетевые настройки и публичные и закрытые адреса для виртуальных машин. Для публичных я выбрал вышеуказанный диапазон, а для закрытых предложенный системой 172.31.Х.Х диапазон. После, когда система предложила зарегистрировать NC, я указал адрес первой созданной машины 192.168.10.2. И это все. После перезагрузки я получил работающую облачную систему.

Для работы с ней можно использовать как UI так и командную строку. После инсталляции система сообщает все параметры для работы с облаком. Если вы что-то забыл просто зайдите на Frontend машину по ssh и вы получите напоминание как это:

 [[email protected] ~]$ ssh [email protected] [email protected]'s password: Last login: Wed Oct 30 14:45:12 2013 from 192.168.1.183 User Console URL (for managing instances, volumes, etc.): https://192.168.10.1:8888/ User Credentials: * Account: demo * Username: admin * Password: password Admin Console URL (for managing user accounts, VM types, etc.): https://192.168.10.1:8443 Admin Credentials: * Account: eucalyptus * Username: admin * Password: admin 

Для работы через UI перейдите по адресу указанному выше

https://192.168.10.1:8888/

Введите ваши данные для demo пользователя и можно начать работать. По умолчанию в системе уже есть один образ на базе CentOS 6.4 и созданы несколько ключей. Так что можно сразу запустить виртуальную машину.

Для работы с командной строкой зайдите по ssh на Frontend машину. И загрузите переменные окружения для одного из двух созданных по умолчанию пользователей. Например:

 . ~/credentials/admin/eucarc 

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

 [[email protected] ~]# euca-describe-availability-zones verbose AVAILABILITYZONE CLUSTER01 192.168.10.1 arn:euca:eucalyptus:CLUSTER01:cluster:cc_01/ AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0005 / 0008 1 256 5 AVAILABILITYZONE |- t1.micro 0005 / 0008 1 256 5 AVAILABILITYZONE |- m1.medium 0005 / 0006 1 512 10 AVAILABILITYZONE |- c1.medium 0002 / 0004 2 512 10 AVAILABILITYZONE |- m1.large 0002 / 0004 2 512 10 AVAILABILITYZONE |- m1.xlarge 0002 / 0004 2 1024 10 AVAILABILITYZONE |- c1.xlarge 0002 / 0004 2 2048 10 AVAILABILITYZONE |- m2.xlarge 0002 / 0004 2 2048 10 AVAILABILITYZONE |- m3.xlarge 0001 / 0002 4 2048 15 AVAILABILITYZONE |- m2.2xlarge 0001 / 0002 2 4096 30 AVAILABILITYZONE |- m3.2xlarge 0001 / 0002 4 4096 30 AVAILABILITYZONE |- cc1.4xlarge 0000 / 0001 8 3072 60 AVAILABILITYZONE |- m2.4xlarge 0000 / 0001 8 4096 60 AVAILABILITYZONE |- hi1.4xlarge 0000 / 0000 8 6144 120 AVAILABILITYZONE |- cc2.8xlarge 0000 / 0000 16 6144 120 AVAILABILITYZONE |- cg1.4xlarge 0000 / 0000 16 12288 200 AVAILABILITYZONE |- cr1.8xlarge 0000 / 0000 16 16384 240 AVAILABILITYZONE |- hs1.8xlarge 0000 / 0000 48 119808 24000 

На моей NC машине стоит 4-х ядерный процессор и 128 GB диск. По умолчанию, после установки я мог бы запустить до 4-х виртуальных машин. Но как вы видите, система предлагает запустить до 8 виртуальных машин. Что бы этого добиться зайдите по ssh на NC машину и отредактируйте несколько переменных в /etc/eucalyptus/eucalyptus.conf файле. Я поставил:

 MAX_CORES="8" NC_WORK_SIZE=70000 

После этого надо перезапустить NC процес /etc/init.d/eucalyptus-nc restart и в моем распоряжении оказалось в двое больше ресурсов. Я бы не стал злоупотреблять с изменением числа процессоров, но удвоить их, думаю, смело можно если виртуальные машины не будут использовать 100% своих процессорных мощностей.

Если вам привычнее использовать русскоязычный интерфейс в UI, то можно поменять языковые настройки UI. Для этого зайдите по ssh на Frontend машину и отредактируйте /etc/eucalyptus-console/console.ini файл. Надо поменять locale language=ru_RU
После этого перезапустите eucalyptus-console процесс /etc/init.d/eucalyptus-console restart

Зайдя опять в UI вы увидите, что меню и многие сообщения переведены на русский язык.

На всю инсталляцию двух машин и настройки я потратил меньше часа.

habr.com

Голубятня: Как создать собственный облачный сервис, не зависящий от жадных тарифов

Начну с двух анонсов. Первый: видит бог, я держался до последнего, однако жизнь — штука суровая, поэтому она обломала даже такую сильную амбицию как неприязнь к Цукербергу 🙂 Одним словом, не выдержал-таки титанического натиска извне (от родных-близких до читателей) и завел страницу на ФБ (sgolubitskiy). Благость, кстати, проявилась незамедлительно: в коем-то веке мои дочери теперь стали читать своего отца 🙂

Как бы там ни было, еще один канал для анонсов и распространения культур-повидла и кислотного знания не помешает. Посему — добро пожаловать: фрэнжу всех хороших людей с легкостью 🙂

Анонс №2: Приглашаю всех посмотреть новый видеообозор планшета Prestigio MultiPad 7.0 Prime Duo, который я сделал в живописнейшем месте — во время лодочной прогулки по речке, протекающих в густых и непроходимых тропических джунглях!

А теперь — в бой! Сегодня в Goloubyatnya classique (та, что выходит теперь в первозданном виде лишь по вторникам) у нас весьма полезная информация, которая вроде как лежит на поверхности, однако на поверку оказывается, что подавляющее большинство пользователей о существующих вариантах не догадываются. А жаль, потому что глупо платить там, где можно не платить. Если вы разделяете эту (для меня) очевидную логику, то удовольствие от культур-повидла будет носить еще и прагматический привкус.

Речь пойдет (уточняю для тех, кто не читает заголовки из принципа) о создании собственного облачного сервиса. Без всяких бесплатных 2 (3, 5) гигабайт, за которыми следуют подписные планы от 5 долларов в месяц и дальше вверх с песнями в зависимости от запрашиваемого вами объема на жестком диске для хранения ваших резервных копий, данных и т.п.

Меня всегда поражала бизнес-парадигма облачных услуг: это каким же нужно обладать гипнотическим талантом в стиле НЛП, чтобы заставить поверить миллионы людей и компаний в то, что им нужны clouds! Зачем?! Бога ради, зачем нужно платить за 50 Гигабайт, если у меня дома с десяток жестких дисков по 1 терабайт каждый? И все уже давно бесплатны.

Полагаю, что в корпоративном мире таких дисков — еще больше. Однако все упорно продолжают отстегивать всяким Безосам за его S3 словно бандерлоги под заведущим оком Каа.

Козырная замануха коммерческих облаков: вы получаете доступ к вашим данным в любое время в любой точке планеты. За деньги, да, получаю. Но что мешает организовать точно такой же доступ самостоятельно и — опять же — сильно бесплатно? На уровне частном это решается минут за 15. На корпоративном — за неделю. Причем облачные серверы будут также доступны 24 часа в сутки из любой точки планеты, однако при этом их можно разместить реально в таких местах, куда не долезет волосатая наглая лапа любого государства, включая мирового жандарма с козлиной бородкой.

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

Решение для создания собственного облачного сервиса называется GoodSynс Pro от замечательного нашего старинного знакомого Siber Systems, создателя лучшего кросс-платформенного менеджера паролей Roboform (впервые я писал о «Сибири» аж 10 лет назад: Без промискуитета).

GoodSync позиционируется как универсальное кросс-платформенное решение для синхронизаций и создания резервных копий на дисках, подключенных напрямую к вашему компьютеру, а также через Windows Share, FTP, WebDAV, SFTP. Встроена и поддержка популярных коммерческих облачных систем — Amazon S3, Google Drive, Windows Azure, Amazon Cloud Drive SkyDrive, WinMobile.

GoodSync реализован под Windows, Mac OS X и Linux, а также для iOS и наверняка Android. Я тестировал программу в 2009 году, в самом начале своей миграции на Мак, на предмет использования ее для локальной синхронизации вместо Time Machine.

Как локальный вариант GoodSync меня не особо впечатлил и в конце концов я остановился на двух программах Carbon Copy Cloner и ChronoSync.

В феврале при обсуждении моей «Мистики Дропбокса» правильный чел по имени Бармалеич помянул использование GoodSync именно в плане замены коммерческого облака. Смутный червь сомнения заставил меня запустить программу (благо, чтобы давно была куплена) и проверить — так и есть! Вот она, скромная неприметная опция, которую я совершенно упустил из видe — на скриншоте выше она идет второй после «Моего компьютера» — это GoodSync Connect.

GoodSync Connect — это сервис, аналогичный тому, что используется для синхронизации всех паролей в системе Roboform Anywhere. Подозреваю, что реализован он на тех же мощностях. Как бы там ни было, именно GoodSync Connect позволяет за несколько минут настроить полноценную облачную систему между любыми компьютерами, расположенными в любой части света.

Реклама на Компьютерре

Делается это следующим образом:

1) Вы создаете новое задание (процесс) для синхронизации либо резервного копирования.

2) Выбираете в левой части окна исходные данные (весь компьютерный диск, либо любую его директорию). В моем случае я выбрал синхронизацию всей папки Documents на моем Маке:

3) В правой части синхронизационного окна вы выбираете сервис GoodSync Connect, в котором вы бесплатно регистрируетесь еще в момент установки программы. Если вы этого по какой-то причине не сделали (как я, например: просто не понял изначально, зачем это нужно), то восполнить пробел можно в любой момент через меню File — Настроить gs-server:

В открывшемся окне вы вводите свой логин и пароль, созданные при регистрации, после чего программа автоматически выводит список всех гаджетов, которые ранее вы привязали к GoodSync Connect:

4) Вот, собственно, и всё! Остается лишь задать тонкие настройки вроде фильтров включения / исключения (то есть, те подкаталоги или просто файлы, которые вы желаете исключить из процесса синхронизации или бэкапирования, если, конечно, таковые имеются):

автоматизации процесса:

либо дополнительные фичи для самых гикнутых и задвинутых:

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

Разумеется, дополнительные настройки GoodSync для автоматизации процесса синхронизации дадут фору самым продвинутым коммерческим облачным сервисам вроде SpiderOak — сравните сами:

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

Фантастическое удобство GoodSync заключается не только в том, что вы абсолютно свободны в выборе вариантов облачных услуг. Скажем, у себя дома (на Родине 🙂 вы настраиваете gs-server на стационарном компьютере таким образом, чтобы резервные копии записывались на внешний накопитель (например, подключеный через USB или Fireware 2-терабайтный диск), подключаете десктоп к ИБП (вместе с маршрутизатором 🙂 — на случай сбоя в подаче электроэнергии, после чего смело отправляетесь бродить по свету. Всякий раз как вы будете вносить малейшее изменении в любой из своих файлов, GoodSync будет тут же эти изменения синхронизировать на вашем домашнем компьютере.

Даже если произойдет сбой, пропадет интернет, погаснет свет, перегрузится ваш домашний компьютер и т.п., ничего страшного: сразу же после восстановления связи GoodSync продолжит синхронизацию точно с той же точки, на которой он прервался.

Преимущества? Никаких ежемесячных платежей коммерческим облачным сервисам, полный контроль за процессами, сохранение приватности и отсутствие опасений, что случится нечто подобное тому, что вчера я описал в Битом Пикселе (история с Amazon S3).

* * *

Сегодня вторник, однако нового конкурса с розыгрышем суперприза от Supersmoke — подарочной модели электронной сигареты Cubica CC — у нас не будет, потому что за неделю никто так и не смог разгадать предыдущее задание! Позор лютый, однако никаких подсказок я давать не собираюсь, потому что квиз и без того проще пареной репы. Посему слушайте снова и угадывайте: «На каком языке разговаривают в этом аудиоклипе ?»

www.computerra.ru

Обзор облачных сервисов для разработки бэкенда мобильных приложений

Разработка бэкенда — сложный и затратный процесс. При разработке мобильных приложений ему зачастую уделяется неоправданно больше внимания. Неоправданно, потому что каждый раз приходится реализовывать типичные для мобильных приложений сценарии: отправить push-уведомление, узнать сколько пользователей заинтересовались акцией и оформили заказ и т.п. Хочется решение, которое позволит сфокусироваться на важных для приложения вещах без потери качества и деталей в реализации второстепенных. И такие решения есть!

Подобные сервисы называются Mobile Backend-as-a-Service (MBaaS). Процессы создания бэкенда с их помощью упрощены, по сравнению с разработкой «вручную». Это экономия на найме отдельного backend-разработчика. А тот факт, что провайдер MBaaS берет на себя все вопросы, связанные со стабильностью серверов, балансировкой нагрузки, масштабируемостью и прочими инфраструктурами сложностями, придает уверенности в качестве полученного результата и является основным преимуществом таких сервисов.

В этой статье рассмотрим несколько крупных и зарекомендовавших себя сервисов: Microsoft Azure, AWS Amplify, Google Firebase, Kumulos.



Пункты, по которым рассмотрим сервисы: функциональность бэкенда и аналитики, сложность интеграции сервиса, надежность и стабильность работы и ценовая политика. Пройдемся по каждому сервису и отметим их особенности по этим критериям.

Microsoft Azure

Microsoft Azure — Infrastructure-As-A-Service (IaaS) сервис, который содержит в себе полноценную BaaS функциональность и помогает при создании бэкенда для мобильных приложений.

MBaaS


Microsoft Azure располагает полным набором функциональности для создания бэкенда для мобильного приложения. Обработка push-уведомлений, автоматическое масштабирование, синхронизация данных, интеграция с социальными сетями и многое другое.

Важная особенность Azure — географическое положение серверов. Они расположены в 54 регионах мира, что повышает вероятность подобрать для себя подходящий по задержке сервер. Поскольку в случае неполадок чаще всего страдают только отдельные регионы, можно предположить, что чем больше регионов, тем меньше вероятность попасть на тот самый «нестабильный». Как утверждают Microsoft, у них больше регионов, чем у любого другого поставщика облачных решений. Это, несомненно, плюс.

Аналитика


Сервис предоставляет возможность в реальном времени мониторить работоспособность приложений и собирать отчёты о «падениях». Позволяя тем самым мгновенно локализовать и решить проблему.

Также в Azure можно использовать их собственную библиотеку для сбора аналитики в приложениях: собирать основные метрики (информация об устройстве, о сессии, об активности пользователей и многое другое) и создавать собственные события для отслеживания. Все собранные данные сразу экспортируются в Azure, позволяя проводить с ними аналитическую работу в удобном формате

Дополнительная функциональность


Также существуют интересные функции типа тестирования сборок приложений на реальных устройствах, настройки CI/CD для автоматизации процесса разработки и инструментарий для отправки сборок приложений на бета-тестирование или сразу в App Store или Google Play

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

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

Сложность интеграции


Сервис Microsoft Azure предоставляет SDK для основных мобильных платформ (iOS и Android) и, что бывает не часто, для кроссплатформенных решений (Xamarin и PhoneGap). 

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

Важно понимать, что высокий порог вхождения — не частный случай с Azure, а общая проблема для IaaS. Например, Amazon Web Services, который будет рассмотрен далее, также подвержен данному недугу еще больше.

Надежность


Стабильность сервиса от Microsoft выглядит достойно. Видно, что минимум раз в месяц могут происходить кратковременные неполадки в различных регионах. Данная картина говорит о достаточной стабильности сервиса, неполадки происходят редко, в отдельных регионах и крайне быстро исправляются, позволяя сервису держать достойный uptime. 

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

Стоимость


В ценовой политике Microsoft Azure разные тарифы оплаты сервиса, есть и бесплатный план с определенными лимитами, которых хватит для тестирования. Важно помнить, что Azure — IaaS сервис, большинство которых из-за своей специфики и сложности подсчета отработанных ресурсов, страдают от сложности прогнозирования стоимости работы. Многие сталкиваются с трудностями и часто даже невозможностью правильно посчитать используемые мощности. Реальный счет может значительно отличаться от того, на который рассчитывали. 

Также у Azure, помимо этих планов, есть отдельные платные услуги: App Service Domain, Azure App Service Certificates и SSL Connections. Все они относятся к администрированию вашей инфраструктуры, их касаться не будем.
Во многих отзывах пользователи жалуются на сложную ценовую политику и невозможность прогнозирования стоимости услуг сервиса. Предложенный Microsoft калькулятор называют бесполезным, а сам сервис крайне дорогим.

Итог по Azure


Сервис Azure от Microsoft — функциональный и стабильный инструмент для использования в качестве основного MBaaS провайдера. То, что сервис изначально предоставляет полноценную инфраструктуру, открывает множество возможностей для дальнейшего развития вашего бэкенда вне рамок мобильных приложений. Большое количество серверов и обширное количество регионов, где они расположены, помогает подобрать подходящие вам по задержке. Позитивные отзывы пользователей это подтверждают. Из негативных моментов — высокий порог вхождения и сложности с прогнозированием стоимости работы сервиса.

Подходит? По этим ссылкам можно детальнее познакомиться с Microsoft Azure, изучить все подробности и начать его использовать: 

AWS Amplify


Amazon Web Services (AWS) — второй IaaS, который попал в нашу подборку. Он представляет огромное количество сервисов и интересен тем, что у него по аналогии с Microsoft Azure существует выделенный набор функциональности под названием AWS Amplify, который по сути и является мобильным бэкэндом. Ранее вы могли слышать название AWS Mobile Hub, который долгое время являлся основным сервисом, предоставляющим MBaaS функциональность. Как пишут сами Amazon, Amplify это доработанный и усовершенствованный Mobile Hub, в котором решены основные проблемы предшественника.

Если верить Amazon, то сервису Amplify доверяет множество крупных компаний, среди которых Netflix, Airbnb и многие другие.

MBaaS


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

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

Аналитика


За аналитику отвечает отдельный сервис Amazon Pinpoint, в котором можно сегментировать аудиторию и проводить масштабные таргетинговые кампании через разные каналы (push уведомления, смс и электронная почта) по привлечению пользователей в сервис.

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

Дополнительная функциональность


Amazon Amplify предоставляет доступ к сервису AWS Device Farm для тестирования билдов ваших приложений на реальных устройствах. Сервис позволяет проводить параллельное автоматизированное тестирование ваших приложений на множестве физических устройств, также доступно и ручное тестирование.

Сервис AWS Amplify Console является инструментом для деплоя и хостинга как серверных ресурсов, так и веб приложений с возможностью настройки CI/CD для автоматизации процесса разработки.

Также необычно выглядит возможность внедрения в мобильные приложения «из коробки» голосовых и текстовых ботов в качестве интерфейса для взаимодействия с пользователем. Работает это на сервисе Amazon Lex.

Интересно, что AWS Amplify предоставляет также и небольшую библиотеку готовых UI компонентов для вашего React Native приложения, что может послужить незначительным ускорением процесса разработки, либо использоваться в прототипе или MVP вашего проекта.

Сложность интеграции


Сервис Amazon Amplify предоставляет SDK для iOS, Android, JavaScript и React Native и достаточно подробную документацию. Важно отметить что помимо REST, сервис поддерживает еще и GraphQL.

Как говорилось в процессе анализа Azure, высокий порог вхождения —общая проблема для всех IaaS. Amazon не исключение, а даже наоборот. Это, наверное, один из самых сложных сервисов для понимания. Это происходит из-за большого количества различных инструментов, которыми располагает AWS. Освоение AWS с нуля займет значительное время. Но если ограничиться только Amplify — можно реализовать рабочее решение в адекватные сроки.

Надежность

Сервис от Amazon по статистике выглядит менее стабильным, чем Azure. Но радует малое количество полноценных отключений (красных клеток). В основном все, что происходит — это предупреждения и нестабильность в работе некоторых сервисов.

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

Стоимость

Ценовая политика Amazon Web Services с первого взгляда весьма проста — платите только за то, чем пользуетесь, сверх бесплатного лимита. Но как и в случае с Microsoft Azure, чем больше сервисов вы используете, тем сложнее прогнозировать итоговую стоимость работы.

В интернете множество отзывов, которые называют AWS слишком дорогим. Чего уж говорить, если давно появились компании, которые за отдельную сумму готовы оптимизировать ваше использование AWS, насколько это возможно минимизируя ежемесячные счета. 

Итог по Amazon Amplify


В целом история с Amazon Amplify похожа на Azure. Во многом аналогичный функционал для MBaaS, предоставление полноценной инфраструктуры и возможность развития своего бэкенда. Позитивно выделяются маркетинговые инструменты Amazon, в частности, Pinpoint.

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

Подходит? По этим ссылкам можно детальнее познакомиться с Amazon Amplify, изучить все подробности и начать его использовать: 


Google Firebase



Сервис Firebase от Google является одним из самых интересных вариантов в качестве MBaaS сервиса для вашего приложения. Он давно зарекомендовал себя в качестве полезного инструмента и является таковым для многих известных приложений: Shazam, Duolingo, Lyft и других. 

MBaaS


Firebase берет на себя все, что понадобится вашему мобильному приложению. Сервис совмещает в себе полноценные бэкенд-фичи, такие как хранение данных, синхронизация, аутентификация, облачные функции (выполнение бэкенд кода), и, в данный момент, в бете находится Machine Learning Kit, при помощи которого реализуется  в приложении различная функциональность на основе машинного обучения (распознавание текста, объектов на фотографиях и много другое). 

Аналитика


Важная особенность Firebase в том, что помимо бэкенд функциональности, сервис предлагает и широкий спектр возможностей для аналитики приложения. Встроенная Google Analytics, сегментирование пользовательской базы и работа с push-уведомлениями. Также в 2017 году Google отметился крутым приобретением, купив широко распространенный сервис Fabric и интегрировав его в Firebase наряду с Crashlytics, крайне полезным инструментом для отслеживания ошибок в приложении и сбора статистики и отчетов о падениях, произошедших на устройствах пользователей.

Дополнительная функциональность


Firebase предоставляет инструмент Firebase Dynamic Links для обработки динамических ссылок на ваш контент, при помощи этого инструмента можно генерировать ссылки, которые ведут в приложение, если оно установлено, если нет — отправляют пользователя в App Store или Google Play для установки. Также подобные ссылки работают в зависимости от устройства, на котором они открываются, если это компьютер, то будет открыта страница в браузере, а если устройство — произойдет переход в приложение.

Также Google позволяет проводить A/B тестирование ваших приложений при помощи Firebase A/B Testing и настраивать удаленную конфигурацию с инструментом Remote Config. 

Сложность интеграции


Становится понятно, что этот сервис совмещает в себе крайне большое количество возможностей для вашего приложения. Для интеграции Firebase стоит использовать SDK необходимой платформы, среди которых iOS, Android, JavaScript, а также для C++ и Unity, что будет очень кстати, если вы разрабатываете игры. Важно отметить, что у Firebase достаточно подробная документация и широкая база пользователей-разработчиков, и как следствие, большое количество  вспомогательного контента в сети, будь то ответы на вопросы или обзорные статьи.

Надежность


Стоит ли полагаться на Google — вопрос отдельной статьи. С одной стороны, у вас есть высокостабильный и работающий провайдер, а с другой, никогда не знаешь, когда «Гугл закроет и этот сервис». Не зря Гугл убрали у себя из миссии «Dont be evil»

Когда провайдер обладает такими ресурсами, казалось бы, аптайм должен стремиться к 100%, но все равно можно найти множество сообщений о проблемах с сервисом, например, цитата одного из пользователей: «Downtime happens. In the case of Firebase, you might say that «uptime» happens». И действительно, если посмотреть на статистику по событиям с сервисами Firebase, увидим, что бывают как небольшие простои, так и полноценные отключения на 5-7 часов, это может быть критично для вашего сервиса.

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

Стоимость


Ценовая политика Firebase понятна и проста, есть 3 плана: Spark, Flame и Blaze. Они идеологически отличаются друг от друга. В то время как Spark — бесплатный план с лимитами, которые позволяют развернуть и протестировать значительную часть функциональности платформы. Планы Flame и Blaze предполагают платное использование. Flame стоит фиксированные 25$ в месяц, но по сути вы получаете тот же Spark, только со значительно большими лимитами. 

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

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

Итог по Firebase


Сервис Firebase от Google представляет собой полноценный MBaaS провайдер, который ограничивает от инфраструктурных сложностей, с которыми напрямую связаны AWS и Azure. Весь необходимый для разработки облачного бэкенда функционал на месте, широкие возможности для аналитики, относительная простота интеграции, довольно низкий порог вхождения и прозрачное ценообразование. 

Из негативных сторон — проблемы со стабильностью сервиса. К сожалению, на это никак не повлиять, остается только надеяться на инженеров Google.

Подходит для вас? По этим ссылкам можно детальнее познакомиться с Google Firebase, изучить все подробности и начать его использовать: 

Kumulos


Kumulos — самостоятельный MBaaS сервис, основанный в 2011 году. 

MBaaS


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

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

Аналитика


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

Важная особенность — возможность хранить и экспортировать данные в другие сервисы, среди которых: Salesforce, Google BigQuery, Amplitude и Tableau.

Дополнительная функциональность


Интересная и не часто встречающаяся функция — инструмент для оптимизации продвижения приложения в App Store. Kumulos App Store Optimization оценивает страницу вашего приложения и предлагает решения по улучшению показателей. Отслеживает факторы успеха приложения, такие как пользовательские оценки и положение приложений в топе разных стран, и на основе этих данных генерируются отчеты. 

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

Сложность интеграции


У Kumulos широкий набор SDK для интеграции как с нативными, так и с кросплатформенными инструментами. Библиотеки активно обновляются и поддерживаются.

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

Надежность


К сожалению, мне не удалось найти никакой статистики по стабильности серверов работы сервиса Kumulos.

Стоимость


Помимо бесплатного триала у Kumulos есть 3 платных плана: Startup, Enterprise и Agency. Они работают по принципу «плачу только за то, что использую». К сожалению, сервис не предоставляет прайс-лист в открытом доступе, похоже, что он рассчитывается индивидуально, исходя из ваших потребностей.

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

Итог по Kumulos


Kumulos предоставляет из себя MBaaS платформу во многом аналогичную Firebase. Здесь присутствует весь необходимый набор инструментов MBaaS сервиса, довольно обширные возможности аналитики и отчетности. Интересно выглядит отдельное предложение для студий мобильных приложений, которое сочетает в себе множество дополнительных преимуществ.

Из негативного — отсутствие каких-либо данных о стабильности серверов и закрытый прайсинг.

Стоит попробовать? По этим ссылкам можно детальнее познакомиться Kumulos, изучить все подробности и начать его использовать: 

Заключение


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

В статье мы рассмотрели 4 сервиса: Microsoft Azure, AWS Amplify, Google Firebase и Kumulos. Среди них 2  крупных IaaS сервиса и 2 MBaaS, которые специализируются именно на мобильном бэкэнде. И в каждом из вариантов встретили определенные проблемы и негативные стороны.

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

Функциональность

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

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

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

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

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

Используя эти сервисы важно не завязываться на одном решении, иначе вы становитесь полностью зависимыми от него и обрекаете себя, на так называемый, «vendor lock». Это значит, что если с сервисом что-то случится, изменится владелец, направление развития или закроется — придется в срочном порядке искать нового MBaaS поставщика, и, в зависимости от размеров приложения, подобный переезд потребует существенных временных, и, как следствие, денежных затрат. Особенно страшно будет, если бэкэнд завязан на какой-либо уникальной функциональности MBaaS-провайдера, так как все поставщики разные и далеко не у всех одинаковый набор функционала. Поэтому редко, когда удается переехать «безболезненно».

Весь анализ в итоге можно описать в таблице:

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

Данные о стабильности взяты с сервиса https://statusgator.com/
Данные о пользовательских оценках взяты с сервиса www.capterra.com

habr.com

как сделать свои приложения Cloud-Native / Сбербанк corporate blog / Habr

В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.

Когда приложение заказывает окружение


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

Развитием этой идеи является подход Infrastructure as code (IAC). Его суть в том, чтобы дать возможность разработчикам или службам эксплуатации применять для обслуживания инфраструктуры такие же подходы, которые используются на этапе разработки. Он позволяет готовить общие программные блоки управления заранее и легко осуществлять интеграцию таких компонентов в новых проектах.

Возможности современных ЦОДов уже позволяют переходить к декларативному языку управления инфраструктурой. В идеале, приложение должно само администрировать занимаемый им пул ресурсов в дата-центре. Это позволит разработчику не быть запертым в ограничениях, связанных с процессом работы с инфраструктурой, когда надо заказывать и проектировать наперед или если одни и те же компоненты инфраструктуры повторяются в разных проектах.


Фактически разработчик или инженер делает Pull Request, в котором находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.), далее менеджер виртуального окружения самостоятельно создает машину или создает новый инстанс базы данных или стартует предустановленный сервис, согласно настройкам в файле. Такой подход — настоящее спасение при работе с большими данными и нейронными сетями. Приложения, связанные с этими технологиями, в некоторых случаях нуждаются в динамически изменяемых объемах памяти и процессорных мощностей.

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

Монолит vs. упорядоченный хаос


Благодаря тому, что облака умеют эластично подстраиваться под потребности разработчика, это, теоретически, упрощает еще одну задачу – проблему масштабирования приложений. Почему теоретически?

К сожалению, задача по масштабированию приложений не является линейной. Чтобы приложение справлялось с огромными нагрузками в периоды пиковой посещаемости (или вычислений), недостаточно просто давать ему дополнительную память и процессорные мощности. Абсолютно у каждого традиционного приложения есть порог, после которого оно уже не в состоянии «переварить» новые ресурсы и продемонстрировать рост производительности. Проблема в данном случае состоит не в ресурсах, а в самой архитектуре большинства программ.

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

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


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

В поисках идей, как решить эти проблемы была разработана другая концепция – service-oriented architecture (SOA). Она подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет другим какую-то функциональность. Между собой модули взаимодействуют через набор веб-служб, и независимо друг от друга могут обращаться к единой или к собственным базам данных.

Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но и у него есть свои недостатки. Ключевой из них – проблемы с масштабированием разработки таких приложений. По мере роста программы, новые функции становится все сложнее «запихивать» в изначально утвержденные архитектором 5-10 пакетов. Их число становится все больше, что оборачивается проблемами с поддержкой.

Микросервис как элемент эволюции приложения


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

Микросервисная архитектура подразумевает, что приложение состоит не из какого-то небольшого количества крупных модулей, а из множества независимых друг от друга частей. В отличие от монолита, в микросервисном приложении можно использовать различные способы взаимодействия компонентов между собой. У системы нет единого, заранее определенного состояния. Вместо этого каждый компонент работает «по ситуации»: как только ему поступает событие он начинает работу. Это позволяет делать очень гибкую и независимую архитектуру.
При этом число сервисов в микросервисном приложении постоянно меняется – какие-то добавляются, какие-то удаляются. В новом подходе можно любой микросервис заменить и вместо него встроить цепочку микросервисов. Другие сервисы продолжают стабильно работать, потому что не связаны напрямую между собой. Такова естественная эволюция программы. Благодаря этому у разработчиков и архитекторов появляется возможность быстро что-то менять, чтобы реагировать на изменения бизнес-требований и опережать конкурентов.

Помимо повышения скорости выпуска обновлений использование микросервисной архитектуры позволяет добиться децентрализации управления. Команда, которая отвечает за разработку того или иного сервиса, сама вправе определять его внутреннюю архитектуру и его особенности. Такой подход, кстати, сейчас в Блоке Технологии внедряет Архитектурный совет Сбербанка.

При этом садясь за разработку своего облачного приложения не следует спешить со скорейшим дроблением его на составные элементы. Главный противник подобного бездумного подхода — Мартин Фаулер; он же – один из авторов идеи микросервисной архитектуры. Проще изначально использовать монолитный подход, и потом стимулировать эволюцию приложения «естественным образом», ориентируясь на расшивку узких мест и добавление дополнительных функций.

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

Четыре детали


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

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

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


Третья важная деталь, которую необходимо учитывать, разрабатывая облачное приложение – способ взаимодействия его составных частей между собой. Как и в SOA, для обмена данными сервисы используют веб-службы, но в микросервисной архитектуре появились паттерны взаимодействия, например, как streaming, CQRS, Event sourcing. Обычно разработчики рассчитывают, что время отклика между запросом и ответом в приложении достаточно небольшое. В распределенной системе нельзя полагаться даже на то, что ответ вообще придет.

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

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

Например: если пользователь делает запрос на получение кредита, то получившая заявку система должна это состояние сохранить, чтобы передать его другим сервисам. А вот сервис, отвечающий за поиск информации во внутренней картотеке кредитных историй, может не сохранять состояние и забыть о том, данные на какого именного пользователя он искал пару минут назад – все равно уже через мгновенье ему придет новый запрос (хотя и в этом процессе может быть различное поведение сервиса).

Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-отрасли. Например, пионером в развитии микросервисной архитектуры является Netflix. Компания выпустила множество open-source приложений, библиотек и фреймворк для мониторинга, балансировки и логирования запущенных микросервисных приложений.

habr.com

Виды облачных сервисов и почему они вам нужны прямо сейчас

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

Что такое облачные сервисы

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

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

Виды облачных сервисов

Попробуем простыми словами рассказать, какими бывают облачные сервисы. Самый базовый случай — это доступ к виртуальному серверу. Купив такое облако, вы сразу после оплаты получаете доступ к командной строке на компьютере с заданными характеристиками и нужной вам операционной системой. Виртуальным такой сервер называется не потому, что он сделан в VR, а потому что на самом деле ваш сервер работает внутри другого (очень мощного) физического сервера вместе с десятком других таких же виртуальных собратьев.

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

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

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

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

Как работают облачные сервисы

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

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

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

Это и есть базовый принцип построения облачных систем.

Преимущества облачных сервисов

У любого облачного сервиса всегда есть три огромных плюса:

  1. Вы избавляетесь от головной боли по развертыванию и обслуживанию IT-инфраструктуры. Облако — это когда кто-то другой за вас следит за работоспособностью, надежностью и безопасностью системы. Любой облачный сервис — крайне требовательная к вниманию штука: нужно делать резервные копии, ставить обновления, заменять вышедшее из строя железо, конфигурировать сервисы. Вы сгружаете все эти заботы на поставщика облачных услуг и просто пользуетесь всем готовым.
  2. Во многих случаях вы экономите деньги. Для большинства бизнесов облака обходятся дешевле, чем свой парк устройств и штат админов. А еще можно брать облачные мощности в аренду на минуты и часы — тогда вы платите лишь за фактическое время использования удаленных машин. Облачные ресурсы создаются и удаляются за секунды, поэтому нет нужды держать сотню-другую серверов про запас на черный день. Нужна мощность — запустили сто виртуальных машин. Не нужна — удалили их и перестали платить.

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

  3. Вы быстрее разрабатываете и выводите продукты на рынок. Собрать приложения и проекты из готовых кусков для проверки бизнес-гипотез? Легко! Больше не надо ждать, пока ваши инженеры напишут с нуля необходимые компоненты.
  4. А еще есть один тонкий момент, о котором многие забывают, — законы. Так, к некоторым видам сервисов предъявляются весьма жесткие законодательные требования, вспомним только весьма известный Федеральный Закон № 152-ФЗ. Возиться со всеми этими документами и нормативами самостоятельно, организовывать реальное соблюдение требований, чтобы исключить нарушения и штрафы — дорого и тяжело. Поэтому можно заказать облако, которое уже настроено под все требования закона.

mcs.mail.ru

Как создать свое облако в интернете – собственный облачный сервер

На главную -> MyLDP -> Тематический каталог -> Программное обеспечение для Linux


Создаем свои собственные облачные сервера с помощью Ubuntu

Оригинал: «Grow Your Own Cloud Servers With Ubuntu»
Автор: Эрик Гайер (Eric Geier)
Дата публикации: January 15, 2010
Перевод: Н.Ромоданов
Дата перевода: февраль 2010 г.

Хотели бы вы полетать в облаке и поэкспериментировать с облачными вычислениями? Теперь у вас есть шанс. С помощью этой статьи вы шаг за шагом изучите процесс настройки своей личной облачной системы, в которой используется пакет Ubuntu Enterprise Cloud (UEC), базирующийся на платформе Eucalyptus.

Система состоит из одного облачного контроллера (также называемого front-end сервером) и одного или нескольких контроллеров узлов. Облачный контроллер управляет средой облака. Вы можете по умолчанию использовать образы ОС Ubuntu или создать свой собственный образ, который будет использоваться в виртуальной среде. В контроллерах узлов вы можете запустить отдельные экземпляры виртуальных машин (VM) для работы с образами.

Системные требования

Для того чтобы можно было работать с облаком, для него нужно выделить, по крайней мере, два компьютера:

  • Один — для front-end сервера (облачного контроллера или контроллера кластеров) со следующими минимальными требованиями: CPU с частотой в 1 ГГц, 512 Мбайт оперативной памяти, CD-ROM, 40 Гбайт дискового пространства и сетевым Ethernet адаптером.
  • Один или несколько для контроллеров узлов с CPU, поддерживающим технологию виртуализации Virtualization Technology (VT), 1Гбайт оперативной памяти, CD-ROM, 40 Гбайт дискового пространства и сетевым Ethernet адаптером.

Вы можете посмотреть список процессоров Intel, поддерживающих технологию VT. Либо в Windows вы можете запустить утилиту SecurAble. В Linux вы можете выполнить проверку следующим образом — посмотреть, если в файле /proc/cpuinfo параметры «vmx» или «svm». Запустите команду egrep ‘(vmx|svm)’ /proc/cpuinfo. Однако имейте в виду, что вы получите результат, если эта возможность включена: она может быть отключена в BIOS.

Подготовка к инсталляции

Во-первых, скачайте образ CD для версии Ubuntu Server remix (мы используем версию 9.10) на любой компьютер, на котором есть устройство записи CD или DVD. Затем запишите образ ISO на CD или DVD. Если вы хотите использовать DVD, убедитесь в том, что компьютеры, которые будут использоваться в облаке, могут читать DVD. Если вы используете Windows 7, вы можете открыть ISO файл и использовать утилиту записи, входящую в состав ОС. Если вы используете Windows Vista или более ранние версии, вы можете скачать стороннее приложение, такое как DoISO.

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

Установка Front-End сервера

Установка front-end сервера сравнительно проста. Для того, чтобы начать установку, просто вставьте компакт-диск с инсталлятором и в загрузочном меню выберите пункт «Install Ubuntu Enterprise Cloud», а затем нажмите клавишу ENTER. При необходимости укажите язык и раскладку клавиатуры. Укажите настройки сети, когда появится запрос.

При появлении запроса на выбор режима установки Cloud Installation Mode, нажмите Enter для того, чтобы выбрать установку по умолчанию, т. е. «Cluster» («кластер»). Затем вам нужно сконфигурировать часовой пояс и задать настройки раздела. После того, как раздел будет подготовлен, установка будет, наконец, запущена. В самом конце, вам будет предложено создать учетную запись пользователя.

Затем вам нужно будет настроить параметры прокси, автоматическое обновление и электронную почту. Кроме того, вам нужно будет задать имя кластера Eucalyptus Cluster. Вам также потребуется настроить IP-адресацию с тем, чтобы пользователи получали динамически назначаемые им адреса.

Установка и регистрация контроллеров узлов

Установка узлов еще проще. Снова вставьте установочный диск, в меню загрузки выберите «Install Ubuntu Enterprise Cloud» и нажмите клавишу Enter. По мере необходимости указывайте требуемые настройки.

Когда дело дойдет до выбора режима установки Cloud Installation Mode, инсталлятор должен автоматически обнаружить существующий кластер и задать вариант установки «Node» («Узел»). Для того, чтобы продолжить, просто нажмите на клавишу Enter. Останется только задать настройку раздела.

Регистрация контроллеров узлов

Прежде, чем продолжить дальше, вы должны знать IP адрес узла (узлов).

Как создать собственное облако, где можно бесплатно хранить любой объём данных

Узнать его можно с помощью следующей команды:

/sbin/ifconfig

Затем вам потребуется установить на контроллере узла открытый ssh ключ, взятый с front-end сервера:

  1. С помощью следующей команды установите временный пароль для пользователя eucalyptus:
  2. sudo passwd eucalyptus

  3. На front-end сервере введите следующую команду для того, чтобы скопировать SSH ключ:
  4. sudo -u eucalyptus ssh-copy-id -i ~eucalyptus/.ssh/id_rsa.pub [email protected]

  5. Затем с помощью следующей команды вы можете удалить пароль учетной записи eucalyptus:
  6. sudo passwd -d eucalyptus

  7. После того, как узлы будут подняты и ключ скопирован, запустите на front-end сервере следующую команду и добавьте узлы:
  8. sudo euca_conf —no-rsync —discover-nodes

Получение и установка идентификационной информации пользователя

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

mkdir -p ~/.euca chmod 700 ~/.euca cd ~/.euca sudo euca_conf —get-credentials mycreds.zip (It takes a while for this to complete; just wait) unzip mycreds.zip cd —

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

Настройка EC2 API и инструментального пакета AMI

Теперь вы должны настроить на front-end сервере пакет EC2 API и инструментальный пакет AMI. Во-первых, все настройки вашей среды Eucalyptus берутся из файла eucarc, поэтому введите:

~/.euca/eucarc

Для того, чтобы при входе в систему это происходило автоматически, введите следующую команду, которая запишет предыдущую команду в ваш файл ~/.bashrc

echo «[ -r ~/.euca/eucarc ] && . ~/.euca/eucarc» >> ~/.bashrc

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

sudo apt-get install ^31vmx32^4

Для того, чтобы удостовериться в том, что все работает, введите следующую команду и получите детальную информацию об имеющемся кластере:

. ~/.euca/eucarc euca-describe-availability-zones verbose

Доступ к панели управления с веб интерфейсом

Теперь вы можете получить доступ к конфигурационной утилите, имеющей веб интерфейс. С любого компьютера, находящимся в той же самой сети, перейдите по URL, https://:8443. Сразу после того, как вы зарегистрируетесь front-end сервере, будет показан IP адрес облачного контроллера. Обратите внимание, что это безопасное соединение происходит по протоколу HTTPS, а не с помощью HTTP. Вполне вероятно, вы получите от браузера предупреждение, касающееся безопасности, поскольку в сервере используется самоподписываемый сертификат вместо сертификата, предоставляемого какой-нибудь из известных служб сертификации Certificate Authority (CA). Игнорируйте это предупреждение, добавив его в список исключений. Подключение будет безопасным.

По умолчанию в качестве имя пользователя и пароля пользователя используется значение «admin». После первой регистрации вам следует ввести новый пароль и email.

Установка образов

Теперь, когда у вас есть настроенное основное облако, вы можете установить образы. Откройте панель управления с веб интерфейсом, выберите вкладку Store, а затем щелкните по кнопке Install (Установить) для установки нужного образа. Начнется загрузка, а затем автоматически начнется установка, которая занимает много времени.

Запуск образов

Перед первым запуском образа на узле, выполните следующие команды с тем, чтобы создать пару ключей для SSH:

touch ~/.euca/mykey.priv chmod 0600 ~/.euca/mykey.priv euca-add-keypair mykey > ~/.euca/mykey.priv

Вам также потребуется открыть порт 22 на узле с помощью следующей команды:

euca-describe-groups euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Наконец, вы можете запустить зарегистрированный образ. Команду для запуска образа можно выполнить через веб интерфейс. Войжите в систему через веб интерфейс, щелкните по вкладке Store, а затем выберите ссылку How to Run с тем, чтобы запустить нужный образ. Появится окошко, в котором будет указана нужная команда.

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

watch -n5 euca-describe-instances

При переходе из состояния «pending» («ожидание») в «running» («выполнение») определите назначенный IP адрес и подключитесь к нему:

IPADDR=$(euca-describe-instances | grep $EMI | grep running | tail -n1 | awk ‘{print $4}’) ssh -i ~/.euca/mykey.priv [email protected]$IPADDR

Для того, чтобы завершить подключение по SSH:

INSTANCEID=$(euca-describe-instances | grep $EMI | grep running | tail -n1 | awk ‘{print $2}’) euca-terminate-instances $INSTANCEID

Обслуживание облака

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

  • Для того, чтобы перезапустить front-end сервер, выполните следующую команду: sudo service eucalyptus [start|stop|restart]
  • Для того, чтобы восстановить работу узла, выполните следующую команду: sudo service eucalyptus-nc [start|stop|restart]
  • Есть следующие несколько файлов с важными данными:
    • Файлы журналов
      /var/log/eucalyptus
    • Конфигурационные файлы
      /etc/eucalyptus
    • База данных
      /var/lib/eucalyptus/db
    • Ключи
      /var/lib/eucalyptus
      /var/lib/eucalyptus/.ssh

Смотрите следующие статьи:

Если вам понравилась статья, поделитесь ею с друзьями:

steptosleep.ru

Разбираемся с «облачными» услугами / 1cloud.ru corporate blog / Habr

Раньше, чтобы развернуть какое-либо приложение, приходилось покупать и настраивать собственные физические серверы. Такой подход обладал большим количеством недостатков, например, если для нормальной работы приложения ему достаточно «полтора сервера», платить все равно приходилось за два – расходы на содержание и обслуживание инфраструктуры оказывались неоправданно высокими.

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

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

«Однако инженеры и исследователи быстро поняли, что такой подход плохо масштабируется, – говорит Прадип Падала (Pradeep Padala), учредитель ContainerX. – Поэтому начались поиски альтернативных способов проведения вычислений: начали разрабатываться распределенные системы, объединяющие в себе мощности огромного количества компьютеров».

Появились такие академические проекты, как Condor – это распределённая сеть компьютеров, развернутая в Висконсинском университете в Мадисоне. На сегодняшний день там установлено 350 настольных UNIX-станций, которые предоставляют доступ для работы пользователям со всего мира. Были и другие проекты, например distributed.net и [email protected] – на тот момент эта идея была инновационной, да и заниматься поиском внеземных цивилизаций тоже достаточно интересно.

Затем появился БАК от ЦЕРН, который породил бессчётное количество исследовательских проектов, на которые уходили миллиарды долларов. Как часть всего этого движения в моду вошли грид-вычисления. Определение грид-вычислений очень близко к тому, что мы называем «вычисления как услуга». В качестве примера можно привести Globus Toolkit.

Одновременно со всем этим, в технической индустрии, VMware и Xen занимались популяризацией виртуализации, которая позволяла запускать сразу несколько машин на одной физической машине. Это преобразило IT-индустрию, а простота использования привлекла внимание стартапов, которым было сложно покупать и содержать свое собственное оборудование.

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

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

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

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

Свои вычислительные ресурсы поставщик объединяет в пул, чтобы их можно было динамически перераспределять в соответствии с нуждами пользователей – это так называемый принцип множественной аренды (Multi-tenancy). Возникает ощущение независимости от местоположения, когда заказчик не знает, где именно находятся ресурсы, но может определять их расположение на абстрактном уровне (страна или регион).

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

Облачные системы автоматически контролируют и оптимизируют использование ресурсов. Это осуществляется путем измерения различных параметров (размер хранилища данных, вычислительная мощность, пропускная способность). Таким образом, как поставщик, так и потребитель получают полную информацию об объеме оказанных/потребленных услуг.

Что касается стоимости услуг, то процесс их формирования может быть достаточно сложным, а ценник изменяться от поставщика к поставщику. Джейсон Лемкин (Jason M. Lemkin), партнер SaaStr Ventures, считает, что если ваш продукт лучше, то не стоит стесняться завышать цену.

Если вы вводите какую-нибудь новую функцию, которая способна кардинально изменить пользовательский опыт, то нет ничего плохого в том, если вы постараетесь извлечь из этого максимальную выгоду. «Если ваш продукт в пять раз серьезнее, чем у конкурента, то вы можете просить за него в 5 раз больше», – утверждает Джейсон.

Помимо характеристик выделяют еще три модели обслуживания: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) и инфраструктура как услуга (IaaS). Отличаются они степенью предоставляемого контроля.

В случае IaaS клиент получает возможность использовать облачную инфраструктуру по своему усмотрению и самостоятельно управлять ресурсами обработки и хранения, а также сетями. «Пользователь может создать виртуальную инфраструктуру и изменить её в любой момент», – говорит консультант Эван Лейт (Ewan Leith). Аутсорсинг стал популярным еще в те времена, когда компании хотели использовать компьютеры, но не хотели нести издержки по их содержанию и обслуживанию. По этой причине мы сегодня имеем технологию виртуализации.

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

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

Второй слой – это платформа как услуга или PaaS. При переходе от модели IaaS к модели PaaS (Platform as a Service) дополнительно на сторону облачного провайдера передается управление операционными системами и базами данных. В этом случае клиентам не приходится думать о дисковом пространстве, которое необходимо выделить, и распределении нагрузки между серверами. Примерами PaaS являются Google App Engine, Heroku и Force.com.

Программное обеспечение как услуга (SaaS) – последний уровень облачных вычислений, обычно дополняющий PaaS. Это программное обеспечение для конечного пользователя, например, обеспечивающее работу с электронной почтой или текстом. Очень часто оно предоставляется по подписке. Примерами SaaS могут служить Google Apps, Salesforce.com и Business Productivity Online Suite от Microsoft.

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

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

Частное облако (private cloud) – это инфраструктура, которая располагается в пределах одной организации. Данная модель развертывания создана с целью удовлетворить потребности внутреннего рабочего персонала, обеспечивая высокий уровень безопасности данных. Частное облако создается, например, для обеспечения какой-либо дочерней компании сервисом корпоративной почты.

Публичное облако (public cloud) – это инфраструктура, предназначенная для свободного использования широкой публикой. Этот тип облака может находиться в собственности, например, коммерческих, научных и правительственных организаций.

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

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

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

P.S. Пара наших публикаций по теме на Хабре:

habr.com

виртуальное приватное облако / Selectel corporate blog / Habr

Главная новость этого месяца: мы запустили публичное тестирование новой услуги — «Виртуальное приватное облако». Любой пользователь может получить в свое распоряжение собственную облачную инфраструктуру, гибкую, управляемую, легко масштабируемую и способную справиться с любыми нагрузками.

О возможностях и преимуществах нового сервиса мы подробно расскажем ниже.

Введение


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

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

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

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

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

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

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

Кроме того, вертикальное масштабирование в облаке иногда может оказаться очень невыгодным с финансовой точки зрения: оплата по принципу pay-as-you-go (т.е. по фактическому потреблению) при незапланированных нагрузках может обернуться весьма неприятными сюрпризами. Для корпоративных клиентов такой принцип оплаты существенно затрудняет планирование расходов — в большинстве случаев сложно предсказать, какой объем ресурсов будет потреблен машиной, работающей под реальной нагрузкой.

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

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

Виртуальное приватное облако


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

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

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

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

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

Чтобы реализовать все описанные возможности, нам требовалась платформа с публичным API. Наш выбор пал на OpenStack — платформу, де-факто давно уже являющуюся стандартом для построения современных облачных сервисов.

OpenStack: краткая справка


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

Работа над OpenStack началась в 2010 году, когда был объединен код двух платформ: Nebula (так называлась платформа, создававшаяся специально для NASA) и RackSpace CloudFiles (разработка компании RackSpace). Вскоре интерес к новому проекту стали проявлять разработчики различных дистрибутивов Linux: уже в 2011 году OpenStack стал основной облачной платформой для Ubuntu Server и Ubuntu Enterprise Cloud. В том же году OpenStack стал использоваться и в OC Debian. В 2012 году к проекту присоединилась компания RedHat и начала работу над собственным дистрибутивом.

Cегодня в работе над проектами OpenStack принимают участие около 9000 индивидуальных разработчиков и 250 организаций, в том числе и такие известные компании, как IBM, EMC, HP, Canonical, Yahoo! и другие.

OpenStack имеет модульную архитектуру и включает следующие компоненты (перечисляем только наиболее важные компоненты — на самом деле их гораздо больше):

  • Nova — контроллер для управления виртуальными машинами. Он выполняет такие функции, как обработка запросов на создание виртуальных машин, контроль работоспособности, распределение нагрузки на физические машины, реакция на сбои и т.п.;
  • Neutron — компонент для управления сетями. С его помощью пользователи могут определять сети, подсети и маршрутизаторы и конфигурировать внутреннюю топологию сетевой инфраструктуры. Neutron поддерживает механизм плавающих (floating) IP-адресов, которые можно динамически выделять виртуальным машинам;
  • Cinder — сервис блочных устройств. Обеспечивает функциональность дисков виртуальных машин;
  • Glance — компонент для управления образами виртуальных машин. Образы Glance используются для быстрого и согласованного развертывания новых серверов;
  • Keystone — модуль авторизации; ключевой компонент, обеспечивающий единую точку авторизации пользователей во всех сервисах;
  • Heat — модуль, отвечающий за оркестрацию. С его помощью можно автоматически разворачивать виртуальные серверы и приложения на базе шаблонов;
  • Swift — модуль объектного хранения данных, который мы уже на протяжении нескольких лет используем в нашей услуге «Облачное хранилище».

Взаимодействие компонентов можно представить в виде следующей схемы:

Почему OpenStack стал, как это уже было сказано выше, фактическим стандартом для построения современных облачных сервисов? Этому способствовали в первую очередь следующие факторы:

  • Открытый исходный код, предоставляющий широкие возможности для доработки и усовершенствования существующих сервисов;
  • Гибкость. Облачная инфраструктура на основе OpenStack получается гибкой и управляемой. Настроенная система выдерживает любые изменения дизайна и в случае необходимости может быть легко переконфигурирована, к примеру, если планируется использование другой системы хранения данных;
  • Широкие возможности интеграции. OpenStack не является замкнутой системой и может взаимодействовать с другими продуктами. Доступна поддержка различных систем виртуализации, существуют плагины для подключения разнообразных устройств хранения данных и сетевого оборудования.

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

Как устроено новое облако


Домены и проекты


Каждый пользователь услуги «Виртуальное приватное облако» получает в распоряжение домен — собственное виртуальное пространство для создания проектов и пользователей. Под проектом в данном случае понимается совокупность объектов и ресурсов, к которым может иметь доступ пользователь: виртуальных машин, дисков,
сетей и других.

Ресурсы и квоты


В начале работы владелец облака приобретает ресурсы (оперативную память, ядра CPU, дисковое пространство) и распределяет их между своими проектами, тем самым устанавливая лимиты на создание разнообразных объектов. В любой момент можно перераспределить ресурсы между проектами или отказаться от части ресурсов.

Управление доступом


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

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

Гибкое создание виртуальных машин


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

Сетевые подключения


Виртуальные машины можно подключать к сети различными способами. Владелец облака может либо арендовать у нас выделенную публичную подсеть (аналогично тому, как это делается для выделенных физических серверов), либо воспользоваться механизмом «плавающих» IP-адресов (floating IP).

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

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

Загрузка образов


В новом облаке поддерживается набор образов для самых распространённых дистрибутивов Linux (таких, как Ubuntu, Debian, CentOS, OpenSUSE), а также Windows Server 2012. Помимо стандартного агента cloud-init, в образах присутствует созданный нами агент, реализующий целый ряд полезных функций: переустановку пароля по запросу из панели управления, статическую конфигурацию сети (в случае отсутствия DHCP), управление SSH-ключами. Кроме того, клиенты могут загружать в проект собственные образы виртуальных машин. Поддерживаются форматы образов, используемых в системах виртуализации Virtualbox, KVM, VMware, а также формат Amazon EC2.

Жесткие диски


К машине можно подключать произвольное количество жестких дисков. Диски могут быть созданы как пустыми, так и на базе образов. Поддерживается технология снапшотов. Если позволяют возможности операционной системы в виртуальной машине, диски можно подключать и отключать «на лету».

Прочие возможности


Помимо всего прочего, поддерживается возможность добавления SSH-ключей, графическая консоль, генерация RC-файлов для работы с консольными клиентами и другие. В ближайшее время ожидается появление множества новых возможностей — следите за новостями!

Панель управления


Важным компонентом любого облака является пользовательская панель, с помощью которой осуществляется управление виртуальными машинами и другим ресурсами. Сообществом разрабатывается панель, которая называется Horizon — как правило, поставщики продуктов на базе Openstack включают ее в комплект в качестве основного средства доступа к инфраструктуре. Реализуя собственное облако, мы решили отказаться от Horizon и создали собственную панель. Чем было обусловено такое решение?

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

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

Еще один минус Horizon заключается в том, что он (будучи при этом созданным относительно недавно — в 2011 году) основывается на морально устаревшей схеме, предполагающей генерацию страниц на стороне сервера. В качестве примера недостатков такого подхода можно упомянуть, что все обновления статусов приходят в виде отрендеренных фрагментов HTML.

Мы постарались сделать нашу панель более производительной и удобной в обращении, для чего реализовали ее на базе актуальных технологий — панель представляет собой одностраничное веб-приложение (Single Page Application), написанное на JavaScript. Такое решение позволило обеспечить быстрый отлик интерфейса, тем самым повышая комфортность и удобство работы с панелью управления для пользователя.

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

Дополнительные серверные компоненты также понадобились и для реализации управления пользователями и ресурсами.

Заключение


Услуга «Виртуальное приватное облако» предоставляет пользователям широкие возможности, для рассказа о
которых одной статьи явно не достаточно. В ближайшее время цикл публикаций, посвящённых OpenStack, будет продолжен.

Сейчас виртуальное приватное облако функционирует в режиме бета-тестирования. Для дальнейшей работы по его усовершенствованию нам очень важно ознакомиться с мнением пользователей. Поэтому мы приглашаем вас принять участие в тестировании. Всем нашим зарегистрированным клиентам мы уже отправили приглашения по электронной почте. Краткая инструкция по основам работы с нашим новым сервисом опубликована здесь.

Заявку на участие в тестировании можно отправить с помощью тикет-системы.

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

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

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

habr.com

API Облачных сервисов — следующий этап в развитии PaaS. Как экономить больше используя облачные платформы


Наверное, про облачные платформы не слышали только люди далекие от ИТ. Бытует мнение, что облачные платформы в недалеком будущем станут раем для приложений, и рано или поздно почти все приложения будут жить «на небесах».

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

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

Также, в конце статьи, будет описан ряд особенностей облачной платформы, которая развивается совместными усилиями специалистов из России и Украины.

В основном, платформы разделяют на три группы, относительно уровня виртуализации:

  • Облачные хостинги
  • Облачные контейнеры
  • Облачные сервисы

Облачные хостинги


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

Представители: Amazon EC2, Azure, Scalaxy, Clodo

Облачные контейнеры

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

Представители: GAE, Heroku

Облачные сервисы

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

Представители: GAE Services, Oracle Service Bus, LongJump, Saleforces Service Cloud, Hivext Cloud Platform

Облачные сервисы предоставляющие API


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

Однако, расходы на администрирование и на ресурсы приложений это далеко не самая затратная часть в ИТ. Наверно, каждый заказчик приложений знает о том, что именно дороже всего обходится при создании и функционировании его приложения. Самая расходная статья это зарплата сотрудников, а если конкретнее, это зарплата программистов и менеджеров. Чем обширнее проект — тем больше необходимо программистов, чем сложнее его уровень — тем выше уровень подготовки и знаний требуется этих же программистов.


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

Конечно, именно эта же проблема решается с помощью использования разносторонних отдельных готовых наработок и библиотек. Их на данный момент набралось привеликое множество в разных областях разработки ПО. Если проанализировать как развивается процесс эволюции техник программирования и самих ЯП, можно явно выделить переходы от низких до более высоких уровней абстракции. На данный момент выделяют 5 поколений ЯП. Каждое новое поколение поглощает количественные наработки предыдущего поколения и содержит наиболее важные, проверенные и отработанные методики и алгоритмы из ранних поколений. Другими словами, создание средств, техник и самих ЯП для разработки приложений прямо подчиняется закону «Переход количества в качество».

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

Сервисно ориентированное программирование


Данный подход к программированию возник не вчера. Относительно давно существует SOAP и на его базе WebServices с WSDL. Пару лет назад про WebServices говорили также много как сейчас про облачные вычисления. Сегодня различные платформы и сайты предоставляют свои API по разным протоколам. Это является качественным продолжением парадигмы SOA и WebServices.

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

Сегодня активно используется multi-cloud подход — формирования логических цепочек вызовов сервисов разных облачных платформ.

Интересы участников процесса разработки приложений

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

Сервисно ориентированная архитектура Hivext Cloud Platform


При большом количестве разных библиотек и фреймворков сложность разработки приложений остается довольно высокой. Даже, для реализации прототипа и проверки бизнес-идеи разработчик сталкивается с необходимостью разработки большого количества сопутствующих задач не связанных с основной идеей приложения. К таким задачам, прежде всего, относятся: настройка серверных решений (WebServer, DB, ORM и др.), реализация модели безопасности (авторизация пользователей, раздача прав доступа, контроль целостности данных, другие), файловое хранилище. В реальности, это только вершина айсберга задач, которые мало связанны с бизнес идеей самого приложения, но требуют выделения ресурсов для их решения.

В центре идеи Hivext лежит таже парадигма SOA. Однако, имеется ряд особенностей, которые являются ключевыми:

  1. наличие большого набора сервисов, расширяемого разработчиками приложений
  2. наличие сервисной шины, которая удобно их объединяет
  3. наличие клиентских библиотек для всех сервисов и для разных ЯП, которые скрывают работу с сервисами за понятными классами и удобными методами
  4. характеристики облачного хостинга — автоматическое получение дополнительных вычислительных ресурсов по требованию

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

К тому же, Hivext обладает рядом отличительных характеристик

  • разработка прямо в облаке, без деплоя — проблема деплоя решена — его вообще нет
    компиляция происходит прямо на серверах платформы, изменения кода сразу же после сохранения скрипта отражаются на результатах работы
  • скриптовая направленность — стимулирует к написанию небольших кусков кода логики, разработка приложений сводится к написанию небольших скриптов
  • мультиязычность — клиентская и серверная;
    — серверную логику можно расширять используя синтаксис разных языков программирования (на данный момент Java, server JS, PHP), причем во все языки программирования можно внедрять классы созданные на Java или вызывать любой скрипт разных ЯП используя сервис скриптинга
    — на клиенте предлагаются SDK для работы с платформой на разных ЯП (j2me, j2se, javascript, PHP, ActionScript/Flash/Flex, Qt)
  • удобно работать разными командами над одним проектом — сшивание результатов на уровне описанных стандартизированных сервисов, работа с разными приложениями как будто с одним и тем же приложением используя все теже сервисы

Сегодня официально опубликован список финалистов Зворыкинского проекта (государственная программа Федерального агенства по делам молодежи), в который прошел проект Hivext Cloud Platform. Благодарим всех, кто верит в наши силы и поддерживает наш проект советом или делом!

Постскриптум

Обобщим преимущества Облачных сервисов предоставляющих API

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

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

Ссылки на материал, используемый во время написания статьи

PaaS Is The Future Of Cloud Services: APIs Are The Key
PaaS-решения: экосистема сервисов приложений

Картинки найдены в Google.

habr.com

1С в облаках / 1С corporate blog / Habr

Идею облачных сервисов применительно к бизнес-приложениям можно сформулировать так: перенос сервера приложений из локальной сети организации в Интернет. Пользователи продолжают использовать привычный софт, запуская нативный или веб-клиент на своем компьютере, но для работы теперь им достаточно иметь только подключение к Интернету, и не нужно входить в локальную сеть организации (физически или через VPN). А в случае варианта SaaS провайдер облачных услуг, на чьих вычислительных мощностях развернут сервер приложений, также берет на себя и всю работу по администрированию и обновлениям приложений, избавляя конечного пользователя от этих забот.

Картинка для привлечения внимания: автор статьи с помощью подручных средств (облака, флаг, самолет, парашют) иллюстрирует тезис «1С в облаках».



Программы 1С поддерживают работу по протоколу http/https, так что проблем с переносом сервера приложений 1С в Интернет нет. Простейший вариант 1С в «облаке» готов.

Но принципиально такой облачный вариант от обычного отличается, по большому счету, только локацией сервера приложений. Для обслуживания новой организации нужна как минимум новая информационная база 1С, а то и физическая или виртуальная машина с экземпляром приложения 1С. Соответственно, затраты на администрирование приложений возрастают линейно с ростом количества организаций.

Multitenancy и разделение данных


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

Такой подход к проектированию архитектуры приложений называется английским термином multitenancy, для которого нет точного русского перевода; ближайший по смыслу – мультиарендность. Основную идею multitenancy можно описать примерно так. Обычное приложение – это коттедж, рассчитанный на проживание одной семьи, которая пользуется его инфраструктурой (стены, крыша, водоснабжение, отопление и т.п.). А multitenancy-приложение – это многоквартирный дом. В нем каждая семья пользуется таким же составом инфраструктуры, но сама инфраструктура реализована для всего дома целиком.

В простейшем понимании цель multitenancy – снизить расходы на поддержание приложения за счет «обобществления» расходов на инфраструктуру. Это такое же движение, как снижение стоимости приложения за счет применения тиражного решения (возможно, с настройкой и доработкой), а не написание «под заказ». Только в одном случае обобществляется разработка, а в другом – эксплуатация.

У multitenancy есть много аспектов. Один из них – разделение данных в приложении. Физически данные всех организаций хранятся в одной базе данных, но каждая организация видит только свои оперативные данные (проводки, списки сотрудников и т.п.), а часть данных (например, различная нормативно-справочная информация) может быть доступна всем организациям сразу. В приложениях 1С это реализуется через механизм разделения данных, предоставляемый платформой 1С:Предприятие.

Облачный сервис


Некоторое время назад перед командой разработчиков 1С встала задача – сделать облачный сервис для сдачи в аренду прикладных решений 1С по модели SaaS. Более того – сделать этот сервис тиражируемым решением, этаким «облаком из коробки», с помощью которого любой купивший решение сможет на своих мощностях развернуть инфраструктуру для сдачи приложений 1С (или своих написанных на 1С:Предприятии приложений) в аренду.

Что представляет собой идеальный, с точки зрения конечного пользователя, облачный сервис? Супермаркет, где на полках лежат программные продукты – бухгалтерия, отчетность, зарплата и кадры,…. Пользователь наполняет свою тележку и идет на кассу, где платит согласно тарифу (отличие от супермаркета в том, что пользователь не покупает программные продукты, а берет их в аренду на определенный срок). Пользователь определяет, кто из его сотрудников будет иметь доступ к бухгалтерии, кто – к зарплате и кадрам и т.д.

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

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

Так была разработана технология 1cFresh (полное официальное название «1С:Технология публикации решений 1cFresh»). 1cFresh продается как отдельный программный продукт и используется партнерами и клиентами 1С в своих SaaS сервисах и частных облаках (private cloud). Сама фирма 1С использует продукт 1cFresh в своем облачном сервисе сдачи в аренду приложений (SaaS) 1cFresh.com и сервисе 1С:БухОбслуживание. Департамент Информационных Технологий Москвы использует продукт 1cFresh, развернутый на собственных вычислительных мощностях, для ведения бухгалтерского и зарплатного учета в учреждениях, финансируемых из бюджета города Москвы: https://balance.mos.ru/.

Было решено разделить функциональность сервиса между следующими крупноблочными компонентами (реализованными на технологиях 1С:Предприятие и Java):

  • Сайт сервиса – единая точка входа для пользователей
  • Менеджер сервиса – инструмент для администрирования и координирования работы всех компонентов сервиса
  • Шлюз приложений – компонент, отвечающий за горизонтальное масштабирование сервиса
  • Агент сервиса – сюда вынесены все утилитарные функции по работе с прикладными решениями – обновление версий прикладных решений, бэкапы и т.д.
  • Форум сервиса – форум для общения пользователей сервиса друг с другом и с представителями провайдера
  • Менеджер доступности – своеобразное табло «Сервис временно не работает», которое показывает пользователям информацию о недоступности сервиса или его части даже в том случае, если не работают центральные компоненты сервиса.


Упрощенная схема сервиса 1cFresh (представлены не все компоненты сервиса)

Подробнее о компонентах.

Сайт сервиса

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

В составе сервиса может быть любое количество кластеров серверов 1С с установленными прикладными решениями. Все эти кластеры регистрируются в менеджере сервиса. Сервера 1С могут быть развернуты как на Windows, так и на Linux. Так, в нашем сервисе 1cFresh.com в качестве рабочих серверов 1С используются сервера с ОС Windows (в качестве СУБД для прикладных решений используется MS SQL) и с Linux CentOS (СУБД — PostgreSQL).

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

Агент сервиса

Приложение, созданное на платформе 1С:Предприятие. Выполняет административные действия с информационными базами сервиса — обновляет версии конфигураций, создает резервные копии по расписанию, собирает статистику о работе сервиса, и т. д.
Шлюз приложений

Написан на Java. Отвечает за горизонтальное масштабирование сервиса. Перенаправляет пользователей сервиса на предназначенные им сервера с прикладными решениями.
Форум сервиса

Форум, где пользователи сервиса общаться друг с другом и с представителями провайдера сервиса по вопросам функционирования сервиса и размещенных в нем прикладных решений. Написан на Java.
Менеджер доступности

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

Собственно информационные базы, в которых происходит работа прикладных решений. Добавление в сервис новых инфобаз выполняется в составе единиц масштабирования. Единица масштабирования развертывается как единый модуль и содержит:
  • кластер серверов «1С:Предприятия»
  • сервер СУБД, на котором хранятся данные информационных баз.
  • один или два (для обеспечения отказоустойчивости) веб-сервера, обрабатывающие HTTP-обращения к информационным базам единицы масштабирования

При проблемах в работе единицы масштабирования будут затронуты лишь те клиенты, кто непосредственно работал с инфобазами, расположенными на ней.
Еще о сервисе

  • В сервисе поддерживается подобная OpenID технология, позволяющая организовать хранение информации о пользователях аутентификацию в единой базе. Благодаря этому внутри сервиса можно настроить Single Sign-On и пользователи смогут переключаться между прикладными решениями (бухгалтерией, зарплатой и т.д.), форумом и входить в сервис техподдержки ИТС (информационно-технологического сопровождения пользователей 1С:Предприятия) используя единый логин.
  • Пользователи могут переносить данные локальных приложений 1С (например, бухгалтерии) в облачную версию приложения и обратно.
  • Пользователь может создать автономное рабочее место, которое представляет собой локальную файловую информационную базу, расположенную на компьютере пользователя. Для работы с этой базой не требуется наличие Интернета и подключение к сервису. В то же время механизмы сервиса обеспечивают обмен данными между автономным рабочим местом и приложением, опубликованным в сервисе.
  • Можно настроить автоматический обмен данными между опубликованными в сервисе прикладными решениями (например, между бухгалтерией и зарплатой), и таким образом минимизировать объем вводимой информации – вводим данные в одном приложении, а пользуемся ими во всех.
  • Система резервного копирования приложений. Резервная копия приложения может быть создана в любой момент по требованию пользователя. Также автоматически по заданному расписанию создаются ежедневная, ежемесячная и ежегодная копии приложения.
  • В технологии 1сFresh есть механизм поставляемых данных, с помощью которого менеджер сервиса хранит и предоставляет приложениям по запросу единую нормативно-справочную информацию, которая может централизованно обновляться.
  • В сервисе могут одновременно работать несколько версий любого прикладного решения. Прикладные решения, размещенные в сервисе, могут использовать разные версии платформы 1С:Предприятие.
  • Можно обновлять версию прикладного решения, с которым работает информационная база.
  • Для облегчения поиска и анализа причин ошибок в технологии 1сFresh есть различные механизмы:
    • Сбор сведений об ошибках при операциях с информационными базами.
    • Запись этих сведений в информационную базу менеджера сервиса. Собранные сведения об ошибках информационных баз хранятся в информационной базе менеджера сервиса в журнале ошибок.
    • Показ сведений об этих ошибках. Администратор сервиса может просмотреть как весь журнал ошибок, так и ошибки, относящиеся к конкретной информационной базе или к конкретному приложению.

  • В технологии 1сFresh разработан механизм витрин, позволяющий разворачивать несколько облачных сервисов в рамках единой технической площадки сервиса. Витрина – это отдельный интернет-ресурс для предоставления сервиса пользователям. Витрина выглядит для пользователя как отдельный независимый сайт, на котором ему доступны приложения для бизнеса. Например, на различных сайтах, расположенных на отдельных доменах, но на одной технической площадке поставщика сервиса, могут быть развернуты витрины приложений для малого бизнеса, витрины, на которых собраны приложения для госсектора, витрины для медучреждений и т. п. Это позволяет продвигать и развивать ресурс не как часть общего сервиса, а как совершенно независимый сервис. Так, облачные сервисы 1cfresh.com (сдача в аренду приложений 1С «для всех») и gos.1cfresh.com («1С:Предприятие 8 через Интернет для государственных учреждений») – это две витрины одного и того же экземпляра сервиса.
  • В сервисе есть Центр идей – механизм, позволяющий регистрировать и обрабатывать идеи, пожелания и предложения пользователей по работе сервиса. Центр идей реализован как функция прикладного решения, где пользователь может просматривать список идей и комментариев к ним, голосовать за идеи других пользователей или оставлять к ним комментарии, а также добавлять свои собственные идеи и пожелания. Чтобы использовать функциональность Центра идей, в прикладном решении должна быть включена соответствующая подсистема.
  • Пользователи, подключившиеся к сервису, созданному по технологии 1сFresh, на коммерческих условиях, платят определенную абонентскую плату поставщику сервиса за его услуги. В сервисе существуют гибкие возможности настройки тарификации пользователей.
  • Есть богатые возможности по просмотру статистики использования сервиса, позволяющие оценить интенсивность использования сервиса, получить среднестатистические ключевые показатели стабильной (нормальной) работы сервиса для последующей оценки отклонений от нормы, определить периоды максимальной и минимальной загрузки ресурсов сервиса для их учета при планировании регламентных операций по обслуживанию и т.п.
  • Есть возможность сбора бизнес-статистики о событиях, возникающих при использовании прикладных решений. Такая статистика может быть полезна разработчикам прикладных решений для лучшего понимания, как их решение используется конечными пользователями, анализа узких мест и т.д.

Приложения для облачного сервиса


Прикладные решения, созданные на платформе 1С:Предприятие, должны соответствовать определенному набору требований, чтобы функционировать в облаке (в 1С используется термин «работа в режиме сервиса»). Требования к приложениям, работающим в режиме сервиса, подробно описаны в документации продукта 1cFresh.

Помимо использования механизма разделения данных, приложение должно реализовывать набор функций для поддержки удаленного администрирования, выгрузки/загрузки данных, создание резервных копий данных и т.д. Приложение должно одинаково функционировать в режиме тонкого клиента и веб-клиента, избегать использования ОС-зависимых механизмов (т.к. сервер в облаке может быть как под управлением Windows, так и Linux), избегать длительных серверных вызовов и т.п.

На сегодня типовые решения от 1С, совместимые с 1cFresh:

  • 1С:ERP Управление предприятием 2
  • 1С:Комплексная автоматизация 2.0
  • 1С:Бухгалтерия 8
  • 1С:Управление небольшой фирмой 8
  • 1С:Предприниматель 2015
  • 1С:Отчетность предпринимателя
  • 1С:Зарплата и управление персоналом
  • 1С-КАМИН: Зарплата»
  • 1С:Бухгалтерия государственного учреждения 8
  • 1С:Комплексная автоматизация 2.0
  • 1С:Управление торговлей, редакция 11
  • 1С:Зарплата и кадры государственного учреждения
  • 1С:Бизнес-старт

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

Список приложений, работающих в режиме сервиса, будет пополняться – мы будем переводить на работу в облаке и другие свои типовые решения. Есть также ряд решений на платформе 1С:Предприятие от партнеров, которые они сдают в аренду на своих экземплярах сервиса (например, ЖКХ 365).

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

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

В технологии 1cFresh есть два механизма для кастомизации приложений:

  • Внешние отчеты и внешние обработки. Это хорошо знакомый механизм кастомизации решений 1С, доработанный для переноса в облако.
  • Использование расширений. Расширения – это механизм плагинов, который позволяет создавать дополнения прикладных решений, не меняя самих прикладных решений. В расширения пока можно добавлять не все прикладные объекты 1С, но мы постоянно работаем над функциональностью расширений.

Заключение


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

Хочется отметить, что облачный сервис 1cFresh соответствует определению облачного сервиса от консалтинговой компании IDC:

В вольном переводе на русский:

  • Общий, стандартный сервис – построенный для мультиарендности, внутри или вне предприятий
  • Снабженный прикладными решениями – решения «под ключ», с необходимыми для начала работы ресурсами
  • Самообслуживание – резервирование и управление доступом к прикладным решениям, обычно через Веб-портал
  • Эластичное масштабирование ресурсов – динамическое, быстрое и точное
  • Оплата по факту использования – время использования измеряется сервисом
  • Авторизованный доступ по сети — доступ через Интернет
  • Стандартные технологии для пользовательского интерфейса – браузер и/или насыщенное интернет-приложение (Rich Internet Application) и лежащие в их основе технологии
  • Публичный интерфейс/API – веб-сервисы, другие общеупотребительные Интернет-API

По определению Gartner технологию 1cFresh можно отнести к Application Platform as a Service (aPaaS): «Application Platform as a Service (aPaaS) is a form of PaaS that provides a platform to support app development, deployment and execution in the cloud.» — « Application Platform as a Service (aPaaS) – это разновидность PaaS, которая предоставляет платформу для разработки, развертывания и исполнения приложений в облаке» (взято отсюда).

P.S. Недавно вышла книга «Облачные технологии «1С:Предприятия»», рассказывающая о технологии 1cFresh. Это первая (но, надеюсь, не последняя) книга, целиком посвященная 1cFresh. Доступна в бумажном и электронном виде, а также для чтения на мобильных устройствах.

habr.com

Как начать работать c сервисными аккаунтами | Яндекс.Облако

Сервис IAM позволяет вам создавать сервисные аккаунты — дополнительные аккаунты, с помощью которых программы могут выполнять операции в Яндекс.Облаке. Сервисные аккаунты бесплатны и позволяют гибко управлять доступами ваших программ. Подробнее в разделе Сервисные аккаунты.

Эта инструкция для владельцев облака и пользователей с ролью администратора на облако или каталог. Пользователи с ролью editor тоже могут создавать сервисные аккаунты, но не могут назначать роли, поэтому не смогут разрешить сервисному аккаунту выполнение операций в Яндекс.Облаке.

Вы научитесь:

Перед началом

  1. Если вы еще не зарегистрированы в Яндекс.Облаке, перейдите в консоль управления.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его.

Создайте сервисный аккаунт

Чтобы создать сервисный аккаунт и назначить ему роли:

  1. Войдите в консоль управления.

  2. Нажмите на строку с именем каталога, в котором вы хотите создать сервисный аккаунт.

  3. Выберите вкладку Сервисные аккаунты.

  4. Нажмите кнопку Создать сервисный аккаунт.

  5. Введите имя сервисного аккаунта.

  6. Чтобы назначить сервисному аккаунту роль на текущий каталог, нажмите Добавить роль и выберите роль, например editor.

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

  7. Нажмите кнопку Создать.

Настройте CLI для работы от имени сервисного аккаунта

От имени сервисного аккаунта вы можете выполнять операции через API, CLI и другие инструменты, которые поддерживают аутентификацию с сервисным аккаунтом. В консоль управления войти с помощью сервисного аккаунта нельзя.

Настройте CLI для работы от имени сервисного аккаунта:

  1. Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

  2. Создайте авторизованный ключ для вашего сервисного аккаунта и запишите его файл:

    yc iam key create --service-account-name my-robot --output key.json 

    Если вы получили ошибку ERROR: service account with name "my-robot" not found, значит в каталоге по умолчанию нет сервисного аккаунта с таким именем. Если имя правильное, то выполните одну из команд:

    • Укажите каталог с сервисным аккаунтом с помощью параметра --folder-name или --folder-id:
      yc iam key create --folder-name my-folder --service-account-name my-robot --output key.json 
    • Укажите сервисный аккаунт по идентификатору с помощью параметра --service-account-id:
      yc iam key create --service-account-id b1gnbfd11bq5g5vnjgr4 --output key.json 
  3. Создайте профиль, который будет использоваться для выполнения операций от имени сервисного аккаунта:

    yc config profile create my-robot-profile 
  4. Укажите в конфигурации профиля авторизованный ключ сервисного аккаунта:

    yc config set service-account-key key.json 

Теперь вы можете выполнять операции от имени сервисного аккаунта, например посмотреть список каталогов, доступных этому аккаунту:

yc resource-manager folder list 

Удалите сервисный аккаунт

Если сервисный аккаунт больше не нужен, удалите его:

  1. Перейдите в каталог, которому принадлежит сервисный аккаунт.
  2. Выберите вкладку Сервисные аккаунты.
  3. Нажмите значок напротив сервисного аккаунта и выберите Удалить сервисный аккаунт.
  4. Подтвердите удаление.

Что дальше

cloud.yandex.ru


Смотрите также



© 2010- GutenBlog.ru Карта сайта, XML.