Comments 118
UFO just landed and posted this here
Статьи написаны человеком с техническим складом ума весьма сложно переводить.
Дело не в техническом складе ума, а в знании русского языка. Учитывая, что вы умудрились допустить две ошибки в комменте из одного предложения, не вижу ничего удивительного в том, что большие объемы вам не даются.
Ну не ошибки, а опечатки. Учитывая, что русский уже 3 года как не мой основной язык ничего удивительного, что я могу допускать ошибки и опечатки, а так же не замечать их. Такие дела.
> комменте
А Вы, я смотрю знаете русский на отлично!
> комменте
А Вы, я смотрю знаете русский на отлично!
Планомерное отсутствие запятых при причастном обороте — это не опечатка, а ошибка. Что характерно, пунктуационные ошибки у вас есть и в тексте, что только подтверждает мое предположение.
«А Вы, я смотрю знаете русский на отлично!»
Во-первых, я действительно достаточно неплохо владею письменным русским языком. Во-вторых, я не списываю свои ошибки на технический склад ума автора оригинального текста.
«А Вы, я смотрю знаете русский на отлично!»
Во-первых, я действительно достаточно неплохо владею письменным русским языком. Во-вторых, я не списываю свои ошибки на технический склад ума автора оригинального текста.
> Планомерное отсутствие запятых при причастном обороте — это не опечатка, а ошибка. Что характерно, пунктуационные ошибки у вас есть и в тексте, что только подтверждает мое предположение.
Я уже объяснил почему я допускаю такие ошибки.
> Во-первых, я действительно достаточно неплохо владею письменным русским языком. Во-вторых, я не списываю свои ошибки на технический склад ума автора оригинального текста.
Оригинальный текст полон технических терминов, оборотов и прочего. Вы когда либо пробовали перевести подобный текст? Что-то мне подсказывает, что нет. Если бы вы действительно хотели бы помочь — вы бы мне написали в личку, а так вы решили выпендриться и получить плюсиков. Такие дела.
Я уже объяснил почему я допускаю такие ошибки.
> Во-первых, я действительно достаточно неплохо владею письменным русским языком. Во-вторых, я не списываю свои ошибки на технический склад ума автора оригинального текста.
Оригинальный текст полон технических терминов, оборотов и прочего. Вы когда либо пробовали перевести подобный текст? Что-то мне подсказывает, что нет. Если бы вы действительно хотели бы помочь — вы бы мне написали в личку, а так вы решили выпендриться и получить плюсиков. Такие дела.
«Я уже объяснил почему я допускаю такие ошибки.»
Если вы обратите внимание, изначально я отвечал на комментарий «Статьи написаны человеком с техническим складом ума весьма сложно переводить. », и указывал именно на недостаточное знание русского языка. Ваша фраза про «уже 3 года как не мой основной язык» только подтверждает мое изначальное замечание. С чем вы спорите, интересно?
«Оригинальный текст полон технических терминов, оборотов и прочего. Вы когда либо пробовали перевести подобный текст? Что-то мне подсказывает, что нет.»
Неверно подсказывает. Я работал переводчиком в русскоязычном PCWeek. Никаких особых проблем в таком переводе нет.
И я хочу заметить, что во фразе «I get this question a lot, from both people inside and outside of the .Net community» есть ровно один технический термин (.net) и ни одного технического оборота. Однако ваш вариант ее перевода («Я получаю этот вопрос очень часто, как от людей внутри и снаружи .Net сообщества») чудовищен.
Просто сравните: «Мне часто задают этот вопрос, как внутри, так и снаружи .net-сообщества». При этом я отдаю себе отчет, что оборот «внутри… снаружи… сообщества» все еще плох, и его надо бы править.
Если вы обратите внимание, изначально я отвечал на комментарий «Статьи написаны человеком с техническим складом ума весьма сложно переводить. », и указывал именно на недостаточное знание русского языка. Ваша фраза про «уже 3 года как не мой основной язык» только подтверждает мое изначальное замечание. С чем вы спорите, интересно?
«Оригинальный текст полон технических терминов, оборотов и прочего. Вы когда либо пробовали перевести подобный текст? Что-то мне подсказывает, что нет.»
Неверно подсказывает. Я работал переводчиком в русскоязычном PCWeek. Никаких особых проблем в таком переводе нет.
И я хочу заметить, что во фразе «I get this question a lot, from both people inside and outside of the .Net community» есть ровно один технический термин (.net) и ни одного технического оборота. Однако ваш вариант ее перевода («Я получаю этот вопрос очень часто, как от людей внутри и снаружи .Net сообщества») чудовищен.
Просто сравните: «Мне часто задают этот вопрос, как внутри, так и снаружи .net-сообщества». При этом я отдаю себе отчет, что оборот «внутри… снаружи… сообщества» все еще плох, и его надо бы править.
> комменте
> А Вы, я смотрю знаете русский на отлично!
А как правильно было бы? Комент? Каммент? Камент? :)
> А Вы, я смотрю знаете русский на отлично!
А как правильно было бы? Комент? Каммент? Камент? :)
Эта ваша фраза — тоже перевод?
Нет.
Magic Goody
перевод просто удивительный
PROMPT линейка (рулит) есди переводить rules)
я понимаю, что вам не понравилось. Но… Говоря на русском, я имею обычай изъясняться аналогично. Без всякого промта.
Перевод пестрит чудовищными англицизмами, однако мысли в тексте здравые — тот же Спольски ещё в начале двухтысячных давал резкие оценки дотнету как платформе для небольших софтовых организаций.
Я их решил не заменять аналогами, чтобы не искажать слова автора. Если есть пожелания — с удовольствием выслушаю.
Ссылка на оценку не помешала бы. Просто два основных продукта Спольски (FogBugz и Kiln начатый года 2-3 назад) сидят на дотнете. Про StackExchange я не заикаюсь, это несколько другая компания, но тоже, в основном, .Net. Правда, последний проект (Trello.com technology stack) на node.js и mongodb, но у Trello толстоватый клиент и в серверной части превалирует задача хранения данных c минимумом логики, так что это скорее из разряда выбора наиболее подходящей технологии под задачу.
А перевод очень хороший, спасибо автору.
А перевод очень хороший, спасибо автору.
Наверное, речь об этой статье, в которой много забавных моментов да и немного устарела она, но в целом, с ней сложно не согласиться.
Ссылка на оценку не помешала бы.
Пожалуйста:
У Microsoft поехала крыша.
Как Microsoft проиграла битву за API.
Пожалуйста, сэр, могу ли я получить компоновщик?
Позже Джоэль резко поменял свою оценку на противоположную, и это довольно подозрительно.
Я ответил в блоге автора. Продублирую здесь.
Примеры stackexchange и myspace не показывают ни чего абсолютно. Даже больше, если платформа так хороша почему примеров так мало? Почему столько новых и успешных проэктов запускаются на технологиях которым иногда всего года 2 отроду, а на .net могут вспомнить всего 2.
myspace стартовали с coldfusion и переехали на .net уже когда были далеко не стартапом.
stackexchange — чистый C# со своим самописным ORM — какой стартап может позволить себе писать свой yet another ORM вместо реализации функционала нужного пользователю. SQLServer — маштабируется scale up, учитыя стоимость лицензий и железа это решение не для стартапа, когда можна тратить буквально несколько $ на БД в месяц на Амазон, а уже когда видна перспектива вкладіваться в собственное железо.
Примеры stackexchange и myspace не показывают ни чего абсолютно. Даже больше, если платформа так хороша почему примеров так мало? Почему столько новых и успешных проэктов запускаются на технологиях которым иногда всего года 2 отроду, а на .net могут вспомнить всего 2.
myspace стартовали с coldfusion и переехали на .net уже когда были далеко не стартапом.
stackexchange — чистый C# со своим самописным ORM — какой стартап может позволить себе писать свой yet another ORM вместо реализации функционала нужного пользователю. SQLServer — маштабируется scale up, учитыя стоимость лицензий и железа это решение не для стартапа, когда можна тратить буквально несколько $ на БД в месяц на Амазон, а уже когда видна перспектива вкладіваться в собственное железо.
UFO just landed and posted this here
Как ASP.NET разработчик соглашусь с написанным. Добровольно связываться с WebForms не хочется. А вот связка ASP.NET MVC + jQuery + EF CodeFirst вызывает только положительные эмоции при старте проектов.
Да и еще в догонку — если не ошибаюсь, то Vishal Joshi из Microsoft говорил что WebForms и правда несколько консервативен. Дело в том, что он ориентирован как раз на корпоративную разработку и все «фишки» сначала внедряются в MVC и уже потом переносятся в WebForms.
EF CodeFirst — именно что только «при старте проектов». С масштабированием плохо все, нет нормального lazy-loading-а и интеграции с кэшем. Хотя, очень радуют подвижки, и новый migration-фреймворк в EF.
Ну так я и написал что при старте (хотя конечно смотря что за проект). Ведь EF CF «заворачивается» в Repository/Spec. Repository/Query и потом меняется на что-то иное по необходимости.
Зачем его заворачивать в Repository/Spec? IDbSet<T> в EF Code-First и есть реализация репозитория (generic-вариант). Миграция Data-Access-уровня осуществляется не заменой реализации интерфейсов аля ISomeRepository, а портированием. Однако, в ряде сценариев EF работает и очень хорошо (и позволяет быстро писать код).
> Зачем его заворачивать в Repository/Spec?
Именно для того, чтобы при необходимости сменить реализацию. IDbSet не подходит, т.к. его относительно сложно корректно реализовать самому.
> Миграция Data-Access-уровня осуществляется не заменой реализации интерфейсов аля
> ISomeRepository, а портированием
А зачем усложнять себе жизнь?
Именно для того, чтобы при необходимости сменить реализацию. IDbSet не подходит, т.к. его относительно сложно корректно реализовать самому.
> Миграция Data-Access-уровня осуществляется не заменой реализации интерфейсов аля
> ISomeRepository, а портированием
А зачем усложнять себе жизнь?
Тут зависит от того, какую архитектуру вы хотите. В свое время я думал так же, но в итоге на практике оказалось, что все, что я хочу — данные и более-менее одинаковые принципы работы с разными сущностями (Сохранить, Удалить). В итоге это привело к тому, что конкретные репозитории начали вырождаться в generic-и.
Что касается «абстракции от конкретной ORM, чтобы, если что, можно было сменить уровень доступа к данным, и вуаля» — на практике все происходит с точностью да наоборот — мы просто теряем «фичи» ORM. Не говоря уже о том, что LINQ — это одна большая протекающая абстракция, и абстрагироваться от нее не имеет смысла. Spec-и и QueryObject-ы получаются ORM-специфичные, и не нужно пытаться абстрагироваться от этого.
Ayende Rahien прекрасно описал эту мысль в своей статье The false myth of encapsulating data access in the DAL
Что касается «абстракции от конкретной ORM, чтобы, если что, можно было сменить уровень доступа к данным, и вуаля» — на практике все происходит с точностью да наоборот — мы просто теряем «фичи» ORM. Не говоря уже о том, что LINQ — это одна большая протекающая абстракция, и абстрагироваться от нее не имеет смысла. Spec-и и QueryObject-ы получаются ORM-специфичные, и не нужно пытаться абстрагироваться от этого.
Ayende Rahien прекрасно описал эту мысль в своей статье The false myth of encapsulating data access in the DAL
> В итоге это привело к тому, что конкретные репозитории начали вырождаться в generic-и
Согласен. Отличия между проектами сводятся к условиям их выборки. Вот тут и подходит Spec. Repository / Query. Они позволяют убрать бизнес-логику из DAL в Domain.
> Spec-и и QueryObject-ы получаются ORM-специфичные,
Согласен. Но они централизуют место где запросы описаны и упрощают переход между ORM. Ну и отделены от ORM.
> мы просто теряем «фичи» ORM.
А это уже вопрос организации DAL. Ведь по сути наверх он должен выдать некие сущности, а как он это сделает (и даже где хранит) — его дело. Верхним слоям это без разницы.
Согласен. Отличия между проектами сводятся к условиям их выборки. Вот тут и подходит Spec. Repository / Query. Они позволяют убрать бизнес-логику из DAL в Domain.
> Spec-и и QueryObject-ы получаются ORM-специфичные,
Согласен. Но они централизуют место где запросы описаны и упрощают переход между ORM. Ну и отделены от ORM.
> мы просто теряем «фичи» ORM.
А это уже вопрос организации DAL. Ведь по сути наверх он должен выдать некие сущности, а как он это сделает (и даже где хранит) — его дело. Верхним слоям это без разницы.
> Согласен. Но они централизуют место где запросы описаны и упрощают переход между ORM. Ну и отделены от ORM.
Поэтому и используем.
> А это уже вопрос организации DAL. Ведь по сути наверх он должен выдать некие сущности, а как он это сделает (и даже где хранит) — его дело. Верхним слоям это без разницы.
Верно, но зачастую такой код получается более тяжеловесным с дополнительным уровнем, который надо поддерживать. Плюс, обычно очень хочется использовать LINQ и/или LINQ-based QueryObject.
В общем и целом, ни разу не было прецедента, что надо менять ORM — обычно ORM это только одна из проблем, когда «надо что-то менять».
P.S. На самом деле досадно, что LINQ получился такой протекающей абстракцией, сильно зависящей от реализации нижележащего IQueryProvider. А выглядел как очень многообещающее универсальное API доступа к данным.
Поэтому и используем.
> А это уже вопрос организации DAL. Ведь по сути наверх он должен выдать некие сущности, а как он это сделает (и даже где хранит) — его дело. Верхним слоям это без разницы.
Верно, но зачастую такой код получается более тяжеловесным с дополнительным уровнем, который надо поддерживать. Плюс, обычно очень хочется использовать LINQ и/или LINQ-based QueryObject.
В общем и целом, ни разу не было прецедента, что надо менять ORM — обычно ORM это только одна из проблем, когда «надо что-то менять».
P.S. На самом деле досадно, что LINQ получился такой протекающей абстракцией, сильно зависящей от реализации нижележащего IQueryProvider. А выглядел как очень многообещающее универсальное API доступа к данным.
По моему опыту, все реальные проблемы с производительностью EF были вызваны неправильным его использованием. EF нарушает принцип наименьшего удивления. В своих недрах он может производить лишние операции и тормозить тогда, когда от него этого никак не ждешь. Но все решаемо, если знать с чем имеешь дело.
Кстати, существует решение для EF для автоматического кеширования/инвалидации на уровне result set`ов.
Для горизонтального масштабирования нагруженного проекта все равно придется прийти к денормализованному хранилищу для чтения (CQRS). Но для работы с нормализованной БД EF неплохо подходит.
Кстати, существует решение для EF для автоматического кеширования/инвалидации на уровне result set`ов.
Для горизонтального масштабирования нагруженного проекта все равно придется прийти к денормализованному хранилищу для чтения (CQRS). Но для работы с нормализованной БД EF неплохо подходит.
Про кэш я имею в виду что-то вроде кэша второго уровня в NHibernate (с возможностью подключить memcached, AppFabric Cache или что-то еще).
Насчет CQRS — имеет смысл, если система достаточно обширна и есть большая разница между Read и Write, и нужно масштабировать их отдельно. Тут и помогает CQRS.
Кстати,
> «придется прийти к денормализованному хранилищу для чтения (CQRS)»
Как эти две вещи связаны? Одно может использовать другое (например, в качестве источника для Read-моделей используется денормализованное хранилище), но они отнюдь не связаны. Можно разделить «C» и «Q», при этом используя одну базу.
Насчет CQRS — имеет смысл, если система достаточно обширна и есть большая разница между Read и Write, и нужно масштабировать их отдельно. Тут и помогает CQRS.
Кстати,
> «придется прийти к денормализованному хранилищу для чтения (CQRS)»
Как эти две вещи связаны? Одно может использовать другое (например, в качестве источника для Read-моделей используется денормализованное хранилище), но они отнюдь не связаны. Можно разделить «C» и «Q», при этом используя одну базу.
Кеш материализованных объектов на EF придется написать самостоятельно, но это не так сложно. С ручной инвалидацией так вообще элементарно.
Насчет CQRS. Это вопрос терминологии. Сейчас простое разделение Query и Command на уровне API чаще называют CQS, когда CQRS подразумевает раздельные хранилища. Но, имея первое, проще будет прийти ко второму, если это понадобится. Только переписав Query Handler'ы и добавив денормализаторы.
Насчет CQRS. Это вопрос терминологии. Сейчас простое разделение Query и Command на уровне API чаще называют CQS, когда CQRS подразумевает раздельные хранилища. Но, имея первое, проще будет прийти ко второму, если это понадобится. Только переписав Query Handler'ы и добавив денормализаторы.
Как по мне, это абсолютные синонимы — CQS и CQRS. Проблема с ними именно в терминологии и в семантике. Я сам за простоту, и под термином CQRS понимаю именно саму концепцию, без конкретизации архитектуры уровня доступа к данным. Денормализаторы — это фича, но это не фича CQRS, насмотря на то, что они прекрасно используются вместе. То же самое касается Event Sourcing-а. Чтобы разделить «Си» и «Кью», не нужен «весь комплект».
Ну да ладно, топик не про CQRS :)
Про кэш — меня всегда смущает «написать самостоятельно, но это не так сложно». Весьма и весьма. Механизм в NH, который отвечает за актуальность данных в кэше второго уровня (в Session-Factory) простым не назовешь. Наверное, костяк не сложен, но отшлифованное production-ready-решение — отнюдь.
Ну да ладно, топик не про CQRS :)
Про кэш — меня всегда смущает «написать самостоятельно, но это не так сложно». Весьма и весьма. Механизм в NH, который отвечает за актуальность данных в кэше второго уровня (в Session-Factory) простым не назовешь. Наверное, костяк не сложен, но отшлифованное production-ready-решение — отнюдь.
Соглашусь с VasilioRuzanni и не соглашусь по поводу EF CodeFirst — вникать в систему достаточно долго и работает оно потом не слишком быстро. Взамен я бы порекомендовал NHibernate + FluentMappings, за час другой можно получить полностью готовую базу для приложения
Насчет скорости — в EF 5 обещают хороший прирост под .NET4.5. А вот по поводу «вникать долго» — удивили. Описание через FluentAPI или атрибуты простое и понятное, прикручивается к POCO на раз. Ну и в плюсах уже упомянутый migration, позволяющий менять модель в процессе разработки.
А внятный мануал не подскажете? А то я когда искал, ничего внятного не находил. Везде предлагали надкрутить над каждым свойством класса по 100500 аттрибутов…
У NH есть ещё одно, крайне важное преимущество — количество провайдеров.
У NH есть ещё одно, крайне важное преимущество — количество провайдеров.
MSDN подойдет? Разбирался по нему. Азы есть у меня в блоге (ссылка в профиле, тут не буду ибо чтобы не сочли за рекламу).
> 100500 аттрибутов
Нет там столько. Можно вообще не трогать классы модели и все описать на FluentAPI.
> 100500 аттрибутов
Нет там столько. Можно вообще не трогать классы модели и все описать на FluentAPI.
Вникать как раз-таки в NH + FluentMappings дольше :) Но я все равно советовал бы NH. Плюс Migrator.NET можно для миграций.
Подход, прекрасный в своей простоте, с использованием соглашений в последнем EF — очень крут. Поэтому, у меня есть даже свой микро-проект, обертка вокруг NH (NHibernateFacade), позволяющий работать с NH в духе EF CF (с использованием IEntityContext вместо DbContext).
P.S. Надо бы выложить на гитхаб и написать статью.
Подход, прекрасный в своей простоте, с использованием соглашений в последнем EF — очень крут. Поэтому, у меня есть даже свой микро-проект, обертка вокруг NH (NHibernateFacade), позволяющий работать с NH в духе EF CF (с использованием IEntityContext вместо DbContext).
P.S. Надо бы выложить на гитхаб и написать статью.
NHibernate конечно хорошо, но в плане простоты конфигурирования EF CodeFirst далеко впереди. Да и производительность EF вполне достаточна для 99,9 % проектов, а если кому-то не хватит скорости EF (очень малый процент) то и NHibernate тут не поможет, нужно будет писать более низкоуровневое решение. Лично я большой фанат EF CodeFirst + POCO :)
Перевод чудовищный. Но, видимо, для не знающих языка пойдёт.
> Таким образом, если запуск выстрелит, вероятно, гораздо легче будет масштабирование .Net стека чем Ruby или PHP.
PHP то как раз масштабировать проще всего.
PHP то как раз масштабировать проще всего.
Ниразу не видел Wordpress блог состоящий из 5 инстансов. Однако .Net и Ruby приложения только так и маштабируют все.
PHP-Fastcgi элементарно разносится на сколько-угодно-серверов.
Различайте масштабирование PHP и масштабирование базы.
Автор статьи хотел сказать MSSQL масштабируется лучше MySQL?
Различайте масштабирование PHP и масштабирование базы.
Автор статьи хотел сказать MSSQL масштабируется лучше MySQL?
> PHP-Fastcgi элементарно разносится на сколько-угодно-серверов.
Не согласен. PHP в режиме fcgi это не совсем fcgi. Это прекрасно видно потому как практически любой код на php заведется в fcgi режиме без редактирования приложения. Это мало чем отличается от пачки апачей перед балансером кроме как меньшим memory-footprint.
Да и сложно это будет разнести PHP-приложение на несколько серверов учитывая, что большинство разработчиков не понимают, что такой деплой, и просят дать им ftp, чтобы они могли скопировать файлы. А все потому, что в отличии от.Net и Ruby в PHP не навязываются гайдлайны и паттерны.
Впрочем, статья вовсе не об этом. Автор просто упомянул, что по его мнению, приложения, написанные на этом стеке, легче маштабировать, чем приложения на Ruby и PHP. Я не согласен, что .Net проще маштабировать чем Ruby, насчет PHP согласен.
Не согласен. PHP в режиме fcgi это не совсем fcgi. Это прекрасно видно потому как практически любой код на php заведется в fcgi режиме без редактирования приложения. Это мало чем отличается от пачки апачей перед балансером кроме как меньшим memory-footprint.
Да и сложно это будет разнести PHP-приложение на несколько серверов учитывая, что большинство разработчиков не понимают, что такой деплой, и просят дать им ftp, чтобы они могли скопировать файлы. А все потому, что в отличии от.Net и Ruby в PHP не навязываются гайдлайны и паттерны.
Впрочем, статья вовсе не об этом. Автор просто упомянул, что по его мнению, приложения, написанные на этом стеке, легче маштабировать, чем приложения на Ruby и PHP. Я не согласен, что .Net проще маштабировать чем Ruby, насчет PHP согласен.
Количество минусов этого комментария впечатляет — сколько народа вообще не имеет понятия о масштабировании :) В теме про .NET — это показатель.
Такое ощущение, что статья написана для менеджеров, которые, почитав разноцветные рекламные буклетики, будут выбирать платформу, на которой вести разработку.
Весь текст умещается в четыре утверждения:
.NET работает намного быстрее динамических языков. (с этим не поспоришь)
ASP.NET MVC намного продуктивнее WebForms. (и какое это имеет отношение к языкам unix стека?)
От Azure держитесь подальше. (солидный довод в пользу дотнета)
Microsoft раздаёт трёхление лицензии на свои продукты. (десятки тысяч $ за mssql сервер это серьёзно, особенно с учётом бесплатности аналогов)
Как насчёт доводов непосредственно для разработчиков? Что-нибудь такое:
У нас есть NuGet!
TeamFoundation это удобно!
IIS делает стектрейсы в эвентлоги!
С AppDomain не надо стопать сервисы!
RDP — сделай всё мышкой!
Весь текст умещается в четыре утверждения:
.NET работает намного быстрее динамических языков. (с этим не поспоришь)
ASP.NET MVC намного продуктивнее WebForms. (и какое это имеет отношение к языкам unix стека?)
От Azure держитесь подальше. (солидный довод в пользу дотнета)
Microsoft раздаёт трёхление лицензии на свои продукты. (десятки тысяч $ за mssql сервер это серьёзно, особенно с учётом бесплатности аналогов)
Как насчёт доводов непосредственно для разработчиков? Что-нибудь такое:
У нас есть NuGet!
TeamFoundation это удобно!
IIS делает стектрейсы в эвентлоги!
С AppDomain не надо стопать сервисы!
RDP — сделай всё мышкой!
от Azure держитесь подальше если вы — carebear. Хотите быть на bleeding edge — вперед, на Azure.
Идея PAAS очень хорошая, но к переносу продакшена надо подходить очень вдумчиво и очень осторожно.
А если стартап и есть экспертиза и понимание — может быть все довольно клево. Но клево на уровне стартапа — т.е. допустимы поломки\быстрые фиксы, нету сла, нету контрактов с суровыми клиентами. Если продакшен — готовиться очень тщательно
Идея PAAS очень хорошая, но к переносу продакшена надо подходить очень вдумчиво и очень осторожно.
А если стартап и есть экспертиза и понимание — может быть все довольно клево. Но клево на уровне стартапа — т.е. допустимы поломки\быстрые фиксы, нету сла, нету контрактов с суровыми клиентами. Если продакшен — готовиться очень тщательно
Мне вот недавно захотелось пощупать Azure, хоть я и не .Net разработчик, просто hype вокруг универсальности платформы и дажу планов по запуску Linux в их виртуальных машинах. Однако, каково же было разочарование, когда после регистрации, я не смог попасть в панель управления. Ведь они решили устроить массовый переход со старой версии на новую, реализованую на Silverlight. И даже установка последней версии (каюсь, грешен, не «с той платформы» захожу) Moonlight не дала возможности ее, панель управления, увидеть. В разных браузерах по разным причинам.
Из под Mac OS X зайти удалось, но после опыта работы c AWS/Google App Engine все показалось очень печальным. :(
Из под Mac OS X зайти удалось, но после опыта работы c AWS/Google App Engine все показалось очень печальным. :(
Да, ненависть к сервелату мне привила именно админка ажура.
Есть идея хорошего стартапа =) — сделать вебморду на html+js к API управления Azure. Дарю ;)
Есть идея хорошего стартапа =) — сделать вебморду на html+js к API управления Azure. Дарю ;)
Не уверен, что в МС оценят такой юмор :)
Уверен что оценят и пустят в bizspark. На админке сервелата они не зарабатывают, API у них есть и так. Почему бы не сделать функционал админки честно кроссплатформенным?
Действительно, почему бы _им_ его не сделать таковым? Как говорит Спольски, там есть много людей, которые хотят напарить разработчикам больше технологий (хороших и разных), чем этим разработчикам нужно. Очень странно видеть переход фронтенда потенциально крос-платформенной ажурной платформы на Silverlight, которому сами MS (по собирательным слухам) пророчат будущее только в Windows (Phone), но не в веб.
— Хотите быть на bleeding edge — вперед, на Amazon.
Dynamo DB, CloudSearch — пока Майкрософт занимается повторением реализации, Амазон клепает новые сервисы и цены скажу более демократичны.
Dynamo DB, CloudSearch — пока Майкрософт занимается повторением реализации, Амазон клепает новые сервисы и цены скажу более демократичны.
У Azure есть свои… эмм… косячки. Но миграция на него со стека MS несложная, если люди понимают, что делают и зачем.
NuGet — это и правда очень хорошо.
TFS — это то, что надо бы отправить в утиль, тем более для стартапа. И использовать Git (ну, или Mercurial).
IIS7/7.5 — очень хорошо, что он есть.
AppDomain — что имеем, то имеем, не жалуемся, но это не какая-то киллер-фича.
NuGet — это и правда очень хорошо.
TFS — это то, что надо бы отправить в утиль, тем более для стартапа. И использовать Git (ну, или Mercurial).
IIS7/7.5 — очень хорошо, что он есть.
AppDomain — что имеем, то имеем, не жалуемся, но это не какая-то киллер-фича.
>TeamFoundation это удобно!
Там VSS же.
Там VSS же.
Вроде как — нет. Другую VCS написали. «Основанную на», но сильно переработанную до уровня современных требований.
Не знал. VSS вспоминаю как страшный сон. И что, файлы теперь не лочатся?
Нет, не лочатся. Стал довольно цивильным но надо привыкнуть. Мы в одном проекте его попользовали, но потом как я понял (я перешел из того проекта) перешли на корп-стандарт — SVN =\
Оно лучше SVN или ты печалишься что не GIT/HG?
Оно довольно удобное, когда привыкнешь и поймешь терминологию. Сравнивать трудно т.к. опыт использования был не такой обширный чтобы сравнивать по делу.
К тому же TFS силен не столько своей VCS, а степенью интеграции багтреккера\дашбордов\VCS друг с другом и с внешними инструментами. Это очень мощное подспорье для управления всем и вся.
Насчет Git\HG — нет, не печалюсь, для себя я намерен переключиться на HG, а переводить всю компанию — я бы не хотел. У нас много всего уже настроенно\завязано, да и идеология центрального репозитория внутри одной компании работает вполне хорошо.
К тому же TFS силен не столько своей VCS, а степенью интеграции багтреккера\дашбордов\VCS друг с другом и с внешними инструментами. Это очень мощное подспорье для управления всем и вся.
Насчет Git\HG — нет, не печалюсь, для себя я намерен переключиться на HG, а переводить всю компанию — я бы не хотел. У нас много всего уже настроенно\завязано, да и идеология центрального репозитория внутри одной компании работает вполне хорошо.
Нет, там не VSS отнюдь. Совершенно новая система. Однако… юзайте git, народ :)
Все тут ноют про перевод — а что чудовищного в переводе-то? Я прочитал и вообще не заметил каких-то проблем. Нормальная терминология, переведена так чтобы не путать читателя всякими НЖМД\НГМД русификациями. Если для вас лексика типа стэк (мне привычней стек но не суть), каркас, паттерн или релевантность — далекая, то зачем вы полезли читать технический перевод?
Другое дело что это — статья-мнение и в общем-то довольно распространенное, если хотели донести до не-технарей — возможно стоило дать пояснения переводчика ( если сами разбираетесь в вопросе), если для технарей-.NETчиков — то тут это мнение известно давно. Ну а про Azure — просто еще одно подтверждение того, что довольно очевидно после первых попыток использования — идея правильная но реалиация сыроватая ;)
Другое дело что это — статья-мнение и в общем-то довольно распространенное, если хотели донести до не-технарей — возможно стоило дать пояснения переводчика ( если сами разбираетесь в вопросе), если для технарей-.NETчиков — то тут это мнение известно давно. Ну а про Azure — просто еще одно подтверждение того, что довольно очевидно после первых попыток использования — идея правильная но реалиация сыроватая ;)
Дело не в технической терминологии. Хороший перевод должен читаться так, будто текст изначально писался на русском. Тут же, видимо, было переведено промтом и убраны самые большие косяки.
Я это, в общем-то, на благо автора говорю. Если его не пинать, он может начать думать, что он переводит нормально, не будет развиваться, и в будущем его переводы так и останутся говном.
PS Об умении автора переводить сужу только по этому посту.
Я это, в общем-то, на благо автора говорю. Если его не пинать, он может начать думать, что он переводит нормально, не будет развиваться, и в будущем его переводы так и останутся говном.
PS Об умении автора переводить сужу только по этому посту.
Разработка приложения на Azure медленее, чем .Net разработка которая происходит на ОС Windows Server или VS. Развертывание занимает больше времени, отладка занимает больше времени, среду Azure трудно воспроизвести на вашем локальном компьютере, бэкапы весьма болезненны, и вы ограничены одним хостинг-провайдером.
Какая-то несуразица написана. То ли перевод корявый, то ли автор даже не пытался делать что-то серьезное для Azure. Если исходить из того, что в понимании автора стартап — это какой-то сайт-сервис, то:
1. В данной ситуации скорость разработки очень слабо зависит от того, под какую среду разрабатывается стартап. Продуманная архитектура нивелирует все различия между средой выполнения. Тут особым образом стоит использование очередей для обмена сообщениями между экземплярами, но если создавать систему, которая будет использовать несколько серверов — там тоже необходимо продумывать подсистему взаимодействия.
2. Аргумент про развертывание вообще не имеет смысла — складывается ощущение, что стартап обновляется чуть ли не каждый час. В любом случае есть нормальные способы деплоя в облако того же сайта, и они ничем не отличаются от деплоя на IIS.
3. Для отладки также есть эмулятор среды Azure, для стартапа отладка ничем не будет отличаться от обычной отладки. А если уж стартапу нужна отладка облачных фишек, то уж тут он и должен разрабатываться конкретно под облако и тогда действительно отладка будет более сложной.
4. Вот с бекапами тут согласен — есть определенные проблемы для различных сценариев. Понятно что если хранить данные в блобах, то и бекапить их тоже хотелось бы, НО Azure как бы гарантирует сохранность данных, так что бекапы только для отката к какому-то предыдущему состоянию нужны. В SQL Azure бекапы тоже не предусмотрены, но есть куча сторонних утилит + некоторые обходные механизмы в самом SQL Azure.
5. Минус в виде ограничение одним хостинг провайдером выглядит глуповато на мой взгляд. Облако — это не обычный хостинг провайдер. Тут нельзя так однозначно говорить, что это какой-то минус. Облако — это совершенно другая экосистема, которая никак не может сравниваться с обычным хостингом.
В целом, с учетом текущих цен на Azure, запустить стартап (2 extra small экземпляра — БД до 1 гб, storage 10 гб + 100к транзакций) обойдется в районе 1500 рублей в месяц. Этих ресурсов хватит, что бы обеспечит работу в первые 3-4, а может и больше, месяцев. Добавление дополнительных es инстансов — это ~500 рублей в месяц (если будут работать весь месяц конечно).
Какая-то несуразица написана. То ли перевод корявый, то ли автор даже не пытался делать что-то серьезное для Azure. Если исходить из того, что в понимании автора стартап — это какой-то сайт-сервис, то:
1. В данной ситуации скорость разработки очень слабо зависит от того, под какую среду разрабатывается стартап. Продуманная архитектура нивелирует все различия между средой выполнения. Тут особым образом стоит использование очередей для обмена сообщениями между экземплярами, но если создавать систему, которая будет использовать несколько серверов — там тоже необходимо продумывать подсистему взаимодействия.
2. Аргумент про развертывание вообще не имеет смысла — складывается ощущение, что стартап обновляется чуть ли не каждый час. В любом случае есть нормальные способы деплоя в облако того же сайта, и они ничем не отличаются от деплоя на IIS.
3. Для отладки также есть эмулятор среды Azure, для стартапа отладка ничем не будет отличаться от обычной отладки. А если уж стартапу нужна отладка облачных фишек, то уж тут он и должен разрабатываться конкретно под облако и тогда действительно отладка будет более сложной.
4. Вот с бекапами тут согласен — есть определенные проблемы для различных сценариев. Понятно что если хранить данные в блобах, то и бекапить их тоже хотелось бы, НО Azure как бы гарантирует сохранность данных, так что бекапы только для отката к какому-то предыдущему состоянию нужны. В SQL Azure бекапы тоже не предусмотрены, но есть куча сторонних утилит + некоторые обходные механизмы в самом SQL Azure.
5. Минус в виде ограничение одним хостинг провайдером выглядит глуповато на мой взгляд. Облако — это не обычный хостинг провайдер. Тут нельзя так однозначно говорить, что это какой-то минус. Облако — это совершенно другая экосистема, которая никак не может сравниваться с обычным хостингом.
В целом, с учетом текущих цен на Azure, запустить стартап (2 extra small экземпляра — БД до 1 гб, storage 10 гб + 100к транзакций) обойдется в районе 1500 рублей в месяц. Этих ресурсов хватит, что бы обеспечит работу в первые 3-4, а может и больше, месяцев. Добавление дополнительных es инстансов — это ~500 рублей в месяц (если будут работать весь месяц конечно).
Ну а кстати, biz spark подразумевает msdn, а msdn подразумевает халявный azure в некоторых пределах. Например, на ultimate позволяет постоянно держать 6 extra small instance + SQL и т.д.
Эта схема работает, интересно?
Эта схема работает, интересно?
Для Biz spark программы там свое условие предоставления хостинга на Azure www.microsoft.com/bizspark/Azure/Default.aspx?WT.mc_id=Azure1cta
А не могли бы вы запилить полноценную статью обзор Azure? Меня .Net все больше и больше привлекает, но необходимость в Windows сервере пока сильно отталкивает.
Кстати, скоро Cloud Foundry будет иметь возможность запускать DEA на Windows серверах, а значит будет еще одна PaaS платформа для .Net.
Кстати, скоро Cloud Foundry будет иметь возможность запускать DEA на Windows серверах, а значит будет еще одна PaaS платформа для .Net.
«Запилить» могу, но обзорную не хочу — тут на хабре их было не мало :)
Вероятно я их все пропустил. Натыкался только на «быстро, дешевого, замечательно, очещуенно, дайте две» Пойду еще поищу.
Что именно интересует? В принципе действительно много обзорных статей было. Часть конечно маркетингового толка, но разобраться можно. Гораздо легче если есть конкретные вопросы — на них можно дать конкретные ответы, а не «маркетинговые буклеты».
Если честно, то из маркетинговых статей вообще не понятно как происходит деплой кода. (кроме того, что медленно).
Вкратце: Есть несколько способов изготовить Package (студия, msbuild, консольная утилита). Это в общем Zip архив в специальном формате и с допданными, суть — инсталлятор
Далее способы загрузить этот Package в Azure — через админку ( с локального диска или если вы ранее загрузили этот package в блоб — указать адрес в блобе) или через API Azure.
После этого ажур начинает развертывание этого пака в соответствии с описанными в паке параметрами — размер роли- xSmall\small\Medium\Large, количество инстансов такой роли — от 2 до Х копий.
Если в паке несколько ролей (несколько Web или несколько разных Worker) — это делается для каждой.
В процессе развертывания выполняются внутренние утилиты типа IIS Configurator который прописывает ваши настройки в локальный (для инстанса) IIS и ваши Startup таски (cmd файл с вашими скриптами, можно вызывать Powershell) — последние позволяют сделать всякие мелочи типа создать папки, выдать права, зарегистировать COM объект и т.д.
После того как каждый инстанс отрапортует общему гипервизору что он все выполнил — считается что пак развернут.
Если вы разворачивали пак в Production слот — это все начинает отвечать по адресу (может отвечать до того как статус обновится, но это не значит что там все 100% поднялось) .cloudapp.net, если разворачивали в Staging слот — то по адресу .cloudapp.net.
Если какая то роль или инстанс в роле не поднялся — гипервизор попробует его перезапустить, если не поможет — перезальет с нуля на новую машину. Если все это не помогает — скажет что развертывание не удалось.
Кролики на ажуре размножаются примерно вот так ;-)
Далее способы загрузить этот Package в Azure — через админку ( с локального диска или если вы ранее загрузили этот package в блоб — указать адрес в блобе) или через API Azure.
После этого ажур начинает развертывание этого пака в соответствии с описанными в паке параметрами — размер роли- xSmall\small\Medium\Large, количество инстансов такой роли — от 2 до Х копий.
Если в паке несколько ролей (несколько Web или несколько разных Worker) — это делается для каждой.
В процессе развертывания выполняются внутренние утилиты типа IIS Configurator который прописывает ваши настройки в локальный (для инстанса) IIS и ваши Startup таски (cmd файл с вашими скриптами, можно вызывать Powershell) — последние позволяют сделать всякие мелочи типа создать папки, выдать права, зарегистировать COM объект и т.д.
После того как каждый инстанс отрапортует общему гипервизору что он все выполнил — считается что пак развернут.
Если вы разворачивали пак в Production слот — это все начинает отвечать по адресу (может отвечать до того как статус обновится, но это не значит что там все 100% поднялось) .cloudapp.net, если разворачивали в Staging слот — то по адресу .cloudapp.net.
Если какая то роль или инстанс в роле не поднялся — гипервизор попробует его перезапустить, если не поможет — перезальет с нуля на новую машину. Если все это не помогает — скажет что развертывание не удалось.
Кролики на ажуре размножаются примерно вот так ;-)
Неудивительно, что автор не рекомендует это использовать в начале. Я думал там в VS кнопочка «сделать хорошо.» Ну или как heroku.
Я вам рассказал краткий жизненный цикл внутри пака =). А из студии — есть такая «кнопочка» ( правда моя студия иногда с Out of memory exception на ней падает) — cfvf сбилдит на вашей машине, запакует и развернет на ажуре.
Проблема с ней, как и с любым «универсальным всемогутером» — если вам надо повторять действие с _предсказуемыми_ результатами — вы будете делать build server. Под него там все сложнее.
А кнопочка — да есть. Вместе с ней выдается майка It's Work on my machine.
Непромышленный подход ни разу. Но для стартапов этого наверное и не требуется, скорей всего.
Проблема с ней, как и с любым «универсальным всемогутером» — если вам надо повторять действие с _предсказуемыми_ результатами — вы будете делать build server. Под него там все сложнее.
А кнопочка — да есть. Вместе с ней выдается майка It's Work on my machine.
Непромышленный подход ни разу. Но для стартапов этого наверное и не требуется, скорей всего.
А вы пробовали сами делать что-то больше чем сэмплы? Вот мы в пятницу запустили проект (2+ года жизни) в Azure, который мигрировал ~2.5 месяца (очень сильно жали сроки). И я согласен с автором и не согласен с вами.
И вот почему:
1. Зависит, т.к. экспертиза по .NET — больше чем по .NET+Azure по определению.
Больше реальных специалистов, работающих инструментов, конкретных решений глубинных проблем и пр. Это действительно ВАЖНО и сильно влияет на начальную скорость разработки, пока не накоплена своя экспертиза. Мы это испытали на себе. Когда есть экспертиза — уже все равно на чем.
Сказки про «продуманность архитектуры» — оставьте маркетингу — ни один проект с первого раза не создавал правильную и продуманную архитектуру, «продуманная архитектура с первого раза» это миф. Только путем итераций получается работоспособное решение. Если заложить все и сразу (если у вас гениальный архитектор(тоже миф) который сразу видит все нужды и направление развития ) — слишком долго делать.
2. Стартап может обновляться каждые 5 минут — тюнинг продакшен конфига например. Ажур — так не может, и вам это известно. Также про нормальные способы обновления — у меня за время работы — админка на сильверлайте висла и крэшилась десятки раз. Хорошо что в момент обновления устояла.
3. Забудьте про эмулятор. Это Epic fail воплощенный в коде. Единственное что можно взять — Azure Storage эмулятор и запилить его на тестовый сервер, предварительно «поправив», чтобы принимал внешние запросы, а не только с 127.0.0.1
4. «Как бэ» гарантирует это не значит что 100% гарантирует. Бэкапы кстати вопрос решаемый, из всего лично нас он парит меньше всего.
5. Она может и должна сравниваться с обычными предложениями на рынке, т.к. именно с ними оно конкурирует. Вся эта чушь про уникальность — маркетинговый бред чтобы выглядеть прилично при сравнении. Т.к. облако проигрывает в некоторых местах сильно — придуманы такие сказки. В других местах оно сильно выигрывает и почему-то это выпячивают вперед, а не говорят — ну мы не будем тут сравнивать, все же разные категории. В общем «или крестик снимайте или трусы оденьте».
Extra small — сидит на 5 мбитах, не говоря уже о Shared CPU. Судя по скоростям и с учетом того что датацентров не так много по всему миру (т.е. очень близкий — не найдете) — это трэш. Small — это минимум c чего можно начинать.
С учетом текущих цен на «fast-food» хостинг, тот же amazon, выигрыша пока не видно. И да, для того чтобы выполнялась SLA Uptime 99.95% у вас должно быть 2 инстанса и платить вы будете как за 2 CPU. По деньгам выигрыш очень сомнительный.
И вот почему:
1. Зависит, т.к. экспертиза по .NET — больше чем по .NET+Azure по определению.
Больше реальных специалистов, работающих инструментов, конкретных решений глубинных проблем и пр. Это действительно ВАЖНО и сильно влияет на начальную скорость разработки, пока не накоплена своя экспертиза. Мы это испытали на себе. Когда есть экспертиза — уже все равно на чем.
Сказки про «продуманность архитектуры» — оставьте маркетингу — ни один проект с первого раза не создавал правильную и продуманную архитектуру, «продуманная архитектура с первого раза» это миф. Только путем итераций получается работоспособное решение. Если заложить все и сразу (если у вас гениальный архитектор(тоже миф) который сразу видит все нужды и направление развития ) — слишком долго делать.
2. Стартап может обновляться каждые 5 минут — тюнинг продакшен конфига например. Ажур — так не может, и вам это известно. Также про нормальные способы обновления — у меня за время работы — админка на сильверлайте висла и крэшилась десятки раз. Хорошо что в момент обновления устояла.
3. Забудьте про эмулятор. Это Epic fail воплощенный в коде. Единственное что можно взять — Azure Storage эмулятор и запилить его на тестовый сервер, предварительно «поправив», чтобы принимал внешние запросы, а не только с 127.0.0.1
4. «Как бэ» гарантирует это не значит что 100% гарантирует. Бэкапы кстати вопрос решаемый, из всего лично нас он парит меньше всего.
5. Она может и должна сравниваться с обычными предложениями на рынке, т.к. именно с ними оно конкурирует. Вся эта чушь про уникальность — маркетинговый бред чтобы выглядеть прилично при сравнении. Т.к. облако проигрывает в некоторых местах сильно — придуманы такие сказки. В других местах оно сильно выигрывает и почему-то это выпячивают вперед, а не говорят — ну мы не будем тут сравнивать, все же разные категории. В общем «или крестик снимайте или трусы оденьте».
Extra small — сидит на 5 мбитах, не говоря уже о Shared CPU. Судя по скоростям и с учетом того что датацентров не так много по всему миру (т.е. очень близкий — не найдете) — это трэш. Small — это минимум c чего можно начинать.
С учетом текущих цен на «fast-food» хостинг, тот же amazon, выигрыша пока не видно. И да, для того чтобы выполнялась SLA Uptime 99.95% у вас должно быть 2 инстанса и платить вы будете как за 2 CPU. По деньгам выигрыш очень сомнительный.
О нет, я все правильно написал.
Автор утверждает «Не использовать Azure на ранней стадии»
Я же наоборот утверждаю, что если планируете использовать Azure для стартапа, то начинать надо сразу.
Вы опровергли мои утверждения, но все они применимы (в вашем случае) именно в тогда, когда вы начинаете миграцию уже готового решения. С миграцией в Azure сложно, очень сложно. Сейчас даже цела ниша появляется с услугой помощи при миграции в облака.
Опять же я не говорил про выигрыш в деньгах (только привел основанную на опыте конфигурацию начальной стадии) — размещение в облаке дороже обычного хостинга.
Датацентров у Azure сейчас более чем достаточно (8 штук, без учета CDN серверов, 1 кстати есть в Москве). Производительности и отзывчивости на Extra Small в первые месяцы стартапа — с лихвой хватает, даже с учетом SLA, если уж у вас начинают расти нагрузки, то перейти на более серьезные размеры никто не мешает, и думаю деньги в этот период уже появляются, что бы была возможность их оплачивать.
Вообще с учетом современных тенденций в пиковых нагрузках — облака являются более предпочтительным способом размещения стартапов ибо там реально платите только за реальную работу, а не за простой железок.
Автор утверждает «Не использовать Azure на ранней стадии»
Я же наоборот утверждаю, что если планируете использовать Azure для стартапа, то начинать надо сразу.
Вы опровергли мои утверждения, но все они применимы (в вашем случае) именно в тогда, когда вы начинаете миграцию уже готового решения. С миграцией в Azure сложно, очень сложно. Сейчас даже цела ниша появляется с услугой помощи при миграции в облака.
Опять же я не говорил про выигрыш в деньгах (только привел основанную на опыте конфигурацию начальной стадии) — размещение в облаке дороже обычного хостинга.
Датацентров у Azure сейчас более чем достаточно (8 штук, без учета CDN серверов, 1 кстати есть в Москве). Производительности и отзывчивости на Extra Small в первые месяцы стартапа — с лихвой хватает, даже с учетом SLA, если уж у вас начинают расти нагрузки, то перейти на более серьезные размеры никто не мешает, и думаю деньги в этот период уже появляются, что бы была возможность их оплачивать.
Вообще с учетом современных тенденций в пиковых нагрузках — облака являются более предпочтительным способом размещения стартапов ибо там реально платите только за реальную работу, а не за простой железок.
Для стартапа важен быстрый старт =) использовать ажур с самого начала с работой на далекую перспективу — это быть уверенным что стартап выстрелит 100%. Этим вроде уже никто не страдает.
Т.е. в случае «если планируете» — да, делать сразу а не переползать.
Но планировать с самого начала использовать «отягчающие» стартап технологии — опрометчиво =).
Датацентры — ну насчет достаточно — спорный вопрос. SQL Azure все также разворачивается только в 5 из них (у меня так сейчас). Разносить базу и роль в разные ДЦ — смысла мало.
Насчет производительности и отзывчивости xSmall — зависит от задач, про CPU не могу сказать, канал — явно узкий. А что подразумевается под ростом тогда? Со 100 пользователей до 500?
Денег может и не быть — обзор на хабре принесет ~3к пользователей пиком. Если стартап годный — они останутся. А деньги от рекламы хотя бы появятся только в конце месяца? Ну да, деньги там не такие большие, но за них же другие предлагают более приличные железки.
С учетом современных тенденций все пихать в облака есть ощущения что скоро эти грабли-таки долетят до высоких лбов и мы увидим «эпические феерверки». Стартапам такой удар «проломит череп».
Что интересно отметить — мы с вами в общем сходимся в одном — работающий продукт мигрировать надо очень осторожно =).
Т.е. в случае «если планируете» — да, делать сразу а не переползать.
Но планировать с самого начала использовать «отягчающие» стартап технологии — опрометчиво =).
Датацентры — ну насчет достаточно — спорный вопрос. SQL Azure все также разворачивается только в 5 из них (у меня так сейчас). Разносить базу и роль в разные ДЦ — смысла мало.
Насчет производительности и отзывчивости xSmall — зависит от задач, про CPU не могу сказать, канал — явно узкий. А что подразумевается под ростом тогда? Со 100 пользователей до 500?
Денег может и не быть — обзор на хабре принесет ~3к пользователей пиком. Если стартап годный — они останутся. А деньги от рекламы хотя бы появятся только в конце месяца? Ну да, деньги там не такие большие, но за них же другие предлагают более приличные железки.
С учетом современных тенденций все пихать в облака есть ощущения что скоро эти грабли-таки долетят до высоких лбов и мы увидим «эпические феерверки». Стартапам такой удар «проломит череп».
Что интересно отметить — мы с вами в общем сходимся в одном — работающий продукт мигрировать надо очень осторожно =).
Автор имел ввиду вот это: stackoverflow.com/questions/5080445/why-does-azure-deployment-take-so-long
Нормальный перевод, чего докопались? Насчет стартапов на .NET — согласен. Эта платформа при правильном подходе позволяет писать очень и очень быстро
Спасибо. А можно ссылку на оригинал статьи?
«придти»? придту
Закончил читать на первом абзаце и пошел на оригинал…
http://appharbor.com как пример того, что asp.net mvc может использоваться для проектов, где нужен быстрый старт и легкая модель разработки, хипстерский git flow/deployment и подключение всего как сервисы — от MS SQL/MongoDB до всяких SendGrid и прочих штук, популярных на heroku.com.
Автору-переводчику — раз уж делаете перевод, то потрудитесь запостить ссылку откуда взята статья и указать оригинального автора, иначе это просто вилами на воде
А про саму статью — мне кажется это вообще бред — указывать программеру какой инструмент использовать и в каких случаях. Всё что быстрей и удобней для разработчиков — то и заработает, если мозг при этом правильный.
А про саму статью — мне кажется это вообще бред — указывать программеру какой инструмент использовать и в каких случаях. Всё что быстрей и удобней для разработчиков — то и заработает, если мозг при этом правильный.
1) Ссылка и автор есть. Вы первый раз на хабре?
2) Статья не на разработчиков ориентирована. Если бы вы ее прочитали — вы бы это поняли.
2) Статья не на разработчиков ориентирована. Если бы вы ее прочитали — вы бы это поняли.
ASP.Net MVC / C# / SqlServer стэк маштабируется как сумасшедший
— Сколько у вас клиентов, каков объём обрабатываемых данных, какое количество железа всё это обслуживает, проводился ли анализ что будет стоить запустить тот же функционал на альтернативной платформе?
Как человек который уже год как пытается запустить стартап на .net
— SqlServer — не для стартапа, он не маштабируется, в том понятии в каком его понимают на других платформах. Вы не сможете добавить slave на читание, сделать умную политику репликации. Стоимость лицензирования SqlServer выбросит вас на мель ещё до начала разработки, это продукт не для стартапа.
— IIS — отсутствие вменяемого способа распространять приложение на любое количество машин, хоть 10, хоть 100, хоть 1000, очень сильно ограничивает. Нам пришлось разработать свой конфигурацинный фреймворк. Даже остановленный IIS может оставить открытыми некоторые файлы, потому накатываение новой конфигурации в 1 из 5 случаев будет происходить с ошибкой. Сейчас анализируем может ли помочь Cheff/Puppet в этом. Но отсутствие таких инструментов показывает, что о маштабировании, mass deployment вообще не думали. (и Web Farm Framework здесь не подходит). Квотирование ресурсов на apppool ещё одна головная боль, тут писали как хорошо с этим будет в следующем iis, а пока ждите выхода следующей ОС в конце года, а тем временем ваши конкуренты накатывают фикс на node.js/mongrel2/nginx и продолжают выкатывать функционал. Производительность WCF/IIS оставляет желать лучшего. Да она неплоха для enterprise, но когда тебе нужно чтобы каждый узел утилизировал каждый герц производительности и мог тянуть максимально возможное число клиентов использование .net экономически не выгодно. Когда МС официально рекомендует использовать на Azure node.js — это декларация о неспособности создать что либо подобное. И когда large instance на node.js выдерживает на порядок больше одновременных сессий чем iis, возникает вопрос о адекватности платформы современным реалиям.
— ASP.Net MVC — Построение RESTfull приложения усложнено, MVC4/WebAPI уже лучше, но поздно и всё ещё бета к тому же сырая. WebAPI: я бы охарактеризовал как «XML/SOAP головного мозга», тяжелое наследство предыдущих технологий довлеет над разработчиками. Если я не хочу/не могу использовать OData большинство преимуществ WebAPI теряется. Вынос IQueryable наружу сервиса упрощает разработку, но привязывает вас к EF и реляционным БД что тут же отражается на масштабируемости. И IQueryable как рак поражает ваше приложение и ограничивает вас в будущих модификациях.
В сухом остатке. C# очень класный язык. Стэк .NET плохо подходит для построения высоко нагруженных сервисов и исключения вроде stack exchange(по сути только C# + IIS там и использован, ORM свой), my space только подтверждают это. Если у вас время, деньги на то чтобы написать самим с нуля под вашу задачу большую часть платформы welcome to the hell, только вот вашы конкуренты которые выберут более легковесную платформу будут иметь преимущество в скорости разработки, а также меньше денег будут тратить на поддержание инфраструктуры.
— Сколько у вас клиентов, каков объём обрабатываемых данных, какое количество железа всё это обслуживает, проводился ли анализ что будет стоить запустить тот же функционал на альтернативной платформе?
Как человек который уже год как пытается запустить стартап на .net
— SqlServer — не для стартапа, он не маштабируется, в том понятии в каком его понимают на других платформах. Вы не сможете добавить slave на читание, сделать умную политику репликации. Стоимость лицензирования SqlServer выбросит вас на мель ещё до начала разработки, это продукт не для стартапа.
— IIS — отсутствие вменяемого способа распространять приложение на любое количество машин, хоть 10, хоть 100, хоть 1000, очень сильно ограничивает. Нам пришлось разработать свой конфигурацинный фреймворк. Даже остановленный IIS может оставить открытыми некоторые файлы, потому накатываение новой конфигурации в 1 из 5 случаев будет происходить с ошибкой. Сейчас анализируем может ли помочь Cheff/Puppet в этом. Но отсутствие таких инструментов показывает, что о маштабировании, mass deployment вообще не думали. (и Web Farm Framework здесь не подходит). Квотирование ресурсов на apppool ещё одна головная боль, тут писали как хорошо с этим будет в следующем iis, а пока ждите выхода следующей ОС в конце года, а тем временем ваши конкуренты накатывают фикс на node.js/mongrel2/nginx и продолжают выкатывать функционал. Производительность WCF/IIS оставляет желать лучшего. Да она неплоха для enterprise, но когда тебе нужно чтобы каждый узел утилизировал каждый герц производительности и мог тянуть максимально возможное число клиентов использование .net экономически не выгодно. Когда МС официально рекомендует использовать на Azure node.js — это декларация о неспособности создать что либо подобное. И когда large instance на node.js выдерживает на порядок больше одновременных сессий чем iis, возникает вопрос о адекватности платформы современным реалиям.
— ASP.Net MVC — Построение RESTfull приложения усложнено, MVC4/WebAPI уже лучше, но поздно и всё ещё бета к тому же сырая. WebAPI: я бы охарактеризовал как «XML/SOAP головного мозга», тяжелое наследство предыдущих технологий довлеет над разработчиками. Если я не хочу/не могу использовать OData большинство преимуществ WebAPI теряется. Вынос IQueryable наружу сервиса упрощает разработку, но привязывает вас к EF и реляционным БД что тут же отражается на масштабируемости. И IQueryable как рак поражает ваше приложение и ограничивает вас в будущих модификациях.
В сухом остатке. C# очень класный язык. Стэк .NET плохо подходит для построения высоко нагруженных сервисов и исключения вроде stack exchange(по сути только C# + IIS там и использован, ORM свой), my space только подтверждают это. Если у вас время, деньги на то чтобы написать самим с нуля под вашу задачу большую часть платформы welcome to the hell, только вот вашы конкуренты которые выберут более легковесную платформу будут иметь преимущество в скорости разработки, а также меньше денег будут тратить на поддержание инфраструктуры.
По сути вопросов — бесплатный Express SQL сам по себе держит довольно приличную нагрузку (вы озвучьте плз на какой нагрузке вы просели так что нужны шарды на чтение ?). Не безумные числа и не голый, все таки кэширование, индексы и оптимизацию запросов никто не отменяет.
Просто интересен масштаб — когда проседает?
IIS — MSDeploy (бывший WebDeploy). Вроде вменяемый способ. Включая миграцию настроек. Какие проблемы решает ваш framework, которые не умеет MSDeploy?
Про открытые файлы — интересно. А багу нашли — это действительно держит IIS? тогда надо писать в connect\фиксить. У нас рестарт iis приводит к тому что все файлы освобождены. Но вообще должно быть довольно сделать recycle app pool.
node.js — это возможность а не рекомендация «использовать вместо».
Хмм, в целом я первый раз слышу о такой серьезной проблеме с производительностью IIS. Вы уверены что правильно его «готовите»? Есть пример что вебферма из 2х IIS (правда машинки не слабые -в сумме 16 физ.ядер) легко держит нагрузку до 50 запросов в секунду, даже не «вспотели».
про Restfull API — мы запилили на mvc 3 и контроллерах — быстро просто и летает. Контроль — полный. WebAPI пока не смотрели, да и вроде нет необходимости — уже все работает. Возможно у нас нет активной работы с коллекциями и фильтрацией по запросу, но в целом — не вижу сложностей
А можно нескромно поинтересоваться — у вашего «еще незапущенного» стартапа уже такая нагрузка что все это нужно? Что же вы такое сделали что так популярны и такая нагрузка на начальном этапе стартапа? Урль в студию, если не жалко.
2All Зачем человека минусуете — он мнение пишет.
Просто интересен масштаб — когда проседает?
IIS — MSDeploy (бывший WebDeploy). Вроде вменяемый способ. Включая миграцию настроек. Какие проблемы решает ваш framework, которые не умеет MSDeploy?
Про открытые файлы — интересно. А багу нашли — это действительно держит IIS? тогда надо писать в connect\фиксить. У нас рестарт iis приводит к тому что все файлы освобождены. Но вообще должно быть довольно сделать recycle app pool.
node.js — это возможность а не рекомендация «использовать вместо».
Хмм, в целом я первый раз слышу о такой серьезной проблеме с производительностью IIS. Вы уверены что правильно его «готовите»? Есть пример что вебферма из 2х IIS (правда машинки не слабые -в сумме 16 физ.ядер) легко держит нагрузку до 50 запросов в секунду, даже не «вспотели».
про Restfull API — мы запилили на mvc 3 и контроллерах — быстро просто и летает. Контроль — полный. WebAPI пока не смотрели, да и вроде нет необходимости — уже все работает. Возможно у нас нет активной работы с коллекциями и фильтрацией по запросу, но в целом — не вижу сложностей
А можно нескромно поинтересоваться — у вашего «еще незапущенного» стартапа уже такая нагрузка что все это нужно? Что же вы такое сделали что так популярны и такая нагрузка на начальном этапе стартапа? Урль в студию, если не жалко.
2All Зачем человека минусуете — он мнение пишет.
Требования к проэкту поддерживать 1 000 000 зарегистрированых пользовалей.
— Express версия даже не рассматривалась, пользовательских данных значительно больше. Если у вас один сервер у вас одна точка отказа. Варианты с репликацией SQL Server и стоимость лицензирования похоронит даже устоявшуюся компанию не то что стартап. В то же время єкпертиза по MySQL настолько большая есть такое количество готовіх решений что SQL Server вообще не стоит рассматривать всерёз, это простая экономика и пусть mysql connector не имеет встроенного оператора IN и имеет ряд других проблем, их то обойти можно, но он нам обходится на два-три порядка дешевле чем сравнимое решение на MS SQL. Кроме того позже планируем некоторые вещи перенести на DynamoDB.
— MSDeploy уже в печёнках сидит, если кто-то смотрел видеоролик или слушал музыку через стриминг сервис, даже стопнутый iis оставляет открытые файлы и даже если выводиш виртуалку с пула и гарантировано не имея клиентов не удаётся провести деплой обновленных сервисов. После xcopy деплоя на всякие apache, хочется удушить тех кто придумал такие костыли. Powershell, iis metadata это всё лишние вещи которые скрывают кривизну архитектуры конфигурирования iis. Не говоря о том что врубав powershell remoting wmiprvse процес за несколько часов набирал 800 Мб RAM, пришлось отказатся от PowerShell вообще(Есть хотфикс но он не решает проблему, без него wmiprvse течёт до 2Гб после чего падает от нехватки памяти). Если бы було всё так хорошо, MS в Azure не создавали свой конфигурационный ферйворк, который делает несколько попыток задеплоить тем же msdeploy.
К тому же MS Deploy не решает проблему конфигурирования, мне нужно чтобы после деплоя машина соответственно своей роли получила некоторуюю конфигурацию. IIS Web Farm Framework не подошол, а так как у нас Amazon, то пришлось писать свой велосипед. Есть надежда что Chef/Puppet несколько упростит задачу, но вопрос в зрелости этих инструментов на платформе Windows.
- «Есть пример что вебферма из 2х IIS (правда машинки не слабые -в сумме 16 физ.ядер) легко держит нагрузку до 50 запросов в секунду, даже не «вспотели».» — попробуйте тоже самое c 1000 открытых соединений (websocket например). Проблема еМСа. Если ваши worker не успевают освободится для следующего клиента, а запросы всё приходят, время ответа растёт экспотенциально. Предложенный воркерраунд решает проблему частично. Ладно ну подниму я балансировщиком нагрузки ещё 10 инстансов, но чёрт побери на том же самом функционале erlang/node.js потребляет в 2, 3 раза меньше ресурсов и обработывает на порядок больше клиентских запросов, а это для страртапа ощутимая экономия. Проблема не в том что он непроизводительный, а в том что соотношение обработанный запрос/исспользованые ресурсы для IIS/ASP.NET/WCF значительно хуже чем у лидеров.
«тогда надо писать в connect\фиксить.» — И что ждать следующей ОС в сентябре. Некоторые проблемы они признали и анонсировали в следующем IIS. Связка IIS — windows на самом деле играет очень плохую службу для МСа, он сейчас как IE6. В открытых проэктах делают патч и продолжают работать, С iis вам придётся жыть с заплаткой до следующего релиза, хорошо если полгода и ваша проблема признана приоритетной. Для стартапа такая политика губительна.
— Стартап не имею права показывать, так как пока закрытое бета тестирование, примерно в июле возможно выйдем на паблик.
— Express версия даже не рассматривалась, пользовательских данных значительно больше. Если у вас один сервер у вас одна точка отказа. Варианты с репликацией SQL Server и стоимость лицензирования похоронит даже устоявшуюся компанию не то что стартап. В то же время єкпертиза по MySQL настолько большая есть такое количество готовіх решений что SQL Server вообще не стоит рассматривать всерёз, это простая экономика и пусть mysql connector не имеет встроенного оператора IN и имеет ряд других проблем, их то обойти можно, но он нам обходится на два-три порядка дешевле чем сравнимое решение на MS SQL. Кроме того позже планируем некоторые вещи перенести на DynamoDB.
— MSDeploy уже в печёнках сидит, если кто-то смотрел видеоролик или слушал музыку через стриминг сервис, даже стопнутый iis оставляет открытые файлы и даже если выводиш виртуалку с пула и гарантировано не имея клиентов не удаётся провести деплой обновленных сервисов. После xcopy деплоя на всякие apache, хочется удушить тех кто придумал такие костыли. Powershell, iis metadata это всё лишние вещи которые скрывают кривизну архитектуры конфигурирования iis. Не говоря о том что врубав powershell remoting wmiprvse процес за несколько часов набирал 800 Мб RAM, пришлось отказатся от PowerShell вообще(Есть хотфикс но он не решает проблему, без него wmiprvse течёт до 2Гб после чего падает от нехватки памяти). Если бы було всё так хорошо, MS в Azure не создавали свой конфигурационный ферйворк, который делает несколько попыток задеплоить тем же msdeploy.
К тому же MS Deploy не решает проблему конфигурирования, мне нужно чтобы после деплоя машина соответственно своей роли получила некоторуюю конфигурацию. IIS Web Farm Framework не подошол, а так как у нас Amazon, то пришлось писать свой велосипед. Есть надежда что Chef/Puppet несколько упростит задачу, но вопрос в зрелости этих инструментов на платформе Windows.
- «Есть пример что вебферма из 2х IIS (правда машинки не слабые -в сумме 16 физ.ядер) легко держит нагрузку до 50 запросов в секунду, даже не «вспотели».» — попробуйте тоже самое c 1000 открытых соединений (websocket например). Проблема еМСа. Если ваши worker не успевают освободится для следующего клиента, а запросы всё приходят, время ответа растёт экспотенциально. Предложенный воркерраунд решает проблему частично. Ладно ну подниму я балансировщиком нагрузки ещё 10 инстансов, но чёрт побери на том же самом функционале erlang/node.js потребляет в 2, 3 раза меньше ресурсов и обработывает на порядок больше клиентских запросов, а это для страртапа ощутимая экономия. Проблема не в том что он непроизводительный, а в том что соотношение обработанный запрос/исспользованые ресурсы для IIS/ASP.NET/WCF значительно хуже чем у лидеров.
«тогда надо писать в connect\фиксить.» — И что ждать следующей ОС в сентябре. Некоторые проблемы они признали и анонсировали в следующем IIS. Связка IIS — windows на самом деле играет очень плохую службу для МСа, он сейчас как IE6. В открытых проэктах делают патч и продолжают работать, С iis вам придётся жыть с заплаткой до следующего релиза, хорошо если полгода и ваша проблема признана приоритетной. Для стартапа такая политика губительна.
— Стартап не имею права показывать, так как пока закрытое бета тестирование, примерно в июле возможно выйдем на паблик.
Требования понятны, при такой формулировке — да, не до экспресса (будет здорово если при выходе вы таки наберете этот миллион, но это не техническая сторона вопроса)
Ну в asp.net тоже Xcopy deploy, но похоже у вас остаются зомбики которые держат файлы. Печально и знакомо. Мы пока на тестовом с этим не боремся
Про PoSh — да, сталкивался, на длительных задачах течет тоже.
Про открытые сокеты — это задачка не обработать х запросов, а удержать Х открытых соединений. Там с этим реально проблемы — пул asp.net — местами печальная штука. В этом месте — печальная. Сами наткнулись когда делали push нотификации ( правда мы в итоге сократили задачу и проблемы не возникли).
В целом — ваши задачи не очень стартапские имхо. Т.е. вы вполне серьезно запарились с производительностью и масштабированием. Обычно для стартапов характерен обратный подход — не паримся и пользуем амазон — не взлетело, тратимся по-минимуму, взлетело — поднимем кучу копий быстро и стандартно. Как только взлетело — тратимся на масштабируемость по-честному.
Ну что ж, удачи. Возможно Ажур действительно вам не подходит — не тот инструмент, чтобы решить эту задачу и таким способом…
Ну в asp.net тоже Xcopy deploy, но похоже у вас остаются зомбики которые держат файлы. Печально и знакомо. Мы пока на тестовом с этим не боремся
Про PoSh — да, сталкивался, на длительных задачах течет тоже.
Про открытые сокеты — это задачка не обработать х запросов, а удержать Х открытых соединений. Там с этим реально проблемы — пул asp.net — местами печальная штука. В этом месте — печальная. Сами наткнулись когда делали push нотификации ( правда мы в итоге сократили задачу и проблемы не возникли).
В целом — ваши задачи не очень стартапские имхо. Т.е. вы вполне серьезно запарились с производительностью и масштабированием. Обычно для стартапов характерен обратный подход — не паримся и пользуем амазон — не взлетело, тратимся по-минимуму, взлетело — поднимем кучу копий быстро и стандартно. Как только взлетело — тратимся на масштабируемость по-честному.
Ну что ж, удачи. Возможно Ажур действительно вам не подходит — не тот инструмент, чтобы решить эту задачу и таким способом…
Задайте эти вопросы разработчикам SO.
Ответ здесь habrahabr.ru/post/142207/#comment_4760286
stackoverflow никогда не был стартапом в том смысле который его представляет большинство. Его не делали полуголодные студенты ночами в гараже. У авторов был работающий бизнес излишек мощностей и готовые наработки.
stackoverflow никогда не был стартапом в том смысле который его представляет большинство. Его не делали полуголодные студенты ночами в гараже. У авторов был работающий бизнес излишек мощностей и готовые наработки.
Стартапы это не только веб, кстати.
Незаслуженно обойдено наличие хороших портов .net-postgresql и mono, т.е. развертывание под .net можно сделать практически бесплатным, было бы желание.
Незаслуженно обойдено наличие хороших портов .net-postgresql и mono, т.е. развертывание под .net можно сделать практически бесплатным, было бы желание.
Имея опыт разработки на php, Ruby, Python и пр. пришлось окунуться в мир .Net, в частности MVC3.
По результатам 2 месяцев разработки и спустя реализованный проект сформировалось некоторое видение, чем я и хочу с вами поделиться.
Мнение чисто субъективное, я признаю, что я мог что-то не понять или понять не так.
Больше всего лучей поноса хочется послать в сторону Entity Framework.
Я использовал Code First подход. Описываешь модели, добавляешь их в контекст, немного магии, и оно все работает.
Но в текущей версии Entity Framework отсутствует понятие миграций базы данных, в виде привычном после рельсов и тд и тп.
Можно настроить пересоздание базы с чистого листа, при изменении в моделях, что терпимо на этапе разработки (если убить по дня на написание seed кода). В бою с этим вообще печаль.
Альтернативный подход это построить модели на основе готовой БД. И при каждом изменении структуры все весело перестраивать ручками.
И более всего поражают существенные различия в АПИ двух подходов, которые не позволяют безболезненно переключиться с одного подхода на другой.
ИМХО MVC это некая попытка вскочить на подножку проезжающего мимо поезда современных средств разработки (Rails, Django и т.д.)
Для .Net это может и является глотком свежего воздуха, но для меня многое кажется странным и пахнет индусами.
Сообщество и документация, наличие внятных примеров тоже оставляет желать лучшего.
По результатам 2 месяцев разработки и спустя реализованный проект сформировалось некоторое видение, чем я и хочу с вами поделиться.
Мнение чисто субъективное, я признаю, что я мог что-то не понять или понять не так.
Больше всего лучей поноса хочется послать в сторону Entity Framework.
Я использовал Code First подход. Описываешь модели, добавляешь их в контекст, немного магии, и оно все работает.
Но в текущей версии Entity Framework отсутствует понятие миграций базы данных, в виде привычном после рельсов и тд и тп.
Можно настроить пересоздание базы с чистого листа, при изменении в моделях, что терпимо на этапе разработки (если убить по дня на написание seed кода). В бою с этим вообще печаль.
Альтернативный подход это построить модели на основе готовой БД. И при каждом изменении структуры все весело перестраивать ручками.
И более всего поражают существенные различия в АПИ двух подходов, которые не позволяют безболезненно переключиться с одного подхода на другой.
ИМХО MVC это некая попытка вскочить на подножку проезжающего мимо поезда современных средств разработки (Rails, Django и т.д.)
Для .Net это может и является глотком свежего воздуха, но для меня многое кажется странным и пахнет индусами.
Сообщество и документация, наличие внятных примеров тоже оставляет желать лучшего.
Миграция уже появилась в EF 4.3. Что же касается самого фреймворка, то на мой взгляд он исполнен весьма качественно и мало чем уступает ROR. Так же здесь нужно учитывать наличие Visual Studio, подобного чему на рельсах и в Django не имеется.
Так же здесь нужно учитывать наличие Visual Studio, подобного чему на рельсах и в Django не имеется.
Ещё год назад я бы с вами согласился. Если для питона был хотя бы Wing IDE и Activestate Komodo, то для Ruby ситуация была печальнее. Но с последними версиями PyCharm, WebStorm, RubyMine мне студии не нужно. Да и менее ресерсоёмкие они.
Ещё год назад я бы с вами согласился. Если для питона был хотя бы Wing IDE и Activestate Komodo, то для Ruby ситуация была печальнее. Но с последними версиями PyCharm, WebStorm, RubyMine мне студии не нужно. Да и менее ресерсоёмкие они.
Нда ну и «перевод»
Sign up to leave a comment.
Должен ли ты использовать .Net для своего стартапа?