История изменений

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

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

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

Возьмём аналогию из ZeroNet и IPFS.

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

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все функции и иметь возможность делать git push/pull. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

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

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

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

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

Возьмём аналогию из ZeroNet и IPFS.

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

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все функции и иметь возможность делать git push/pull. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

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

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

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

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

Возьмём аналогию из ZeroNet и IPFS.

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

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все возможнности. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

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

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

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

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

Возьмём аналогию из ZeroNet и IPFS.

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

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все возможнности. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

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

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

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

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

Возьмём аналогию из ZeroNet и IPFS.

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

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все возможнности. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

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