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

В марте 2024 компания Rusonyx приняла стратегическое решение о смене поставщика панели управления сайтами и серверами. Выбор в пользу ispmanager был сделан на основе тщательного анализа, учитывающего стандарты безопасности и производительности. Новое ПО ведет к 60%-му сокращению расходов на закупку панели управления, сохраняя при этом весь необходимый функционал для бесперебойной работы сайтов клиентов.

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

рассказал Максим Балыкин, технический директор Rusonyx.

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

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

прокомментировал генеральный директор ispmanager Федор Богомолов.

С 23 июля 2024 г. вступили в силу изменения в реквизитах нашей компании. Мы изменили юридическое наименование, юридический адрес и КПП.
Эти изменения никак не отразятся на порядке и качестве предоставления наших услуг. Коммерческое обозначение Rusonyx продолжает действовать.
Новое наименование общества: Общество с ограниченной ответственностью «Астра Облако», краткое наименование: ООО «Астра Облако»
Новый юридический адрес общества: 123100, г. Москва, вн.тер.г. муниципальный округ Пресненский, наб Краснопресненская, д. 8
Новый КПП общества: 770301001
Все остальные реквизиты остаются прежними: ОГРН, ИНН и банковские реквизиты.
При оформлении всех платёжных, финансовых и прочих документов с 23.07.2024 г. просим указывать новое наименование организации, юридический адрес и КПП.

bgp.tools/as/41535#prefixes
astracloud.ru
my.rusonyx.ru/#/start

Компания Rusonyx основана в 2001 году и специализируется на предоставлении услуг хостинга и облачных ресурсов, а также продаже SSL-сертификатов и программного обеспечения 1C-Битрикс, CGP и дополнений к ним. Является российским локальным интернет-регистратором (Local Internet Registry, LIR), занимается распределением адресного IP-пространства пользователям сетей и оказанием сопутствующих регистрационных услуг. Размещает ИТ-ресурсы в одном из крупнейших дата-центров в России DataPro, имеющего сертификацию на соответствие уровню Tier III по классификации Uptime Institute.
С апреля 2024-го года входит в состав «Группы Астра».

www.ispsystem.ru/cases/rusonyx

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

Максим Балыкин Технический директор Rusonyx

Хостинг-провайдер Rusonyx приобрел петербургскую компанию Infobox, оцененную примерно в 90 млн руб. На фоне стагнации рынка Rusonyx рассчитывает сохранить эффективность, объединившись с конкурентами, полагают эксперты. Сегмент может вырасти за счет оказания облачных сервисов, но в этой сфере хостинг-провайдерам придется конкурировать с такими крупными игроками, как «Ростелеком» и МТС.

Хостинг-провайдер Rusonyx приобрел крупнейшего в Санкт-Петербурге конкурента — Infobox (ООО «Национальные коммуникации»), рассказал “Ъ” гендиректор и совладелец Rusonyx Константин Анисимов. Сумма сделки, по его словам, составила около 90 млн руб. По итогам объединения база клиентов Rusonyx увеличится на 12 тыс., до 37 тыс., а сотрудники Infobox войдут в Rusonyx. Годовой оборот объединенной структуры превысит 300 млн руб., ожидают в Rusonyx.

ООО «Русоникс» приобрело 99% ООО «Национальные коммуникации» 25 декабря, еще 1% напрямую получил Константин Анисимов, следует из данных «Спарк-Интерфакс».

Выручка Infobox в 2019 году составила 89 млн руб., чистая прибыль — 11,4 млн руб. Выручка самого ООО «Русоникс» за тот же период составила 83 млн руб. при чистой прибыли в 7,6 млн руб. С учетом финансовых показателей подконтрольных компаний совокупные доходы Rusonyx вдвое превышают показатели Infobox, утверждает Константин Анисимов.

Rusonyx прежде принадлежала структуре японского венчурного фонда United Managers Japan и Константину Анисимову. В 2020 году, по словам гендиректора, японский фонд вышел из компании и продал долю неназванному «иностранному инвестору с российскими корнями», а контрольную долю сохранил сам господин Анисимов.

Rusonyx приобретает не первый актив. В 2018 году компания купила провайдера облачных услуг Caravan Aero, еще через год — одного из старейших столичных хостинг-провайдеров «Зенон Н.С.П.» (см. “Ъ” от 25 октября 2019 года). Компания оказывает услуги хостинга сайтов и предоставляет виртуальные выделенные серверы в аренду и облачные сервисы.

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

