Приложения-кандидаты для переноса в cloud
В блоге Tech Republic 10 Things опубликована интересная заметка 10 applications you can move to the cloud (pdf-версия). В ней перечислены 10 приложений-кандидатов для переноса в облако:
- Conferencing software
- CRM
- Web hosting
- Development test labs
- Video hosting
- Email security
- Basic office applications
- Batch processing applications
Участвуя не первый год в обсуждениях на тему “у себя/в аутсоурс” (со времен работы в HP) готов согласиться со всеми пунками. Но вот что вызвало удивление – отсутствие упоминания средств совместной работы (collaboration). будь то средства класса sharepoint для внутреннего потребления, будь то инструменты E2.0 (корпоративный блоггинг, enterprise social network и т.п.) – как мне кажется, вполне естественно его рассматривать в качестве средств того же уровня “утилитарности”, что и e-mail. Так что со свой стороны добавляю collaboration software. Соответственно, и security составляющая предполагает collaboration security. А если совсем по уму, то и email security и collaboration security (например, антивирусная проверка документов, закачиваемых в collaboration-систему) и такие средства как rights management (управление правами), могут рассматриваться в случае облачных сервисов как их расширенная опция (с т.з. прайс-листа), а не как отдельные сервисы.
Еще один класс приложений, который мне представляется логичным выносить во вне (конечо, как и в любом другом случае, посчитав деньги ;) – интеграция с внешними системами (чаще всего партнерскими, например, для сетевых, франшизных или дистрибуторских бизнесов), благо появляются такие средства как Windows Azure AppFabric (опять-таки не потому что я в MS, а имхо пример хороший). Так что еще можно добавить к списку external applications integration.
* Update 01.12.2010: подумалось. что имеет смысл периодически апдейтить по мере оформления мыслей о пропущенных вариантах приложений-кандидатов для cloud.
Собственно, вот несколько дополнений к первоначальному списку, с которыми не просто сталкивался, а на самом-то деле и использую (как минимум часть из них):
- project management
- distance learning
- desktop-mobile device synchronization services
- VOIP call center / help desk / web sales assitant
Ярлыки: Analytics and Reports, Application Platforms, Cloud, SaaS, SOA
Комментарии: 4:
Также вполне можно добавить BugTracking/IssueTracking
Прочитав статью, Update и комментарий хотел бы добавить что практически все приложения можно переносить в облако при условии соблюдения ряда требований, как правило, по безопасности; и естественно посчитав хорошенько перед этим. Все пополняющийся список тому свидетельство. Интересно а можно ли назвать хотя бы одно приложение, которое никогда нельзя перенести в облако?
Иван, я полагаю, что среды разработки и моделирования, все-таки должны быть локальны. Развитые графические редакторы, профессиональные средства верстки, в моем представлении также неидеальны А чем более end-user'овскими являются многопользовательские (именнно в этом срабатывает эффект масштаба облаков) приложения - тем большая вероятность, что их можно перенести в облако.
Сергей, я периодически отслеживаю Ваши статьи и презентации; и очень уважаю Вас как эксперта! К сожалению сам не могу похвастаться такими достижениями, как Вы; поэтому хотел бы заранее извиниться за возможные ляпы в моих суждениях.
Но я бы немного не согласился. С моей точки зрения, и среды моделирования (смотря ещё что под этим понимать?) и разработки уже могут идти по пути облачного представления. Если для моделирования это проблема может быть связана с типичной нехваткой вычислительных ресурсов, которые в облаке могут наращиваться достаточно в очень больших объемах. То для сред разработки это типичный collaboration, когда продукт разрабатывается по всему земному шару; дополнительно можно наверно привести пример расширенного управления безопасностью за интелектуальной собственностью, которая храниться не локально где-то, а в облаке. Примерно такие же соображения можно привести и для графических редакторов, хотя здесь все может быть не так прозрачно в связи с тем что графические редакторы, собственно как и работа с ними все-таки процесс более "интимный". Я конечно понимаю, что те функции что я привел могут реализовываться и в развитой сетевой инфраструктуре на базе сетевого ПО; но это опять дополнительные затраты как единовременные на закупку и настройку, так и операционные на поддержку.
Все требует счета.
Повторно хотел бы извиниться, если сделал какие-либо ляпы :)
Я сам занимаюсь внедрением PLM системы WNC, которая полностью построена на работе через Web браузер и поэтому уже оценил возможность централизованного администрирования и настройки и т.п., когда я практически независим от конечного пользователя.
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница