И тогда наверняка нас захватят облака

Почему облака победят?

Думаю, вряд ли кто-то из представителей ИТ индустрии мог не заметить тенденцию по «переезду всего и вся» в облака, для примера вот такая «картинка из интернета» по каким-то исследованиям отображает эту самую пугающую динамику:

Является ли текущая тенденция по переезду софта в облако постоянной? Будет ли всё это продолжаться? К слову, ещё лет 5 назад я себя считал противником облачных решений, потому что в общем и целом не видел в них смысла: для компании это получается дороже (да, я не оговорился, вопреки навязанному популярному мнению облака-таки обходятся дороже), появляется зависимость от интернета, ничем не гарантируется сохранность и конфиденциальность данных, непрозрачное управление мощностью и  скоростью, ну и самое главное – ПО поставляется «AS IS» и какая-либо кастомизация ограничивается тем, что заранее предусмотрели разработчики. Худшим компаниям это на руку, но лучших лишает конкурентных преимуществ. Но сейчас будущее господство «облачных решений» вряд ли можно ставить под сомнение.     

Если кто-то до сих пор сомневается, короткое шуточное доказательство данной "теоремы":

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

Доказать: Всё ПО вскоре станет «облачным»

Доказательство:

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

- Регулярные и прогнозируемые, а не разовые и непрогнозируемые поступления  денег.

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

- Возможность гибко регулировать стоимость своего ПО.

- Следовательно, компании разработчики облачного софта получат больше денег

- Следовательно, компании разработчики облачного софта привлекут лучших разработчиков, в том числе у компаний разработчиков десктоп решений

- Следовательно, качество «облачного» софта будет улучшаться, а десктопного – ухудшаться

- Где лучше софт, там и клиенты, там и победа. Бинго!

Доказательство, конечно, такое - весьма шуточное, но «в каждой шутке есть доля шутки».

Как функционирует облачное приложение?

Современное облачное приложение выглядит как-то так:

Если спуститься на инфраструктурный уровень, то всё ещё несколько интереснее:

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

1. Логика приложения полностью отделена от данных
2. Пользовательский интерфейс отделен от бизнес логики
3. Логика приложения поделена на отдельные микросервисы, которые могут управляться, разрабатываться и обслуживаться независимо друг от друга
4. Каждый микросервис может быть изолирован от другого
5. Каждый микросервис может иметь свой источник данных или не иметь такового
6. Источники данных облачного приложения распределены и кластеризованы
7. Архитектура приложения подразумевает использование как внешнего так и внутреннего балансировщика нагрузки

Но и это ещё не всё. На самом деле приложения даже впрямую не обращаются друг к другу. Их взаимодействие выглядит как-то так:

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

Для чего я тут привожу данные красивые картинки с очевидными всем вещами? Всё это только чтобы лучше ответить (прежде всего для себя) на следующий вопрос:

А как у 1С обстоят дела с облаками?

Если кратко – никак. И сами представители 1С - достаточно честные люди и не называют свои решения «облачными»:

Вот так это называется на сайте 1cfresh.com. Всё, что вы увидите с названием «1С:Облако», на самом деле решения партнёров и с облачными технологиями имеют мало чего общего. Так вот, главное облачное, что у 1С есть – это fresh. А Fresh – если отбросить всякие порталы и инфраструктурные обвязки – не что иное, как помещение всех приложений в одну БД. К сожалению, точных и честных картинок, демонстрирующих, что есть 1C:Fresh и традиционное облачное приложение, найти не удалось, поэтому ниже мои «произведения искусства».

Вот примерно так выглядит сервис 1C:Fresh: куча пользователей, один сервер 1С и одна база на сервере СУБД в которой по факту куча «баз». Схема, конечно, сильно упрощена:

А вот примерно так выглядит облачное приложение:

При этом под «данными» на этом рисунке понимается совсем не одна БД для приложения, и даже не использование её реплик; по факту это может быть два разных типа технологий:

1. Кластерная параллельная СУБД (ClickHouse, MongoDB, CouchDB, Cassandra)
2. MapReduce (Hadoop, Spark, хотя сейчас, конечно, поддерживается всем, чему не лень)