«Хостинг-провайдеры становятся сегментом рынка облачных сервисов и услуг», — считает он. Изначально хостинг-провайдеры оказывали исключительно услуги размещения веб-сайтов, но сегодня спектр их услуг серьезно расширился, объясняет ведущий консультант iKS-Consulting Станислав Мирин. Компании этого сегмента, по его наблюдениям, начинают оказывать также услуги хранения и обработки данных.

Облачный рынок в России, по оценкам iKS-Consulting, вырос в прошлом году до 100 млрд руб., а входящий в него сегмент «Инфраструктура как услуга» (IaaS) составил 29,5 млрд руб. На рынке лидируют «Ростелеком», МТС и «Крок», а Rusonyx занимает на нем лишь 0,2%.

Хостинг-провайдеров, как и поставщиков облачных услуг для бизнеса, можно отнести к облачному рынку, говорит директор по развитию сервисов «Крок Облачные сервисы» Сергей Зинкевич. Отличие, по его словам, заключается в целевой аудитории. «Если услугами хостинг-провайдеров пользуется малый бизнес, то услугами облачных провайдеров — крупные компании, которые размещают в облаке критичную инфраструктуру», — объясняет он.

До прямой конкуренции с поставщиками облачных сервисов хостинг-провайдерам «еще далеко», считает гендиректор сети дата-центров 3data Илья Хала. Тем не менее этот сегмент интересен для инвестиций, считает он. Главным активом в сделках с хостинг-провайдерами, по его мнению, являются клиенты.

www.rusonyx.ru

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

Я спросил у Яндекса…

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


Кстати, знаете дату появления первой в мире web-страницы? Считается, что праотец всего интернета поселился в августе 1991 года вот по этому адресу: info.cern.ch. Выглядело это весьма эпично. Теперь понятно, откуда зеленые буквы на черном фоне в «Матрице». Любопытно, что в русском сегменте сети можно найти массу источников утверждающих, что все началось еще в 1990 году.


Кстати, видели «папу всея веба»? Знакомьтесь, Тим Бернерс-Ли, собственной персоной. Этого мужчину считают «отцом» основополагающих технологий веба — HTTP, URI/URL и HTML. Жив. Цел. Орел. 63 года.


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



Точкой отсчета для услуг российского хостинга можно считать рубеж 1999-2000 годов, когда появились компании, предоставляющие только хостинг и не предоставляющие услуги подключения конечного пользователя к Интернету. Хотя, официально День Хостинг-провайдера в России начали отмечать лишь с 1 марта 2011 года.

Кстати, хотите посмотреть на одно из первых рекламных предложений услуг хостинга в русском сегменте сети? Enjoy!

Цены и дополнительные услуги как говорится «доставляют».

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



«Немытые хостеры» становятся звездами… но не все
В 2009 года Сергей Белоусов (основатель Parallels, Acronis, Runa Capital, Rolsen и др.) рассказывал Константину Анисимову (моему шефу в Rusonyx), как он встречался с тогдашним генеральным директором VMware Полом Маритцем. Они спорили о технологиях виртуализации, Сергей доказывал, что контейнеры это крутая технология. Пол ответил тогда, что да, технология хорошая, но ты выбрал неправильный рынок. Мы работаем на респектабельном корпоративном рынке, а ты делаешь софт для каких-то «немытых хостеров» (unwashed hosters).


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

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

Когда бизнес идет по накатанной, особенно пока рынок рос — стимулов перестраиваться прямо скажем было немного. «Зачем ремонтировать часы, которые не сломались», как говорится в старой английской поговорке. Тем не менее, очевидно, что развитие бизнеса по традиционной модели для хостеров с каждым годом становится менее рентабельным. Отсюда исчезновение старожилов, всевозможные слияния и поглощения. Рынок постепенно консолидируется. И эти процессы очевидно продолжатся в этом и последующие годы!

отмечает Константин Анисимов, генеральный директор Rusonyx.

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

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

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

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

3. Активное развитие направления FaaS («функция как сервис»). Все больше и больше пользователей начинают использовать serverless computing (бессерверные вычисления) при разработке своих приложений. Благодаря чему компании-разработчики программного обеспечения, веб-приложений, чат-ботов, сервисов в области Интернета вещей и финансовых технологий могут снизить затраты на разработку до 15-20 раз.

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

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

В 2018 году serverless это самый быстрый способ сделать бекенд приложения, даже если вы никогда их не делали. Да, я знаю про бесчисленное множество конструкторов приложений, MBaaS или BaaS, но мне хочется показать, что serverless подходит не только для элементарных приложений, но и для масштабируемых сложносочиненных бекендов, которые не получится сделать на конструкторе.

