![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
don_katalanSTANISLAV KUKAREKA
(1 2)
Закончив (временно) исторический экскурс вернемся к сути. То есть к ключевым собственно параметрам. Наверное вы слышали уже классическую формулу “Быстро, хорошо, дешево. Вычеркните что то одно”. Та формула мудра. И с ПНГ примерно то же самое, хотя там все еще намного гуще. И вычеркнуть придется даже не “что то одно” а скорее два из трех. Ну или полтора как минимум. Казалось бы это все полный провал и пропасть пессимизма. Но на самом деле - нет. Вернее иногда и “да”, и даже не редко так бывает, но в общем случае - скорее нет, и свет реально есть в конце тоннеля. Прикол тут в том что даже то “одно из трех” что у вас остается - обычно позволяет вытянуть оставшиеся два параметра, что были уже принесены в жертву. И порой на уровень вообще недостижимый никакими средствами другими. В том и весь смысл, ради того и городили этот огород.
Итак, две части предыдущие с глубоким погружением в археологию вопроса по сути были только об одном, о “столбиках”. О той границе между “карриером” и “пайлоадом”, программой и системой, формою и содержанием. О том как эта граница возникала исторически, зачем и почему. Ибо вопрос тот архиважен. И тут мы от виртуализации (что есть вопрос о той самой границе) можем плавно перейти к собственно облакам в частности. И вообще систем архитектуре, если в общем. Тут упомянутое разделение и собственно “граница” возникла исторически, и предопределила логику процесса. А логика там такова что сам по себе компьютер (сеть, кластер, облако, и даже цельный интернет) есть только средством. Все это ради “программы”, ради того что бы ее запустить и от нее получить какой нибудь полезный результат. Ну или бесполезный, то уже как повезет. Итак, “оно все” - только средство.
Программ тех за полвека (и даже более) было написано много и разных. И в принципе процесс их написания никогда не был слишком легким делом. Программа представляет из себя ценность какую-то, причем немалую. По крайней мере так было задумано. Но если ты сегодня хочешь от программы чуть больше чем ты от нее имел еще вчера - то у тебя по сути есть только два пути. Переписать ее (тем ее свойства изменив) или изменить условия ее выполнения. Вот этот второй путь стал очень популярным в силу ряда причин. И именно “граница” та, тот интерфейс программный (или не программный) определяет то чего реально можно “с другого конца сделать”. То есть как и насколько можно изменить то поведение программы не трогая самой программы...
Итак, если вчера у тебя какая нибудь база данных работала на перфоленте, то завтра ты туда можешь присунуть например диск магнитный. Который в принципе - быстрей в 100500 раз и тебе станет по идее очень сильно легче. Воткнуть еще один сундук в машзале, воткнуть куда то провода, админ какой нибудь пропишет драйвера. И будет счастие. А тот чувак который эту СУБД писал - все так же может в отпуске лежать на пляже на Гавайях, или вообще в могиле. Не проблема. Ибо админ местечковый который кабеля пихает и драйвера прописывает - очень дешевле чем тот гавайский пляжник даже если он живой. И уж подавно - если уже не живой... По сути дела таким образом там был буквально открыт “второй фронт”, ага. Что было очень важным стратегическим достижением. И это все очень давно случилось, еще и писюков никаких небыло тогда и был там повсеместный парад черных холодильников. Но гладко только на бумаге, а в жизни есть еще овраги...
Ибо у любой палки есть два конца, и за все следует платить. И сама логика какой то СУБД что эффективно юзает устройства с доступом последовательным - сильно отличается от логики разумной (разумной логики естественно) СУБД что оперирует устройствами с рандомным блочным доступом. Дорога в рай проходит через иголье ушко, и хрена ты туда заедешь просто нагло на верблюде. И далее тут остро встал вопрос тех самых интерфейсов, которые должны быть уже гибкие достаточно что бы использовать “новые возможности” хоть как то плодотворно, но и при этом быть достаточно простыми что бы их можно было как нибудь стандартизировать и унифицировать. Ну то есть про “границу” там вопрос встал. И вся последующая история виртуализации есть парадокс на эту тему. Ну то есть попытки попросту решить черз колено. Когда просто волевым решением они блин отказались от использования программных интерфейсов (которые блин для того собственно и были придуманы) и пришли к эмуляции прямо железа, якобы богом нам данного. Мол тут вы уже никак не отвертитесь от счастья своего. Решение весьма сомнительное с точки зрения собственно эффективности, но поражающее прямо в пятку своей неизбежностью. Вот так мы понемногу приближаемся к современному состоянию вопроса. Огромнейшую роль тут безусловно сыграли писюки как таковые, и историческое там презрение ко всем правилам тона хорошего и архитектурного строительства. И особенно - гигантская та доля рынка которую те писюки сожрали и то внимание которое им уделялось всякими железа производителями. Короче всем тем “правилам игры” которые так или иначе были навязаны через упомянутую боль, боль, и еще раз боль...
(1 2)
Закончив (временно) исторический экскурс вернемся к сути. То есть к ключевым собственно параметрам. Наверное вы слышали уже классическую формулу “Быстро, хорошо, дешево. Вычеркните что то одно”. Та формула мудра. И с ПНГ примерно то же самое, хотя там все еще намного гуще. И вычеркнуть придется даже не “что то одно” а скорее два из трех. Ну или полтора как минимум. Казалось бы это все полный провал и пропасть пессимизма. Но на самом деле - нет. Вернее иногда и “да”, и даже не редко так бывает, но в общем случае - скорее нет, и свет реально есть в конце тоннеля. Прикол тут в том что даже то “одно из трех” что у вас остается - обычно позволяет вытянуть оставшиеся два параметра, что были уже принесены в жертву. И порой на уровень вообще недостижимый никакими средствами другими. В том и весь смысл, ради того и городили этот огород.
Итак, две части предыдущие с глубоким погружением в археологию вопроса по сути были только об одном, о “столбиках”. О той границе между “карриером” и “пайлоадом”, программой и системой, формою и содержанием. О том как эта граница возникала исторически, зачем и почему. Ибо вопрос тот архиважен. И тут мы от виртуализации (что есть вопрос о той самой границе) можем плавно перейти к собственно облакам в частности. И вообще систем архитектуре, если в общем. Тут упомянутое разделение и собственно “граница” возникла исторически, и предопределила логику процесса. А логика там такова что сам по себе компьютер (сеть, кластер, облако, и даже цельный интернет) есть только средством. Все это ради “программы”, ради того что бы ее запустить и от нее получить какой нибудь полезный результат. Ну или бесполезный, то уже как повезет. Итак, “оно все” - только средство.
Программ тех за полвека (и даже более) было написано много и разных. И в принципе процесс их написания никогда не был слишком легким делом. Программа представляет из себя ценность какую-то, причем немалую. По крайней мере так было задумано. Но если ты сегодня хочешь от программы чуть больше чем ты от нее имел еще вчера - то у тебя по сути есть только два пути. Переписать ее (тем ее свойства изменив) или изменить условия ее выполнения. Вот этот второй путь стал очень популярным в силу ряда причин. И именно “граница” та, тот интерфейс программный (или не программный) определяет то чего реально можно “с другого конца сделать”. То есть как и насколько можно изменить то поведение программы не трогая самой программы...
Итак, если вчера у тебя какая нибудь база данных работала на перфоленте, то завтра ты туда можешь присунуть например диск магнитный. Который в принципе - быстрей в 100500 раз и тебе станет по идее очень сильно легче. Воткнуть еще один сундук в машзале, воткнуть куда то провода, админ какой нибудь пропишет драйвера. И будет счастие. А тот чувак который эту СУБД писал - все так же может в отпуске лежать на пляже на Гавайях, или вообще в могиле. Не проблема. Ибо админ местечковый который кабеля пихает и драйвера прописывает - очень дешевле чем тот гавайский пляжник даже если он живой. И уж подавно - если уже не живой... По сути дела таким образом там был буквально открыт “второй фронт”, ага. Что было очень важным стратегическим достижением. И это все очень давно случилось, еще и писюков никаких небыло тогда и был там повсеместный парад черных холодильников. Но гладко только на бумаге, а в жизни есть еще овраги...
Ибо у любой палки есть два конца, и за все следует платить. И сама логика какой то СУБД что эффективно юзает устройства с доступом последовательным - сильно отличается от логики разумной (разумной логики естественно) СУБД что оперирует устройствами с рандомным блочным доступом. Дорога в рай проходит через иголье ушко, и хрена ты туда заедешь просто нагло на верблюде. И далее тут остро встал вопрос тех самых интерфейсов, которые должны быть уже гибкие достаточно что бы использовать “новые возможности” хоть как то плодотворно, но и при этом быть достаточно простыми что бы их можно было как нибудь стандартизировать и унифицировать. Ну то есть про “границу” там вопрос встал. И вся последующая история виртуализации есть парадокс на эту тему. Ну то есть попытки попросту решить черз колено. Когда просто волевым решением они блин отказались от использования программных интерфейсов (которые блин для того собственно и были придуманы) и пришли к эмуляции прямо железа, якобы богом нам данного. Мол тут вы уже никак не отвертитесь от счастья своего. Решение весьма сомнительное с точки зрения собственно эффективности, но поражающее прямо в пятку своей неизбежностью. Вот так мы понемногу приближаемся к современному состоянию вопроса. Огромнейшую роль тут безусловно сыграли писюки как таковые, и историческое там презрение ко всем правилам тона хорошего и архитектурного строительства. И особенно - гигантская та доля рынка которую те писюки сожрали и то внимание которое им уделялось всякими железа производителями. Короче всем тем “правилам игры” которые так или иначе были навязаны через упомянутую боль, боль, и еще раз боль...
no subject
Date: 2020-07-06 03:38 pm (UTC)