Привет Хабр! Меня зовут Ильдар. Хочу поделиться с сообществом своими идеями разработки Облачной ОС.
Начну с рассказа простого кейса, почему я начал задумываться о создании Облачной ОС. В прошлом году я решал бизнес задачи по настройке CRM+телефония+сайт+почта+вебинары+email рассылка. Решение есть, оно настраиваемое и рабочее. Но есть нюансы, которые я заметил в процессе настройки.
Первый нюанс, в том что, я получил рабочую систему, в «мультисервисах» в «мультиокнах». Т.е. чтобы с ней работать, нужно заходить в разные системы по разным url адресам и менять везде настройки. К примеру, чтобы добавить сотрудника, нужно добавить его в CRM, затем в телефонию, затем создать почту, затем добавить интеграцию почты в срм. Очень много действий, по созданию и удалению пользователя. Особенно, когда пользователей много. Легко запутаться, и что-то забыть.
Второй нюанс в том, что клиент (юр лицо) платил этим системам по Visa карте, и нет никакой возможности платить как юр лицо. Вообще мне непонятно, зачем разрабатывать системы для юр лиц и делать только Visa/Mastercard платежи, которые предназначены для физ лиц, а не для юр лиц. А как компании должны отчитываться по бухгалтерии? Я знаю, что некоторые системы работают с юр лицами, но только со своей страны. А если юр лицо из другой страны? Что делать в этом случае? Самое странное, это то, что нужно помнить о том, когда в каких сервисах истекает тот или иной платеж. Если сервис один, то все просто. А если их 10, или 20? А как мне выставить единый счет и просто его оплатить?
В-третьих сбои. Так как система «мультисервисная», то возрастает количество сервисов, возрастает и риск сбоя всей системы. Получалось так. В один день висит CRM на пол дня, в другой день зависает телефония. За месяц сервисы зависают по одному-двум раз каждый, но так как сервисов много, то получается, что вся система виснет в месяц более 5 дней, стабильно раз в неделю, а это убытки, т.к. менеджеры не работают, продажи не идут. Работать при этом, становиться невозможно.
В-четвертых, я хочу делать бэкапы системы. И возникает вопрос, а как их делать, если системы не позволяют это делать? И если они позволят, то где мне этот бэкап потом запустить?
В-пятых, я хочу, чтобы сервисы географически хостились в той стране, где я живу, а лучше в том же городе, для улучшения пинга, да и чтобы им можно было позвонить по городскому телефону или прийти в офис, чтобы решить какой либо вопрос, а не так, что приходится звонить по межгороду в другую страну по диким тарифам.
И самый интересный момент. А как мне эти сервисы запустить на своем сервере? Т.е. арендовать сервер на доверенном хостинге, и там настроить всю систему? А никак, это же SaaS и вендорлок.
Имхо, но мы сейчас живем в период переизбытка систем SaaS сервисов, которые создают свои платформы со своей авторизацией, панелью управления. Для конечного потребителя это неудобно, ведь от всех них, нужно знать пароли, помнить где-что находится, и еще интегрировать их между собой.
Забавно, но недавно мне пришла реклама, о сервисе, который обеспечивает межсервисную интеграцию одного сервиса с другим. И возникает вопрос, у нас было куча сервисов, и появился еще один сервис, который занимается, тем, что должны делать сами сервисы. И зачем он? Как это упрощает работу? Наоборот, это еще больше усложняет работу, потому что увеличивается количество окон, url адресов в которых нужно постоянно заходить и что-то менять и настраивать. А также увеличивается риск сбоя.
Об этих проблемах я и задумался. Хочется одно окно, единый url адрес, по которому можно будет пользоваться системой. Так у меня появилась идея создания Облачной Операционной Системы.
Описание Облачной ОС
Скажу сразу. Я ее создал. Называется она BAYRELL Cloud OS и сейчас находится в альфа версии 0.1. Она OpenSource. Инструкция по установке здесь. Скажу сразу это альфа версия, и многое я в ней еще не сделал. Я планирую выпуск версии 0.2, который будет более проработан. Список изменений, того что будет в версии 0.2 здесь на гитхабе.
Суть Облачной ОС очень проста. Это технология запуска кроссплатформенных облачных IT сервисов и облачного ПО в единой системе. В едином окне. Под единым окном я понимаю один url адрес, логин и пароль, по которому обращается клиент, чтобы получить доступ ко всей интранет системе с установленным туда софтом. Для клиента это удобно. Одно окно, один логин и пароль. Всё, что нужно для работы там.
Миссия Облачной ОС. Объединить и интегрировать усилия программистов, IT компаний вендоров, облачных хостингов и интеграторов, для синергетического эффекта. Совместными усилиями создать очень хорошую IT систему и сборки к ней, которые будут решать различные задачи в разных нишах.
Операционная система дает одно свойство – она запускает программы, которые под нее написаны, в единой среде. ОС предоставляет ядро, как фундаментальный стандарт, с уже готовой авторизацией, регистрацией, обеспечивает обмен данными между приложениями и службами. ОС задает стандарт разработки ПО, так, чтобы дать софту возможность взаимодействовать друг с другом, а пользователю единый интерфейс взаимодействия с интранет системой.
В отличие от привычных традиционных операционных систем, данная ОС облачная. Т.е. устанавливается не на локальные компьютеры, а устанавливается в облако или на сервера и делает из них облачный кластер. И соответственно если, разные IT компании, будут разрабатывать софт, под эту систему, то получится использовать и интегрировать их наработки в единой системе, в одном окне. А не так, как сейчас, с SaaS решениями, где нужно заходить в кучу разных систем, чтобы работать с ними.
Вторая важная функция в том, что ОС дает возможность устанавливать программы в один клик. Упрощает процесс настройки софта. Вспомните те простыни мануалов, которые нужно читать, чтобы поднять или настроить сервер, nginx, почту и т.п. А если сделать возможность установить софт в одну кнопку? Ведь это же здорово, и самое главное возможно. Нажал кнопку, софт установился. В интерфейсе можно мышкой поменять настройки. Это значительно упрощает управление сервером.
Я знаю многие скажут консоль наше все. Я тоже люблю консоль. Но наступили те времена, когда в голове нужно держать кучу команд и параметров к ним. И это проблема. Я открыл мануал к nftables и сразу же закрыл. Потому что теперь нужно учить еще и те команды. Мало того что iptables сложный, так они еще сложнее сделали. Уже недостаточно знать команды man, ls, mkdir и т.п. Сейчас нужно управлять Docker, кубернетос кластерами и прочими системами, network manager для сети и т.п. Количество команд, которые нужно помнить возрастает с каждым годом, и проще не становиться. А зачем тогда IT системы, если они усложняют жизнь, а не упрощают их. Ведь хочется иметь систему с простым логичным интерфейсом, или, например, админить систему с телефона.
Роль контейнеров
Сделать, то что я говорю можно. Docker контейнеры являются важным элементом системы. Все программное обеспечение распространяется в Docker контейнерах. Docker обеспечивает как раз простую установку софта. Теперь нужен лишь интерфейс, для того, чтобы это все удобно настраивать.
Я сделал веб интерфейс для управление кластером. Самим кластером управляет Docker Swarm, а веб интерфейс управляет Docker swarm'ом. Пока интерфейс простенький и к сожалению, еще не удалось избежать ввода консольных команд, но думаю в версии 0.2, я сделаю более удобным веб интерфейс инсталлятора и настройку кластера.
В версии 0.1 я более сосредоточился, чтобы написать первый софт и создать экосистему для его запуска. Я решил следующие задачи:
- Модель слоев и виртуальных пространств.
- Запуск софта в кластере.
- HTTP маршрутизация через nginx. Обновление маршрутизации через интерфейс.
- Авторизация пользователей.
- Разработал софт, планировщик задач, для примера.
Модель Облачной ОС
В Облачной ОС есть два важных понятия. Это виртуальные пространства и слои данных.
Дело в том, что иногда требуется установить несколько CRM систем в один кластер, или две разных версии одной CRM, которые будут отдельно друг от друга работать, или хостить в кластере несколько компаний. И вместо того, чтобы запускать на каждую компанию отдельный инстанс CRM, есть возможность запуска одного инстанса, который будет уметь обслуживать сразу несколько компаний. Это нужно для экономии производительности.
Знаете почему Shared хостинги дешевле чем VPS? Потому что они делят одни ресурсы одного сервера между собой, а VPS по сути запускает отдельную виртуальную машину. Вот и получается, что на одном сервере VPS можно запустить 10-20 инстансов, а хостинг может обслуживать тысячи клиентов на одном сервере.
Но данные клиентов нужно как-то разделить между собой. Это решается с помощью концепции виртуальных пространств и слоев данных.
Проще показать на схеме. Каждая служба — это Docker service. В конфиге службы указываются параметры подключения к базе данных. База данных делится на слои данных.
В системе можно создавать несколько виртуальных пространств. Например, для каждого клиента — отдельное виртуальное пространство, или, один прод, другой тестовый, как указано в схеме. На проде реальная база. В тестовом пространстве тестирование новых процессов компании. В проде запущено два рабочих слоя CRM (например, нужно сделать две базы). А также запущена новая версия этой CRM на одной из текущих слоёв, чтобы протестировать, как будет работать новая версия CRM, на реальных данных, в рабочей среде, но при этом не обновлять текущую версию, с которой сейчас работают пользователи.
У каждого слоя есть идентификатор UID и URL адрес, по которому он доступен. UID имеет вид «cloud_os.test:layer_0». «cloud_os.test» — это название пространства, «layer_0» — номер слоя. UID может быть одинаковым у слоев для разных служб. Одинаковый UID нужен, чтобы упростить настройку обмена данными между службами. По умолчанию, служба просто будет отправлять запрос в другую службу с текущим layer_uid.
Каждое виртуальное пространство будет обладать своим ключом подписи запросов. Служба отправляет запрос в системную шину другой службе и подписывает его ключом space_id. Отправляя запрос, она указывает свой space_id, службу адресат и layer_uid данных, которая она хочет запросить.
Когда запрос приходит в службу получателя по системной шине, эта служба смотрит есть ли такой ключ подписи у пары layer_uid, space_id, которые были указаны в запросе. Если находит, то проверяет подпись. Если подпись неверна, то отклоняет запрос. Это нужно, чтобы сделать изоляцию виртуальных пространств между собой. Но если нужно сделать обмен данными между несколькими пространствами, то в них нужно добавить слои служб с одинаковыми UID.
Технология обмена данными между службами, будет разработана в версии 0.2. Я сделал наброски концепции шины обмена данными. Это больше черновик и после того как я сделаю релиз Облачной ОС версии 0.2, поправлю текст концепции. Но общую суть в тексте я описал. Сейчас реализована только внешняя шина данных.
Бизнес модель
Как это все использовать, и как зарабатывать деньги?
Имхо, я думаю одним из причин, почему линукс не популярен среди десктоп, является то, что он бесплатный. Забавно, но это так. Сейчас объясню. Причина в наличии качественного софта.
Серверный софт под линукс успешен, потому что другие компании используют этот софт в своих бизнес задачах, для того чтобы зарабатывать деньги. И от того как работает этот серверный софт и сколько он стоит, зависит то, сколько эти компании заработают.
Покупка лицензий на серверный софт это издержки для компаний. Поэтому компании могут инвестировать в Opensource разработки, чтобы решить свои бизнес задачи и снизить свои издержки. Они заинтересованы в этом. Потому что это влияет на их прибыль.
А что даст инвестирование в десктоп? За операционную систему платит конечный потребитель, а не компания разработчик софта. Разработчики софта, в основном, пишут свой софт под ту ОС, которая популярна на данный момент, потому что они смогут больше заработать, на количестве установок. А инвестирование в линукс не даст прибыли разработчикам софта для десктопа.
Линукс бесплатный. У него нет продаж, значит инвестировать разработку с продаж не получится. В итоге это влияет на скорость написания качественного софта. Процесс идет медленно, потому чтобы сделать качественный софт, нужны специалисты, а им нужно платить зарплату. А Windows инвестирует в разработку с продаж, это дает возможность больше нанять специалистов и быстрее разрабатывать софт, сделать его удобнее для пользователя. А чем удобнее для пользователя, тем больше будут пользоваться, тем еще больше софта будет написано под эту систему. Вот поэтому Windows популярнее линукса на десктоп.
Хотя сейчас ситуация потихоньку меняется. С юзабилити и качественным софтом в линуксе дела обстоят гораздо лучше, чем было раньше. Я с 2016 года пользуюсь линуксом на десктопе. Но есть все же моменты, которые хочется исправить и доработать. Например, CorelDraw не поставить на линукс. И мне, чтобы использовать банк клиент, нужно использовать Windows систему, потому что на линуксе банк клиент не работает.
Чтобы сделать линукс популярным, нужен качественный софт под него, которым будут пользоваться люди. А также система доставки и магазин приложений. Я благодарен компании Steam, которая сделала для линукса клиент, и игры теперь работают на линуксе. Те игры, которые не поддерживают линукс, запускаются благодаря технологии Valve Proton.
Я считаю, линукс хорошей системой для IT программистов, которые делают интернет сервисы. Потому что софт, которые программисты пишут, будет работать под линуксом на сервере. И гораздо лучше писать софт в родной системе, нежели использовать сборки типо Denwer или cygwin. Именно по этой причине я поставил Ubuntu. Потому что нужно было работать с докер, lxc, iptables, php, python, nodejs, npm и прочими штуками. А запускать постоянно виртуальную машину с линкусом в Windows, чтобы пользоваться этими инструментами, как то это неправильно. А cygwin и msys2 давно перестали справляться с теми задачами, которые мне нужны.
Я сам подумываю о сборке десктоп версии на базе openbox с контейнерами. Контейнеры, либо flatpak, либо что-то новое. чтобы упростить процесс доставки приложений. Также хорошо разработать для линукса маркет приложений, чтобы дать разработчикам возможность заработка. Вот тогда линукс начнет заходить в массы. Может быть я это сделаю в рамках разработки облачной ОС. Пока сложно сказать.
Этим я хочу сказать то, что ключом к развитию технологий является удобство в использовании технологии с точки зрения клиента, за это он готов платить деньги, за комфорт, за то что его задачи решаются. А от того, сколько денег будет приходить в технологию, тем активнее и быстрее она будет развиваться. Например, чтобы разработать десктоп версию линукса у меня не хватает ресурсов, и пока этот проект только в планах.
Для разработки Облачной ОС тоже нужны ресурсы. А чтобы ресурсы получить, нужно понимать как зарабатывать. А варианты заработка есть. Я представляю бизнес модель.
Есть два типа компаний: вендоры софта и облачные интеграторы. Одна и та же компания может являться и тем и тем. Вендоры софта — разрабатывают облачный софт. Облачные интеграторы берут разработанный вендорами софт и формируют сборку, которая лучше будет решать задачи клиента, в определенной нише. Для каждой ниши своя сборка. Они создают продукт для конечного потребителя из готовых решений, разработанными разными вендорами.
Клиент же сам может решить: приобрести сборку у облачных интеграторов, либо напрямую купить решения у вендора и тем самым собрать свою сборку. Но скорее всего, выгоднее будет брать решения у облачных интеграторов, потому что оно будет комплексным, разработанное и адаптированное под нишу клиента. А времени самостоятельно собирать сборку у клиента может не быть. Ему нужно решения для бизнеса, для его ниши, как можно быстрее и удобнее.
Облачных интеграторов будет много, но так как каждый из них работает в своей нише, количество интеграторов никак не влияет друг на друга и не создает конкуренцию между ними. Наоборот, большое количество интеграторов создает качественные сборки для большего количества ниш.
Бизнес выгода облачных интеграторов в том, что они не занимаются разработкой софта. Они берут лицензии на софт у вендоров по оптовым ценам и делают сборку. Каждая продажа конечной сборки окупает затраты на покупку лицензии. Для облачных интеграторов не нужно нести затраты на разработку своего софта, когда есть готовый. По скромным оценкам, чтобы разработать простой сервис, нужно для начала 50 000$. А если для сборки нужно 10 таких сервисов? Выходит приличная сумма. Гораздо логичнее найти компании, которые будут заниматься разработкой софта и купить у них лицензии или взять в аренду, что еще дешевле.
Интерес же вендоров, продать как можно больше количество лицензий. Они заинтересованы в том, чтобы работать как можно с большим количеством облачных интеграторов. Больше облачных интеграторов — больше продаж.
Получается будет две цены у вендоров, одна оптовая для облачных интеграторов, другая розничная для конечного потребителя, если продажи идут напрямую клиенту. Возможен также вариант продажи лицензий через магазин приложений, если такой будет.
Самый интересный здесь нюанс в том, что с ростом количества продаж у вендора, снижается себестоимость этого софта. Это очень интересный феномен. Это отличается, например, от реального производства товаров. По идее IT продукт это не физический товар, и не услуга. Это что-то другое. IT софт не производиться на станках и для выпуска каждого нового экземпляра продукта не нужны затраты.
Поясню на примере. Чтобы произвести 100 экземпляров IT продукта, нужно затратить 0. Чтобы произвести 10 000 экземпляров IT продукта, тоже нужно затратить 0. В этом весь феномен. Хотя, скорее всего, там есть какие-то затраты, в виде стоимости интернета, электричества или объема трафика, которое затрачивается, чтобы скачать файл. Но они настолько малы. И я даже не знаю как это посчитать, и нужно ли вообще это считать. А вот если вы записываете свой софт на CD диск, то да затраты на производство будут. Но кто в 2020м записывает что-то на CD диск, для того чтобы распространить софт, когда есть гитхаб и докерхаб?
Затраты есть другие. Они идут, чтобы продать товар: реклама, оплата менеджерам по продажам. Или же, чтобы разработать новую версию продукта. Но они не относятся именно к производству экземпляра IT продукта.
В итоге, если обеспечить максимальные продажи софта вендоров, то их себестоимость IT продукта будет низкой, и продавать лицензии можно по низкой цене. В итоге, это скажется на конечные цены для потребителей. И, к примеру, CRM будет стоить не стопятьсот, а в десятки раз дешевле.
Для клиента, конечного потребителя, преимущества будут следующие:
- Получает систему, которая работает в едином окне.
- Получает возможность устанавливать софт в один клик.
- Доступные цены для клиента.
- Может создавать бэкапы и холодные резервные копии системы.
- Отсутствует вендорлок, клиент может запустить софт на своих серверах.
- За софт клиент будет платить в единое окно. При этом, в каждом регионе для юр лиц будут свои облачные интеграторы, которые будут предоставлять клиентам бухгалтерские документы.
- Также облачный интегратор, обеспечивает внедрение, тех поддержку. И ему можно всегда позвонить, либо их человек подъедет в офис и настроит, что не работает. Это удобно, и иногда очень не хватает, если работать с SaaS решениями.
Рынки
Есть два огромных рынка, где может применяться данная модель. Это рынок интранет систем для бизнес задач, и рынок IoT систем для умного дома. Причина, по которой рынок IoT систем, пока странно развивается, в том, что нет маркета приложений и операционной системы для IoT.
Роль Облачной ОС
Схема красивая. Но возникает вопрос? А как разные вендоры должны разрабатывать софт, таким образом, чтобы он нормально работал друг с другом? И как облачные интеграторы будут собирать сборку? А вот для этого и нужна облачная операционная система. Она задает фундаментальный стандарт, как должен работать софт, чтобы его запустить интегрированно друг с другом.
Текущая ситуация в том, что сейчас все вендоры хотят разработать свой SaaS, и получается, то о чем я говорил в начале, мультисервисная проблема. Мало того, что сервисов становится много и клиентам сложно и неудобно, так сами вендоры, при разработки SaaS решения несут лишние издержки, такие как:
- содержание технической поддержки;
- обслуживание серверов;
- содержание отдела продаж.
Имхо, но это все можно делегировать облачным интеграторам. Вендоры должны сделать облачный софт и адаптировать его под ОС, а облачные интеграторы, создадут из этого софта сборку и будут заниматься продажами, тех поддержкой, внедрением, обслуживанием и даже хостингом. Сейчас они поступают так: делают сборку SaaS решений, обеспечивают продажи и тех поддержку. Но становится две тех поддержки, и по сути облачный интегратор, просто передает запросы от клиента сервису, и ждет пока SaaS сервис ему ответит. А я считаю, что облачный интегратор, сам должен решать вопрос и исправлять проблему, а не ждать у моря погоды, когда ответит ему SaaS.
Касательно IoT. Я слышал есть кондиционеры для дома, и чтобы ими управлять нужно скачать мобильное приложение. А если у меня дома будет много умных устройств, мне для каждого из них нужно будет ставить приложение на телефон? И будет опять та же ситуация, когда куча всяких приложений на телефоне, для управления разными устройствами. А можно как-то это всё объединить в одно приложение?
Я считаю, что умный дом должен построен по следующей схеме. Есть IoT ОС, которая ставится на распу. Это распа и все устройства умного дома подключаются к одной сети по wi-fi или по bluetooth. А приложения для управления устройствами умного домом ставятся в IoT ОС, например, скачиваются с маркета приложений, с сайта производителя устройства или с докер хаба. Мобильное приложение оно одно, от управления этой ОС. Зайдя в мобильное приложение, открывается доступ ко всему софту и всем устройствам подключенных к умному дому. И сама ОС, управляет умными домом по тем алгоритмам, которые заложены в приложении.
Подытожем и поговорим, немного, об играх
Почему я так уверен в успехе? Все очень просто. Есть довольно интересный опыт в сфере игровой индустрии.
Во первых есть Steam, который является интернет магазином игр. Самое классное, что есть в стиме, это возможность купить и скачать игру в несколько кликов, возможность запуска игр на линуксе и воркшоп, где сообщество публикует плагины к играм. Steam workshop это очень крутое решение. Совместными усилиями разные разработчики улучшают игры.
Во вторых стоит отметить две игры Dwarf Fortress и RimWorld.
Dwarf Fortress — это игра, пример вечной разработки, когда разработчики хотят своими силами разработать целиком всю игру. В итоге игра находиться в альфе и долго разрабатывается (с 2002 года, а уже 2020). 18 лет разработки и нет релиза, это никуда не годится.
RimWorld это игра вдохновленная идеями Dwarf Fortress. Там не стояла задача разработать все на свете, и ванильная версия игры довольно скромная. Но что очень сильно меня удивило, это то, что сообщество создало очень большое количество модов, которые доводят игру до логического уровня, как должно работать на самом деле. Самый интересный модпак, это сборка HardCore SK. Они собрали моды, и сделали между ними баланс. Это позволило создать совершенно другую игру, которая отличается от ванильной, и я думаю, такой как раз таки и должен быть настоящий RimWorld. Ребята просто молодцы! И это работает со стим версией.
Именно тот факт, что разработчики RimWorld позволили создавать плагины для их игры, получился шедевр в виде сборки HardCore SK.
По сути, те кто создал сборку HSK сделали интеграцию игры и готовых модов, то что я и говорил про облачных интеграторов. Они даже не разрабатывали все эти моды. Облачные интеграторы также делают интеграции, но делают это для IT систем, бизнеса и IoT рынка.
Из этого я сделал очень важный вывод. Очень сложно самому, одной компании разработать мега супер пупер крутой вундер сервис, в котором будет всё, и все клиенты будут использовать только его. Если это и возможно, то это будет очень долго, дорого и в далеком будущем. Логичнее построить инфраструктуру, где другие люди и компании смогут не только разработать большое количество разного софта, под разнообразные задачи, но так же и зарабатывать на этом. И причем, это будет на порядки быстрее. Единственное что нужно для этого, это операционная система (ядро), которая будет задавать фундаментальный стандарт, как софт должен работать друг с другом, и решать принципиальные важные вопросы по авторизации, безопасности, обмене данными между сервисами и т.п.
Я сейчас собираю команду. Если есть желание присоединиться или инвестировать в проект, то пишите в личку.
Также буду признательным, если вы подпишетесь на сообщество вк, фб, инстаграм, или посетите мой сайт.
Публикую инструкцию по установке облачной ОС версии 0.1 на Raspberry Pi и ссылку на пост, о том, как я разработал язык программирования. Кстати сама ОС написана на нем :).
Язык программирования сейчас представляет собой единую фуллстек технологию для разработки сайтов и облачных IT систем. Его преимущество в том, что он транслируется сразу в js и php. И он функциональный. В нем из коробки работают неизменяемые структуры данных. При этом можно писать в функциональном стиле или по старинке в ООП. Есть server side render для бэкенд и client render для фронтенд. Но самое главное преимущество, в том, что это единая технология, на котором можно написать фронтенд и бэкенд. И не нужно заводить зоопарк на nodejs. Я вообще хочу отказаться от nodejs в пользу python или llvm + webassembly с компиляцией. Т.е программа пишется на одном языке и компилируется через llvm для бэкенд, и через webassembly для фронтенд. Но это будущее :).
Буду признателен, если вы поставите звездочки на проекты:
Также я думаю открыть школу по программированию. Если кто хочет поднять свои скилы в IT, тоже пишите в личку.
numitus2
Мне кажется вас нужна не "Облачная ОС". А хорошо написанные программы которые будут интегрироваться друг с другом
vistoyn Автор
И как они должны быть интегрированы? По какому стандарту? Как сделать единую авторизацию и чтобы они под одним доменом работали? Как запустить их в кластере на своем сервере?
le1ic
www.gartner.com/reviews/market/enterprise-integration-platform-as-a-service
Stas911
Дык SSO сто лет в обед — в чем проблема-то?
bank_admin
.