На днях мы запустили первое в России serverless облако — Rusonyx Serverless на базе платформы Swifty. Первые три месяца использования платформой бесплатны, так что все желающие могут попробовать serverless подход в деле.

В статье я расскажу, как создать простое todo приложение с аутентификацией, профилем пользователя, хранением картинок и, собственно, управлением задачами используя serverless подход. Мы, естественно, будем делать это на Swifty, но подход здесь примерно одинаков для всех serverless решений. Пример готового приложения можно посмотреть здесь. Фронтенд написан на vue.js, запускать который мы будем на встроенном Object Storage (S3), бекенд будем делать на функциях на Go и Python.

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

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


Теперь, когда у вас есть аккаунт можно приступать к созданию самих функций. Swifty включает сервис аутентификации — Authentication, который дает базовые операции signup, signin и logout, а также возможность создавать, изменять, получать и удалять профиль пользователя. В нем есть также интеграция с Facebook и возможность связывать уже созданный профиль с профилем Facebook. Но они нам пока не понадобятся. Maybe later.

Создаем сервис аутентификации:

• Открываем Swifty -> Authentication Services.
• Нажимаем Create Auth Database и называем базу todoapp. Я в дальнейшем буду использовать это название, но вы можете назвать свою базу по-желанию.

В результате будет создано много чего:

• Функция todoapp.base — делает signup, signin и logout пользователей, реализует OAuth 2.0 протокол.
• Функция todoapp.fb — позволяет аутентифицировать пользователей через fb.
• Функция todoapp.link — связывает аккаунты уже созданных пользователей с их аккаунтами на fb.
• Функция todoapp.profiles — создает, обновляет, удаляет профили пользователей в MongoDB.
• БД todoapp_mgo — Mongo для хранения аккаунтов пользователей.
• БД todoapp_profiles — Mongo для хранения профилей пользователей.
• Authentication Middleware (AuthMW) — прокси, который позволяет при обращении к API функции проверять аутентификацию пользователя через проверку его JWT токена, который ему выдала функция todoapp.base. Нет токена или он не верен — запрос к API будет отброшен.

Мы используем “.” в наименовании функций для разделения их по папкам. Поэтому если вы создадите новую функцию с именем todoapp.newfunction, то она автоматически попадет в папку todoapp и отобразится там с именем newfunction. Ваш список функций теперь должен содержать следующий набор (см.картинку).


Можно пропустить, но лучше прочитать
Этот параграф, в принципе, можно пропустить. Или нет, если вы хотите понять, как работает наш сервис аутентификации и чуть больше понять о принципах работы Swifty. Функция todoapp.base, написанная на Go, дает базовые возможности аутентификации, но ничто не мешает вам расширить ее возможности в соответствии с потребностями вашего приложения. Как бы вы ее не меняли, не трогая signin и signout, она все-равно будет делать свою работу. В функции есть переменная SWIFTY_AUTH_NAME, которая хранит название AuthMW. Функции также нужен доступ к MongoDB и собственно AuthMW, которые прописаны на вкладке Access в свойствах функции. Также у нее есть REST API триггер у которого есть ссылка, которую и нужно вызывать, чтобы получить доступ к функции.

Функция todoapp.base ожидает, что вы передадите ей userid и password в виде аргументов запроса. При этом пароль шифруется.

Вот примеры таких запросов:

* Sign up:
https://api.swifty.cloud:8686/call/012.../signup&userid=user@yourmail.com&password=xxxxxxxx
* Sign in:
https://api.swifty.cloud:8686/call/012.../signin&userid=user@yourmail.com&password=xxxxxxxx
* Log out:
https://api.swifty.cloud:8686/call/012.../leave&userid=user@yourmail.com

Если, например, signin был успешен (функция успешно проверила переданный пароль), то вы получите JSON с JWT токеном, который нужно будет использовать каждый раз при обращении к функциям, для которых включена аутентификация. JWT токен создается на базе Bearer Authentication схемы. Подробнее про OAuth 2.0 и Bearer cхему можно прочитать тут.

Если аутентификация не успешна, то вызываемая функция не запускается и запрос возвращает код 401.

Управление профилем пользователя
Итак, у каждой функции есть REST API url, ссылка, которую нужно вызвать, чтобы запустить функцию. Чтобы получить эту ссылку для функции аутентификации, откройте функцию todoapp.base, перейдите на вкладку Triggers, скопируйте REST API url и сохраните его как AUTH_URL где-нибудь. Чуть дальше нам потребуется вставить эту ссылку в конфигурационный файл фронтенда нашего приложения.


