Comments 25
А российские разработки есть?
>> А вы слышали о том, что Azure готовится к выходу на Linux платформу? По правде говоря, пока это только слухи, но вы только представьте какой кусок «облачного» пирога откусит Microsoft.
Уже не слухи. habrahabr.ru/post/145471/
Уже не слухи. habrahabr.ru/post/145471/
Не, ну видно же, что обзор заказан MS. Над же, поставить azure на 3-е место, а salesforce — на 7-е!
Хороший знакомый, работающий в Microsoft в США нахваливал этот сервис не меньше «родного» Azure: http://heroku.com
Индусы, на индийской ленте новостей сделали обзор после консультаций с астрологом — не иначе, конечно надо опубликовать его на хабре. Ни одного факта в рейтинге нет — блеск.
Прежде чем пилить подобные обзоры, я стараюсь всегда посмотреть, не будет ли в ближайшем будущем крупных пачек анонсов от рассматриваемых вендоров. Так и тут — у MS был, по сути, перезапуск платформы с введением большого количества фич, через три дня после выпуска этого обзора. Соответственно, обзор устарел через три дня после выхода, о чем говорит ремарка про Linux.
IBM? EMC?
Наличие Red Hat в нашем списке, может вызывать у вас спорные чувства, поскольку многие, мягко говоря, не симпатизируют этой компании,WTF? Спорные чувства вызывает вот эта фраза. Написана ерунда. Силами Red Hat разрабатывается почти весь апстрим Open Source, не симпатизировать могут только ярые ненавистники СПО.
UFO just landed and posted this here
Мой личный рейтинг:
1. Amazon Web Services
и с большим отставанием
2. Heroku
3. Azure
4. Google App Engine
И это при том что я .NET разработчик. Azure-у ещё клепать и клепать чтобы догнать Amazon, а главное догнать мало, нужны killer особенности, которых не будет у конкурента.
1. Amazon Web Services
и с большим отставанием
2. Heroku
3. Azure
4. Google App Engine
И это при том что я .NET разработчик. Azure-у ещё клепать и клепать чтобы догнать Amazon, а главное догнать мало, нужны killer особенности, которых не будет у конкурента.
они уже есть.
WebSites + Git Deployment
Ну и вообще — качественный Deploy Azure проектов, стабильность (инстанс никогда не «умрет», потому что всегда есть его копии, с амазоном легко попасть на деградирующее железо).
Ну и все же Azure дешевле обходится. Особенно в самом начале.
Простой пример — делал я проект для амазона. И для тестов делаем Micra instance, ставим на него дополнительно SQL (платить на момент разработки не хочется...), работаем несколько месяцев, а потом решаемся запускаться.
Если ничего не меняем — падаем при первом же хабра-эффекте.
Если начинаем разносить по разным инстанс, то перенастройка среды займет пару дней (вынести SQL на отдельный сервер, перенастроить конфиги, перенастроить бэкап-образ для Cloud-formation, перенастроить сам cloud formation, подключить load-balancer).
А в azure — SQL всегда внешний. Стоит немного, а если есть Bizspark или MSDN — вообще все бесплатно. И ничего перенастраивать не надо.
Я по этому .Net проекты стараюсь в Azure запихивать…
WebSites + Git Deployment
Ну и вообще — качественный Deploy Azure проектов, стабильность (инстанс никогда не «умрет», потому что всегда есть его копии, с амазоном легко попасть на деградирующее железо).
Ну и все же Azure дешевле обходится. Особенно в самом начале.
Простой пример — делал я проект для амазона. И для тестов делаем Micra instance, ставим на него дополнительно SQL (платить на момент разработки не хочется...), работаем несколько месяцев, а потом решаемся запускаться.
Если ничего не меняем — падаем при первом же хабра-эффекте.
Если начинаем разносить по разным инстанс, то перенастройка среды займет пару дней (вынести SQL на отдельный сервер, перенастроить конфиги, перенастроить бэкап-образ для Cloud-formation, перенастроить сам cloud formation, подключить load-balancer).
А в azure — SQL всегда внешний. Стоит немного, а если есть Bizspark или MSDN — вообще все бесплатно. И ничего перенастраивать не надо.
Я по этому .Net проекты стараюсь в Azure запихивать…
> Bizspark или MSDN
MSDN — для большого продакшина не хватит.
Bizspark — подойдёт только для стартапа и не всякого.
У Amazon есть Free Usage Tier если уж на то пошло. А MSDN подписка денег стоит и немалых, за эти деньги AWS несколько лет можно оплатить.
Если под SQL вы понимаете MS SQL, то для нагруженых сервисов он тоже не годится. Под MySQL есть тонны хорошо проверенных решений, которые достаточно быстро поднимаются и позволяют реализовать самые разные стратегии маштабирования, под MS SQL есть 2 или 3 whitepapers с кучей воды и выводом что даже с кучей бабла у вас ничего большого не выйдет. Ну, а аналога Dynamo DB c гарантированым откликом в Azure пока нет.
> качественный Deploy Azure проектов,
Ну я бы качественным этот Deploy неназвал. Microsoft просто спрятала все косяки IIS для вас за большим количеством попыток. Если смотреть немного шире, то Amazon предлагает нормальный деплой для Java, PHP уже давно, и недавно также для .NET, но я его ещ' не пробовал. В резульате я мого в одном решении исспользовать и Ellastic Search и ASP.NET WebAPI/Silverlight.
Ну и проблема деплоя проблема тут с кривой архитектурой IIS и .net деплоя. До появления Azure MS вообще не задумывалась как опубликовать тоже приложение на сотнях инстансах IIS. WebDeploy плохо приспособлены к этому. WebConfig будет у вас один. Пришлось писать своё расширение для Chef которое положит правильный конфиг для сервиса. Ну и что достаёт больше всего, произвольное падение WebDeploy из-за кокого-то заблокированого файла, даже при чистом iis.
> инстанс никогда не «умрет»
Если вы не настроиили Load Balancer и мониторинг, то будет у вас умирать. Я так подозреваю что если вам нужны пользовательские метрики «живучести сервиса», то и Azure нужно настраивать. Для Амазона разработка продакшин решения заняла менее чем пол дня и решилась иссключительно маленьким скриптом. И вообще это задача для operation team.
> вынести SQL на отдельный сервер
То есть вы исспользуете AWS/Azure как банальный VPS. В любом чуть большем проэкте SQL Server жывёт на своём инстансе, просто потому что помяти хочет много и конкурирует за диск.
Кстати буквально несколько недель или дней назад(не помню даты письма) Amazon запустил RDS и для SQL Server, так что MS SQL или Oracle или MySQL будет для вас всегда внешний, и Free Usage Tier на него тоже расспространяется.
Итого из вашего объяснения я так понял что о том как маштабировать сервис вы сначала не задумываетесь и разница с Azure разве в том что некоторые вещи он от вас прячет, тот же LoadBalancer для AppFabric, прозрачный инстанс SQL Server и для вас создаётся ощущение более лёгкой настройки. Для ваших решений это работает. Для моего бывшего проэкта более 100 разных инстансов, .net/java AWS давала существеную экономию.
MSDN — для большого продакшина не хватит.
Bizspark — подойдёт только для стартапа и не всякого.
У Amazon есть Free Usage Tier если уж на то пошло. А MSDN подписка денег стоит и немалых, за эти деньги AWS несколько лет можно оплатить.
Если под SQL вы понимаете MS SQL, то для нагруженых сервисов он тоже не годится. Под MySQL есть тонны хорошо проверенных решений, которые достаточно быстро поднимаются и позволяют реализовать самые разные стратегии маштабирования, под MS SQL есть 2 или 3 whitepapers с кучей воды и выводом что даже с кучей бабла у вас ничего большого не выйдет. Ну, а аналога Dynamo DB c гарантированым откликом в Azure пока нет.
> качественный Deploy Azure проектов,
Ну я бы качественным этот Deploy неназвал. Microsoft просто спрятала все косяки IIS для вас за большим количеством попыток. Если смотреть немного шире, то Amazon предлагает нормальный деплой для Java, PHP уже давно, и недавно также для .NET, но я его ещ' не пробовал. В резульате я мого в одном решении исспользовать и Ellastic Search и ASP.NET WebAPI/Silverlight.
Ну и проблема деплоя проблема тут с кривой архитектурой IIS и .net деплоя. До появления Azure MS вообще не задумывалась как опубликовать тоже приложение на сотнях инстансах IIS. WebDeploy плохо приспособлены к этому. WebConfig будет у вас один. Пришлось писать своё расширение для Chef которое положит правильный конфиг для сервиса. Ну и что достаёт больше всего, произвольное падение WebDeploy из-за кокого-то заблокированого файла, даже при чистом iis.
> инстанс никогда не «умрет»
Если вы не настроиили Load Balancer и мониторинг, то будет у вас умирать. Я так подозреваю что если вам нужны пользовательские метрики «живучести сервиса», то и Azure нужно настраивать. Для Амазона разработка продакшин решения заняла менее чем пол дня и решилась иссключительно маленьким скриптом. И вообще это задача для operation team.
> вынести SQL на отдельный сервер
То есть вы исспользуете AWS/Azure как банальный VPS. В любом чуть большем проэкте SQL Server жывёт на своём инстансе, просто потому что помяти хочет много и конкурирует за диск.
Кстати буквально несколько недель или дней назад(не помню даты письма) Amazon запустил RDS и для SQL Server, так что MS SQL или Oracle или MySQL будет для вас всегда внешний, и Free Usage Tier на него тоже расспространяется.
Итого из вашего объяснения я так понял что о том как маштабировать сервис вы сначала не задумываетесь и разница с Azure разве в том что некоторые вещи он от вас прячет, тот же LoadBalancer для AppFabric, прозрачный инстанс SQL Server и для вас создаётся ощущение более лёгкой настройки. Для ваших решений это работает. Для моего бывшего проэкта более 100 разных инстансов, .net/java AWS давала существеную экономию.
Если не секрет, поделитесь стратегией в Амазоне — по какой логике делили на инстансы, как добивались отказоустойчивости и т. п.
Єдиной стратегии нет и быть не может. Есть типовые примеры рекомендованых архитектур от Amazon, но всё одно, это довольно индивидуальные вещи:
1. Какие объёмы пользовательских данных вы собираетесь обрабатывать,
2. с какой скоростью, как достичь приемлемой для конечного польхователя визуальной скорости обработки.
3. Индивидуальные особености платформы разработки(Я люблю .net, но деплоймент на iis это какая-то рулетка, примерно 25-30% деплойментов падают с непонятными ошибками).
ELB <-> EC2 <-> S3
EC2 <-> RDS
EC2 <-> DynamoDB (иерерхические запроы начали летать)
CloudWatch + custom metrics (привет App Pool с WF под IIS которые могут отожрать всю машину) + AutoScaling
CloudFront оказался не нужен, для наших данных задержка отдачи контента клиентам была несущественна.
EllasticCache тоже не нужен, вместо него исспользуется для схожих целей DynamoDB.
Было желание подключить WebSockets/Long polling, но это уже без меня, и пока не решились отказатся от ELB в пользу своего балансера.
1. Какие объёмы пользовательских данных вы собираетесь обрабатывать,
2. с какой скоростью, как достичь приемлемой для конечного польхователя визуальной скорости обработки.
3. Индивидуальные особености платформы разработки(Я люблю .net, но деплоймент на iis это какая-то рулетка, примерно 25-30% деплойментов падают с непонятными ошибками).
ELB <-> EC2 <-> S3
EC2 <-> RDS
EC2 <-> DynamoDB (иерерхические запроы начали летать)
CloudWatch + custom metrics (привет App Pool с WF под IIS которые могут отожрать всю машину) + AutoScaling
CloudFront оказался не нужен, для наших данных задержка отдачи контента клиентам была несущественна.
EllasticCache тоже не нужен, вместо него исспользуется для схожих целей DynamoDB.
Было желание подключить WebSockets/Long polling, но это уже без меня, и пока не решились отказатся от ELB в пользу своего балансера.
Sign up to leave a comment.
10 самых влиятельных компаний в Cloud Computing