В первом случае за всё отвечает СУБД – это, собственно, может быть просто очень хитрая и продуманная технология кластеризации, как Oracle RAC. Для конечного разработчика всё при этом достаточно прозрачно

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

И первое, и второе позволяет использовать так называемый «шардинг». Куски таблицы могут быть распределены по разным серверам, достаточно слабо друг с другом связанным. Соответственно, ваши возможности масштабирования ничем не ограничены, и, к слову, стоят совсем недорого. Для примера, шардинг в MongoDB намного более простое и естественное явление, чем AlwaysOn в MsSQL Server.

Теперь к самому главному – всё вышеперечисленное нужно только для понимания утверждения «SingleDatabase и HightLoad едва ли совместимы в современном мире». А у нас во Fresh не просто SingleDatabase, а Single SingleDatabase. Т.е. когда весь мир живёт по принципу «разделяй и властвуй», 1С наоборот – «соберём-ка мы все яйца в одну корзину».

Единственное, что какое-то время удерживало от критики, – теорема CAP. Краткое содержание которой просто: «всё и сразу не получится». Всегда страдает либо согласованность, либо доступность, либо устойчивость данных. Но после того, как я для себя уяснил, что у 1С и сейчас с согласованностью данных есть существенные проблемы: //infostart.ru/public/1051660/  наверное, можно написать, что технология fresh – тупиковый путь в мир облачных технологий.

И что делать?

Если планов иммиграции из РФ нет – можно не волноваться как минимум ещё лет десять, новости, которые казались такими печальными, на поверку очень оптимистичные – я про тот самый «Закон о суверенном интернете» http://duma.gov.ru/news/44551/ , который де-факто подразумевает включение DPI во всём магистральном сетевом оборудовании. Следовательно, интернет вне пределов РФ будет тупить жутко, да и в пределах РФ будет много проблем между провайдерами. Поэтому «тотального нашествия облаков» нам можно не опасаться, пока вся эта история не будет вновь переиграна.

Если же хочется чувствовать свой вес на международном рынке – нужно понимать, что «проблема с облаками» застигла врасплох не только 1С, но и все технологии разработки для Enterprise. Технологии внутрикорпоративной разработки всё-таки предполагали создание больших монолитных приложений, с развитой архитектурой и огромным количеством модулей. Трудная сборка, практически нереально покрыть unit тестами, CI/CD превращается в АД. С переходом к микросервисной архитектуре всё существенно упростилось. Приложения теперь мелкие и компактные, запускаются в контейнерах, контейнеры оркеструются каким-нибудь Kubernetes, и всё стало существенно проще. 90% мощи и возможностей Enterprise технологий Java и .Net не нужны в этом случае. А «плата» в виде «виртуальной машины» кажется слишком высокой для приложений, которые и без того запускаются в специально для них созданной виртуальной машине (контейнере). Так что если хочется взгляда в будущее, учите Go, Python, Js (Ts). Чем более простой и легковесный язык, тем больше популярности он набирает.

А что делать, если хочется в облака с 1С?

Сначала я, конечно, напишу, что считаю - 1С «упустили» скачок облачных технологий. Хорошо, конечно, что есть хотя бы 1C:Fresh, но это явно какая-то «полумера», которая была придумана, чтобы обеспечить работу кучи пользователей в одной базе без существенных трудозатрат на разработку чего-то нового. Потому как непонятно, что пойдёт, а что нет.

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

• Открыть исходный код платформы для модификации в прикладном решении. Ну или хотя бы Front части. По интерфейсам, скорости и подходам, конечно, сильно уступаем традиционному Web-у
• Сделать поддержку разных СУБД для каждого объекта метаданных, включая NoSQL СУБД.
• Сделать возможной работу без сервера 1С. Приложение должно по сути использовать Web сервер, и поддерживать управление сеансами от Web сервера. Тогда кластеризация будет практически неограниченной

Но, конечно, у нас с вами всего этого нет, и вряд ли когда либо будет. Что можно сделать?

Идея, которая меня не отпускает – исключить из этого «порочного круга» хотя бы сервер 1С. К сожалению, с ним вместе нужно будет исключать и сервер СУБД. Но не беда – есть файловые базы.  Конечно, я не первый, кто это придумал: //infostart.ru/public/242527/ .