Также нам нужен API URL для todoapp.profiles, чтобы наше приложение могло управлять профилями пользователей. Откройте эту функцию, перейдите на вкладку Triggers, скопируйте REST API url и сохраните его как PROFILE_URL.

Управление аватаром пользователя
Наше приложение также позволяет загрузить аватар пользователя и продемонстрировать, как можно хранить файлы на встроенном Object Storage. Картинка пользователя загружается с помощью специальной функции и хранится на встроенном Object Storage. Доступ к картинке можно получить через функцию или с помощью стандартного S3 API, ключи доступа к которому можно получить на вкладке управления Object Storage в UI.

Чтобы создать функцию управления картинками:

• Переходим на вкладку Functions -> New Function -> From repo (Templates). Мы храним все шаблоны функций в публичном git репозитории swifty.demo. Этот репозиторий должен быть выбран по умолчанию.
• Выберите функцию Avatar management (python), нажмите Next и введите имя новой функции todoapp.avatar. Нажмите Create.
• Далее перейдите на вкладку Triggers, нажмите Add Trigger, выберете REST API (URL). Скопируйте появившуюся ссылку и сохраните ее как PICTURE_URL.

Далее нужно создать бакет в Object Storage для хранения картинок пользователей:

• Переходим на вкладку Object Storage -> Create Bucket. Назовите новый бакет todoappimages.
• Переходим на вкладку Functions -> todoapp.avatar -> Access -> нажимаем Add, выбираем Object Storage, вновь созданный бакет todoappimgaes и жмем Add.

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

• Переходим на вкладку Functions -> todoapp.avatar -> Variables и нажимаем Create Variable.
• Вводим имя переменной — BUCKET_NAME, и ее значение — todoappimages.

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

Создаем функцию:

• Переходим на вкладку Functions -> New Function -> From repo (Templates).
• Выберите функцию TODO application (python), нажмите Next и введите имя новой функции todoapp.tasks. Нажмите Create.
• Далее перейдите на вкладку Triggers, нажмите Add Trigger, выберете REST API (URL). Скопируйте появившуюся ссылку и сохраните ее как TASKS_URL.

Далее нам нужна база данных, чтобы хранить наши задачи. Самый простой вариант — MongoDB.

• Переходим на вкладку Mongo Database -> Create Database и создаем базу с именем todoapp_tasks.
• Переходим на вкладку Functions -> todoapp.tasks -> Access -> Add и добавляем новую базу.

Теперь наша функция имеет доступ к БД todoapp_tasks и мы можем обратиться к ней из функции с помощью библиотеки swifty, например так:

