Опубликована стратегия облачных вычислений правительства США Опции

OldMan47

Восточная мудрость гласит: "Сколько ни повторяй халва, халва ..., во рту сладко не станет"
Облачные теоретики бесконечно далеки от прагматичного бизнес-народа. Их мотив прозрачен до неприличия. А Кундра, тем не менее,

облачные теоретики немного более адекватны и технически подкованы (как выясняется) чем облачные паникёры-теоретики.

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

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

Ну, а ценность для "маленького бизнеса" - это тоже вопрос. Ему ЭТО действительно нужно? Быть может без понтов он обойдется записной книжечкой и калькулятором? В крайнем случае ноутбука хватит за-глаза. Приходится вертеться и много двигаться, чтобы выжить. С буком намного удобнее.

Есть у меня друг, сис. админ.... Были у него пробелмы с бюджетом под ИТ - оборудование было нужно и под АД, и под то, и под сё... а не давали денег, точнее на то, что давали нужного кол-ва приличного железа не купишь - вот тут-то ему виртуализация очень пригодилась.

OldMan47

Восточная мудрость гласит: "Сколько ни повторяй халва, халва ..., во рту сладко не станет"
Облачные теоретики бесконечно далеки от прагматичного бизнес-народа. Их мотив прозрачен до неприличия. А Кундра, тем не менее,

облачные теоретики немного более адекватны и технически подкованы (как выясняется) чем облачные паникёры-теоретики.

Сударь!
Так речь идет не технике забивания шурупов, а о приемлемости данной фичи серьёзному бизнесу с ГАРАНТИЕЙ компенсации потенциального ущерба. Оговорки типа "AS IS" и отнекивание от ответственности за ущерб от использования поделок - это детский лепет в стиле мелкомягких.
Что M$, что SAP на претензии к обломам и глюкам отвечают одинаково: "Вы не умеете пользоваться нашей самой лучшей в мире системой". И это в режиме tête à tête. А с кого спрашивать в балагане, именуемом "Интернет"?
Вопрос в целом совсем не технический, а сугубо правовой. Кто из облачных теоретиков и чем поручится за гарантии ненанесения ущерба?
Тезис о "технической подкованности облачных теоретиков" сродни совковому тезису "пассажиры для заполнения поездов". Нужна бизнес-подкованность и юридическая подкованность для гарантий бизнесу. И в целом Ваши облачные песнопения целесообразнее адресовать самому Кундре, чтобы он мог спать спокойно. :D

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

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

Для простоты рассмотрим обычное корпоративно-серверное решение: операционка + пачка прикладного софта. У нас это была солярка + пачка саповских компонент. В всем этом букете софта, все блоки которого ДОЛЖНЫ ВЗАИМОДЕЙСТВОВАТЬ, установлены жесткие требования по согласованию ВЕРСИЙ. Поэтому при апгрейде любого из них было небходимо тщательно проанализировать потребности в апгрейдах связанных компонент (и солярки тоже). Кроме этого, поскольку саповские модули это не просто инсталляция, но и частные бизнес-настройки, необходимо тестирование работоспособности настроек после наката патчей по ВСЕМ проапгрейденным компонентам. Бывали прецеденты, когда требования от бизнеса проапгрейдить некоторый блок давали нежелательные побочные эффекты в других компонентах. Напомню, что в этой заварушке завязаны и соляркины патчи. В результате иногда приходилось делать откаты патчей и тормозить апгрейд.
Таким образом, балансировка апгрейдов без прямого управления со стороны хозяина системы в принципе нонсенс.
Если теперь к этой простейшей системе добавим лишних "игроков" в виде облачных и прочих интернет-услуг и некоторого количества компаний, пользующихся ими, то система вообще становится неуправляемой из-за коллизий требований к версионности со стороны каждого из "игроков".

Ну, а ценность для "маленького бизнеса" - это тоже вопрос. Ему ЭТО действительно нужно? Быть может без понтов он обойдется записной книжечкой и калькулятором? В крайнем случае ноутбука хватит за-глаза. Приходится вертеться и много двигаться, чтобы выжить. С буком намного удобнее.

Есть у меня друг, сис. админ.... Были у него пробелмы с бюджетом под ИТ - оборудование было нужно и под АД, и под то, и под сё... а не давали денег, точнее на то, что давали нужного кол-ва приличного железа не купишь - вот тут-то ему виртуализация очень пригодилась.

