История изменений
Исправление byko3y, (текущая версия) :
Да норм сейчас большинство реализаций s3. Вот что реально там ещё нужно это strict consistency, который амазон допилил в прошлом году. А так 90% фичей работают
Умоляю, не надо про гарантии согласованности, я про них целую статью на хабре писал (а вы не прочитали :( ). Eventual consistency — это проблема, которая есть только у одного амазона, больше ни у кого ее нет. Вот недавние тесты:
https://docs.aws.amazon.com/amazonglacier/latest/dev/api-upload-part.html
Все проблемы S3 амазон создал сам себе на ровном месте. Например, возьмем заливку частями, которыми я нынче занимаюсь:
https://docs.aws.amazon.com/amazonglacier/latest/dev/api-upload-part.html
https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html
Объясни мне, как так могло получиться, что в подобных сервисах одного и того же AWS подобные запросы не имеют ни одного совпадающего параметра? Даже SHA256 названо по разному. А, вру, есть один совпадающий заголовок Content-Length, и название заголовка Host одинаково. Всё, на этом совпадения заканчиваются. Просто как можно НАСТОЛЬКО ПЛОХО делать API?
У меня когда-то были сомнения по поводу того, что это руководители проектов в штатах так изящно выбирают акценты разработки, чтобы сэкономить на разработке, но продать много фич так, будто разработка стоила очень дорого. Но возьми тот же последний амазоновский провал в лице New World — у меня снова и снова возникает мысль, что да, умелое построение акцентов имеет место, но есть также фактор НИКТО НЕ ПОНИМАЕТ ЧТО НУЖНО СДЕЛАТЬ И КАК. Они, может быть, и хотели бы сделать хорошее дорогое решение, но не умеют.
И по итогу успех AWS — это даже не хитрый подход к разработке. Это 10% разработки и 90% маркетинга. Плюс-минус пять процентов. Я теперь даже не уверен, действительно ли они осознавали, что кривое API вендорлочит юзверей, или же им тупо БЫЛО ВСЁ РАВНО ЧТО ПРОДАВАТЬ.
Исходная версия byko3y, :
Да норм сейчас большинство реализаций s3. Вот что реально там ещё нужно это strict consistency, который амазон допилил в прошлом году. А так 90% фичей работают
Умоляю, не надо про гарантии согласованности, я про них целую статью на хабре писал (а вы не прочитали :( ). Eventual consistency — это проблема, которая есть только у одного амазона, больше ни у кого ее нет. Вот недавние тесты:
https://docs.aws.amazon.com/amazonglacier/latest/dev/api-upload-part.html
Все проблемы S3 амазон создал сам себе на ровном месте. Например, возьмем заливку частями, которыми я нынче занимаюсь:
https://docs.aws.amazon.com/amazonglacier/latest/dev/api-upload-part.html
https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html
Объясни мне, как так могло получиться, что в подобных сервисах одного и того же AWS подобные запросы не имеют ни одного совпадающего параметра? Даже SHA256 названо по разному. А, вру, есть один совпадающий заголовок Content-Length, и название заголовка Host одинаково. Всё, на этом совпадения заканчиваются. Просто как можно НАСТОЛЬКО ПЛОХО делать реализацию?
У меня когда-то были сомнения по поводу того, что это руководители проектов в штатах так изящно выбирают акценты разработки, чтобы сэкономить на разработке, но продать много фич так, будто разработка стоила очень дорого. Но возьми тот же последний амазоновский провал в лице New World — у меня снова и снова возникает мысль, что да, умелое построение акцентов имеет место, но есть также фактор НИКТО НЕ ПОНИМАЕТ ЧТО НУЖНО СДЕЛАТЬ И КАК. Они, может быть, и хотели бы сделать хорошее дорогое решение, но не умеют.
И по итогу успех AWS — это даже не хитрый подход к разработке. Это 10% разработки и 90% маркетинга. Плюс-минус пять процентов. Я теперь даже не уверен, действительно ли они осознавали, что кривое API вендорлочит юзверей, или же им тупо БЫЛО ВСЁ РАВНО ЧТО ПРОДАВАТЬ.