Но это ещё не вся суть. В случае использования файловой БД (по сути это просто файловый ресурс, который должен быть доступным) приложением по факту будет являться только Apache сервер с модулем 1С внутри. Такой контейнер поднимается за несколько секунд. Конечно, для того, чтобы это нормально работало, нужно бы контейнерами как-то централизованно управлять (оркестрировать). Для этого обычно юзают Kubernetes. А дальше просто – пока контейнер не используется – он «спит». Таким образом ресурсы потребляет только в тот момент, когда нужен. По скорости – файловая база в общем случае производительнее клиент-серверной, если с ней работает один пользователь. Но это ещё не всё. Если спросить у вас – как работать с базой 1С наиболее быстрым образом – все, наверное, ответят «на RAM диске». Нормальный человек при этом, конечно, скажет: «Какой RAM диск, там же данные!». Конечно, хранить файловую БД на RAM диске на конкретном сервере не самая лучшая идея. Но в современном мире технологии «in-memory» достаточно распространены, соответственно появились и технологии, обеспечивающие их надежность. В частности, Memory Storage поддерживается в HDFS (Hadoop). Ну а Hadoop, как известно, вполне себе распределенная система, соответственно, каждая часть данных хранится на нескольких узлах. Остановка одного из них не приводит к потере данных, а учитывая скорость RAM диска, не приведёт даже к деградации производительности. Вообще распределенная ФС – общий подход к организации высокопроизводительного и надежного хранилища данных. Правда, при этом особое внимание стоит уделить сетевым коммуникациям и выбору технологии для ФС. При этом, конечно, будут некоторые задержки (Latency) из-за доступа к данным по сети, но файловые БД менее к ним чувствительны. Поэтому даже если такая производительность не нужна – проще организовывать распределенную ФС (ceph или cinder).

Далее возникает резонный вопрос: «а как же объём данных»? Ранее на 300 баз (к примеру) был только один файл конфигурации, а теперь храним 300 одинаковых. То же самое касается поставляемых данных. В современном мире это также не такой уж актуальный вопрос. Дедупликация поддерживается как большинством распределенных, да и не распределенных ФС так и большинством дисковых полок. Одинаковые блоки не хранятся дважды без необходимости. Поэтому от использования разделенной БД экономия дискового пространства вряд ли будет такой существенной, как это кажется на первый взгляд.

Таким образом, всё, что необходимо для создания облачного приложения, у 1С по сути уже есть. И это всё – «маленькая dll-ка», которая устанавливается как модуль Apache и позволяет выполнять все функции работы платформы с файловой БД. Открыли бы её исходный код и сделали возможность использовать для разных объектов метаданных разные «системы хранения», и обрабатывать, соответственно, разными Web серверами.   

Конечно, всё это дело нужно ещё как то администрировать. Но эти вопросы в общих чертах уже решены. Я решал вот так //infostart.ru/public/661836/ Но сейчас, собственно, есть и «родной» продукт 1С: https://wonderland.v8.1c.ru/blog/1s-tsentr-administrirovaniya-administrirovanie-eto-prosto/ В случае, если всё это расположено в вашей внутренней инфраструктуре, можно, конечно, воспользоваться и Ansible и PowerShell. Никаких трудностей задачи централизованного администрирования не вызывают.

В общем, лучшее, что можно сделать на 1С, всё ещё сильно далеко от того, что происходит с Web приложениями в современном мире. Конечно, как человеку от 1С зависимому, мне достаточно грустно и печально от осознания данного факта. Последние изменения в платформе мы, к сожалению, видим – усиление лицензионной политики, а не повышение открытости… А с закрытой платформой трудно использовать всё то современное, что в мире появляется.

P.S. части тем, затронутых в статье, мы коснёмся на секции HighLoad Infostart Event https://event.infostart.ru/2019/agenda/#section-34266 приходите на секцию, а особенно на круглый стол, который, надеюсть будет в этом году не менее интересным чем в прошлом.

и голосуйте за мои доклады, вернее уже только один доклад https://event.infostart.ru/2019/agenda/#item1067429