Сударь! Про сис.админовские проблемы такого рода можно долго плакать друг другу в жилетку. У меня тоже они были всегда. :( Полезным выходом был, тем не менее, только вариант, когда удавалось убедить шефа в необходимости создания полигона под конкретную юзеровскую задачу.

OldMan47

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

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

OldMan47

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

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

Фиксируем откат от сервиса «Программное обеспечение как услуга».
Рассматриваем сервис «Платформа как услуга».
Тройка первых вопросов:
1. Управление бэкапами. Своё по требованиям бизнес-логики или дяди Васи по технологии "from thumb"?
2. Пропускная способность каналов и их гарантированность работы. Для работы с OLAP крайне критичны обе позиции, для OLTP - особенно вторая, иначе бизнес встанет.
3. Синхронизация данных в гетерогенной ИТ-системе.
Это, по-Вашему, "притянутые за уши потенциальные проблемы"? Попробуйте доказать это топ-менеджерам компании, которые недосчитаются прибыли.

OldMan47

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

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

Фиксируем откат от сервиса «Программное обеспечение как услуга».
Рассматриваем сервис «Платформа как услуга».
Тройка первых вопросов:
1. Управление бэкапами. Своё по требованиям бизнес-логики или дяди Васи по технологии "from thumb"?
2. Пропускная способность каналов и их гарантированность работы. Для работы с OLAP крайне критичны обе позиции, для OLTP - особенно вторая, иначе бизнес встанет.
3. Синхронизация данных в гетерогенной ИТ-системе.
Это, по-Вашему, "притянутые за уши потенциальные проблемы"?

1. как хочешь, так и будет, только плати.
2. проблемы каналов не являются специфическими для облычных вычислений, нет смысла их сюда приплетать.
3. как захочешь, так и будет, только плати.

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

1. расскажи про свой опыт, а то выглядит как предположения.
2. часто ты про технологические ньюансы рассказываешь топ-менеджерам?
3. если обсуждаешь это с топ-менеджерами, накидай на вскидку анализ кост\бенефит, карту рисков. какими данными оперируешь на встречах? конец света не рассматриваешь?

OldMan47

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

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

Фиксируем откат от сервиса «Программное обеспечение как услуга».
Рассматриваем сервис «Платформа как услуга».
Тройка первых вопросов:
1. Управление бэкапами. Своё по требованиям бизнес-логики или дяди Васи по технологии "from thumb"?
2. Пропускная способность каналов и их гарантированность работы. Для работы с OLAP крайне критичны обе позиции, для OLTP - особенно вторая, иначе бизнес встанет.
3. Синхронизация данных в гетерогенной ИТ-системе.
Это, по-Вашему, "притянутые за уши потенциальные проблемы"?

1. как хочешь, так и будет, только плати.

Так деньги счет любят, и гарантии эффективности. Скупой платит дважды, а тупой постоянно. :D

2. проблемы каналов не являются специфическими для облычных вычислений, нет смысла их сюда приплетать.

Если Ваши "облычные вычисления" - вещь в себе, мухи ("облычные вычисления") отдельно и котлеты (бизнес-приложения) отдельно, то вопросов нет, успехов Вам на ниве ИТ-самообслуживания.

3. как захочешь, так и будет, только плати.

:+: Плати, плати, плати, ... Вот это и есть истинная подоплека "облычных вычислений", а не польза для юзеров. Очень напоминает сценку у гадалки.

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

1. расскажи про свой опыт, а то выглядит как предположения.

У Вас есть коммерческие предложения? Или просто ля-ля-ля?

2. часто ты про технологические ньюансы рассказываешь топ-менеджерам?

Разумеется! Когда надо объяснить суть предлагаемой технологии. У ключевых топов на последних проектах, в которых я участвовал, нормальная соображаловка.

3. если обсуждаешь это с топ-менеджерами, накидай на вскидку анализ кост\бенефит, карту рисков. какими данными оперируешь на встречах? конец света не рассматриваешь?

Спасибо! Понял, Вы не в теме.
Сухой остаток. Сервис «Платформа как услуга» повисает ввиду превращения облаков в воздушные замки.

У нас и средств таких нет. Вообще облачные вычисления нужны. Огромная экономия на коммунальных услугах. Когда дойдем неизвестно. Хомяченко писал о шестом укладе , а мы еще в третьем.

ну амерканцы в своем репертуаре)) наверное на задней передаче постоянно))

это все теория притом США и так страна уже не та в которую стоит стремится!!!