Программирование состоит из манипуляций с кодом и обдумывании.
Не набивка — а огромное число перемещений, небольших или больших правок. Но вовсе не из: думал 7 часов не прикасаясь к клавиатуре, потом за 1 час все набил
Если верить статье то инвестор надеялся что ему предложат готовый продукт доведенный до товарного вида и с кучей потенциальных заказчиков, а он только «бабло стричь будет».
Это чуть ли не самая распространенная болезнь у ищущих инвестиций. Носители идей что носятся со своими идеями — себя и свою идею часто переоценивают.
От того что у вас есть идея — не значит что она у вас хорошая и не значит что вы способны ее реализовать.
Если ваша идея кажется вам гениальной — рискните и первый этап финансирования своей идеи осуществите за свой счет.
Это мигом отсекает кучу фантазеров и жуликов. Никто не желает рисковать собственными деньгами.
Дело инвесторов — присоединиться к проекту на этапе когда вы уже показали что можете
Если верить статье то инвестор надеялся что ему предложат готовый продукт доведенный до товарного вида и с кучей потенциальных заказчиков, а он только «бабло стричь будет».
Ошибаетесь
Даже готовый продукт ни дает никаких гарантий заработка
Всегда считал Wordpress жертвой своей популярности. Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности
Да хоть в 100 раз. Любой программист средней руки может написать узкоспециализированное решение, которое будет летать.
Это решение будет летать в своей специализированной задаче. И только в ней. Расширение же функционала или переориентация узкоспециализированной системы — обходятся недешево. И что намного важнее — изменения вносятся недостаточно быстро.
С коннекторами в гошке, к сожалению, у сфинкса — грусно.
Нативный не поддерживает многопотчку и падает при конкурентных запросах из нескольких потоков (казалось бы, что в 2017 году это базовый фунционал), не говоря уж об коннекшн пулинге…
Коннектор через протокол MySQL — просто отказался работать с ошибкой
БД можете сделать а коннектор починить нет?
И вместо этого соорудили новую БД, не разобравшишь ни со Сфинксом ни с Эластиком?
Как программист я вас понимаю.
Но менеджеру за вашу не эффективность я бы всыпал люлей
С Эластиком — вполне ожидаемая плата за хорошую работу распределенки. Жаль что вы этого не понимаете, хотя и пытаетесь что то для черьезных вещей разрабатывать
На год назад Сфинкс 2 было актуальным. И с коннекторами под Go — порядок.
SQL хранилище там не требуется для отдачи вообще. Для индексации SQL хранилище опционально.
Ну то есть вам очень хотелось сделать свой велосипед, вы даже не вникнули в аналоги. Ни в Сфинкс ни в Эластик. Ограничились дефолтными настройками?
Вау! Получили 15к RPS на том же железе, с теми же условиями, где Elastic давал 500.
Все тормоза Эластика — от автоматического распределения данных по кластеру.
Без этого — есть уже быстрое решение на C написанное. Sphinx называется.
На конференции Highload был доклад Ivi. Почему они перешли с Sphinx на ElasticShearch. Там рассказано что производительность у Elastic ниже чем у Сфинкса. Но они решели это уменьшением размера ответа — в терминах SQL это limit в запросе в 200 строк. При 1500 строках Сфинкс существенно шустрее Эластика
10М пользователей может дать сотни тысяч RPS на всю систему.
Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш
Постгрес даже по записи держит 100 000 при включенной отложенной записи. Не то что по чтению.
Кэширование в любом случае применять стоит на всякий случай.
Но вот это ваше "нагрузку в 100к даже близко нельзя подпускать к Постгрес" — откровенно коробит и выдает в вас специалистов, не вникающих в инструменты с которыми работаете
Я думаю, как раз в России такие вещи привычнее и чаще решаются с помощью «права справедливости», а не писаного закона. Если правообладатель получил за экземпляр программы её полную стоимость (речь об 1С, например), ему какая разница, ломаный там будет эмулятор или нет, — если из однопользовательской программы не пытаются делать сервер.
Отнюдь.
Именно в РФ именно такая ситуация и закреплена в законе явно. То есть купив программу вы можете её крякать. Это совершенно законно. Но только если это не превращает программу в её более дорогую версию.
В США это совсем не так. Более то, по американскому "закону об защите прав в цифровую эпоху" вы сильно подставитесь перед правообладателем. И вам останется уповать только на упомянутое вами "право справедливости"
Особо никак. Только по референсам и по своему опыту сотрудничества с ним. Сертификат экспертные знания в общем случае никак не подтверждает, это просто индикатор того, что человек был на курсах и сдавал экзамен.
Я сталкивался с прямо обратной ситуацией.
Хозяин фирмы сам был эксперт. Но без сертификата.
У него был сотрудник с сертификатом. Так вот этот с сертификатом был напротив не лучшим а одним из худших спецов.
Держали только потому что поставщик требовал сертифицированного спеца в штате
Кстати такой вопрос. Тут пишут про большое количество «конфликтов интересов», а что мешает людям поменять амазон на азюр от мелкомягких? Или там вообще не принято азур считать за вариант?
Vendor lock.
Чтобы максимально эффективно использовать облака — нужно заточиться под конкретного поставщика. А даже у разных поставщиков на казалось бы стандартном OpenStack есть свои особенности.
Сравнительно недавно появилось ПО которое хорошо сглаживает vendor lock, например Kubernetes. Но и он опять таки не позволяет полностью учитывать все нюансы облака конкретного. Например как к Kubernetes прикрутить AWS Lambda и чем ее заменить при переезде на Azure?
Мы уже год или два приняли решение что неплохо съехать бы с Google AppEngine.
Но столкнулись с тем что объем переписки кода будет столь велик что целесообразно будет заодно вообще всю систему в корне переделать заодно.
Не каждая компания может держать узкого специалиста по виртуализации
Вообще то двух как минимум.
Держать сердце предприятия под надзором одного-единственного человека который может заболеть, попасть под машину, уволиться, запить, обидеться/саботировать, чего то не знать в отдельных важных аспектах — довольно рисковано
А два высококвалифицированных спеца — это довольно дорого. Особенно если учесть что они не всегда будут хорошо нагружены/"утилизированы"
Заголовок не соответствует. Компании не покидают облака, а переезжают в частные.
Если вы не купите железа то никакого масштабированя в вашем облаке не будет.
Поэтому то что вы называете частным облаком — является таковы только с точки зрения какого нибудь микросервиса который легко отмасштабируется внутри вашего облака.
Но с точки зрения всей системы — у нее отсутствует основной признак облака: простая расширяемость/перестройка структуры без капитальных затрат.
Большинство говорит так: скажите какая у Вас СХД, мы купим такую-же и Вы у нас ее арендуете
Все последние расчеты говорили что через примерно 3 года оплаты, стоимость аренды равна стоимости покупки целиком всего комплекта оборудования.
Для кого-то это плюс, а для нас при рабочем сроке серверного оборудования в 5-6 лет, это 50% убытка от IAAS решения.
Чтобы оценить стоимость облаков — нужно учесть еще и свой персонал обслуживающий и работы по разворачиванию и поддержке системы.
Статья не показывает правильные акценты.
Компании из статей были согласны платить за железо в облаках больше чем за свое чтобы не заморачиваться с покупкой/размещением/настройкой/поддержкой и с повтором этого при расширении. Плюс непонятно какое нужно оборудование под перспективы роста — таким образом риски по закупке оборудование под рост остались на облаке
Вместо этого компании из статьи сосредоточили свои ресурсы на разработке. В частности кому кому а уж Ватсапу и Дропбоксу выйгранное время дало очень много. Вплоть до самого факта существования этих компаний сейчас.
То есть тут дело вовсе не цене оборудования.
Дело в том что живя в облаке вы получаете гибкость/время. Переносите часть рисков на облако. А сами сосредотачиваетесь на своем основном бизнесе. Но никто не обещал что облака выгодны всегда и для всех. Маркетологи умалчивают эти моменты. Но мы то с вами на то и профи чтобы понять самим где и что выгоднее
Программирование состоит из манипуляций с кодом и обдумывании.
Не набивка — а огромное число перемещений, небольших или больших правок. Но вовсе не из: думал 7 часов не прикасаясь к клавиатуре, потом за 1 час все набил
Это столь удивительный факт — SSD во конце второго десятилетия 21 века?
Это чуть ли не самая распространенная болезнь у ищущих инвестиций. Носители идей что носятся со своими идеями — себя и свою идею часто переоценивают.
От того что у вас есть идея — не значит что она у вас хорошая и не значит что вы способны ее реализовать.
Если ваша идея кажется вам гениальной — рискните и первый этап финансирования своей идеи осуществите за свой счет.
Это мигом отсекает кучу фантазеров и жуликов. Никто не желает рисковать собственными деньгами.
Дело инвесторов — присоединиться к проекту на этапе когда вы уже показали что можете
Ошибаетесь
Даже готовый продукт ни дает никаких гарантий заработка
Да хоть в 100 раз. Любой программист средней руки может написать узкоспециализированное решение, которое будет летать.
Это решение будет летать в своей специализированной задаче. И только в ней. Расширение же функционала или переориентация узкоспециализированной системы — обходятся недешево. И что намного важнее — изменения вносятся недостаточно быстро.
БД можете сделать а коннектор починить нет?
И вместо этого соорудили новую БД, не разобравшишь ни со Сфинксом ни с Эластиком?
Как программист я вас понимаю.
Но менеджеру за вашу не эффективность я бы всыпал люлей
Инвестор как раз знает. Не инвестировать в треш. Но просители инвестиций считают инвесторов лохами для разводки, если верить статье
Да ладно?
Конкурения в ех-СССР меньше. Бабло поднять проще.
Или для вас тот кто не обул инвесторов на миллиард — не стартапер? Тут я вынужден согласиться, действительно, миллиардами в ех-СССР мало кто рискует.
На год назад Сфинкс 2 было актуальным. И с коннекторами под Go — порядок.
SQL хранилище там не требуется для отдачи вообще. Для индексации SQL хранилище опционально.
Ну то есть вам очень хотелось сделать свой велосипед, вы даже не вникнули в аналоги. Ни в Сфинкс ни в Эластик. Ограничились дефолтными настройками?
Все тормоза Эластика — от автоматического распределения данных по кластеру.
Без этого — есть уже быстрое решение на C написанное. Sphinx называется.
На конференции Highload был доклад Ivi. Почему они перешли с Sphinx на ElasticShearch. Там рассказано что производительность у Elastic ниже чем у Сфинкса. Но они решели это уменьшением размера ответа — в терминах SQL это limit в запросе в 200 строк. При 1500 строках Сфинкс существенно шустрее Эластика
Постгрес даже по записи держит 100 000 при включенной отложенной записи. Не то что по чтению.
Кэширование в любом случае применять стоит на всякий случай.
Но вот это ваше "нагрузку в 100к даже близко нельзя подпускать к Постгрес" — откровенно коробит и выдает в вас специалистов, не вникающих в инструменты с которыми работаете
Вывод: хакеры плохо зарабатывают.
Ведь у лучших программистов зарплаты отличаются от средник поболее чем 2.7 раза
Прямо сейчас посмотрел у Адобы про Фотошоп:
644 рубля в месяц. Без НДС.
Только не глянул — для частных лиц или на фирмы тоже распространяется
Отнюдь.
Именно в РФ именно такая ситуация и закреплена в законе явно. То есть купив программу вы можете её крякать. Это совершенно законно. Но только если это не превращает программу в её более дорогую версию.
В США это совсем не так. Более то, по американскому "закону об защите прав в цифровую эпоху" вы сильно подставитесь перед правообладателем. И вам останется уповать только на упомянутое вами "право справедливости"
Я сталкивался с прямо обратной ситуацией.
Хозяин фирмы сам был эксперт. Но без сертификата.
У него был сотрудник с сертификатом. Так вот этот с сертификатом был напротив не лучшим а одним из худших спецов.
Держали только потому что поставщик требовал сертифицированного спеца в штате
Vendor lock.
Чтобы максимально эффективно использовать облака — нужно заточиться под конкретного поставщика. А даже у разных поставщиков на казалось бы стандартном OpenStack есть свои особенности.
Сравнительно недавно появилось ПО которое хорошо сглаживает vendor lock, например Kubernetes. Но и он опять таки не позволяет полностью учитывать все нюансы облака конкретного. Например как к Kubernetes прикрутить AWS Lambda и чем ее заменить при переезде на Azure?
Мы уже год или два приняли решение что неплохо съехать бы с Google AppEngine.
Но столкнулись с тем что объем переписки кода будет столь велик что целесообразно будет заодно вообще всю систему в корне переделать заодно.
Вообще то двух как минимум.
Держать сердце предприятия под надзором одного-единственного человека который может заболеть, попасть под машину, уволиться, запить, обидеться/саботировать, чего то не знать в отдельных важных аспектах — довольно рисковано
А два высококвалифицированных спеца — это довольно дорого. Особенно если учесть что они не всегда будут хорошо нагружены/"утилизированы"
Если вы не купите железа то никакого масштабированя в вашем облаке не будет.
Поэтому то что вы называете частным облаком — является таковы только с точки зрения какого нибудь микросервиса который легко отмасштабируется внутри вашего облака.
Но с точки зрения всей системы — у нее отсутствует основной признак облака: простая расширяемость/перестройка структуры без капитальных затрат.
Чтобы оценить стоимость облаков — нужно учесть еще и свой персонал обслуживающий и работы по разворачиванию и поддержке системы.
Статья не показывает правильные акценты.
Компании из статей были согласны платить за железо в облаках больше чем за свое чтобы не заморачиваться с покупкой/размещением/настройкой/поддержкой и с повтором этого при расширении. Плюс непонятно какое нужно оборудование под перспективы роста — таким образом риски по закупке оборудование под рост остались на облаке
Вместо этого компании из статьи сосредоточили свои ресурсы на разработке. В частности кому кому а уж Ватсапу и Дропбоксу выйгранное время дало очень много. Вплоть до самого факта существования этих компаний сейчас.
То есть тут дело вовсе не цене оборудования.
Дело в том что живя в облаке вы получаете гибкость/время. Переносите часть рисков на облако. А сами сосредотачиваетесь на своем основном бизнесе. Но никто не обещал что облака выгодны всегда и для всех. Маркетологи умалчивают эти моменты. Но мы то с вами на то и профи чтобы понять самим где и что выгоднее