В том, что SaaS и Cloud Computing займут заметную долю рынка, кто-то сомневается, кто-то — нет. SaaS выгоден в первую очередь софтостроителям, а Cloud Computing — хостерам нового поколения. А в обществе потребления рулят всё таки производители а не потребители. Или нет…
В последнее время появляются статьи и хвалебного и пугательного толка. О том сколько счастья прольётся на нас при переходе на эти технологии нам расскажут маркетологи. Чем они изначально опасны написал сам Столлман. Менее оторванные от реальных потребностей люди пишут о потенциальных проблемах. Практичные пользователи пишут о своих опытах с разными облаками, плюсах и минусах.
Я хочу попытаться поразмышлять проблемах и предложить черновой вариант решения, который уж точно подошёл бы мне.
Дальше я как и несколько хабра-авторов до меня буду просто писать “облако” вместо SaaS и/или Cloud Computing. Неспециалистам всё равно, а специалисты, и без того, посмеются над всей статьёй.
Так же для упрощения, разделю людей на противников и защитников облаков и несколько гиперболизирую их.
Итак, что вызывает чувство неуверенности и дискомфорта у потенциального пользователя облаков — “фирмы”, когда он задумывается о задействовании “SaaS”, “облачного хостера” или полного погружения в “облако”.
Противники облаков пугаются передачи своих баз данных посторонним компаниям. Их де там уведут. Защитники убеждают, что от этого должно защитить SLA, да и большинство утечек приватной информации по статистике произошло благодаря как раз штатным сотрудникам.
В общем случае не правы обе стороны. Всё зависит от деталей. Если на фирме сеть и КИС администрируют “студенты” “за еду”, то переезд к облачному хостеру, где соединение шифровано, блюдётся SLA и работают только профи, значительно укрепит информационную безопасность. Если же наоборот у вас настоящий сисадмин и/или квалифицированный разработчик, а облако сомнительно, или “в результате ошибки программистов” собирает на сторону приватную информацию, есть повод остеречься.
Руководство фирмы боится, что если произойдёт обрушение системы — не будет ответственного за восстановление работы. Да и админы фирм, когда лежали гуглодоки явно были не в своей тарелке от абсолютной беспомощности. Защитники облаков упирают на исключительную редкость таких обрушений. И заодно указывают на способность нерадивых админов точно так-же на несколько часов уронить систему. А памятное падение яндекса убеждает что и профи могут накосячить. В общем по данному пункту честный счёт 1:1. Но с точки зрения персонала фирмы — приятнее пинать конкретного человек а не далёкое облако. Кстати во время набора этой статьи произошла безболезненная ошибка
КИС которая создавалась ещё на Clipper, Fox Pro, MS Access 2.0, или 1С, используемая не только для сведения баланса приводят к неполному и/или переходу в облака. В общем-то без решения данной проблемы ценность облаков вообще не видна. А вот SaaS от этого не только не страдает, но и, при гибком подходе, авторов наоборот может выиграть у аналогичных традиционных приложений. Проблема унаследованных систем обычно в том, что раз всё работает, руководство просто не желает платить за обновление технологий.
Как и в офлайновой жизни стандарты API являются мощным оружием конкурентной борьбы. Ни о какой универсальности или кросс-платформенности речи быть не может. Ну разве только о кросс-платформенности клиентской, отображаемой в браузере части. Вот разве только приводимая как классика GMail поддерживает, кроме web интерфейса, ещё и почтовые стандарты POP3 и IMAP.
Противники облаков не очень сильно выпячивают тотальную зависимость облаков от интернет соединения, поскольку подавляющее большинство потенциальных потребителей облачных услуг и так абсолютно зависимы от интернета. Хотя хотелось бы иметь возможность поработать в оффлайне, и синхронизироваться при восстановлении связи.
Противники сравнивают уход в облако с добровольной сдачей в рабство облачному хостеру. И видимо в связи с отсутствием вменяемых аргументов защитники облаков игнорируют эти опасения. А как быть фирме, которая сделала ставку на одно API или хостера а они грубо говоря или загнулись или стали болезненно невыгодны.
Единственный способ решить сразу все перечисленные проблемы — Open Source. Мне это видится следующим образом.
Существует инсталяционый пакет для Cloud или SaaS не только клиентской части но и серверной. И настройки позволяют локальный сервер сделать резервным, чтобы он мог работать как один единственный, или локальная резервная часть облака.
Пройдёмся по проблемам в обратном порядке.
6. Вендорозависимость больше не проблема: можно перейте к другому облачному хостеру просто установив у него серверную часть. Можно развернуть серверную у самих себя.
5. При отключении интернета офис станет работать с локальным сервером. Конечно он не сможет полностью заменить облако/SaaS и скорее всего будет тормозить, но главное работа не встанет.
4. К открытому софту всегда можно прицепить шлюз в какой-нибудь протокол. Как выдающийся пример — jabber, у которого есть транспорт практически в любую IM сеть: ICQ, Mail.ru, vkontakte, MSN, IRC и прочие.
3. Это спорно, но мне кажется, что перевести унаследованную систему выгоднее сразу на open source базу(но делать её саму открытой не обязательно).
2. Если вы не только поставите себе локальный сервер, но и наймёте админа — получите и стабильность облака и локальное ответственное лицо.
1. Открытость должна как минимум облегчить поиск точек неконтролируемого злоупотребления привилегиями. А как максимум позволит полностью защититься от врагов при условии сквозного шифрования.
0. подели на меня.
В последнее время появляются статьи и хвалебного и пугательного толка. О том сколько счастья прольётся на нас при переходе на эти технологии нам расскажут маркетологи. Чем они изначально опасны написал сам Столлман. Менее оторванные от реальных потребностей люди пишут о потенциальных проблемах. Практичные пользователи пишут о своих опытах с разными облаками, плюсах и минусах.
Я хочу попытаться поразмышлять проблемах и предложить черновой вариант решения, который уж точно подошёл бы мне.
Дальше я как и несколько хабра-авторов до меня буду просто писать “облако” вместо SaaS и/или Cloud Computing. Неспециалистам всё равно, а специалисты, и без того, посмеются над всей статьёй.
Так же для упрощения, разделю людей на противников и защитников облаков и несколько гиперболизирую их.
Итак, что вызывает чувство неуверенности и дискомфорта у потенциального пользователя облаков — “фирмы”, когда он задумывается о задействовании “SaaS”, “облачного хостера” или полного погружения в “облако”.
1. Приватность
Противники облаков пугаются передачи своих баз данных посторонним компаниям. Их де там уведут. Защитники убеждают, что от этого должно защитить SLA, да и большинство утечек приватной информации по статистике произошло благодаря как раз штатным сотрудникам.
В общем случае не правы обе стороны. Всё зависит от деталей. Если на фирме сеть и КИС администрируют “студенты” “за еду”, то переезд к облачному хостеру, где соединение шифровано, блюдётся SLA и работают только профи, значительно укрепит информационную безопасность. Если же наоборот у вас настоящий сисадмин и/или квалифицированный разработчик, а облако сомнительно, или “в результате ошибки программистов” собирает на сторону приватную информацию, есть повод остеречься.
2. Поддержка 24*7
Руководство фирмы боится, что если произойдёт обрушение системы — не будет ответственного за восстановление работы. Да и админы фирм, когда лежали гуглодоки явно были не в своей тарелке от абсолютной беспомощности. Защитники облаков упирают на исключительную редкость таких обрушений. И заодно указывают на способность нерадивых админов точно так-же на несколько часов уронить систему. А памятное падение яндекса убеждает что и профи могут накосячить. В общем по данному пункту честный счёт 1:1. Но с точки зрения персонала фирмы — приятнее пинать конкретного человек а не далёкое облако. Кстати во время набора этой статьи произошла безболезненная ошибка
“Google Docs has encountered a server error or bug. We are looking into the problem now.
Please try one of these interim solutions:
* Reload this page.
* Download the document by right-clicking it in the main document list and selecting "Export."“3. Унаследованные системы
КИС которая создавалась ещё на Clipper, Fox Pro, MS Access 2.0, или 1С, используемая не только для сведения баланса приводят к неполному и/или переходу в облака. В общем-то без решения данной проблемы ценность облаков вообще не видна. А вот SaaS от этого не только не страдает, но и, при гибком подходе, авторов наоборот может выиграть у аналогичных традиционных приложений. Проблема унаследованных систем обычно в том, что раз всё работает, руководство просто не желает платить за обновление технологий.
4. Стандарты API
Как и в офлайновой жизни стандарты API являются мощным оружием конкурентной борьбы. Ни о какой универсальности или кросс-платформенности речи быть не может. Ну разве только о кросс-платформенности клиентской, отображаемой в браузере части. Вот разве только приводимая как классика GMail поддерживает, кроме web интерфейса, ещё и почтовые стандарты POP3 и IMAP.
5. Интернет зависимость
Противники облаков не очень сильно выпячивают тотальную зависимость облаков от интернет соединения, поскольку подавляющее большинство потенциальных потребителей облачных услуг и так абсолютно зависимы от интернета. Хотя хотелось бы иметь возможность поработать в оффлайне, и синхронизироваться при восстановлении связи.
6. Вендорозависимость
Противники сравнивают уход в облако с добровольной сдачей в рабство облачному хостеру. И видимо в связи с отсутствием вменяемых аргументов защитники облаков игнорируют эти опасения. А как быть фирме, которая сделала ставку на одно API или хостера а они грубо говоря или загнулись или стали болезненно невыгодны.
Решение всех моих проблем с SaaS и Cloud
Единственный способ решить сразу все перечисленные проблемы — Open Source. Мне это видится следующим образом.
Существует инсталяционый пакет для Cloud или SaaS не только клиентской части но и серверной. И настройки позволяют локальный сервер сделать резервным, чтобы он мог работать как один единственный, или локальная резервная часть облака.
Пройдёмся по проблемам в обратном порядке.
6. Вендорозависимость больше не проблема: можно перейте к другому облачному хостеру просто установив у него серверную часть. Можно развернуть серверную у самих себя.
5. При отключении интернета офис станет работать с локальным сервером. Конечно он не сможет полностью заменить облако/SaaS и скорее всего будет тормозить, но главное работа не встанет.
4. К открытому софту всегда можно прицепить шлюз в какой-нибудь протокол. Как выдающийся пример — jabber, у которого есть транспорт практически в любую IM сеть: ICQ, Mail.ru, vkontakte, MSN, IRC и прочие.
3. Это спорно, но мне кажется, что перевести унаследованную систему выгоднее сразу на open source базу(но делать её саму открытой не обязательно).
2. Если вы не только поставите себе локальный сервер, но и наймёте админа — получите и стабильность облака и локальное ответственное лицо.
1. Открытость должна как минимум облегчить поиск точек неконтролируемого злоупотребления привилегиями. А как максимум позволит полностью защититься от врагов при условии сквозного шифрования.
0. подели на меня.