db = swifty.MongoDatabase(os.getenv('TASKS_DB_NAME’))

Нам осталось только прописать переменную окружения с именем базы данных:

• Переходим на вкладку Functions -> todoapp.tasks -> Variables и нажимаем Create Variable.
• Вводим имя переменной — TASKS_DB_NAME, и ее значение — todoapp_tasks.
• Включаем аутентификацию для функций

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

Как включить проверку токенов для определенных функций:

• Переходим на вкладку Functions и выбираем функции todoapp.tasks и todoapp.avatar.
• Нажимаем Manage Authentication и выбираем сервис todoapp, нажимаем Enable.
• Теперь, функции todoapp.tasks и todoapp.avatar будут выполнены только для пользователей с правильным JWT токеном сгенерированным с помощью todoapp.base.

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


Публикация приложения
Займемся фронтендом нашего приложения. Фронтенд написан на vue.js и нам нужно всего лишь добавить ссылки на наши функции в его конфигурационный файлик и пересобрать приложение с этой обновленной конфигурацией. Здесь все просто и никаких знаний vue.js и JavaScript не понадобиться.

Для того, чтобы пересобрать приложение вам нужен установленный node.js. Если у вас его нет, то используйте, пожалуйста, официальный гайд, чтобы его поставить. Если у вас mac, то есть хороший гайд здесь. Также вам понадобиться git, чтобы стянуть репозиторий себе на компьютер. Пожалуйста, сделайте:

# git clone https://github.com/swiftycloud/swifty.todoapp

После этого перейдите в папку /swifty.todoapp/src и откройте файл config.js в вашем любимом редакторе. Вам нужно поменять содержащиеся там переменные на на те, которые вы сохранили ранее:

export const AUTH_URL = "https://api.swifty.cloud/call/991..."
export const PROFILE_URL = "https://api.swifty.cloud/call/281..."
export const PICTURE_URL = "https://api.swifty.cloud/call/e6a..."
export const TASKS_URL = "https://api.swifty.cloud/call/4b1..."

Переменные связанные с FB нам пока не нужны.

Затем вам нужно пересобрать приложение:

# npm run build
…
DONE Build complete. The dist directory is ready to be deployed.

Прежде чем собрать приложение вы можете также протестировать его локально:

# npm run serve

и зайти в него через браузер по адресу localhost:8080

Мы используем Object Storage для хранения статических файлов нашего приложения. Перейдите на вкладку Object Storage, создайте бакет todoapp и загрузите в него файлы из папки /swifty.todoapp/dist/ соблюдая именование папок (их придется создать руками).

Последний шаг — публикация приложения. Нажмите More -> HTTP Server Settings и включите HTTP Server для вашего бакета. Скопируйте появившуюся ссылку и перейдите по ней — это и есть ваше приложение!


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

Что дальше?
Мы показали простой пример, как использовать serverless для создания приложений. У нас еще много шаблонов популярных функций, а у вас, я уверен, еще много идей для новых приложений. Пробуйте шаблоны, пишите свои функции и make your ideas come app.

Ну и конечно же, обращайтесь, если у вас есть какие-то вопросы по serverless вообще и Swifty в частности.
www.rusonyx.ru/swifty/

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

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

Появление концепции Serverless, предполагающей создание и запуск приложений без необходимости настраивать серверную часть на этом фоне кажется вполне логичным. Несмотря на популярность названия «Serverless», встречается также аббревиатура FaaS («Functions as a Service»). Так вот, вас не должно вводить в заблуждение пресловутое Serverless. Оно вовсе не означает полный отказ от серверов. Как известно: «Если что-то убыло, значит где-то прибыло». В данном случае, речь идет о том, что железо уходит на сторону Amazon, Microsoft и других монстров индустрии, предоставляя рядовым разработчикам возможность творить без оглядки на размер серверного шкафа и хороших отношений с командой DevOps.



Основные преимущества концепции Serverless:

Простота создания и развертывания продукта;
Возможность быстро и просто масштабировать ваш проект;
Высокая доступность и отказоустойчивость бекенда;
Отсутствие необходимости управления серверной инфраструктурой и как следствие снижение ваших затрат на поддержку ее работоспособности;
Ускорение разработки приложений;
Сокращение затрат на инфраструктуру и DevOps (и вам больше не нужен Docker);

Больше информации по теме можно почерпнуть, например, здесь, здесь и здесь.

DevOps умер, да здравствует DevOps?

Serverless является отличным дополнением к автоматизации. Любой хороший DevOps, использующий AWS, Azure, IBM Cloud или GCP, способен применить соответствующие бессерверные решения для повышения управляемости приложений. Но чем насыщенней среда, тем нужнее люди способные к ней адаптироваться. Иными словами, DevOps, конечно же не умрет, но требования к знаниям и навыкам специалистов неизбежно эволюционируют.

Тем более, что сфера применения serverless уже сейчас очень широка:

• Финансы
• Ритейл
• IoT
• Социальные медиа
• Чаты
• Uber-like приложения

Где на serverless можно реализовывать очень разные сценарии:

• Backend для приложений и сайтов
• Data Processing (images, video, логи)
• IoT (включая SmartCity)
• Serverless веб-сайты
• Автоматизированные задачи (включая бекапы)
• Cloudlet
• (data preprocessing)
• Чат-боты
• Окружения для обучения программированию

Кто здесь?
Крупные игроки уже на этом рынке: Amazon AWS, Azure, IBM Cloud, Google Cloud, Oracle. Имея значительные ресурсы, ИТ-гиганты способны работать в перспективных направлениях, улавливая тренды и существенно опережая отрасль в своем развитии. Плюс, есть множество Open Source проектов, в той или иной степени реализующие serverless. Тем интереснее российский ландшафт.


Сегодня мы имеем довольно пеструю картину. С одной стороны, как и во всем мире, доминируют решения от лидеров рынка типа Microsoft, Amazon и Google, а с другой стороны, возникают по-настоящему интересные альтернативы.

К таковым можно отнести первое в России serverless облако — Rusonyx serverless на базе swifty.cloud. Эта штука – простой путь к махровому крутому, масштабируемому бекенду.

Rusonyx serverless на базе swifty.cloud фактически — out-of-the-box платформа для бекендов приложений, сайтов и чат-ботов, но при этом не лимитированная возможностями традиционных Backend-as-a-Service решений. Она включает в себя большинство необходимых сервисов:

• Serverless функции
• SQL и noSQL базы данных
• Object Storage
• Authentication-as-a-Service
• Симпатичный UI, API, CLI для Mac/Linux
• Шаблоны функций и целых сервисов

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

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

Make your ideas come app, как говорят ребята из swifty.cloud